EVPN and VPLS integration

Systems with EVPN endpoints and SDP bindings to the same far-end bring down the SDP bindings.

• The router allows the establishment of an EVPN endpoint and an SDP binding to the same far-end but the SDP binding is kept operationally down. Only the EVPN endpoint remains operationally up. This is true for spoke SDPs (manual, BGP-AD, and BGP-VPLS) and mesh SDPs. It is also possible between VXLAN and SDP bindings.

• If there is an existing EVPN endpoint to a specified far-end and a spoke SDP establishment is attempted, the spoke SDP is setup but kept down with an operational flag indicating that there is an EVPN route to the same far-end.

• If there is an existing spoke SDP and a valid/used EVPN route arrives, the EVPN endpoint is setup and the spoke SDP is brought down with an operational flag indicating that there is an EVPN route to the same far-end.

• In the case of an SDP binding and EVPN endpoint to different far-end IPs on the same remote PE, both links are up. This can happen if the SDP binding is terminated in an IPv6 address or IPv4 address different from the system address where the EVPN endpoint is terminated.

The user can add spoke SDPs and all the EVPN-MPLS endpoints in the same split horizon group (SHG).

• A CLI command is added under the bgp-evpn>mpls> context so that the EVPN-MPLS endpoints can be added to a split horizon group: bgp-evpn>mpls> [no] split-horizon-group group-name

• The bgp-evpn mpls split-horizon-group must reference a user-configured split horizon group. User-configured split horizon groups can be configured within the service context. The same group-name can be associated with SAPs, spoke SDPs, pw-templates, pw-template-bindings, and EVPN-MPLS endpoints.

• If the split-horizon-group command in bgp-evpn>mpls> is not used, the default split horizon group (that contains all the EVPN endpoints) is still used, but it is not possible to refer to it on SAPs/spoke SDPs.

• SAPs and SDP bindings that share the same split horizon group of the EVPN-MPLS provider-tunnel are brought operationally down if the point-to-multipoint tunnel is operationally up.

The system disables the advertisement of MACs learned on spoke SDPs and SAPs that are part of an EVPN split horizon group.

• When the SAPs and spoke SDPs (manual or BGP-AD/VPLS-discovered) are configured within the same split horizon group as the EVPN endpoints, MAC addresses are still learned on them, but they are not advertised in EVPN.

• The preceding statement is also true if proxy-ARP/proxy-ND is enabled and an IP-MAC pair is learned on a SAP or SDP binding that belongs to the EVPN split horizon group.

• The SAPs and, or spoke SDPs added to an EVPN split horizon group should not be part of any EVPN multihomed ES. If that happened, the PE would still advertise the AD per-EVI route for the SAP and, or spoke SDP, attracting EVPN traffic that could not possibly be forwarded to that SAP and, or SDP binding.

• Similar to the preceding statement, a split horizon group composed of SAPs/SDP bindings used in a BGP-MH site should not be configured under bgp-evpn>mpls>split-horizon-group. This misconfiguration would prevent traffic being forwarded from the EVPN to the BGP-MH site, regardless of the DF/NDF state.

  Figure: EVPN-VPLS integration shows an example of EVPN-VPLS integration.

  Figure: EVPN-VPLS integration

  

  An example CLI configuration for PE1, PE5, and PE2 is provided below.

  
  *A:PE1>config>service# info 
  ----------------------------------------------
  pw-template 1 create
  vpls 1 name "vpls-1" customer 1 create
    split-horizon-group "SHG-1" create 
    bgp
      route-target target:65000:1
      pw-template-binding 1 split-horizon-group SHG-1 
    exit
    bgp-ad
      no shutdown
      vpls-id 65000:1
    exit
    bgp-evpn
      evi 1
      mpls bgp 1
        no shutdown
        split-horizon-group SHG-1
    exit
    spoke-sdp 12:1 create
    exit
    sap 1/1/1:1 create
    exit
  
  *A:PE5>config>service# info 
  ----------------------------------------------
  pw-template 1 create
    exit
  vpls 1 customer 1 create
    bgp
      route-target target:65000:1
      pw-template-binding 1 split-horizon-group SHG-1 # auto-created SHG
    exit
    bgp-ad
      no shutdown
      vpls-id 65000:1
    exit
    spoke-sdp 52:1 create
    exit
  
  *A:PE2>config>service# info 
  ----------------------------------------------
  vpls 1 name "vpls-1" customer 1 create
    end-point CORE create
      no suppress-standby-signaling
    exit
    spoke-sdp 21:1 end-point CORE
      precedence primary
    exit
    spoke-sdp 25:1 end-point CORE
  

• PE1, PE3, and PE4 have BGP-EVPN and BGP-AD enabled in VPLS-1. PE5 has BGP-AD enabled and PE2 has active/standby spoke SDPs to PE1 and PE5.

  In this configuration:

  • PE1, PE3, and PE4 attempt to establish BGP-AD spoke SDPs, but they are kept operationally down as long as there are EVPN endpoints active among them.

  • BGP-AD spoke SDPs and EVPN endpoints are instantiated within the same split horizon group, for example, SHG-1.

  • Manual spoke SDPs from PE1 and PE5 to PE2 are not part of SHG-1.

• EVPN MAC advertisements:

  • MACs learned on FEC128 spoke SDPs are advertised normally in EVPN.

  • MACs learned on FEC129 spoke SDPs are not advertised in EVPN (because they are part of SHG-1, which is the split horizon group used for bgp-evpn>mpls). This prevents any data plane MACs learned on the SHG from being advertised in EVPN.

• BUM operation on PE1:

  • When CE1 sends BUM, PE1 floods to all the active bindings.

  • When CE2 sends BUM, PE2 sends it to PE1 (active spoke SDP) and PE1 floods to all the bindings and SAPs.

  • When CE5 sends BUM, PE5 floods to the three EVPN PEs. PE1 floods to the active spoke SDP and SAPs, never to the EVPN PEs because they are part of the same SHG.