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.
F. Aragon [Wed, 10 Apr 2019 17:08:50 +0000 (19:08 +0200)]
zebra: pseudowire event recovery (DoS fix)
When having a route recovery, because of the route installation
cycling and the next hop label check, it could happen that the PW
never gets recovered. The original code shows the intention of retrying,
but the code was missing. The fix includes the call to the timer programming
the recovery attempt.
Example for reproducing the issue:
|P1| <-> |P2| <-> |P3|
- Being P1, P2, P3 nodes, using IS-IS as IGP, and having a pseudowire
betwen P1 and P3 (P1, P2, P3 having configured LDP daemons).
- After 60 seconds, kill the IS-IS daemon in P2.
- Wait 30 seconds
- Launch again the IS-IS daemon in P2
- The bug/issue is that after P1 <-> P3 recovering connectivity sometimes
the PW is not recovered because the reason explained in the first paragraph.
F. Aragon [Fri, 5 Apr 2019 13:26:14 +0000 (15:26 +0200)]
zebra: label manager race condition fix
This fix covers the case where two or more events are processed but only one
becoming effective. E.g. when mixing a synchronous label request from a LDP
deamon and an asynchronous request from a BGP daemon it could happen to the
BGP having the label chunk, but the LDP stuck waiting for the response.
Donald Sharp [Wed, 28 Nov 2018 23:46:36 +0000 (18:46 -0500)]
bgpd: interface based peers should automatically override it's peer group
When a interface based peer is setup and if it is part of a peer
group we should ignore this and just use the PEER_FLAG_CAPABILITY_ENHE
no matter what.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
projects / matthieu / frr.git / log