In Figure: Core diversity with parallel NG-MVPN services on parallel IGP instances, Red and Blue networks correspond to separate IGP instances tied to separate loopback interfaces. In core diversity, MVPN services on the LER are bound to a domain by advertising MP-BGP routes, with next hop set to the appropriate loopback address, and having the receiving LERs resolve those BGP next hops, based on the corresponding IGP instance. All subsequent MVPN BGP routing exchanges must set and resolve the BGP next hop with the configured non-system loopback.
With this feature, an MP-BGP next hop would resolve to a link LDP label which is indirectly associated with a specific IGP instance. Services which advertise BGP routes with next hop Red loopback would result in traffic flowing over the Red network using LDP and Blue loopback would result in traffic flowing over Blue network. See Figure: Core diversity with parallel NG-MVPN services on parallel IGP instances.
Most importantly, the common routes in each IGP instance must have a unique and active label. This is required to ensure that the same route advertised in two different IGP domains do not resolve to the same label. LDP local-lsr-id can be used to ensure FECs and label mapping be advertised via the right instance of IGP.
Core diversity allows an operator to optionally deploy multicast NG-MVPN in either default IGP instance or one of the non-default IGP instances to provide, for example, topology isolation or different level of services. The following describes the main feature attributes:
NG- MVPN can use IPv4/IPv6 multicast.
NG-MVPN can use a non-default OSPF or ISIS instance.
Note: This is accomplished by using their loopback addresses instead of a system address.The BGP Connector also uses non-default OSPF loopback as NH, via two methods:
-
Setting the BGP local-address to a loopback interface IP address
-
Creating a routing policy to set the NH of a MVPN AD route to the corresponding loopback IP
-
RSVP-TE/LDP transport tunnels also use non-systemIP loopback for session creation. As an example, RSVP-TE p2mp LSPs would be created to non systemIP loopbacks and mLDP creates a session via local-lsr-id.
Need to add the source-address for mvpn auto-discover default.
On the source PEs, a NG-MVPN is assigned to a non-default IGP core instance as follows:
NG-MVPN is statically pointed to use one of the non-default red/blue IGP instances loopback addresses as source address instead of system loopback IP.
MVPN export policy is used to change unicast route next-hop VPN address (BGP Connector support for non-default instances).
Alternatively, the BGP local-address can be set to the correct loopback interface assigned for that specific instance.
The preceding configuration ensures that MVPN-IPv4/v6 and IP-VPN routes for the non-default core instance use non-default IGP loopback instead of system IP. This ensures MVPN-IPv4/v6 advertisement/joins run in the correct core instance and mLDP and P2MP RSVP tunnels (I-PMSI and S-PMSI) for multicast can be set-up using and terminating on non-system IP.
If BGP export policy is used to change unicast route next-hop VPN address, then unicast traffic must be forwarded in non-default red or blue core instance LDP or RSVP (terminating on non-system IP) must be used.