NH tracking is already in use for type-1, type-3 and type-5 routes.
This change extends that tracking to EAD and ESR to eliminate the 9s
delay (BGP holdtimer) with ES/L2-NHG update seen when all the uplinks
are shutdown on a remote EVPN PE.
Ticket: #2682896
Signed-off-by: Anuradha Karuppiah <anuradhak@nvidia.com>
The BGP configuration for BGP EVPN RT5 setup consists in mainly
2 bgp instances (eventually one is enough) and L3VNI config.
When L3VNI is configured before BGP instances, and BGP route
targets are auto derived as per rfc8365, then, the obtained
route targets are wrong. For instance, the following can be
obtained:
=> show bgp vrf cust1 vni
BGP VRF: cust1
Local-Ip: 10.209.36.1
L3-VNI: 1000
Rmac: da:85:42:ba:2a:e9
VNI Filter: none
L2-VNI List:
Export-RTs:
RT:12757:1000
Import-RTs:
RT:12757:1000
RD: 65000:1000
whereas the derived route targets should be the below
ones:
=> show bgp vrf cust1 vni
BGP VRF: cust1
Local-Ip: 10.209.36.1
L3-VNI: 1000
Rmac: 72:f3:af:a0:98:80
VNI Filter: none
L2-VNI List:
Export-RTs:
RT:12757:268436456
Import-RTs:
RT:12757:268436456
RD: 65000:1000
There is an update handler that updates appropriately L2VNIs.
But this is not the case for L3VNIs. Add the missing code.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
when doing BGP over an IGP platform, the expectation is that
the path calculation for a given prefix takes into account the
igpmetric given by IGP.
This is true with prefixes obtained in a given BGP instance where
peering occurs. For instance, ipv4 unicast entries or l2vpn evpn
entries work this way. The igpmetric is obtained through nexthop
tracking, like below:
south-vm# show bgp nexthop
Current BGP nexthop cache:
1.1.1.1 valid [IGP metric 10], #paths 1, peer 1.1.1.1
2.2.2.2 valid [IGP metric 20], #paths 1, peer 2.2.2.2
The igp metric is taken into account when doing best path
selection, and only the entry with lowest igp wins.
[..]
*>i[5]:[0]:[32]:[5.5.5.5]
1.1.1.1 0 100 0 ?
RT:65400:268435556 ET:8 Rmac:2e:22:6c:67:bb:73
* i 2.2.2.2 0 100 0 ?
RT:65400:268435556 ET:8 Rmac:f2:d3:68:4e:f4:ed
however, for imported EVPN RT5 entries, the igpmetric was not
copied from the parent path info. Fix it. In this way, the
imported route entries use the igpmetric of the parent pi.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
There is no need to test for null values in the hash compare
function as that we are guaranteed to send in data in
the hash compare functions.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
There is no need to test for null values in the hash compare
function as that we are guaranteed to send in data in
the hash compare functions.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Some BGP updates received by BGP invite local router to
install a route through itself. The system will not do it, and
the route should be considered as not valid at the earliest.
This case is detected on the zebra, and this detection prevents
from trying to install this route to the local system. However,
the nexthop tracking mechanism is called, and acts as if the route
was valid, which is not the case.
By detecting in BGP that use case, we avoid installing the invalid
routes.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Gateway IP overlay index of the remote type-5 route is resolved
recursively using remote type-2 route. For the purpose of this
recursive resolution, for each L2VNI, we build a hash table of the
remote IP addresses received by remote type-2 routes.
For the topologies where overlay index resolution is not needed, we
do not need to build this remote-ip-hash.
Thus, make the recursive resolution of the overlay index conditional on
"enable-resolve-overlay-index" configuration.
router bgp 65001
bgp router-id 192.168.100.1
neighbor 10.0.1.2 remote-as 65002
!
address-family l2vpn evpn
neighbor 10.0.1.2 activate
advertise-all-vni
enable-resolve-overlay-index----------> New configuration
exit-address-family
Gateway IP overlay index will be resolved only if this configuration is present.
Signed-off-by: Ameya Dharkar <adharkar@vmware.com>
When EVPN prefix route with a gateway IP overlay index is imported into the IP
vrf at the ingress PE, BGP nexthop of this route is set to the gateway IP.
For this vrf route to be valid, following conditions must be met.
- Gateway IP nexthop of this route should be L3 reachable, i.e., this route
should be resolved in RIB.
- A remote MAC/IP route should be present for the gateway IP address in the
EVI(L2VPN table).
To check for the first condition, gateway IP is registered with nht (nexthop
tracking) to receive the reachability notifications for this IP from zebra RIB.
If the gateway IP is reachable, zebra sends the reachability information (i.e.,
nexthop interface) for the gateway IP.
This nexthop interface should be the SVI interface.
Now, to find out type-2 route corresponding to the gateway IP, we need to fetch
the VNI for the above SVI.
To do this VNI lookup effitiently, define a hashtable of struct bgpevpn with
svi_ifindex as key.
struct hash *vni_svi_hash;
An EVI instance is added to vni_svi_hash if its svi_ifindex is nonzero.
Using this hash, we obtain struct bgpevpn corresponding to the gateway IP.
For gateway IP overlay index recursive lookup, once we find the correct EVI, we
have to lookup its route table for a MAC/IP prefix. As we have to iterate the
entire route table for every lookup, this lookup is expensive. We can optimize
this lookup by adding all the remote IP addresses in a hash table.
Following hash table is defined for this purpose in struct bgpevpn
Struct hash *remote_ip_hash;
When a MAC/IP route is installed in the EVI table, it is also added to
remote_ip_hash.
It is possible to have multiple MAC/IP routes with the same IP address because
of host move scenarios. Thus, for every address addr in remote_ip_hash, we
maintain list of all the MAC/IP routes having addr as their IP address.
Following structure defines an address in remote_ip_hash.
struct evpn_remote_ip {
struct ipaddr addr;
struct list *macip_path_list;
};
A Boolean field is added to struct bgp_nexthop_cache to indicate that the
nexthop is EVPN gateway IP overlay index.
bool is_evpn_gwip_nexthop;
A flag BGP_NEXTHOP_EVPN_INCOMPLETE is added to struct bgp_nexthop_cache.
This flag is set when the gateway IP is L3 reachable but not yet resolved by a
MAC/IP route.
Following table explains the combination of L3 and L2 reachability w.r.t.
BGP_NEXTHOP_VALID and BGP_NEXTHOP_EVPN_INCOMPLETE flags
* | MACIP resolved | MACIP unresolved
*----------------|----------------|------------------
* L3 reachable | VALID = 1 | VALID = 0
* | INCOMPLETE = 0 | INCOMPLETE = 1
* ---------------|----------------|--------------------
* L3 unreachable | VALID = 0 | VALID = 0
* | INCOMPLETE = 0 | INCOMPLETE = 0
Procedure that we use to check if the gateway IP is resolvable by a MAC/IP
route:
- Find the EVI/L2VRF that belongs to the nexthop SVI using vni_svi_hash.
- Check if the gateway IP is present in remote_ip_hash in this EVI.
When the gateway IP is L3 reachable and it is also resolved by a MAC/IP route,
unset BGP_NEXTHOP_EVPN_INCOMPLETE flag and set BGP_NEXTHOP_VALID flag.
Signed-off-by: Ameya Dharkar <adharkar@vmware.com>
SVI ifindex for L2VNI is required in BGP to perform EVPN type-5 to type-2
recusrsive resolution using gateway IP overlay index.
Program this svi_ifindex in struct zebra_vni_t as well as in struct bgpevpn
Changes include:
1. Add svi_if field to struct zebra_evpn_t
2. Add svi_ifindex field to struct bgpevpn
3. When SVI (bridge or VLAN) is bound to a VxLAN interface, store it in the
zebra_evpn_t structure.
4. Add this SVI ifindex to ZEBRA_VNI_ADD
5. Store svi_ifindex in struct bgpevpn
Signed-off-by: Ameya Dharkar <adharkar@vmware.com>
The IP/IPv6 prefix carried with EVPN RT-5 is imported in the BGP vrf according
to the attached route targets.
If the prefix carries a gateway IP overlay index, this gateway IP should be
installed as the nexthop of the route imported in the BGP vrf.
This route in vrf will be marked as VALID only if the nexthop is resolved in the
SVI network.
To receive runtime reachability information for the nexthop, register it with
the nexthop tracking module.
Send this route to zebra after processing.
Signed-off-by: Ameya Dharkar <adharkar@vmware.com>
While installing this route in the EVPN table, make sure all the conditions
mentioned in the draft
https://tools.ietf.org/html/draft-ietf-bess-evpn-prefix-advertisement-11 are
met.
Draft mentions following conditions:
- ESI and gateway IP cannot be both nonzero at the same time.
- ESI, gateway IP, RMAC and VNI label all cannot be 0 at the same time.
If the received EVPN RT-5 route does not meet these conditions, the route is
treated as withdraw.
Signed-off-by: Ameya Dharkar <adharkar@vmware.com>
Gateway IP overlay index is generated for EVPN RT-5 when following CLI is
configured.
router bgp 100 vrf vrf-blue
address-family l2vpn evpn
advertise ipv4 unicast gateway-ip
advertise ipv6 unicast gateway-ip
BGP nexthop of the VRF IP/IPv6 route is set as the gateway IP of the
corresponding EVPN RT-5
Signed-off-by: Ameya Dharkar <adharkar@vmware.com>
This is always a 16 bit unsigned value.
- signed int is the wrong type to use
- encoding a signed int as a uint32 is bad practice
- decoding a signed int encoded as a uint32 into a uint16 is bad
practice
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
When VNI RD changes, EAD/EVI routes with old RD should be withdrawn from
the global routing table and EAD/EVI routes in the VNI should be
advertised with the new RD.
Signed-off-by: Ameya Dharkar <adharkar@vmware.com>
There are multiple problems:
- commit ef7c53e2 introduced a new return value 2 which broke things,
because a lot of code treats non-zero return as an error,
- there is an incorrect error returned when AS number mismatches.
This commit fixes both.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
When validating a MACIP route's IP address,
bgp_evpn_route_add_l3_ecomm_ok checked for a non link-local v6 address
without checking if the v6 address existed. Since empty v6 addresses
do not fall into the fe80 range, MAC-Only routes were always passing
this check and getting IP-VRF extended communities (RMAC/IP-VRF RT)
added to the routes.
This commit requires ipaddr_v6 to exist AND fall outside of the
link-local range for IP-VRF ext-comms to be added.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
1. When a local ES is deleted or the ES-bond goes into bypass we treat
imported MAC-IP routes with that ES destination as remote routes instead
of sync routes. This requires a re-evaluation of the routes as
"non-local-dest" and an update to zebra.
2. When a ES is attached to an access port or the ES-bond transitions from
bypass to LACP-up we treat imported MAC-IP routes with that ES destination as
sync routes. This requires a re-evaluation of the routes as
"local-dest" and an update to zebra.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
In the case of EVPN type-2 routes that use ES as destination, BGP
consolidates the nh (and nh->rmac mapping) and sends it to zebra as
a nexthop add.
This nexthop is the EVPN remote PE and is created by reference of
VRF IPvx unicast paths imported from EVPN Type-2 routes.
zebra uses this nexthop for setting up a remote neigh enty for the PE
and a remote fdb entry for the PE's RMAC.
Ticket: CM-31398
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
There are two changes in this commit -
1. Maintain a list of global MAC-IP routes per-ES. This list is maintained
for quick processing on the following events -
a. When the first VTEP/PE becomes active in the ES-VRF, the L3 NHG is
activated and the route can be sent to zebra.
b. When there are no active PEs in the ES-VRF the L3 NHG is
de-activated and -
- If the ES is present in the VRF -
The route is not installed in zebra as there are no active PEs for
the ES-VRF
- If the ES is not present in the VRF -
The route is installed with a flat multi-path list i.e. without L3NHG.
This is to handle the case where there are no locally attached L2VNIs
on the ES (for that tenant VRF).
2. Reinstall VRF route when an ES is installed or uninstalled in a
tenant VRF (the global MAC-IP list in #1 is used for this purpose also).
If an ES is present in the VRF we use L3NHG to enable fast-failover of
routed traffic.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
In a sym-IRB setup the remote ES may not be installed if the tenant
VRF is not present locally. To allow that case while retaining the
fast-failover benefits for the case where the tenant VRF is locally
present we use the following approach -
1. If ES is present in the tenant VRF we use the L3NHG for installing
the MAC-IP based tenant route. This allows for efficient failover via
L3NHG updates.
2. If the ES is not present locally in the corresponding tenant VRF we
fall back to a non-NHG multi-path based routing approach. In this
case individual routes are updated when the ES links flap.
PS: #1 can be turned off entirely by disabling use-l3-nhg in BGP.
Ticket: CM-30935
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
When an ES goes down the MAC-IP route must be updated to remove it from
the tenant VRF routing table. This is because the fast-failover
(via EAD-per-ES withdraw) procedures described in RFC 7432 are only
applicable to L2 forwarding/MAC-ECMP. For L3/routed traffic (in a
sym-IRB setup) failover, individual paths need to be withdrawn.
To handle this difference in L2/L3 requirements BGP updates the MAC-IP
route to include the L3 ECOM if local destination ES is oper-up and
to exclude the L3 ECOM if local ES is oper-down.
Ticket: CM-30935
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
1. When VNI export RT changes, for each local es_evi, update local
EAD/ES and EAD/EVI routes and advertise.
2. When VNI import RT changes, uninstall all type-1 routes imported in
the VNI and import routes carrying the updated RT.
Signed-off-by: Ameya Dharkar <adharkar@vmware.com>
Neither tabs nor newlines are acceptable in syslog messages. They also
break line-based parsing of file logs.
Signed-off-by: David Lamparter <equinox@diac24.net>
The `struct ecommunity` structure is using an int for a size value.
Let's switch it over to a uint32_t for size values since a size
value for data can never be negative.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
evpn route-map match (filter) on vni is not working
at the origin of the routes.
evpn match vni route checks for encap type as vxlan.
the source route attribute is not set with vxlan encap
thus the match filter wouldn't work.
Ticket:CM-32554
Reviewed By:CCR-11056
Testing Done:
At source have match vni plus set statement in route-map.
Validate the origin of the route's outbound correctly sets
the 'set' statment based on match vni filter.
At origin:
route-map RM-EVPN-TE-Matches permit 10
match evpn vni 4001
set large-community 10:10:119
Receiving end:
Route [5]:[0]:[24]:[78.41.1.0] VNI 4001
5550
27.0.0.15 from TORS1(downlink-5) (27.0.0.15)
Origin incomplete, metric 0, valid, external, bestpath-from-AS 5550, best (First path received)
Extended Community: RT:5550:4001 ET:8 Rmac:00:02:00:00:00:4d
Large Community: 10:10:119 <--- Large community stamped
Last update: Thu Dec 10 22:19:26 2020
Signed-off-by: Chirag Shah <chirag@nvidia.com>
Two L3 next groups are installed per-VRF per-ES for v4 and v6. These
NHGs are used as an indirect destination for symmetric IRB host routes.
Using L3NHGs allows for efficient failover of an ES (similar to the
use of L2NHGs) i.e. when an ES goes down the number of dataplane
updates are limited to 2xN (where N is the number of tenant VRFs
associated with the ES) instead of updating all host-routes behind the
ES.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
1. MAC-IP routes in the VPN routing table are linked to the
destination ES for efficient handling for remote ES link flaps.
2. Only MAC-IP paths whose nexthops are active (added via EAD-ES)
are imported into the VRF routing table.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Local attached hosts are routed via the access ports using the neigh and
fdb/MAC dplane entries.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Convert usage of the attr->evpn_overlay to get/set functionality.
Future commits will allow us to abstract this data to when
we actually need it for the `struct attr`.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Add an accessor for the bgp_attr.pmsi_tnl_type to allow
us to abstract where it is. Every attribute is paying
the price of this bit of data as part of `struct bgp_attr`
In the future we'll move it elsewhere.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When iterating over the bgp_dest table, using this pattern:
for (dest = bgp_table_top(table); dest;
dest = bgp_route_next(dest)) {
If the code breaks or returns in the middle we will not have
properly unlocked the node as that bgp_table_top locks the top
dest and bgp_route_next locks the next dest and unlocks the old
dest.
From code inspection I have found a bunch of places that
we either return in the middle of or a break is issued.
Add appropriate unlocks.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The route_map_object_t was being used to track what protocol we were
being called against. But each protocol was only ever calling itself.
So we had a variable that was only ever being passed in from route_map_apply
that had to be carried against and everyone was testing if that variable
was for their own stack.
Clean up this route_map_object_t from the entire system. We should
speed some stuff up. Yes I know not a bunch but this will add up.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Create appropriate accessor functions for the rn->lock
data. We should be accessing this data through accessor
functions since it is private data to the data structure.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
