Example-1

Figure: EVPN-VPWS endpoints example-1

In Figure: EVPN-VPWS endpoints example-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: EVPN-VPWS endpoints example-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.