Figure: Multihomed anycast solution shows the anycast mechanism used to support gateway redundancy for dual BGP-instance services. The example shows two redundant DC gateways (DCGWs) where the VPLS services contain two BGP instances: one each for EVPN-VXLAN and EVPN-MPLS.
The example shown in Figure: Multihomed anycast solution depends on the ability of the two DCGWs to send the same inclusive multicast route to the remote PE or NVEs, such that:
-
The remote PE or NVEs create a single BUM destination to one of the DCGWs (because the BGP selects only the best route to the DCGWs).
-
The DCGWs do not create a destination between each other.
This solution avoids loops for BUM traffic, and known unicast traffic can use either DCGW router, depending on the BGP selection. The following CLI example output shows the configuration of each DCGW.
/* bgp configuration on DCGW1 and DCGW2 */
config>router>bgp#
group ”WAN"
family evpn
type internal
neighbor 192.0.2.6
group ”DC"
family evpn
type internal
neighbor 192.0.2.2
/* vpls service configuration */
DCGW-1# config>service>vpls(1)#
-----------------------
bgp
route-distinguisher 64501:12
route-target target:64500:1
exit
bgp 2
route-distinguisher 64502:12
route-target target:64500:1
exit
vxlan instance 1 vni 1 create
exit
bgp-evpn
evi 1
incl-mcast-orig-ip 10.12.12.12
vxlan bgp 1 vxlan-instance 1
no shutdown
mpls bgp 2
no shutdown
auto-bind-tunnel
resolution any
exit
<snip>
DCGW-2# config>service>vpls(1)#
-----------------------
bgp
route-distinguisher 64501:12
route-target target:64500:1
exit
bgp 2
route-distinguisher 64502:12
route-target target:64500:1
exit
vxlan instance 1 vni 1 create
exit
bgp-evpn
evi 1
incl-mcast-orig-ip 10.12.12.12
vxlan bgp 1 vxlan-instance 1
no shutdown
mpls bgp 2
no shutdown
auto-bind-tunnel
resolution any
<snip>
Based on the preceding configuration example, the behavior of the DCGWs in this scenario is as follows:
-
DCGW-1 and DCGW-2 send inclusive multicast routes to the DC RR and WAN RR with the same route key. For example:
-
DCGW-1 and DCGW-2 both send an IR route to DC RR with RD=64501:12, orig-ip=10.12.12.12, and a different next-hop and tunnel ID
-
DCGW-1 and DCGW-2 both send an IR route to WAN RR with RD=64502:12, orig-ip=10.12.12.12, and different next-hop and tunnel ID
-
-
DCGW-1 and DCGW-2 both receive MAC/IP routes from DC and WAN that are redistributed to the other BGP instances, assuming that the route is selected as best route and the MAC is installed in the FDB.
As described in section BGP-EVPN routes in services configured with two BGP instances, router peer policies are required so that only VXLAN or MPLS routes are sent or received for a specific peer.
-
Configuration of the same incl-mcast-orig-ip address in both DCGWs enables the anycast solution for BUM traffic for all the following reasons:
-
The configured originating-ip is not required to be a reachable IP address and this forces the remote PE or NVEs to select only one of the two DCGWs.
-
The BGP next-hops are allowed to be the system-ip or even a loopback address. In both cases, the BGP next-hops are not required to be reachable in their respective networks.
-
In the example shown in Figure: Multihomed anycast solution, PE-1 picks up DCGW-1's inclusive multicast route (because of its lower BGP next-hop) and creates a BUM destination to 192.0.2.4. When sending BUM traffic for VPLS-1, it only sends the traffic to DCGW-1. In the same way, the DCGWs do no set up BUM destinations between each other as they use the same originating-ip in their inclusive multicast routes.
The remote PE or NVEs perform a similar BGP selection for MAC/IP routes, as a specific MAC is sent by the two DCGWs with the same route-key. A PE or NVE sends known unicast traffic for a specific MAC to only one DCGW.