Fredi Raspall [Sun, 2 May 2021 15:13:11 +0000 (17:13 +0200)]
isisd: clear the N-flag in ext. reachability TLVs
If the n-flag-clear option is set in the configuration of a prefix
segment, clear the flag in the extended ip reachability TLVs.
RFCs 7794 and 8667 are not too strict on the setting / clearing the
N-flag in prefix SIDs. However, if there exists a cmd line option
to clear it, it should be cleared in the TLVs announced, as other
vendors do.
Igor Ryzhov [Mon, 17 May 2021 16:35:57 +0000 (19:35 +0300)]
ripngd: fix interface wakeup after shutdown
RIPNG schedules a call to `ripng_interface_wakeup` in 1 second after
receiving the interface UP event from zebra. The function is called even
if the interface was shut down during this interval.
This is incorrect and also leads to a crash in the following scenario:
```
vtysh -c "conf" -c "router ripng vrf red" -c "network enp2s0"
ip link add red type vrf table 1
ip link set enp2s0 vrf red
ip link set enp2s0 down
ip link set enp2s0 up && sleep 2 && ip link del red
```
Igor Ryzhov [Mon, 17 May 2021 16:34:02 +0000 (19:34 +0300)]
ripd: fix interface wakeup after shutdown
RIP schedules a call to `rip_interface_wakeup` in 1 second after
receiving the interface UP event from zebra. The function is called even
if the interface was shut down during this interval.
This is incorrect and also leads to a crash in the following scenario:
```
vtysh -c "conf" -c "router rip vrf red" -c "network enp2s0"
ip link add red type vrf table 1
ip link set enp2s0 vrf red
ip link set enp2s0 down
ip link set enp2s0 up && ip link del red
```
Mark Stapp [Tue, 11 May 2021 19:57:39 +0000 (15:57 -0400)]
lib,zebra: Use a flag to track down status for connected addrs
Track 'down' state of connected addresses with a new flag. We
may have multiple addresses on an interface that share a prefix;
in those cases, we need to determine when the first address
is valid, to install a connected route, and similarly detect
when the last address goes 'down', to remove the connected
route.
Donald Sharp [Wed, 5 May 2021 03:48:17 +0000 (23:48 -0400)]
zebra: Consolidate on 1 function netlink_parse_rattr_nested
if_netlink.c created it's on nested parsing #define which
is identical to netlink_parse_rtattr_nested. Consolidate
on one instead of having this duality.
Donald Sharp [Wed, 5 May 2021 03:43:47 +0000 (23:43 -0400)]
zebra: memset the `struct rtattr *tb[SIZE]` in setting function
In order to parse the netlink message into the
`struct rtattr *tb[size]` it is assumed that the buffer is
memset to 0 before the parsing. As such if you attempt
to read a value that was not returned in the message
you will not crash when you test for it.
The code has places were we memset it and places where we don't.
This *will* lead to crashes when the kernel changes. In
our parsing routines let's have them memset instead of having
to remember to do it pre pass in to the parser.
lynne [Tue, 4 May 2021 15:06:49 +0000 (11:06 -0400)]
ospf6d: Limit the number of interface addresses being supported
The code had no limits on addresses configured on an interface running
ospf6d. The code would crash when more than 100 addresses were added.
This change limits the number of interface address to 100 if mtu is set
to the default value. If the mtu is set to a jumbo packet size or larger
we will support 200 interface addresses.
Martin Buck [Mon, 10 May 2021 20:48:32 +0000 (22:48 +0200)]
ospf6d: Send MAXAGE LS update for received old self-originated LSAs
Fixes OSPFv3-26.13 ANVL RFC conformance bug #8576 by improving the bugfix
for #7030 from 4c63a76a. That commit changed handling of received old
non-MAXAGE LSAs with a MAXAGE counterpart in the LSDB from "add all LSAs to
LSDB and flood non-self-originated ones" to "add & flood only
non-self-originated LSAs and ignore self-originated LSAs". The new behaviour
is similar but adds sending a MAXAGE LS Update for received self-originated
LSAs to remove the old LSAs from the network, resulting in "add & flood
non-self-originated LSAs, don't add but send MAXAGE LS Update for
self-originated LSAs". The missing MAXAGE LS Update is what OSPFv3-26.13
ANVL complained about.
Signed-off-by: Martin Buck <mb-tmp-tvguho.pbz@gromit.dyndns.org>
Neal Shrader [Thu, 6 May 2021 18:51:06 +0000 (14:51 -0400)]
bgpd: scope evpn specific path selection to type-2 routes
For EVPN routes, there is specific logic in place for path selection
surrounding MAC Mobility. For pure type-5 routes, if a route is
advertised with a MED, this is ignored since it ultimately falls inside
of the EVPN specific path selection logic, and ultimately selects the
lower IP address. This change ensures only type-2 routes fall into the
EVPN BGP path selection.
Javier Garcia [Thu, 22 Apr 2021 14:09:54 +0000 (16:09 +0200)]
pathd. Pathd TED support . Documentation update - [part 4/4]
- As an example of pathd and igp (ospfd) config:
! igp ospfv2 snippet
interface eth0
ip ospf network point-to-point
!
router ospf$
mpls-te on
mpls-te export
...
!pathd snippet
segment-routing
traffic-eng
mpls-te on
mpls-te import ospfv2
segment-list sl-1
index 10 nai adjacency 10.1.2.11 10.1.2.1
index 20 nai adjacency 10.1.20.1 10.1.20.2
index 30 nai adjacency 10.2.5.2 10.2.5.5
!
policy color 5 endpoint 10.10.10.5
name five
binding-sid 5555
candidate-path preference 600 name cp51 explicit segment-list sl-1
candidate-path preference 500 name cp52-dyn dynamic
Signed-off-by: Javier Garcia <javier.garcia@voltanet.io>
Javier Garcia [Thu, 22 Apr 2021 14:04:42 +0000 (16:04 +0200)]
pathd. TED support . Validation of candidate path - [part 2/4]
- Explicit segment list nai will be resolved to corresponded sid.
- Dynamic segment list (from pce) will be validated.
- If segment list could not be resolved or validated won't be used.
- Now this new config is supported
segment-list sl-1
index 10 nai prefix 10.1.2.1/32 iface 1
index 30 nai adjacency 10.2.5.2 10.2.5.5
index 40 nai prefix 10.10.10.5/32 algorithm 0
Signed-off-by: Javier Garcia <javier.garcia@voltanet.io>
Chirag Shah [Wed, 5 May 2021 01:09:37 +0000 (18:09 -0700)]
zebra: check vni oper state in svi up notif
When clagd is stopped on secondary device,
all vxlan interfaces (vnis) are kept in protodown state.
FRR treats protodown vxlan interfaces (vnis) as interface down
and sends vni delete to bgpd.
In the event of clagd down, SVIs are flapping as underlying
bridge is going through churn.
When FRR receives SVI up notification do not trigger event to bgpd
if vnis are operationaly down.
Ticket:#2600210 CM-22929
Reviewed By:CCR-11544
Testing Done:
Performed CLAG stop/start on secondary device, all vxlan devices
remained in protodown along with this validated the vnis are cleaned up
and added back in bgpd.
Wesley Coakley [Wed, 5 May 2021 14:28:53 +0000 (10:28 -0400)]
lib: ip prefix-list enforce expected ge le behavior
When specifying only an "le" for an existing ip prefix-list qualified with
both an "le" and "ge" make sure to remove the "ge" property so it does
not stay in the tree.
E.g. Saying these two things in order:
ip prefix-list test seq 1 permit 1.1.0.0/16 ge 18 le 24
ip prefix-list test seq 1 permit 1.1.0.0/16 ge 18
... should result in the second statement "overwriting" the first like
this:
vxdev-arch# do show ip prefix-list
ZEBRA: ip prefix-list foobar: 3 entries
seq 1 permit 15.0.0.0/16 ge 18
Previously this did not happen and "le" would stick around since it was
never given NB_OP_DESTROY and purged from the data tree.
Wesley Coakley [Thu, 6 May 2021 16:31:37 +0000 (12:31 -0400)]
tools: stop frr-reload squashing le 32 / le 128
frr-reload no longer consolidates ip prefix-list "le 32" or "le 128"
rules when a "ge" is present, more accurately representing existing user
config and reflecting also what is accepted in CLI.
Quentin Young [Tue, 27 Apr 2021 20:20:27 +0000 (16:20 -0400)]
bgpd: rework BGP_MAX_PACKET_SIZE & friends
BGP_MAX_PACKET_SIZE no longer represented the absolute maximum BGP
packet size as it did before, instead it was defined as 4096 bytes,
which is the maximum unless extended message capability is negotiated,
in which case the maximum goes to 65k.
That introduced at least one bug - last_reset_cause was undersized for
extended messages, and when sending an extended message > 4096 bytes
back to a peer as part of NOTIFY data would trigger a bounds check
assert.
This patch redefines the macro to restore its previous meaning,
introduces a new macro - BGP_STANDARD_MESSAGE_MAX_PACKET_SIZE - to
represent the 4096 byte size, and renames the extended size to
BGP_EXTENDED_MESSAGE_MAX_PACKET_SIZE for consistency. Code locations
that definitely should use the small size have been updated, locations
that semantically always need whatever the max is, no matter what that
is, use BGP_MAX_PACKET_SIZE.
BGP_EXTENDED_MESSAGE_MAX_PACKET_SIZE should only be used as a constant
when storing what the negotiated max size is for use at runtime and to
define BGP_MAX_PACKET_SIZE. Unless there is a future standard that
introduces a third valid size it should not be used for any other
purpose.
Pat Ruddy [Thu, 6 May 2021 13:36:52 +0000 (14:36 +0100)]
tests: fix intermittent key error in bgp-auth topotest
There is a rare case where with prefix peers the peer is
completely absent from the json output when checking the
peer state resulting in a python key error. Check key exists
before checking the state.