Igor Ryzhov [Thu, 27 Jan 2022 18:05:40 +0000 (21:05 +0300)]
vrrpd: use ipaddr_is_zero when needed
Replace custom implementation or call to ipaddr_isset with a call to
ipaddr_is_zero.
ipaddr_isset is not fully correct, because it's fine to have some
non-zero bytes at the end of the struct in case of IPv4 and the function
doesn't allow that.
Donald Sharp [Mon, 24 Jan 2022 20:37:54 +0000 (15:37 -0500)]
zebra: Don't double delete the table we are cleaning up
vrf_disable is always called first before
vrf_delete. The rnh_table and rnh_table_multicast tables
are already deleted as part of vrf_disable. No need
to do it again.
ckishimo [Tue, 25 Jan 2022 17:49:27 +0000 (18:49 +0100)]
ospf6d: show if area is NSSA
This PR will include if the area is NSSA in the output of "show ipv6 ospf"
r2# show ipv6 ospf
...
Area 0.0.0.0
Number of Area scoped LSAs is 8
Interface attached to this area: r2-eth1
SPF last executed 20.46717s ago
Area 0.0.0.1[Stub]
Number of Area scoped LSAs is 9
Interface attached to this area: r2-eth0
SPF last executed 20.46911s ago
Area 0.0.0.2[NSSA]
Number of Area scoped LSAs is 14
Interface attached to this area: r2-eth2
SPF last executed 20.46801s ago
Quentin Young [Thu, 20 Jan 2022 22:24:30 +0000 (17:24 -0500)]
pimd: fix misuse of xpath buf size constants
XPATH_MAXLEN denotes the maximum length of an XPATH. It does not make
sense to allocate a buffer intended to contain an XPATH with a size
larger than the maximum allowable size of an XPATH. Consequently this PR
removes buffers that do this. Prints into these buffers are now checked
for overflow.
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)#
```
Louis Scalbert [Wed, 20 Oct 2021 14:26:30 +0000 (16:26 +0200)]
bgpd: apply maximum-prefix-out without clearing the neighbor
Abstract:
- The command "neighbor PEER maximum-prefix-out NUMBER" cannot be applied
without clearing the BGP neighbor.
- Apply the maximum-prefix-out value as soon as it is modified without
clearing the neighbor.
subgroup_update_packet() and subgroup_withdraw_packet() respectively
manages the announcement and withdrawal BGP message to the peer.
subgrp->scount counter counts the number of sent prefixes.
Before the patch, the maximum out prefix limitation was applied in
subgroup_update_packet() in order that subgrp->scount never exceeds the
limit. Setting a limit inferior to the effective number of sent prefix
did not result in sending any withdrawal message to reduce the number of
sent prefixes. Without clearing the BGP neighbor, the limitation only
applied to the announcement of new prefixes when the limitation was
over.
With the patch, the limitation is checked in subgroup_announce_check().
The function is intended to say whether a prefix has to be announced in
regards to the prefix-list, route-map... Now when a maximum-prefix-out
value is changed/removed, the neighbor AFI/SAFI table is re-parsed in
the same way as for the application of route-map, prefix-lists...
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
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.