zebra: set ZEBRA_IFC_DOWN on connected routes for inactive interfaces
If you are in a situation where you have multiple addresses on an
interface, zebra creates one connected route for them.
The issue is that the rib entry is not created if addresses were
added before the interface was running.
We add the address to a running interface in a typical flow.
Therefore, we handle the route & rib creation within a single ADD event.
In the opposite case, we create the route entries without activating them.
These are considered to be active since ZEBRA_IFC_DOWN is not set.
On the following interface UP, we ignore the same ADDR_ADD as it overlaps
with the existing prefixes -> rib is never created.
The minimal reproducible setup:
-----------------------------------------
ip link add name dummy0 type dummy
ip addr flush dev dummy0
ip link set dummy0 down
ip addr add 192.168.1.7/24 dev dummy0
ip addr add 192.168.1.8/24 dev dummy0
ip link set dummy0 up
vtysh -c 'show ip route' | grep dummy0
packaging: Set default permissions for /var/log/frr to 0755
At the moment we set /var/log/frr permissions to 0750 (frr:frr), but the log
file is 0640 (root:adm) (unless logrotated) and that doesn't allow adm group
to even open the directory.
Donald Sharp [Mon, 18 Apr 2022 18:06:26 +0000 (14:06 -0400)]
bgpd: Allow type 5 routes to be handled better when link is flapping
In some stress testing, we are seeing type-5 evpn routes being
left in a rejected state in zebra.
Sequence of events as I am seeing it:
a) Interface comes up that type5 routes nexthop depends on
b) zebra processes creates the connected and lets bgp know via nht
c) bgp installs the route to zebra
d) zebra processes and sends install to kernel
e) before route is installed, the interface the nexthop points at flaps
f) the route install is rejected, notify zebra
g) the interface comes up
h) zebra gets the notification about the route install rejection
i) zebra processes the down/up and turns it into a single up event
j) BGP never reinstalls the type 5 route
This up event does not translate into a nexthop tracking event
when the events happen quickly enough and/or zebra is extremelyh
busy and bgp would never see that the nexthops changed even very quickly.
This is the same thing that was going on with
https://github.com/FRRouting/frr/pull/7724
in PBR.
To fix this let's notice the interface up/down events for v4
in bgp now as well.
When lsp-mtu is configured larger than interface mtu and the interface
is brought up, the ISIS code would crash. When other vendors have this
misconfiguration they just continue ISIS running and allow the LSP
packets to be created but not sent. When the misconfiguration is corrected
the LSP packets start being sent. This change creates that same behavior
in FRR.
The startup issue I am hitting is when the isis lsp-mtu is larger that the interfaces mtu.
We run into this case when we are in the process of changing the mtu on a tunnel.
I issue a shutdown/no shutdown on the interface, because the tunnel MTU is smaller
than the lsp-mtu, it is considered an error and calls circuit_if_del. This deletes
part of the circuit information, which includes the circuit->ip_addr list. Later on we get
an address update from zebra and try to add the interface address to this list and crash.
2022/04/07 20:19:52.032 ISIS: [GTRPJ-X68CG] CSM_EVENT for tun_gw2: IF_UP_FROM_Z
calls isis_circuit_if_add
this initialize the circuit->ip_addrs
isis_circuit_up
has the mtu check circuit->area->lsp_mtu > isis_circuit_pdu_size(circuit) and fails
returns ISIS_ERROR
on failure call isis_circuit_if_del
this deletes the circiut->ip_addrs list <----
2022/04/07 20:19:52.032 ZEBRA: [NXYHN-ZKW2V] zebra_if_addr_update_ctx: INTF_ADDR_ADD: ifindex 3, addr 192.168.0.1/24
message to isisd to add address
isis_zebra_if_address_add
isis_circuit_add_addr
circuit->ip_addr we try to add the ip address to the list, but it was deleted above and isisd crashes
Donald Sharp [Mon, 28 Mar 2022 11:35:53 +0000 (07:35 -0400)]
zebra: When `zebra nexthop proto only` limit errors
Operators are seeing:
Mar 28 07:19:37 kingpin zebra[418]: [TZANK-DEMSE] netlink_nexthop_msg_encode: nhg_id 68 (zebra): proto-based nexthops only, ignoring
Mar 28 07:19:37 kingpin zebra[418]: [TZANK-DEMSE] netlink_nexthop_msg_encode: nhg_id 68 (zebra): proto-based nexthops only, ignoring
Mar 28 07:19:37 kingpin zebra[418]: [YXPF5-B2CE0] netlink_route_multipath_msg_encode: RTM_DELROUTE 2804:4d48:4000::/42 vrf 0(254)
Mar 28 07:19:37 kingpin zebra[418]: [YXPF5-B2CE0] netlink_route_multipath_msg_encode: RTM_NEWROUTE 2804:4d48:4000::/42 vrf 0(254)
Mar 28 07:19:37 kingpin zebra[418]: [TVM3E-A8ZAG] _netlink_route_build_singlepath: (single-path): 2804:4d48:4000::/42 nexthop via fe80::b6fb:e4ff:fe26:c5d5 if 2 vrf default(0)
Mar 28 07:19:37 kingpin zebra[418]: [HYEHE-CQZ9G] nl_batch_send: netlink-dp (NS 0), batch size=140, msg cnt=2
Mar 28 07:19:37 kingpin zebra[418]: [P2XBZ-RAFQ5][EC 4043309074] Failed to install Nexthop ID (68) into the kernel
When `zebra nexthop proto only` is turned on.
Effectively zebra intentionally does not do the nexthop group installation
and the dplane notification in zebra_nhg.c just assumes it was a failure
and prints an error message. Since this act was intentional, let's
just notice that it was intentional and not report the message
as a failure.
Yash Ranjan [Mon, 21 Mar 2022 11:30:22 +0000 (04:30 -0700)]
ospf6d: Check for MinLSInterval timer when adding to LSUpdate list
A router has some static routes and redistributes turned on.
"clear ipv6 ospf process" command is applied. Then static routes
are deleted. In 1 in 5 runs, AS-External LSAs are not getting removed
from the neighbors even though it gets removed from its own LSDB.
Because of the clear process command, MAX_AGE LSAs are advertised and
fresh LSAs are installed in the LSDB. When the MAX_LSAs are advertised
back to the same router as part of the flooding process, it gets added
to the LSUpdate list even though it comes inside the MinLSArrival time.
When the static routes get deleted, it removed the LSA from the
LSRetrans list but not from LSUpdate list. The LSAs present in the
LSUpdate list gets advertised when sending LS Updates.
When an old copy of an LSA is more recent than the new LSA, check if it
has come inside the MinLSArrival time before adding to the LSUpdate
list.
bgpd: take SRv6 locator's prefix length into account when generating SIDs
Until now, it has been hard-coded that the position at which the label
is inserted is from the 64th bits. Therefore, when the Locator prefix
was not /64, incorrect SIDs were generated. Also, SIDs are generated
in duplicate on Lines 604 & 613 in bgpd/bgp_mplsvpn.c.
In this patch, the position where the label is inserted is calculated
based on the sum of block_bits_length and node_bits_length (i.e., the
user-specified Locator prefix length). In addition, SID generation is
performed at one location in alloc_new_sid.
Optional recognized and unrecognized BGP attributes,
whether transitive or non-transitive, SHOULD NOT be updated by the
route server (unless enforced by local IXP operator configuration)
and SHOULD be passed on to other route server clients.
By default LB ext-community works with iBGP peers. When we receive a route
from eBGP peer, we can send LB ext-community to iBGP peers.
With this patch, allow sending LB ext-community to iBGP/eBGP peers if they
are set as RS clients.
FRR does not send non-transitive ext-communities to eBGP peers, but for
example GoBGP sends and if it's set as RS client, we should pass those attributes
towards another RS client.
frr(config-if)# ip igmp join 232.1.1.1 10.10.10.10
frr(config-if)# do sh ip igmp sources
Interface Address Group Source Timer Fwd Uptime
ens192 232.1.1.1 10.10.10.10 04:10 N 00:00:10
frr(config-if)#
The above output is misaligned and is having Address field which is not
required here.
projects / mirror_frr.git / log