The bgp_gr_restart_retain_routes test is looking for specific output
that does not include the routes nexthop id:
def _bgp_check_kernel_retained_routes():
output = (
r2.cmd("ip route show 172.16.255.1/32 proto bgp dev r2-eth0")
.replace("\n", "")
.rstrip()
)
expected = "172.16.255.1 via 192.168.255.1 metric 20"
diff = topotest.get_textdiff(
output, expected, "Actual IP Routing Table", "Expected IP RoutingTable"
)
if diff:
return False
return True
While the output includes nexthop group id's now:
root@r2:# ip route show 172.16.255.1 proto bgp dev r2-eth0
172.16.255.1 nhid 8 via 192.168.255.1 metric 20
Let's just mark r2 as not to use nexthop groups for installation
and this test issue will go away.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
No mistake, just to unify style for the parameter of function address - remove
ampersand. In current code, only this one place of `hook_register()`s needs
to be made.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
Add a knob to accept lower seq number in evpn updates
from BGP in Zebra.
Note: Knob is enabled by default
Signed-off-by: Stephen Worley <sworley@nvidia.com>
There are lib debugs being set but never show up in
`show debug` commands because there was no way to show
that they were being used. Add a bit of infrastructure
to allow this and then use it for `debug route-map`
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
In order to minimize the changes of test files, this PR adds `func-bits`
parameters on the SRv6 locator definition.
Signed-off-by: Ryoga Saito <ryoga.saito@linecorp.com>
In order to set function length of SID freely, this PR relieves the
lower limitation of `func-bits`.
Signed-off-by: Ryoga Saito <ryoga.saito@linecorp.com>
In order to send correct SRv6 L3VPN advertisement, we need to save
srv6_locator_chunk in vpn_policy. With this information, we can
construct correct SRv6 L3VPN advertisement packets.
Signed-off-by: Ryoga Saito <ryoga.saito@linecorp.com>
Add default SRv6 Function Length for usecases like SRv6 L3VPN. The
default value (16) comes from the default Function length for SRv6
L3VPN in BGPd.
Signed-off-by: Ryoga Saito <ryoga.saito@linecorp.com>
There is code that sets the pi based upon matching it against
the same peer. In this code the type and sub-type are also
compared to the passed in type and sub-type. Let's just use
type and sub-type as that if we have a pi we know type and sub-type
are already correct. This should also make the first iteration
work correctly when the pi has not been created yet when we call
the martian_update function.bgpd: Remove unnecessary check for pi and setting type and sub-type
There is code that sets the pi based upon matching it against
the same peer. In this code the type and sub-type are also
compared to the passed in type and sub-type. Let's just use
type and sub-type as that if we have a pi we know type and sub-type
are already correct. This should also make the first iteration
work correctly when the pi has not been created yet when we call
the martian_update function.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
vtysh.xref only contains a rather-useless duplicate of every single CLI
command incorporated into vtysh... and including it prevents frr.xref
from becoming the source for vtysh_cmd.c.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
It already "looks" like a bitmask, but we currently can't flag a command
both YANG and HIDDEN at the same time. It really should be a bitmask.
Also clarify DEPRECATED behaviour (or the absence thereof.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The issue fixed in the previous commit now correctly triggers a failure:
("assertion (list_add(&head, &itm[j]) == &itm[j]) failed")
Turns out the "shitty" hash function was not shitty enough.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The typesafe hash data structure enforces items to be unique, but their
hash values may still collide. To this extent, when two items have the
same hash value, the compare function is called to see if it returns 0
(aka "equal").
While the _find() function handles this correctly, the _add() function
mistakenly only checked the first item with a colliding hash value for
equality, and if it was inequal proceeded to add the new item. There
may however be additional items with the same hash value collision, one
of which could still compare as equal. In that case, _add() would
mistakenly add the new element, failing to notice the already added
item. Breakage ensues.
Fix by looking for an equal element among *all* existing items with the
same hash value, not just the first.
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
[DL: rewrote commit message, fixed whitespace/formatting]
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
- for a given IP nexthop, dump all NH entries, including
colored entries, or entries with an ifindex.
- when a given IP nexthop is requested, the path is displayed.
For better readibility, remove the carriage return between
'Last update' and 'Paths', because ctime() function already
performs carriage return.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When zebra requests tunnel data it is sending a RTM_GETTUNNEL per
interface that is a VXLAN tunnel. If the kernel that is being
used does not support the particular request type then zebra
will get a error message per tunnel request back. Unfortunately
netlink_parse_info *stops* reading on the first error message.
Therefor one kernels that are returning an error message
let's gather all of those errors. This will allow things
like route reads to actually work properly
Fixes: #12056
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Section 6.2.7 of RFC 4861 states that a router SHOULD log
inconsistencies in RA information detected on a given link:
```
- Cur Hop Limit values (except for the unspecified value of zero
other inconsistencies SHOULD be logged to system network
management).
- Values of the M or O flags.
- Reachable Time values (except for the unspecified value of zero).
- Retrans Timer values (except for the unspecified value of zero).
- Values in the MTU options.
- Preferred and Valid Lifetimes for the same prefix. If
AdvPreferredLifetime and/or AdvValidLifetime decrement in real
time as specified in Section 6.2.1 then the comparison of the
lifetimes cannot compare the content of the fields in the Router
Advertisement, but must instead compare the time at which the
prefix will become deprecated and invalidated, respectively. Due
to link propagation delays and potentially poorly synchronized
clocks between the routers such comparison SHOULD allow some time
skew.
```
We were not logging inconsistencies if "the unspecified value of zero"
was used for Reachable Time but were logging them for Retrans Timer.
This updates the validation check to also skip the logging of Retrans
Timer inconsistencies if either local/rx value is 0.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
When we process a received Router Advertisement we have some logic in
place to detect and log mismatches in a handful of flags/values.
However, these logs do not include what the actual values are, which
means it's up to the operator to grab a packet capture and compare that
against the local configuration...
So let's make life a little easier by including those in the log itself.
Before:
```
2022/09/30 20:37:16 ZEBRA: [KV2V1-7GM7G][EC 4043309149] enp1s0(2): Rx RA - our AdvCurHopLimit doesn't agree with fe80::5054:ff:feca:b085
2022/09/30 20:37:16 ZEBRA: [KS0BP-4GR8K][EC 4043309149] enp1s0(2): Rx RA - our AdvManagedFlag doesn't agree with fe80::5054:ff:feca:b085
2022/09/30 20:37:16 ZEBRA: [RE4EC-VYEJ2][EC 4043309149] enp1s0(2): Rx RA - our AdvOtherConfigFlag doesn't agree with fe80::5054:ff:feca:b085
2022/09/30 20:37:16 ZEBRA: [X6794-9MW18][EC 4043309149] enp1s0(2): Rx RA - our AdvReachableTime doesn't agree with fe80::5054:ff:feca:b085
2022/09/30 20:37:16 ZEBRA: [S1KXC-H8F4W][EC 4043309149] enp1s0(2): Rx RA - our AdvRetransTimer doesn't agree with fe80::5054:ff:feca:b085
```
After:
```
Sep 30 20:45:18 ub20-2 zebra[47487]: [GSW5Z-V7DZN][EC 4043309149] enp1s0(2): Rx RA - our AdvCurHopLimit (14) doesn't agree with fe80::5054:ff:fe9a:e2ca (64)
Sep 30 20:45:18 ub20-2 zebra[47487]: [RHHTS-F96DR][EC 4043309149] enp1s0(2): Rx RA - our AdvManagedFlag (0) doesn't agree with fe80::5054:ff:fe9a:e2ca (1)
Sep 30 20:45:18 ub20-2 zebra[47487]: [MNBY3-FTN6W][EC 4043309149] enp1s0(2): Rx RA - our AdvOtherConfigFlag (0) doesn't agree with fe80::5054:ff:fe9a:e2ca (1)
Sep 30 20:45:18 ub20-2 zebra[47487]: [GG62B-XXWR0][EC 4043309149] enp1s0(2): Rx RA - our AdvReachableTime (20) doesn't agree with fe80::5054:ff:fe9a:e2ca (777)
Sep 30 20:45:18 ub20-2 zebra[47487]: [YG220-D6B4H][EC 4043309149] enp1s0(2): Rx RA - our AdvRetransTimer (13) doesn't agree with fe80::5054:ff:fe9a:e2ca (0)
```
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
