From a BGP perspective, the two BGP instances configured in the service are independent of each other. The redistribution of routes between the BGP instances is resolved at the EVPN application layer.
By default, if EVPN-VXLAN and EVPN-MPLS are both enabled in the same service, BGP sends the generated EVPN routes twice: with the RFC 9012 BGP encapsulation extended community set to VXLAN and a second time with the encapsulation type set to MPLS.
Usually, a DCGW peers a pair of Route Reflectors (RRs) in the DC and a pair of RRs in the WAN. For this reason, the user needs to add router policies so that EVPN-MPLS routes are only sent to the WAN RRs and EVPN-VXLAN routes are only sent to the DC RRs. The following examples show how to configure router policies.
config>router>bgp#
vpn-apply-import
vpn-apply-export
group "WAN"
family evpn
type internal
export "allow only mpls"
neighbor 192.0.2.6
group "DC"
family evpn
type internal
export "allow only vxlan"
neighbor 192.0.2.2
config>router>policy-options# info
----------------------------------------------
community "vxlan" members "bgp-tunnel-encap:VXLAN"
community "mpls" members "bgp-tunnel-encap:MPLS"
policy-statement "allow only mpls"
entry 10
from
family evpn
community vxlan
action drop
exit
exit
exit
policy-statement "allow only vxlan"
entry 10
from
family evpn
community mpls
action drop
exit
exit
exit
In a BGP instance, the EVPN routes are imported based on the route-targets and regular BGP selection procedures, regardless of their encapsulation.
The BGP-EVPN routes are generated and redistributed between BGP instances based on the following rules:
Auto-discovery (AD) routes (type 1) are not generated by services with two BGP EVPN instances, unless a local Ethernet segment is present on the service. However, AD routes received from the EVPN-MPLS peers are processed for aliasing and backup functions as usual.
MAC/IP routes (type 2) received in one of the two BGP instances are imported and the MACs added to the FDB according to the existing selection rules. If the MAC is installed in the FDB, it is readvertised in the other BGP instance with the new BGP attributes corresponding to the BGP instance (route target, route distinguisher, and so on). The following considerations apply to these routes:
The mac-advertisement command governs the advertisement of any MACs (even those learned from BGP).
A MAC route is redistributed only if it is the best route based on the EVPN selection rules.
If a MAC route is the best route and has to be redistributed, the MAC/IP information, along with the MAC mobility extended community, is propagated in the redistribution.
The router redistributes any MAC route update for which any attribute has changed. For example, a change in the SEQ or sticky bit in one instance is updated in the other instance for a route that is selected as the best MAC route.
EVPN inclusive multicast routes are generated independently for each BGP instance with the corresponding BGP encapsulation extended community (VXLAN or MPLS). Also, the following considerations apply to these routes:
Ingress Replication (IR) and Assisted Replication (AR) routes are supported in the EVPN-VXLAN instance. If AR is configured, the AR IP address must be a loopback address different from the system-ip and the configured originating-ip address.
IR, P2MP mLDP, and composite inclusive multicast routes are supported in the EVPN-MPLS instance.
The modification of the incl-mcast-orig-ip command is supported, subject to the following considerations:
The configured IP in the incl-mcast-orig-ip command is encoded in the originating-ip field of the inclusive multicast Routes for IR, P2MP, and composite tunnels.
The originating-ip field of the AR routes is still derived from the service>system>vxlan>assisted-replication-ip configured value.
EVPN handles the inclusive multicast routes in a service based on the following rules:
For IR routes, the EVPN destination is set up based on the NLRI next hop.
For P2MP mLDP routes, the PMSI Tunnel Attribute tunnel-id is used to join the mLDP tree.
For composite P2MP-IR routes, the PMSI Tunnel Attribute tunnel-id is used to join the tree and create the P2MP bind. The NLRI next-hop is used to build the IR destination.
For AR routes, the NLRI next-hop is used to build the destination.
If the routes have the same originating-ip but different route distinguishers and next-hops, the router processes both routes. In the case of IR routes, it sets up two destinations: one to each next-hop.
If the routes have the same originating-ip, different route distinguishers, but same next hops, the router sets up only one binding for IR routes.
The router ignores inclusive multicast routes received with its own originating-ip, regardless of the route distinguisher.
IP-Prefix routes (type 5) are not generated or imported by a service with two BGP instances.