In Figure 1, PE1 is configured with the following Epipe services:
endpoint X create
exit
endpoint Y create
exit
bgp-evpn
evi 350
local-attachment-circuit "CE-1" endpoint "Y" create
eth-tag 1
exit
remote-attachment-circuit "ICB-1" endpoint "Y" create
eth-tag 2
exit
local-attachment-circuit "CE-2" endpoint "X" create
eth-tag 2
exit
remote-attachment-circuit "ICB-2" endpoint "X" create
eth-tag 1
exit
mpls bgp 1
auto-bind-tunnel
resolution any
exit
no shutdown
exit
exit
sap lag-1:1 endpoint X create
exit
sap 1/1/1:1 endpoint Y create
exit
In Figure 1, PE2 is configured with the following Epipe services:
bgp-evpn
evi 350
local-attachment-circuit "CE-1" create
eth-tag 1
exit
remote-attachment-circuit "ICB-1" create
eth-tag 2
exit
// implicit endpoint "Y"
mpls bgp 1
auto-bind-tunnel
resolution any
exit
no shutdown
exit
exit
sap lag-1:1 create
exit
// implicit endpoint "X"
In this example, if we assume multihoming on CE1, the following applies:
PE1 advertises two AD per-EVI routes, for tags 1 and 2, respectively. PE2 advertises only the route for tag 1
AD per-EVI routes for tag 1 are advertised based on CE1 SAPs' states
AD per-EVI route for tag 2 is advertised based on CE2 SAP state
PE1 creates endpoint X with sap lag-1:1 and ES-destination to tag 1 in PE2
PE2 creates the usual destination to tag 2 in PE1
In case of all-active MH:
traffic from CE1 to PE1 is forwarded to CE2 directly
traffic from CE1 to PE2 is forwarded to PE1 with the label that identifies CE2's SAP
traffic from CE2 is forwarded to CE1 directly because CE1's SAP is the endpoint Tx; in case of failure on CE1's SAP, PE1 changes the Tx object to the ES-destination to PE2
In case of single-active MH, traffic flows in the same way, except that a non-DF SAP is operationally down and therefore cannot be an endpoint Tx object.