Donatas Abraitis [Thu, 19 Dec 2019 20:09:47 +0000 (22:09 +0200)]
bgpd: Make sure we can use `no bgp listen range ...`
Fixes:
```
exit1-debian-9(config-router)# no bgp listen range 192.168.10.0/24 peer-group TEST
% Peer-group does not exist
exit1-debian-9(config-router)#
```
Closes https://github.com/FRRouting/frr/issues/5570
Donald Sharp [Mon, 2 Dec 2019 14:37:47 +0000 (09:37 -0500)]
bgpd: Prevent crash in bgp_table_range_lookup
The function bgp_table_range_lookup attempts to walk down
the table node data structures to find a list of matching
nodes. We need to guard against the current node from
not matching and not having anything in the child nodes.
Add a bit of code to guard against this.
Traceback that lead me down this path:
Nov 24 12:22:38 frr bgpd[20257]: Received signal 11 at 1574616158 (si_addr 0x2, PC 0x46cdc3); aborting...
Nov 24 12:22:38 frr bgpd[20257]: Backtrace for 11 stack frames:
Nov 24 12:22:38 frr bgpd[20257]: /lib64/libfrr.so.0(zlog_backtrace_sigsafe+0x67) [0x7fd1ad445957]
Nov 24 12:22:38 frr bgpd[20257]: /lib64/libfrr.so.0(zlog_signal+0x113) [0x7fd1ad445db3]1ad445957]
Nov 24 12:22:38 frr bgpd[20257]: /lib64/libfrr.so.0(+0x70e65) [0x7fd1ad465e65]ad445db3]1ad445957]
Nov 24 12:22:38 frr bgpd[20257]: /lib64/libpthread.so.0(+0xf5f0) [0x7fd1abd605f0]45db3]1ad445957]
Nov 24 12:22:38 frr bgpd[20257]: /usr/lib/frr/bgpd(bgp_table_range_lookup+0x63) [0x46cdc3]445957]
Nov 24 12:22:38 frr bgpd[20257]: /usr/lib64/frr/modules/bgpd_rpki.so(+0x4f0d) [0x7fd1a934ff0d]57]
Nov 24 12:22:38 frr bgpd[20257]: /lib64/libfrr.so.0(thread_call+0x60) [0x7fd1ad4736e0]934ff0d]57]
Nov 24 12:22:38 frr bgpd[20257]: /lib64/libfrr.so.0(frr_run+0x128) [0x7fd1ad443ab8]e0]934ff0d]57]
Nov 24 12:22:38 frr bgpd[20257]: /usr/lib/frr/bgpd(main+0x2e3) [0x41c043]1ad443ab8]e0]934ff0d]57]
Nov 24 12:22:38 frr bgpd[20257]: /lib64/libc.so.6(__libc_start_main+0xf5) [0x7fd1ab9a5505]f0d]57]
Nov 24 12:22:38 frr bgpd[20257]: /usr/lib/frr/bgpd() [0x41d9bb]main+0xf5) [0x7fd1ab9a5505]f0d]57]
Nov 24 12:22:38 frr bgpd[20257]: in thread bgpd_sync_callback scheduled from bgpd/bgp_rpki.c:351#012; aborting...
Nov 24 12:22:38 frr watchfrr[6779]: [EC 268435457] bgpd state -> down : read returned EOF
Nov 24 12:22:38 frr zebra[5952]: [EC 4043309116] Client 'bgp' encountered an error and is shutting down.
Nov 24 12:22:38 frr zebra[5952]: zebra/zebra_ptm.c:1345 failed to find process pid registration
Nov 24 12:22:38 frr zebra[5952]: client 15 disconnected. 0 bgp routes removed from the rib
I am not really 100% sure what we are really trying to do with this function, but we must
guard against child nodes not having any data.
Fixes: #5440 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Sun, 1 Dec 2019 14:29:32 +0000 (09:29 -0500)]
bgpd: Fix memory leak in json output of show commands
When dumping a large bit of table data via bgp_show_table
and if there is no information to display for a particular
`struct bgp_node *` the data allocated via json_object_new_array()
is leaked. Not a big deal on small tables but if you have a full
bgp feed and issue a show command that does not match any of
the route nodes ( say `vtysh -c "show bgp ipv4 large-community-list FOO"`)
then we will leak memory.
Before code change and issuing the above show bgp large-community-list command 15-20 times:
Memory statistics for bgpd:
System allocator statistics:
Total heap allocated: > 2GB
Holding block headers: 0 bytes
Used small blocks: 0 bytes
Used ordinary blocks: > 2GB
Free small blocks: 31 MiB
Free ordinary blocks: 616 KiB
Ordinary blocks: 0
Small blocks: 0
Holding blocks: 0
After:
Memory statistics for bgpd:
System allocator statistics:
Total heap allocated: 924 MiB
Holding block headers: 0 bytes
Used small blocks: 0 bytes
Used ordinary blocks: 558 MiB
Free small blocks: 26 MiB
Free ordinary blocks: 340 MiB
Ordinary blocks: 0
Small blocks: 0
Holding blocks: 0
Please note the 340mb of free ordinary blocks is from the fact I issued a
`show bgp ipv4 uni json` command and generated a large amount of data.
Fixes: #5445 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donatas Abraitis [Thu, 31 Oct 2019 07:53:18 +0000 (09:53 +0200)]
bgpd: Reflect the distance in RIB when it is changed for an arbitrary afi/safi
debian-9# show ip route 192.168.255.2/32 longer-prefixes
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
F - PBR, f - OpenFabric,
> - selected route, * - FIB route, q - queued route, r - rejected route
B>* 192.168.255.2/32 [20/0] via 192.168.0.1, eth1, 00:15:22
debian-9# conf
debian-9(config)# router bgp 100
debian-9(config-router)# address-family ipv4
debian-9(config-router-af)# distance bgp 123 123 123
debian-9(config-router-af)# do show ip route 192.168.255.2/32 longer-prefixes
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
F - PBR, f - OpenFabric,
> - selected route, * - FIB route, q - queued route, r - rejected route
B>* 192.168.255.2/32 [123/0] via 192.168.0.1, eth1, 00:00:09
debian-9(config-router-af)# no distance bgp
debian-9(config-router-af)# do show ip route 192.168.255.2/32 longer-prefixes
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
F - PBR, f - OpenFabric,
> - selected route, * - FIB route, q - queued route, r - rejected route
B>* 192.168.255.2/32 [20/0] via 192.168.0.1, eth1, 00:00:02
debian-9(config-router-af)#
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.
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
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
Donald Sharp [Thu, 21 Feb 2019 21:10:56 +0000 (16:10 -0500)]
zebra: Re-evaluate the nexthop tracking if flags changed
Routing protocols are allowed ( and even encouraged ) to modify
the flags that influence the nexthop tracking. As such when
we modify the tracking of a nexthop to go from, say, connected force
or not we must re-evaluate the nexthop and send the results
up to the interested parties.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com> Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
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>
exit-vrf is not working any more, so anything configured after executing this command are still configured under that VRF context.
For example: Below configuration
vrf VRF_A
ip route 11.11.11.11/32 Null0
exit-vrf
ip route 21.21.21.21/32 Null0
results in ...
vrf VRF_A
ip route 11.11.11.11/32 Null0
ip route 21.21.21.21/32 Null0
exit-vrf
!
It should have been
!
ip route 21.21.21.21/32 Null0
!
vrf VRF_A
ip route 11.11.11.11/32 Null0
exit-vrf
!
Porting https://github.com/FRRouting/frr/pull/4725 from FRR master.
Signed-off-by: Sri Mohana Singamsetty <msingamsetty@vmware.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().
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 [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.)
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 [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.
Mark Stapp [Tue, 14 May 2019 15:28:30 +0000 (11:28 -0400)]
zebra: [7.0] remove vrf LSPs when vrf is deleted
Try to remove any LSPs associated with a vrf when the vrf is
deleted. The vrf code was calling a helpful zebra_mpls api,
but that api was basically a no-op for vrfs other than
the default.
Martin Winter [Mon, 13 May 2019 11:49:49 +0000 (04:49 -0700)]
FRRouting Releast 7.0.1
Changes since 7.0:
- bgp:
- Don't send Updates with BGP Max-Prefix Overflow
- Make sure `next-hop-self all` backward compatible with force
- Fix as-path validation in "show bgp regexp"
- Fix interface-based peers to override peergroups
- Fix removing private AS numbers if local-as is used
- Fix show bgp labeled_unicast
- Add command to lookup prefixes in rpki table
- Fix peer count in "show bgp ipv6 summary"
- Add missing ipv6 only peer flag action
- Fix address family output in "show bgp [ipv4|ipv6] neighbors"
- Add missing checks for vpnv6 nexthops
- Fix nexthop for ipv6 vpn case
- rip: Fix removal of passive interfaces
- ospf:
- Fix json timer output
- Fix milliseconds in json output
- bfd:
- Fix source port according RFC 5881, Sec 4
- Fix IPv6 link-local peer removal
- Fix interface clean up when deleting interface
- pim: Fix interface clean up when deleting interface
- nhrp: Fix interface clean up when deleting interface
- lib:
- Workaround to get FRR building with libyang 0.x and 1.x
- Fix in priv handling
- Make priv elevation thread-safe
- zebra:
- Pseudowire event recovery
- Fix race condition in label manager
- Fix system routes selection and next-hop tracking
- Set connected route metric based on devaddr metric
- Display metric for connected routes
- Add selected fib details to json output
- Always use replace if installing new route
- watchfrr: Silently ignore declare failures (for backward compatibility)
- RPM packages: Switch to new init script
Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>
Renato Westphal [Mon, 6 May 2019 18:57:02 +0000 (15:57 -0300)]
lib, yang: disable libyang custom user types temporarily
libyang 1.0 introduced a few changes in the user types API, and
these changes made FRR incompatible with libyang 1.x. In order to
ease our migration from libyang 0.x to libyang 1.x, let's disable
our libyang custom user types temporarily so that FRR can work
with both libyang 0.x and libyang 1.x. This should be especially
helpful to the CI systems during the transition. Once the migration
to libyang 1.x is complete, this commit will be reverted.
Disabling our libyang custom user types should have only
minimal performance implications when processing configuration
transactions. The user types infrastructure should be more important
in the future to perform canonization of YANG data values when
necessary.
projects / mirror / frr.git / log