Interoperable interface-less IP-VRF-to-IP-VRF model (Ethernet encapsulation)

This model is interface-less because no Supplementary Broadcast Domain (SBD) is required to connect the VPRNs of the tenant, and no recursive resolution is required upon receiving an IP prefix route. In other words, the next-hop of the IP prefix route is directly resolved to an EVPN tunnel, without the need for any other route. The standard specification draft-ietf-bess-evpn-ip-prefix supports two variants of this model that are not interoperable with each other:

• EVPN IFL for Ethernet NVO (Network Virtualization Overlay) tunnels

  Ethernet NVO indicates that the EVPN packets contain an inner Ethernet header. This is the case for tunnels such as VXLAN.

  In the Ethernet NVO option, the ingress PE uses the received router's MAC extended community address (received along with the route type 5) as the inner destination MAC address for the EVPN packets sent to the prefix

• EVPN IFL for IP NVO tunnels

  IP NVO indicates that the EVPN packets contain an inner IP packet, but without Ethernet header. This is similar to the IPVPN packets exchanged between PEs.

Figure: Interface-less IP-VRF-to-IP-VRF model illustrates the Interface-less IP-VRF-to-IP-VRF model.

Figure: Interface-less IP-VRF-to-IP-VRF model

SR OS supports the interoperable Interface-less IP-VRF-to-IP-VRF Model for Ethernet NVO tunnels. In Figure: Interface-less IP-VRF-to-IP-VRF model this interoperable model is shown on the left side PE router. The following is the model implementation:

• There is no data path difference between this model and the existing R-VPLS EVPN tunnel model or the model described in Interface-ful IP-VRF-to-IP-VRF with unnumbered SBD IRB model.

• This model is enabled by configuring config>service>vprn>if>vpls>evpn-tunnel (with ipv6-gateway-address mac for IPv6), and bgp-evpn>ip-route-advertisement. In addition, because the SBD IRB MAC/IP route is no longer needed, the bgp-evpn no mac-advertisement command prevents the advertisement of the MAC/IP route.

• The IP prefix routes are processed as follows:

  • On transmission, there is no change in the IP prefix route processing compared to the configuration of the Interface-ful IP-VRF-to-IP-VRF with Unnumbered SBD IRB Model.

    • IPv4/IPv6 prefix routes are advertised based on the information in the route-table for IPv4 and IPv6, with GW-IP=0 and the corresponding MAC extended community.

    • If bgp-evpn no mac-advertisement is configured, no MAC/IP route is sent for the R-VPLS.

  • The received IPv4/IPv6 prefix routes are processed as follows:

    1. Upon receiving an IPv4/IPv6 prefix route with a MAC extended community for the router, an internal MAC/IP route is generated with the encoded MAC and the RD, Ethernet tag, ESI, Label/VNI and next hop derived from the IP prefix route itself.

    2. If no competing received MAC/IP routes exist for the same MAC, this IP prefix-derived MAC/IP route is selected and the MAC is installed in the R-VPLS FDB with type ‟Evpn”.

    3. After the MAC is installed in FDB, there are no differences between this interoperable interface-less model and the interface-ful with unnumbered SBD IRB model. Therefore, SR OS is compatible with the received IP prefix routes for both models.

The following is an example of a typical configuration of a PE's SBD and VPRN that work in interface-less model for IPv4 and IPv6:

7750SR#config>service#

vpls 2 customer 1 name "sbd" create
       allow-ip-int-bind
       exit
       bgp
       exit
       bgp-evpn
            evi 2
            no mac-advertisement
            ip-route-advertisement
            mpls bgp 1
                 auto-bind-tunnel resolution any
                 no shutdown
vprn 1 customer 1 create
       route-distinguisher auto-rd
       interface "sbd" create
            ipv6
            exit
            vpls "sbd"
                 evpn-tunnel ipv6-gateway-address mac