When we receive an igmp query on a interface, ensure that the
source address of the packet is connected to the incoming
interface. This will prevent a meanie from crafting a igmp
packet with a source address less than ours and causing
us to suspend query activities.
Fixes: #1692
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The `no redistribute ...` commands were not allowing
the input to be in any order. Fix code to allow this.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
1) If we are moving the nexthop we are tracking to
a new rn in the rib, then we know that the route
to get to that nexthop has changed. As such
we should notify the upper level.
This manifested itself because the code had a trigraph `?`
in the wrong order. Put the comparison in the right order.
2) If we are re-matching to the same rn and we call compare_state
then we need to see if our stored nexthops are the same or different.
If they are the same we should not notify. If they are different
we should notify. compare_state was only comparing the flags
on a route and since those are not necessarily the right flags
to look at( and we are well after the fact that the route has
already changed and been processed ) let's just compare
the nexthops to see if they are the same or different.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Fix details :
Added a utility cli to generate a igmp query on an interface.
This won't impact the existing query generation based on the
general query interval.
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
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>
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>
MTYPE definitions should be local to the file using them whereever
possible. Also remove some superfluous ;
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The "static struct mtype * const MTYPE_FOO" doesn't quite make a
"constant" that is usable for initializers. An 1-element array works
better.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Position of address family and encoding type is defined wrongly in the
packed structure. This will correct the position as per RFC 4601 4.9.1
Signed-off-by: Saravanan K <saravanank@vmware.com>
When running `show run` of route-maps the order is basically
the order read in some fashion. Convert the display to
always be the alphabetically sorted order.
Suggested-by: Manuel Schweizer <manuel@cloudscale.ch>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
