saravanank [Sat, 4 May 2019 17:21:02 +0000 (10:21 -0700)]
pimd: store PIM bootstrap message in list and forward if no_fwd not set
If no_fwd bit not set,
forward on all interfaces including which it came.
store it in bsm list with size for forwarding it later to new neighbor.
calculate PIM mtu of the interface, if bsm size is more do sematic frag and send
Signed-off-by: Saravanan K <saravanank@vmware.com>
saravanank [Sat, 4 May 2019 16:46:14 +0000 (09:46 -0700)]
pimd: Instate partial rp_list(when its full) to bsrp_list(main list).
When all rp received on a partial list, this routine is called.
if static rp configured for the group range
if partial list is empty
clean main list and partial list
else
replace main with partial and start the g2rp timer with head of new main
return
if main list was empty
call rp new with head of partial list and start g2rp timer.
else
if partial list is empty
call rp del
else
stop g2rp timer of old elected rp.
call rp change with new rp(head of partial list) and start g2rp timer.
swap the lists and clean the old list(now partial list).
Signed-off-by: Saravanan K <saravanank@vmware.com>
saravanank [Sat, 4 May 2019 14:14:24 +0000 (07:14 -0700)]
pimd: Parse the grp2rp mapping from BSM pkt and add to partial rp list
Bootstrap rp table is route_table datastructure with group range as key.
Each node represents a group range.
Every node has two lists of rp nodes. partial list and active list(bsrp_list)
Whenever a rp is parsed from BSM, it is updated to partial list.
When partial list is full, we move it to main list(bsrp_list). This commit doesn't cover that.
Rp Election routine based on RFC 7761 Sec 4.7
Hash calculation for rp election based on RFC 7761 Sec 4.7.2
Signed-off-by: Saravanan K <saravanank@vmware.com>
saravanank [Sat, 4 May 2019 13:04:17 +0000 (06:04 -0700)]
pimd: PIM Bootstrap packet processing
1. Packet validation as per RFC 5059 Sec 3.1.3
We won't supporting scope zone BSM as of now, they are dropped now.
Order of the check slightly be changed in code for optimization.
if ((DirectlyConnected(BSM.src_ip_address) == FALSE) OR
(we have no Hello state for BSM.src_ip_address)) {
drop the Bootstrap message silently
}
if (BSM.dst_ip_address == ALL-PIM-ROUTERS) {
if (BSM.no_forward_bit == 0) {
if (BSM.src_ip_address != RPF_neighbor(BSM.BSR_ip_address)) {
drop the Bootstrap message silently
}
} else if ((any previous BSM for this scope has been accepted) OR
(more than BS_Period has elapsed since startup)) {
#only accept no-forward BSM if quick refresh on startup
drop the Bootstrap message silently
}
} else if ((Unicast BSM support enabled) AND
(BSM.dst_ip_address is one of my addresses)) {
if ((any previous BSM for this scope has been accepted) OR
(more than BS_Period has elapsed since startup)) {
#the packet was unicast, but this wasn't
#a quick refresh on startup
drop the Bootstrap message silently
}
} else {
drop the Bootstrap message silently
}
2. Nexthop tracking registration for BSR
3. RPF check for BSR Message.
Zebra Lookup based rpf check for new BSR
NHT cache(pnc) based lookup for old BSR
Signed-off-by: Saravanan K <saravanank@vmware.com>
saravanank [Sat, 4 May 2019 12:07:39 +0000 (05:07 -0700)]
pimd: PIM Msg header includes N bit as defined by RFC
This commit includes parsing of Nbit and contructing pim hdr with Nbit
Adding Nbit to PIm hdr structure
Adding Scope zone bit and Bidir bit to Encoded IPv4 Group Address
Signed-off-by: Saravanan K <saravanank@vmware.com>
When bs time out occurs,
1. Delete the bsm list
2. Reset the BSR address
3. delete nexthop tracking for the expired BSR
4. Give one more lease of life to all the bsr advertised rp with hold time
5. clear partial list of each grp node if not empty
Signed-off-by: Saravanan K <saravanank@vmware.com>
DS Overview:
Bootstrap RP table has grp node.
scope --> rp table --> grp node1 --> rp list --> rp nodes(g2rp timer)
|
-------> grp node2 --> rp list --> rp nodes(g2rp timer)
When grp2rp mapping expires, following has to be done.
1. delete the rp node from the active bs-rp list in the list
2. calculate the elapsed time for other rp nodes in the list
3. delete those nodes having more elapse time than their hold time
4. If the list is not empty and current rp src is not static
rp change with new rp(head) & start g2rp timer with value holdtime - elapse
5. If the list is empty and current rp src for the grp is not static
delete the rp
6. If the list is not empty and current rp is static, just start the
g2rp timer with value holdtime - elapse
7. If list is empty and pending list is empty, delete grp node.
Note: g2rp timer will be run only on elected RP node for optimization.
when it expires, other node are update with elapse time.
This list is sorted insuch way that elected RP is the HEAD of list
Signed-off-by: Saravanan K <saravanank@vmware.com>
saravanank [Fri, 3 May 2019 13:57:57 +0000 (06:57 -0700)]
lib: implement utility function API which does the following
1. listnode_add_sort_nodup - This API adds to list only if no duplicate
element available in the list. returns true/false
2. list_filter_out_nodes - This API deletes the nodes which satisfy the given
condition. condition is passed as a func ptr in
API. This function takes in node data(void ptr).
Signed-off-by: Saravanan K <saravanank@vmware.com>
saravanank [Fri, 3 May 2019 08:19:48 +0000 (01:19 -0700)]
pimd: Implementation of show ip pim bsr command
Command to display current bsr, last received bsm ts, bsr uptime
Sw3# sh ip pim bsr
PIMv2 Bootstrap information
Current preferred BSR address: 30.0.0.100
Priority Fragment-Tag State UpTime
0 6390 ACCEPT_PREFERRED 91:26:24
Last BSM seen: 00:00:37
Signed-off-by: Saravanan K <saravanank@vmware.com>
pim_rp_new split into pim_rp_new_config and pim_rp_new.
pim_rp_new_config is called by CLI.
pim_rp_new will be called by pim_rp_new_config and bsm rp config.
pim_rp_del is split into pim_rp_del_config and pim_rp_del
pim_rp_del_config is called by CLI.
pim_rp_del is called by pim_rp_del_config and bsm rp config
Signed-off-by: Saravanan K <saravanank@vmware.com>
saravanank [Thu, 2 May 2019 15:04:47 +0000 (08:04 -0700)]
pimd: interface commands to enable/disable bsm processing
(intf)ip pim bsm - to enable bsm processing on the interface
(intf)no ip pim bsm - to disable bsm processing on the interface
(intf)ip pim unicast-bsm - to enable ucast bsm processing on the interface
(intf)no ip pim unicast-bsm - to disable ucast bsm processing on the interface
Note: bsm processing and ucast bsm processing is enabled by default on a
pim interface. The CLI is implemented as a security feature as recommended by
RFC 5059
Signed-off-by: Saravanan K <saravanank@vmware.com>
saravanank [Thu, 2 May 2019 08:35:35 +0000 (01:35 -0700)]
pimd: Show RP source in show ip pim rp-info command
Sw3# sh ip pim rp-info
RP address group/prefix-list OIF I am RP Source
20.0.0.2 225.1.1.1/32 ens192 no BSR
9.9.9.9 226.1.1.1/32 (Unknown) no BSR
30.0.0.100 229.1.1.5/32 ens192 no Static
Signed-off-by: Saravanan K <saravanank@vmware.com>
saravanank [Thu, 2 May 2019 07:48:27 +0000 (00:48 -0700)]
pimd: Implement nexthop match where if given address match any of the next hop in ecmp case
For each BSM packet, rpf check is performed. We will be accepting if the
source address match any of the next hop neighbor(in ecmp case) to reach
the Bootstrap Router.
1. pim_nexthop_match - this lookup in zebra and return true if any of the
next hop nbr is matching (in ecmp case).
2. pim_nexthop_match_nht_cache - this api searches the given address in local
pnc and return true if any of the next hop
nbr is matching (in ecmp case).
Signed-off-by: Saravanan K <saravanank@vmware.com>
Quentin Young [Wed, 24 Apr 2019 17:23:12 +0000 (17:23 +0000)]
doc: add copyright notice from Ralph Keller
Ralph has kindly granted us GPLv2+ license to use this documentation,
and requests that we keep a reference to his name. Add these facts to
the documentation.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Donald Sharp [Mon, 22 Apr 2019 21:36:58 +0000 (17:36 -0400)]
pimd: When creating new upstream state, figure out what we should join
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>
Quentin Young [Mon, 22 Apr 2019 20:22:00 +0000 (20:22 +0000)]
doc: cleanup OSPF API server documentation
* 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>
pim: fix order of vxlan mroutes cleanup when pimd is shutdown
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.
bgpd: lock the tenant-vrf associated with the l2-vni
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]
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.
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.
pimd: display commands for the pim-vxlan-sg database and worklist
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
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.
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:~#
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.
pimd: add termination mroutes for each vxlan multicast tunnels
To terminate a multicast VxLAN tunnel entry we setup a mroute with
ipmr-lo in the OIL -
(0.0.0.0, 239.1.1.100) Iif: uplink-1 Oifs: uplink-1 ipmr-lo
This is done by the vxlan component that add ipmr-lo as a local
member to termination SG entries. In addition termination entries
are also subject to MLAG DF election on the anycast VxLAN-AA setup.
pimd: MLAG flag defintions in the PIM upstream entries
Two flags have been introduced per-upstream entry -
1. XXX_MLAG_VXLAN - This indicates that MLAG DF (designated-forwarded)
election is needed on the entry. In the case of pim-evpn this flag is set
for termination (*, G) entries and will be inherited by the (S, G) entries
that are created as a result of SPT switchover on the G.
2. XXX_MLAG_NON_DF - This is set on entries that have lost the
DF election. Such entries are primarily used for blackholing traffic on
one of the MLAG switches. On a hardware accelerated switch this blackholing
happens in the ASIC preventing (non-needed) traffic hitting the CPU.
pimd: register local VTEP-IP for each BUM MDT via NULL registers
For multicast vxlan tunnels we register the local VTEP-IP independent
of the prescence of BUM traffic i.e. we prime the pump. This
is acheived via NULL registers.
VxLAN orig entries with upstream in a PIM_REG_JOIN state are linked to
a work list for periodic NULL register transmission. Once the SPT setup
is complete the upstream-entry moves to a PIM_REG_PRUNE state and is
remved from the VxLAN work list.
pimd: add peerlink-rif to the origination-mroute's OIL
In a PIM MLAG setup (say L11<->L12 is the anycast VTEP pair) the RP
can choose to join either MLAG switch as the anycast VTEP-IP is
present on both. Let's say the RP joins L11.
Hosts are dual connected to L11<->L12 and can send traffic to either
switch. Let's say a host sends broadcast traffic to L12; now L12
must encapsulate and send the traffic toward L11. To do that the
origination-mroute on L12 must include the ISL in its OIL -
(36.0.0.9, 239.1.1.100) Iif: peerlink-3.4094 Oifs: peerlink-3.4094
L11 has a similar mroute -
(36.0.0.9, 239.1.1.100) Iif: peerlink-3.4094 Oifs: peerlink-3.4094 uplink-1
This mroute is used to rx traffic on peerlink-3.4094 and send it out of
uplink-1. Note that this mroute also includes the peerlink-rif in its
OIL. Explicit removal of IIF from OIL is done by the kernel (and other
dataplanes) to prevent traffic looping.
pimd: support for vxlan origination-upstream entries
For every (local-vtep-ip, bum-mcast-grp) registered by evpn an origination
mroute is setup by pimd. The purpose of this mroute is to forward vxlan
encapsulated BUM -
Sample mroute (single VTEP):
(27.0.0.7, 239.1.1.100) Iif: lo Oifs: uplink-1
Sample mroute (anycast VTEP):
(36.0.0.9, 239.1.1.100) Iif: peerlink-3.4094\
Oifs: peerlink-3.4094 uplink-1
This commit is part-1 of orignation mroute setup and includes setup
of upstream entries with vxlan properties.
pimd: header changes to cache MLAG information needed for pim-vxlan
This information will come in from a MLAG component. Hidden commands
will also be provided for testing the interface independent of the
separate MLAG component.
PS: It is possible that this cache will be merged with the base
pim-mlag datastructures once they are available.
pimd: vxlan definitions for creation origination and terminatiom mroutes
pim vxlan component will create upstream entries and OIFs for
multicast VxLAN tunnel origination and termination in single-VTEP
and anycast-VTEP (MLAG) setups.
pimd: API for enabling pim on the vxlan term device ipmr-lo
ipmr-lo is a dummy netdev with no additional addressing requirements -
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:~#
This device is used by pim-vxlan to signify multicast-vxlan-tunnel
termination.
In an anycast VTEP setup the peerlink-rif (ISL) is added as a OIF to the
tunnel origination mroute. A new OIF protocol, VxLAN, has been added to
allow that functionalty.
pimd: definition of pim-evpn origination and termination devices
Two devices have special significance to multicast VxLAN tunnels -
1. tunnel origination device -
This device is used as the source device to vxlan-encapsulate BUM traffic.
In the case of the default-vrf this is lo. And in the case of non-default
VRF this is vrf-net-device. This patchset is limited to default-VRF
underlay so all subsequent references of origination-dev are to lo. But it
is possible in the future to extend support to non-default VRFs.
Sample origination mroute on single-VTEP:
(27.0.0.7, 239.1.1.100) Iif: lo Oifs: uplink-1
In the case of MLAG we need to mroute traffic form the MLAG-peer so
we force the IIF to the ISL.
Sample origination mroute on MLAG-VTEP:
(36.0.0.9, 239.1.1.100) Iif: peerlink-3.4094 Oifs: peerlink-3.4094 uplink-1
2. tunnel termination device -
This device is used in the OIL to indicate that packets matching the flow
must be vxlan terminated and overlay packets subsequently forward to the
tenants. A special device has been created for this purpose called ipmr-lo.
This is a simple dummy interface from the kernel perspective which has
special siginficance only to pimd which implicitly enabled pim on the
device and adds it to the termination mroutes.
Sample termination mroute:
(0.0.0.0, 239.1.1.100) Iif: uplink-1 Oifs: uplink-1 ipmr-lo
PS: currently we default the termination device name to "ipmr-lo" but in
the future it is possible to provide a config command to set the
termination device.
pimd: per-SG control to allow any router to register itself as source
In a VxLAN-AA setup both the anycast VTEPS can send VxLAN encapsulated
traffic. This is despite the fact that the it is not-DR on the IIF
associated with the originating mroute.
projects / matthieu / frr.git / log