Trey Aspelund [Tue, 16 Nov 2021 21:11:26 +0000 (21:11 +0000)]
bgpd: retain peer asn even with remove-private-AS
In situations where remove-private-AS is configured for eBGP peers
residing in a private ASN, the peer's ASN was not being retained
in the AS-Path which can allow loops to occur. This was addressed
in a prior commit but it only addressed cases where the "replace-AS"
keyword was configured.
This commit ensures we retain the peer's ASN when using
"remove-private-AS" for eBGP peers in a private ASN regardless of other
keywords.
Before ("remote-private-AS" only):
=========
ub18# show ip bgp neighbors enp6s0 advertised-routes | include 100.64.0.2
*> 100.64.0.2/32 :: 0 i <<<<< empty as-path, no way to prevent loop
After ("remote-private-AS" only):
=========
ub18# show ip bgp neighbors enp6s0 advertised-routes | include 100.64.0.2
*> 100.64.0.2/32 :: 0 42000000014200000001 i <<<< retain peer's asn, breaks loop
Donatas Abraitis [Fri, 21 Jan 2022 21:31:58 +0000 (23:31 +0200)]
bgpd: Show negative form of capability extended-nexthop for interface peers
```
exit1-debian-11(config-router)# neighbor 192.168.100.3 remote-as external
exit1-debian-11(config-router)# do sh run | include extended
exit1-debian-11(config-router)# neighbor 192.168.100.3 capability extended-nexthop
exit1-debian-11(config-router)# do sh run | include extended
neighbor 192.168.100.3 capability extended-nexthop
exit1-debian-11(config-router)# no neighbor 192.168.100.3 capability extended-nexthop
exit1-debian-11(config-router)# do sh run | include extended
exit1-debian-11(config-router)# neighbor eth0 interface remote-as external
exit1-debian-11(config-router)# do sh run | include extended
exit1-debian-11(config-router)# neighbor eth0 capability extended-nexthop
exit1-debian-11(config-router)# do sh run | include extended
exit1-debian-11(config-router)# no neighbor eth0 capability extended-nexthop
exit1-debian-11(config-router)# do sh run | include extended
no neighbor eth0 capability extended-nexthop
exit1-debian-11(config-router)#
```
Donald Sharp [Wed, 3 Feb 2021 14:13:59 +0000 (09:13 -0500)]
lib: Figure out if we are being starved for cpu
If a thread timer should have popped CPU_CONSUMED_CHECK
seconds in the past, and we are only handling it now. Consider
the thread starved and notice it.
Igor Ryzhov [Wed, 19 Jan 2022 20:02:11 +0000 (23:02 +0300)]
bgpd: fix populating the attribute
This code is populating a temporary variable `add` instead of the attr.
Initially this variable was later copied to the attr but the copying was
erroneously deleted by 0a50c2481. Directly populate the attr to restore
the correct behavior.
Igor Ryzhov [Wed, 19 Jan 2022 19:55:44 +0000 (22:55 +0300)]
bgpd: remove wrong overlay index comparison
Here we try to compare the new attr with the existing one but this call
compares the existing index with zero instead. attrhash_cmp already
compares indexes using overlay_index_same so this call is both wrong and
useless.
Donatas Abraitis [Wed, 19 Jan 2022 17:02:01 +0000 (19:02 +0200)]
bgpd: Show Graceful Restart seconds remaining per prefix
```
exit1-debian-11# sh ip bgp 10.10.10.10/32
BGP routing table entry for 10.10.10.10/32, version 14
Paths: (1 available, best #1, table default)
Not advertised to any peer
65000, (stale)
192.168.0.2 from 192.168.0.2 (0.0.0.0)
Origin incomplete, metric 0, valid, external, best (First path received)
Last update: Wed Jan 19 17:13:51 2022
Time until Graceful Restart stale route deleted: 117
```
```
~# vtysh -c 'show bgp ipv4 unicast 100.100.100.100/32'
BGP routing table entry for 100.100.100.100/32, version 7
Paths: (2 available, best #2, table default)
Advertised to non peer-group peers:
home-spine1.donatas.net(192.168.0.2)
65002, (stale)
192.168.10.17 from donatas-pc(192.168.10.17) (0.0.0.0)
Origin incomplete, valid, external
Last update: Sat Jan 15 21:45:47 2022
65001
192.168.0.2 from home-spine1.donatas.net(192.168.0.2) (2.2.2.2)
Origin incomplete, metric 0, valid, external, best (Older Path)
Last update: Sat Jan 15 21:25:19 2022
```
~# vtysh -c 'show bgp ipv4 unicast 100.100.100.100/32'
BGP routing table entry for 100.100.100.100/32, version 7
Paths: (2 available, best #2, table default)
Advertised to non peer-group peers:
home-spine1.donatas.net(192.168.0.2)
65002, (stale)
192.168.10.17 from donatas-pc(192.168.10.17) (0.0.0.0)
Origin incomplete, valid, external
Community: llgr-stale
Last update: Sat Jan 15 21:49:01 2022
Time until Long-lived stale route deleted: 16
65001
192.168.0.2 from home-spine1.donatas.net(192.168.0.2) (2.2.2.2)
Origin incomplete, metric 0, valid, external, best (First path received)
Last update: Sat Jan 15 21:25:19 2022
```
Donald Sharp [Fri, 14 Jan 2022 17:50:51 +0000 (12:50 -0500)]
zebra: Modify route_notify_internal to use a route_node
Pass in the route_node that is under consideration
into route_notify_internal to allow calling functions
to reduce stack size as well as looking up data.
Donald Sharp [Tue, 4 Jan 2022 18:11:35 +0000 (13:11 -0500)]
tests: Add ospf_instance_redistribute testing
Redistribution for ospf with instance id's using instance id's
was incorrect. Add some small tests to make sure it catches the
issues and we don't regress.
This cannot be correct behavior. When redistributing in the absense
of an instance number the default instance of 0 should be used and should
be the only route redistributed. Here is the correct behavior:
eva# show ip route
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, r - rejected, b - backup
t - trapped, o - offload failure
K>* 0.0.0.0/0 [0/100] via 192.168.119.1, enp39s0, 00:00:28
D>* 4.5.6.7/32 [150/0] via 192.168.100.1, virbr1, weight 1, 00:00:02
D[3]>* 4.5.6.8/32 [150/0] via 192.168.100.1, virbr1, weight 1, 00:00:02
D[4]>* 4.5.6.9/32 [150/0] via 192.168.100.1, virbr1, weight 1, 00:00:02
C>* 192.168.100.0/24 is directly connected, virbr1, 00:00:28
C>* 192.168.110.0/24 is directly connected, virbr2, 00:00:28
C>* 192.168.119.0/24 is directly connected, enp39s0, 00:00:28
C>* 192.168.122.0/24 is directly connected, virbr0, 00:00:28
eva# show ip ospf data
OSPF Instance: 3
OSPF Router with ID (192.168.122.1)
AS External Link States
Link ID ADV Router Age Seq# CkSum Route
4.5.6.7 192.168.122.1 6 0x80000001 0x477c E2 4.5.6.7/32 [0x0]
Donald Sharp [Mon, 3 Jan 2022 17:15:02 +0000 (12:15 -0500)]
ospfd: Get `default-information originate` working for ospf instances
The ospf instance code is not properly handling the default route
when using default-information originate. This is because
the code is looking for the default route to be saved with an
instance of <ospf instance id> but we always save it as a instance
id of 0. In fact OSPF asks zebra for the default route as a special
case in instance 0, always.
Here is the correct behavior:
eva# show ip ospf data
OSPF Instance: 3
OSPF Router with ID (192.168.122.1)
AS External Link States
Link ID ADV Router Age Seq# CkSum Route
0.0.0.0 192.168.122.1 8 0x80000001 0xdb08 E2 0.0.0.0/0 [0x0]
eva# show ip route
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, r - rejected, b - backup
t - trapped, o - offload failure
K>* 0.0.0.0/0 [0/100] via 192.168.119.1, enp39s0, 00:02:03
Fixes: #10251 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Donald Sharp [Mon, 3 Jan 2022 17:11:37 +0000 (12:11 -0500)]
zebra: Add hint to what instance we are looking at
FRR allows redistribution to a client with a specific
instance in mind. The code was not allowing you to figure
out what instance was being looked at. So let's clarify this
in the debugs.
sarita patra [Tue, 4 Jan 2022 11:26:06 +0000 (03:26 -0800)]
pim: Keeping list of address-family under gmp container
Renamed frr-igmp.yang to frr-gmp.yang, igmp to gmp container.
to support IGMP and MLD protocol.
frr-gmp.yang, created a list of address family under mgmd
container. For PIMV4 the key is IPV4, where as for PIMV6
the key is IPV6. This is done for PIMV6 development.
This commit will have all the northbound changes to support
IPV4 address family.
tests: Fix random failure in test_PIM_hello_tx_rx_p1
The test case test_PIM_hello_tx_rx_p1 is failing randomly because
sometimes the hello packet is received and sometimes not received while getting
the stats data.
When the hello packet is received HelloRx gets incremented to 1 and then
shutdown of the interface is executed which resets the stats to 0
and again when "no shutdown" of the interface is done, the stats get incremented to 1.
The test case checks after "no shutdown" of the interface whether the stats is incremented
but in this case although the stats got incremented the before and after value is same.
Hence the test case failed.
Update ospfd and ospf6d to send opaque route attributes to
zebra. Those attributes are stored in the RIB and can be viewed
using the "show ip[v6] route" commands (other than that, they are
completely ignored by zebra).
Example:
```
debian# show ip route 192.168.1.0/24
Routing entry for 192.168.1.0/24
Known via "ospf", distance 110, metric 20, best
Last update 01:57:08 ago
* 10.0.1.2, via eth-rt2, weight 1
OSPF path type : External-2
OSPF tag : 0
Trey Aspelund [Fri, 14 Jan 2022 21:57:32 +0000 (21:57 +0000)]
bgpd: fix advertisedRoutes json key
'show bgp ... neighbor [routes|received-routes]' both incorrectly
used a json key of 'advertisedRoutes'.
This corrects the key to be 'receivedRoutes' for commands where
the displayed routes were received, not advertised.
before:
unet> r3 show ip bgp neigh 10.2.30.2 received-routes json | include Routes
"advertisedRoutes":{
after:
ub18# show ip bgp neighbors enp1s0 received-routes json | include Routes
"receivedRoutes":{
ub18# show ip bgp neighbors enp1s0 advertised-routes json | include Routes
"advertisedRoutes":{
David Lamparter [Wed, 5 Jan 2022 15:23:23 +0000 (16:23 +0100)]
lib: add `s` option to `pI4`/`pI6`/`pIA` printfrr
Adding an `s` after these printfrr specifiers replaces 0.0.0.0 / :: in
the output with a star (`*`). This is primarily intended for use with
multicast, e.g. to print `(*,G)`.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
David Lamparter [Wed, 5 Jan 2022 18:51:19 +0000 (19:51 +0100)]
tools: disable printf ext checks in checkpatch
checkpatch.pl has a hardcoded list of printf extensions supported... by
the Linux kernel. This happens to have covered the ones we have in FRR
so far, but `%pPA` isn't on the list and others may not be either.
Since we have the frr-format GCC plugin (and CI runs that on Debian 11)
we don't really need these checks in checkpatch.pl.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Sarita Patra [Mon, 14 Jun 2021 01:48:35 +0000 (18:48 -0700)]
zebra: Fix for route node having no tracking NHT
Topology:
IXIA-----(ens192)FRR(ens224)------iXIA
Configuration:
1. Create 8 sub-interfaces on ens192 under Default VRF and configure 8
EBGP session between FRR and IXIA.
2. Create 1000 sub-interfaces on ens224 under Default VRF and configure
1000 EBGP session between FRR and IXIA.
3. 2M prefixes distributed from Left side Ixia each with 8 ECMP path.
4. So in total, there are 2M prefixes * 8 ECMP = 16M prefixes entries
in RIB and FIB.
Issue:
Shut ens192 and ens224, this is taking 1hr 15 mins to clean up the routes.
Root Cause:
In the case of route deletion, if the particular route node is having
nht count = 0, we are going to the parent and doing nht evaluation,
which is not needed.
Fix:
If the deleted the route node is having nht count > 0, then do a nht
evaluation on the parent node.
Shut ens192 and ens224, it is taking 1 min to clean up the routes
with the fix.
projects / mirror / frr.git / log