when receiving an EAGAIN while trying to read the header
of a ZAPI message, we were erroneously continuing as if
everything was fine, which could crash zebra. Fix this
by returning and letting the re-armed read task deal with
this
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
under some conditions, the callback to get a label for
a LU bgp path could be called after the path had already
been freed. In this case we would be reading garbage
and potentially crash. Lock the path info before
queueing the callback, and unlock as the first step
of the callback, exiting gracefully if the path info
is now NULL.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
In a pim-evpn setup (say TORC11<=>TORC12) an mroute can have a mix of
PIM and IGMP joins. The vxlan termination device ipmr-lo is IGMP
joined on termination mroutes and the peerlink-rif can be pim joined
on the same mroute if the MLAG peer (TORC11) loses all its uplinks to
underlay -
root@TORC12:~# net show pim state 239.1.1.101|grep pimreg
1 * 239.1.1.101 uplink-1
pimreg(I ), ipmr-lo( J ), peerlink-3.4094( J )
root@TORC12:~#
When the uplinks come back up on TORC11 it will prune the peerlink-rif
and join the RP (say spine) via the uplinks.
TORC12 is rxing the prune and removing the if_channel
(pim_ifchannel_delete). However it is not removing the OIF from
mfcc_ttl basically leaving behind a leaked OIF in the forwarding
entry. And this is because it is deriving the owner flag from the
parent upstream entry and incorrectly concluding that all OIFs are
IGMP joined.
Thix fix flushes out both PIM and IGMP ownership when the ifchannel is
deleted.
There is a second fix in the commit and that is to set the proto mask
correctly (to STAR) for inherited OIFs. (S,G) entries can inherit the
OIF from the (*, G) entry and this decision can change when the pim/igmp
ifchannel is removed. The earlier code was setting the proto-mask
incorrectly to PIM or IGMP.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
(cherry picked from commit d4d1d968dbbe61347393f7dace8b675496ff1024)
When a link goes down the vifi was being deleted but the OIF stayed
in the OIL with a stale vifi -
oroot@act-7726-03:~# net show pim state
Codes: J -> Pim Join, I -> IGMP Report, S -> Source, * -> Inherited from (*,G), V -> VxLAN
Installed Source Group IIF OIL
1 * 239.1.1.111 swp1s1 pimreg(I ), ipmr-lo( J )
1 6.0.0.28 239.1.1.111 lo pimreg( J ), ipmr-lo( *), swp1s1( J )
root@act-7726-03:~# ip link set swp1s1 down
root@act-7726-03:~# net show pim state
Codes: J -> Pim Join, I -> IGMP Report, S -> Source, * -> Inherited from (*,G), V -> VxLAN
Installed Source Group IIF OIL
1 * 239.1.1.111 swp1s0 pimreg(I ), ipmr-lo( J )
1 6.0.0.28 239.1.1.111 lo ipmr-lo( *), swp1s0( J ), <oif?>( J ) >>>>>>>>
root@act-7726-03:~#
The problem was as a part ifchannel_delete the join state of the channel
was checked to avoid incorrect OIF deletion this was preventing the OIF
from being flushed. Fix is to flip the channel join-state to NOINFO before
deleting it.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
These two data types were written to handle redistribute
and external data types. On shutdown cleanup the memory
allocated to these if we are doing redistribution.
This was found using valgrind.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Lets allow specification to accept microseconds, but limit the timers
configuration in FRR to milliseconds (minimum is 10 ms and maximum is 60
seconds).
This matches the RFC 5880 and the IETF BFD YANG draft model.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Make the function parameter `const` so the analyzer doesn't suspect we
are trying to change its value.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Add command 'no bfd' to remove all BFD sessions configuration and fix
other daemon integration.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
```
warnings: BFD: [EC 100663317] YANG model "frr-bfdd@*" not embedded, trying external file
```
Embed the YANG model into the binary to avoid reading an external file.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
When the remote discriminator hasn't been assigned yet, then we can't
return a value of 0. The value '0' is an invalid discriminator and the
yang handlers will complain about it.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Lets start using the new BFD yang model and translate the BFD session
configuration commands to use the northbound.
One important change: all sessions will default to use
`VRF_DEFAULT_NAME` (usually "default") when no VRF is configured. All
places which search for BFD sessions must now take this into account.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
These functions are going to be used by the future northbound
implementation to handle BFD sessions.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Some more complex CLI usages will require northbound to support
signalizing a custom configuration node end.
For an example:
```
router bgp 100
bgp router-id 10.254.254.1
neighbor 10.0.0.100 remote-as 200
!
address-family ipv4 unicast
network 10.0.1.0/24
network 10.0.2.0/24
network 10.0.3.0/24
exit-address-family
!
address-family ipv6 unicast
neighbor 10.0.0.100 activate
exit-address-family
!
```
This commit implements a new callback called `cli_show_end` which
complements `cli_show` and is only called at the end of processing the
yang configuration node. It will be used to write the configuration
node termination like: "!" or "exit-address-family".
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
EVPN route's extended community include
important informations like Mobility sequence,
router mac, and RT values, include the ecomm
in evpn brief output.
Ticket:CM-25353
Testing Done:
Validated in evpn deployment with routes.
TOR#show bgp l2vpn evpn route
...
Network Next Hop Metric LocPrf Weight Path
Extended Community
Route Distinguisher: 27.0.0.11:3
*> [2]:[0]:[0]:[48]:[00:02:00:00:00:04]:[128]:[fe80::202:ff:fe00:4]
36.0.0.11 0 4435 5546 i
RT:5546:1008 ET:8 ND:Router Flag
* [2]:[0]:[0]:[48]:[00:02:00:00:00:36]
36.0.0.11 0 4435 5546 i
RT:5546:1008 RT:5546:4003 ET:8 MM:0, sticky MAC Rmac:44:38:39:ff:ff:01
*> [2]:[0]:[0]:[48]:[00:02:00:00:00:36]
36.0.0.11 0 4435 5546 i
RT:5546:1008 RT:5546:4003 ET:8 MM:0, sticky MAC Rmac:44:38:39:ff:ff:01
* [3]:[0]:[32]:[36.0.0.11]
36.0.0.11 0 4435 5546 i
RT:5546:1008 ET:8
*> [3]:[0]:[32]:[36.0.0.11]
36.0.0.11 0 4435 5546 i
RT:5546:1008 ET:8
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Also fixes some issues related to -
show evpn arp-cache vni xx vtep yy
Ticket: CM-25380
Signed-off-by: Nitin Soni<nsoni@cumulusnetworks.com>
Reviewed-by: CCR-8858
Testing-Done: Evpn scale test with 30K neighs
when working with a standard vrf backend, bfdd ignores that and tries to
create and configure bfd sockets for each vrf, which will fail for the
second vrf discovered, since the network namespace used is the same, and
it is not possible to use same socket settings twice. Handle this case,
and avoids to reinitialise sockets.
This patch however does not leverage bfd support for vrf-lite.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
