Prevent IPv6 routes received via a ibgp session with one of its own interface
ip as nexthop from getting installed in the BGP table.
Implemented IPV6 HASH table, where we need to add any ipv6 address as they
gets configured and delete them from the HASH table as the ipv6 addresses
get unconfigured. The above hash table is used to verify if any route learned
via BGP has nexthop which is equal to one of its its connected ipv6 interface.
Signed-off-by: Biswajit Sadhu sadhub@vmware.com
the json code has not been updated since a variety of new flags have
been added to the code base. Add those flags in so we can tell
what is going on sometimes.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The PIM-EVPN doc was not rendering very well on the
website. So Update documentation to allow it to render
better.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Add the ability to select on a S or G for a `show ip mroute`
command.
show ip mroute 225.1.1.111
show ip mroute 4.5.6.7 225.1.1.111
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Always when creating a new S,G state look at all possible ifchannels
to decide what the mroute should be.
The bug that this is fixing is this:
Suppose two incoming `*,G` joins on swp1, and swp2.
Now suppose that one of those ifchannel `*,G` sends a `*,G S,G RPT Prune`.
We were creating the S,G upstream state as we should but we were
only looking at the S,G ifchannel to decide the S,G mroute we would
be creating. As such what we need to do is to look over the associated
*,G ifchannels and allow us to associate correct oil needed.
Ticket: CM-24732
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* Reflow to 80 columns
* Improve markup
* Add --apiserver option to example ospfd invocations
* Add note on requirement of this option to use api server
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Start using the dataplane for interface-address programming,
on netlink platforms. Other platforms just stubbed at this
point.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Fixup in response to Jafar's review comments.
This is actually old code moved in from pimd to lib. But the fixup does
make sense.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
1. vxlan instance cleanup needs to be done before the upstream entries are
force-flushed.
2. also vxlan callbacks need to be ignored post instance-cleanup.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
The l2vni (bgpevpn instance) was maintaining a back pointer to the
tenant vrf without locking it. This would result in bgp_terminate crashing
as the tenant-vrf is released before the underlay-vrf (vpn->bgp_vrf->l2vnis
is NULL). Call stack -
BGP: [bt 3] /lib/libfrr.so.0(listnode_delete+0x11) [0x7f041c967f51]
BGP: [bt 4] /usr/lib/frr/bgpd(bgp_evpn_free+0x26) [0x55e3428eea46]
BGP: [bt 5] /lib/libfrr.so.0(hash_iterate+0x4a) [0x7f041c95f00a]
BGP: [bt 6] /usr/lib/frr/bgpd(bgp_evpn_cleanup+0x22) [0x55e3428f0a72]
BGP: [bt 7] /usr/lib/frr/bgpd(bgp_free+0x180) [0x55e342955f50]
PIM: vxlan SG (*,239.1.1.111) term mroute-up del
BGP: [bt 8] /usr/lib/frr/bgpd(bgp_delete+0x43a) [0x55e342959d7a]
BGP: [bt 9] /usr/lib/frr/bgpd(sigint+0xee) [0x55e3428d6a5e]
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by: Vivek Venkataraman <vivek@cumulusnetworks.com>
Reviewed-by: Chirag Shah <chirag@cumulusnetworks.com>
This was resulting in static analyzer warnings for subsequent usage
of the same pointer -
pimd/pim_vxlan.c:962:36: warning: Access to field 'info' results in a
dereference of a null pointer (loaded from variable 'ifp')
pim_ifp = (struct pim_interface *)ifp->info;
^~~~~~~~~
1 warning generated.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
The MLAG component on the switch is expected to provide some
properties (such as peerlink-rif) to bootstrap the anycast-VTEP
functionality. The final interface for this is being defined as
a part of the pim-mlag functionality.
This commit provides a hidden command to test the anycast-VTEP
functionality independent of the MLAG component.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Sample output:
root@TORS1:~# vtysh -c "show ip pim vxlan-groups"
Codes: I -> installed
Source Group Input Output Flags
27.0.0.7 239.1.1.101 lo I
* 239.1.1.100 - ipmr-lo I
* 239.1.1.101 - ipmr-lo I
27.0.0.7 239.1.1.100 lo I
root@TORS1:~#
root@TORS1:~# vtysh -c "show ip pim vxlan-work"
Codes: I -> installed
Source Group Input Flags
27.0.0.7 239.1.1.100 lo I
PS: note the worklist dump is a hidden command
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
The unique physical IP is used as the SIP in the ip header to ensure
that pim-register-stop makes it back to the right MLAG switch.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
1. peerlink-rif as OIF in origination mroutes -
Hosts are multi-homed to the anycast-VTEP pair and can send BUM traffic to
either switch. But the RP would have only joined one MLAG switch for
pulling down the MDT. To make that work we add the peerlink/ISL as
an OIF to origination mroutes (TORC11<=>TORC12 is an anycast VTEP pair) -
root@TORC11:~# ip mr |grep "(36.0.0.9, 239.1.1.100)"
(36.0.0.9, 239.1.1.100) Iif: peerlink-3.4094 Oifs: peerlink-3.4094 uplink-1
root@TORC11:~#
root@TORC12:~# ip mr |grep "(36.0.0.9, 239.1.1.100)"
(36.0.0.9, 239.1.1.100) Iif: peerlink-3.4094 Oifs: peerlink-3.4094
root@TORC12:~#
2. VTEP-PIP as register source -
TORC11 and TORC12 share the same anycast VTEP IP (36.0.0.9 in the above
example). And that is the source registered by both VTEPs for all the BUM
mcast-groups. However to allow the pim register start machine to close
the SIP in the register-pkt's IP header must be set to an unique IP address.
This is the VTEP PIP.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
1. special handling of term device in orig mroutes -
The multicast-vxlan termination device ipmr-lo is added to the (*, G)
mroute -
(0.0.0.0, 239.1.1.100) Iif: uplink-1 Oifs: uplink-1 ipmr-lo
This means that it will be inherited into all the SG entries including the
origination mroute. However we cannot terminate the traffic we originate
so some special handling is needed to exclude the termination device
in the origination entries -
27.0.0.7, 239.1.1.100) Iif: lo Oifs: uplink-1
2. special handling of term device on the MLAG pair -
Both MLAG switches pull down BUM-MDT traffic but only one (the DF) can
terminate the traffic. The non-DF must not exclude the termination device
from the MFC to prevent dups to the overlay.
DF -
root@TORC11:~# ip mr |grep "(0.0.0.0, 239.1.1.100)"
(0.0.0.0, 239.1.1.100) Iif: uplink-1 Oifs: uplink-1 ipmr-lo State: resolved
root@TORC11:~#
non-DF -
root@TORC12:~# ip mr |grep "(0.0.0.0, 239.1.1.100)"
(0.0.0.0, 239.1.1.100) Iif: uplink-1 Oifs: uplink-1 State: resolved
root@TORC12:~#
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
An interface needs to be designated as "termination device" and added to
the termination mroute's OIL. This is used by kernel and ASIC backends
to vxlan-decaps matching flows.
The default termination device is expected to have the prefix (start
sub-string) "ipmr-lo". This can be made configurable if needed -
root@TORS1:~# ip -d link show ipmr-lo
28: ipmr-lo: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default
link/ether 12:5a:ae:74:51:a2 brd ff:ff:ff:ff:ff:ff promiscuity 0
dummy addrgenmode eui64
root@TORS1:~# ip mr
This commit includes the changes to enable pim implicitly on the device
and set it up as the vxlan-term device per-pim-instance.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
