Mitch Skiba [Thu, 14 Nov 2019 19:28:23 +0000 (19:28 +0000)]
bgpd: Fix per afi/safi addpath peer counting
The total_peercount table was created as a short cut for queries about
if addpath was enabled at all on a particular afi/safi. However, the
values weren't updated, so BGP would act as if addpath wasn't enabled
when determining if updates should be sent out. The error in behavior
was much more noticeable in tx-all than best-per-as, since changes in
what is sent by best-per-as would often trigger updates even if addpath
wasn't enabled.
Donald Sharp [Mon, 18 Nov 2019 16:43:52 +0000 (11:43 -0500)]
pimd: Create pimreg interface when we start any interface config
When you configure interface configuration without explicitly
configuring pim on that interface, we were not creating the pimreg
interface and as such we would crash in an attempted register
since the pimreg device is non-existent.
The crash is this:
==8823== Invalid read of size 8
==8823== at 0x468614: pim_channel_add_oif (pim_oil.c:392)
==8823== by 0x46D0F1: pim_register_join (pim_register.c:61)
==8823== by 0x449AB3: pim_mroute_msg_nocache (pim_mroute.c:242)
==8823== by 0x449AB3: pim_mroute_msg (pim_mroute.c:661)
==8823== by 0x449AB3: mroute_read (pim_mroute.c:707)
==8823== by 0x4FC0676: thread_call (thread.c:1549)
==8823== by 0x4EF3A2F: frr_run (libfrr.c:1064)
==8823== by 0x40DCB5: main (pim_main.c:162)
==8823== Address 0xc8 is not stack'd, malloc'd or (recently) free'd
exit2-debian-9# show ip bgp ipv4 unicast dampening parameters
Half-life time: 1 min
Reuse penalty: 2
Suppress penalty: 3
Max suppress time: 4 min
Max suppress penalty: 32
exit2-debian-9# show ip bgp ipv4 multicast dampening parameters
Half-life time: 5 min
Reuse penalty: 6
Suppress penalty: 7
Max suppress time: 8 min
Max suppress penalty: 18
bgpd: Do not send next-hop as :: in MP_REACH_NLRI if no link-local exists
This is the unusual case when you have global IPv6 address and no link-local
on interface attached. Like here:
eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP
link/ether 08:00:27:65:c6:82 brd ff:ff:ff:ff:ff:ff
inet6 2a02:4780:face::1/64 scope global
valid_lft forever preferred_lft forever
Donatas Abraitis [Fri, 25 Oct 2019 10:01:02 +0000 (13:01 +0300)]
nhrp: Make sure `no ip nhrp map <something>` works as expected
We passed peer as NULL and nothing happened.
exit2-debian-9# conf
exit2-debian-9(config)# int gre1
exit2-debian-9(config-if)# ip nhrp map 1.1.1.1 local
exit2-debian-9(config-if)# ip nhrp map 2.2.2.2 3.3.3.3
exit2-debian-9(config-if)# do sh run
...
!
interface gre1
ip nhrp map 1.1.1.1 local
ip nhrp map 2.2.2.2 3.3.3.3
!
...
exit2-debian-9(config-if)# no ip nhrp map 1.1.1.1
exit2-debian-9(config-if)# do sh run
...
!
interface gre1
ip nhrp map 2.2.2.2 3.3.3.3
!
Matthew Smith [Tue, 9 Jul 2019 17:59:44 +0000 (12:59 -0500)]
bgpd: honor max prefix timer on inbound sessions
When using the maximum-prefix restart option with a BGP peer,
if the peer exceeds the limit of prefixes, bgpd causes the
connection to be closed and sets a timer. It will not attempt
to connect to that peer until the timer expires. But if the
peer attempts to connect to it before the timer expires, it
accepts the connection and starts exchanging routes again.
When accepting a connection from a peer, reject the connection
if the max prefix restart timer is set.
Signed-off-by: Matthew Smith <mgsmith@netgate.com>
Donald Sharp [Fri, 20 Sep 2019 10:41:02 +0000 (06:41 -0400)]
bgpd: Invalid NH's should send an apropriate reason code
RFC 4271 sec 6.3 p33, In the case of a BGP_NEXTHOP attribute with an
incorrect value, FRR is supposed to send a notification
and include 'Corresponding type, length and value of the NEXT_HOP
attribute in the notification data.
Fixes: #4997 Signed-off-by: Nikos <ntriantafillis@gmail.com> Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Thu, 20 Jun 2019 15:12:35 +0000 (11:12 -0400)]
bgpd: `neighbor X:X::X default-originate` complains about (null)
The `neighbor X:X::X default-originate command is complaining
that:
The route-map '(null)' does not exist.
Upon inspection of the code we were passing a NULL
string to the lookup. Testing for null gets us this:
donna.cumulusnetworks.com# conf t
donna.cumulusnetworks.com(config)# router bgp 99
donna.cumulusnetworks.com(config-router)# neighbor 2001:1::1:2 remote-as 99
donna.cumulusnetworks.com(config-router)# neighbor 2001:1::1:2 default-originate
donna.cumulusnetworks.com(config-router)# end
donna.cumulusnetworks.com# show run
Building configuration...
Current configuration:
!
frr version 7.2-dev
frr defaults datacenter
hostname donna.cumulusnetworks.com
log stdout
no ipv6 forwarding
!
ip route 4.5.6.7/32 10.50.11.4
!
router bgp 99
neighbor 2001:1::1:2 remote-as 99
!
address-family ipv4 unicast
neighbor 2001:1::1:2 default-originate
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
eva# show bgp ipv4 uni 4.4.4.4
BGP routing table entry for 4.4.4.4/32
Paths: (1 available, best #1, table default)
Advertised to non peer-group peers:
10.50.12.118
999 999 999 999
10.50.12.118 from 10.50.12.118 (10.50.12.118)
Origin incomplete, metric 0, valid, external, best (First path received)
Last update: Mon Aug 26 09:47:17 2019
eva# conf
eva(config)# route-map BLARBLE permit 10
eva(config-route-map)# no set as-path prepend last-as 3
eva(config-route-map)# end
eva# clear bgp ipv4 uni *
eva# show bgp ipv4 uni 4.4.4.4
BGP routing table entry for 4.4.4.4/32
Paths: (1 available, best #1, table default)
Advertised to non peer-group peers:
10.50.12.118
999
10.50.12.118 from 10.50.12.118 (10.50.12.118)
Origin incomplete, metric 0, valid, external, best (First path received)
Last update: Mon Aug 26 09:48:31 2019
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
bgpd: Convert to network byte order before passing value to `community_del_val`
community_val_get() returns ntohl(val) which is used in more places like
community_include(), community_add_val(), but community_del_val() is missing
back conversion htonl().
Renato Westphal [Mon, 27 May 2019 22:48:13 +0000 (19:48 -0300)]
lib: fix outdated candidate configuration issue
Even when using the classic CLI mode (i.e. when --tcli is not
used), the northbound code still uses vty->candidate_config
to perform configuration changes. From the perspective of the
user, the running configuration is being edited directly, but
under the hood the northbound layer does a full configuration
transaction for each command. When the running configuration is
edited by a northbound client other than the CLI (e.g. kernel,
gRPC), vty->candidate_config might become outdated, and this can
lead to lots of weird problems. To fix this, always regenerate
vty->candidate_config before each configuration command when
using the classic CLI mode. When using the transactional CLI,
the user needs to update the candidate manually using the "update"
command, otherwise the "commit" command will fail with this error:
"% Candidate configuration needs to be updated before commit".
Fixes some problems reported by Don after moving an interface from
one VRF to another one while zebra is running.
Reported-by: Don Slice <dslice@cumulusnetworks.com> Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Donald Sharp [Tue, 25 Jun 2019 04:30:11 +0000 (00:30 -0400)]
pimd: Dissallow query to be received from a non-connected source
When we receive an igmp query on a interface, ensure that the
source address of the packet is connected to the incoming
interface. This will prevent a meanie from crafting a igmp
packet with a source address less than ours and causing
us to suspend query activities.
Fixes: #1692 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
David Lamparter [Tue, 18 Jun 2019 04:15:21 +0000 (06:15 +0200)]
FRRouting release 7.1
- gRPC northbound plugin
- "table NNN" removed from zebra
- more dataplane MT work
- EVPN in non-default VRFs
- RFC 8212 (default deny policy for eBGP)
- RFC 8106 (IPv6 RA DNS options)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
David Lamparter [Sun, 9 Jun 2019 23:35:04 +0000 (01:35 +0200)]
tools: retain sanity when reloading under systemd
Without this, we end up restarting watchfrr with the systemd watchdog
non-functional & tripped a bit later. Also, if watchfrr is in the
"control" cgroup, systemd 232 will kill it. (241 apparently doesn't.
Can't find anything about this in systemd's ChangeLog though.)
Donald Sharp [Wed, 5 Jun 2019 01:38:11 +0000 (21:38 -0400)]
bfdd: Modify bfdd to quietly accept access-lists
The `access-list ...` command was causing bfdd to return
'unknown commands'. Make bfdd at least cognizant of
access-lists enough to not create strange error messages
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donatas Abraitis [Mon, 20 May 2019 13:43:01 +0000 (16:43 +0300)]
bgpd: Show FQDN in `show [ip] bgp` output
We already show this information in `show [ip] bgp <prefix`, thus why don't
show it in global output. It's very handy when using at scale and to see
the whole picture instead of resolving neighbor manually.
It will show FQDN only if `bgp default show-hostname` is toggled.
Martin Winter [Mon, 18 Feb 2019 15:57:24 +0000 (07:57 -0800)]
snapcraft: Disable libyang CACHE for snap package (Temp workaround)
There seems to be a bug in latest libyang running when running in
a snap container which causes a failure of the cache logic. Disable
CACHE for now as it's not yet needed. Will be re-enabled in a later
release
Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>
David Lamparter [Mon, 20 May 2019 21:41:16 +0000 (23:41 +0200)]
bgpd: use DLIST for adv_fifo
I mistakenly assumed that something called "FIFO" would primarily be
used by removing items from the front. This isn't the case for the
adv_fifo... so use a DLIST there to make sure deletions from the middle
of the queue are fast.
Issue 1:
Getting an empty json without any warning message, while executing
the command "show ip bgp neighbor <x.x.x.x> advertised-routes
json" when the bgp instance is not present or getting created.
Issue 2:
Getting an empty json without any warning message, while executing
the command "show ip bgp vrf/view <name> advertised-routes json"
when the specified view/vrf is not present.
Fix:
Display warning message while executing the above cli commands, when
the bgp instance, specified vrf is not present.
Renato Westphal [Mon, 13 May 2019 18:18:57 +0000 (15:18 -0300)]
lib: fix crash in the CLI grammar sandbox
The CLI grammer sandbox needs to initialize the northbound subsystem
otherwise the running_config global variable won't be set, which
leads to crashes.
Bug: If there are 2 different prefixes under an rd, the
output of "show bgp l2vpn evpn json" would print only one of the
prefixes.
RCA: prefix info was added to the json_object once per rd. Hence,
prefix and rd were added just once, as the loop iterated over all
the prefixes and paths.
This is related to my earlier commit that went in via PR 4283:
https://github.com/FRRouting/frr/pull/4283
Chirag Shah [Thu, 9 May 2019 19:25:44 +0000 (12:25 -0700)]
zebra: unset sticky mac upon local deletion
if the local sticky mac delete request is received,
if there are associated neighbor entries present, mac's
only local flag is removed and marked as auto mac.
this results in next local mac learning automatically assumes
mac is sticky.
There is a case when bridge learning off is configured, user
configures sticky mac via bridge fdb add.
This MAC learns associated neighbor entry.
Later user deletes stick mac via bridge fdb del, this triggers
frr to delete mac but if there are neighbors present, frr marks
MAC as AUTO but does not remove sticky flag.
User enables bridge learning on which triggers
The mac to learn as dynamic entry and in absence of this
fix, the mac is marked as sticky.
Issue1: The following json cli commands are broken (they dont display
anything):
1. show [ip] bgp l2vpn evpn json
2. show [ip] bgp l2vpn evpn all neighbors <IP> routes json
3. show [ip] bgp l2vpn evpn rd <RD> json
4. show [ip] bgp l2vpn evpn rd <RD> neighbors <IP> routes json
RCA1: The existing json_object was partially filled.
Some fields like "prefix", "prefixLen", etc were not
filled in the json_object.
RCA2: Code missing to display the constructed json_object.
Issue2: Column header not shown on bgp evpn commands.
Fix: turned on the flag to display header
Output after fix:
The above commands have been made to follow the existing output style of
"show bgp l2vpn evpn routes json"
leaf-1# sh bgp l2vpn evpn json
{
"bgpTableVersion":1,
"bgpLocalRouterId":"10.100.0.1",
"defaultLocPrf":100,
"localAS":65000,
"10.100.0.1:3":{
"rd":"10.100.0.1:3",
"[3]:[0]:[32]:[10.100.0.1]":{
"prefix":"[3]:[0]:[32]:[10.100.0.1]",
"prefixLen":288,
"paths":[
{
"valid":true,
"bestpath":true,
"pathFrom":"external",
"routeType":3,
"ethTag":0,
"ipLen":32,
"ip":"10.100.0.1",
"weight":32768,
"peerId":"(unspec)",
"aspath":"",
"path":"",
"origin":"IGP",
"nexthops":[
{
"ip":"10.100.0.1",
"afi":"ipv4",
"used":true
}
]
}
]
}
},
..........
..........
"10.100.0.2:2":{
"rd":"10.100.0.2:2",
"[3]:[0]:[32]:[10.100.0.2]":{
"prefix":"[3]:[0]:[32]:[10.100.0.2]",
"prefixLen":288,
"paths":[
{
"valid":true,
"bestpath":true,
"pathFrom":"external",
"routeType":3,
"ethTag":0,
"ipLen":32,
"ip":"10.100.0.2",
"weight":0,
"peerId":"205.0.113.2",
"aspath":"65002",
"path":"65002",
"origin":"IGP",
"nexthops":[
{
"ip":"10.100.0.2",
"afi":"ipv4",
"used":true
}
]
},
{
"valid":true,
"pathFrom":"external",
"routeType":3,
"ethTag":0,
"ipLen":32,
"ip":"10.100.0.2",
"weight":0,
"peerId":"203.0.113.4",
"aspath":"65001 65002",
"path":"65001 65002",
"origin":"IGP",
"nexthops":[
{
"ip":"10.100.0.2",
"afi":"ipv4",
"used":true
}
]
}
]
}
},
....
....
"numPrefix":10,
"totalPrefix":10
}
leaf-1# sh bgp l2vpn evpn
BGP table version is 1, local router ID is 10.100.0.1
Status codes:s suppressed, d damped, h history, * valid, > best, i - int
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: ip 10.100.0.1:3
*> [3]:[0]:[32]:[10.100.0.1]
10.100.0.1 32768 i
Route Distinguisher: ip 10.100.0.1:4
*> [3]:[0]:[32]:[10.100.0.1]
10.100.0.1 32768 i
Route Distinguisher: ip 10.100.0.1:5
*> [3]:[0]:[32]:[10.100.0.1]
10.100.0.1 32768 i
Route Distinguisher: ip 10.100.0.1:6
*> [3]:[0]:[32]:[10.100.0.1]
10.100.0.1 32768 i
Route Distinguisher: ip 10.100.0.2:2
*> [3]:[0]:[32]:[10.100.0.2]
10.100.0.2 0 65002 i
* [3]:[0]:[32]:[10.100.0.2]
10.100.0.2 0 65001 65002
Route Distinguisher: ip 10.100.0.2:3
*> [3]:[0]:[32]:[10.100.0.2]
10.100.0.2 0 65002 i
* [3]:[0]:[32]:[10.100.0.2]
10.100.0.2 0 65001 65002
Route Distinguisher: ip 10.100.0.2:4
projects / mirror / frr.git / log