After a router reboot the L3 network via it converges before the L2
network. This is because MLAG intentionally holds down bridge-access
and vxlan-network ports for some time (MLAG init-delay) to prevent traffic
from switching to a router that is not fully ready. This also means that
routes (from vrf-peering sessions) that qualify for evpn type-5
advertisments are available long before the L3-VNI is available for that
tenant VRF. In these windows bgpd was adding these evpn-type-5 routes with
a L3-VNI of 0 (which was not fixed up after the L3-VNI became available) -
BGP routing table entry for 100.0.0.1:2:[5]:[0]:[0]:[32]:[200.1.1.1]
Paths: (1 available, best #1)
Advertised to non peer-group peers:
MSP1(uplink-1) MSP2(uplink-2)
Route [5]:[0]:[0]:[32]:[200.1.1.1] VNI 0 >>>>>>>>
65001 65535
36.0.0.9 from 0.0.0.0 (27.0.0.9)
Origin incomplete, metric 0, valid, sourced, local, bestpath-from-AS 65001, best
Extended Community: ET:8 RT:5544:4001 Rmac:44:38:39:ff:ff:01
AddPath ID: RX 0, TX 327
Last update: Wed Feb 27 18:37:10 2019
Fix is to defer creating type-5 routes till the L3-VNI is available for
that tenant VRF (this was already being done for most cases; fixup takes
care of some that missed the check).
Ticket: CM-24022
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
}
/* advertise type-5 routes */
- bgp_evpn_advertise_type5_routes(bgp_vrf, afi, safi);
+ if (advertise_type5_routes(bgp_vrf, afi))
+ bgp_evpn_advertise_type5_routes(bgp_vrf, afi, safi);
return CMD_SUCCESS;
}
"Processing route_map %s update on advertise type5 route command",
rmap_name);
- if (route_update) {
+ if (route_update && advertise_type5_routes(bgp, afi)) {
bgp_evpn_withdraw_type5_routes(bgp, afi, safi);
bgp_evpn_advertise_type5_routes(bgp, afi, safi);
}