Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

Configuring MBGP MVPNs to Support IPv6 Multicast Traffic

 

Multiprotocol BGP-based (MBGP) multicast VPNs (MVPNs) (also referred to as next-generation Layer 3 VPN multicast) can transport IPv6 multicast customer traffic across an IPv4 core network using RSVP-TE tunnels. Transporting IPv6 multicast customer traffic across an IPv4 core network does not require that IPv6 support or multicast support be configured in the core network.

The following features are supported for IPv6 multicast transport:

  • PIM sparse mode

    • Static rendezvous points

    • Bootstrap router protocol

    • Embedded RP

  • PIM dense mode

  • PIM source-specific multicast

  • MLD on the provider edge (PE) router to host interface

  • RSVP-TE, PIM-SSM, or PIM-ASM inclusive provider tunnels

  • RSVP-TE selective provider tunnels

  • BGP mesh topologies or route reflectors

The configuration required to support IPv6 multicast traffic across an MBGP MVPN is largely the same as the configuration to support IPv4 multicast traffic. For an example of configuring an MBGP MVPN to transport IPv4 multicast customer traffic, see Example: Configuring MBGP Multicast VPNs.

To transport IPv6 multicast customer traffic across a service provider IPv4 core network:

  1. If RSVP-TE LSPs and the bootstrap router protocol are used, enable the IPv6 address family on all core-facing interfaces on all PE routers participating in the MVPN. It is not necessary to configure an IPv6 address.
  2. Enable MBGP to carry multicast VPN NLRI for the IPv6 address family and enable VPN signaling on all PE routers participating in the MVPN.
  3. Enable MBGP to carry Layer 3 VPN NLRI for the IPv6 address family for unicast routes on all PE routers participating in the MVPN.
  4. Allow IPv6 routes to be resolved over an MPLS network by converting all routes stored in the inet.3 routing table to IPv4-compatible IPv6 addresses and then copying them into the inet6.3 routing table on all PE routers participating in the MVPN.

    The inet6.3 routing table is used to resolve next-hop addresses for both IPv6 and IPv6 VPN routes.

  5. By default, the routers support MLD version 1 (MLDv1). If you want to use MLDv2 on directly connected customer hosts, configure MLD version 2 on the PE router to host interfaces.
  6. Configure either a static rendezvous point (RP) or the bootstrap router (BSR) protocol using the following:

    • If you are using a static RP, configure the local RP IPv6 address on the router that is the rendezvous point.

    • If you are using a static RP, configure the RP IPv6 address on all PE routers in the MVPN that are not the rendezvous point.

    • If you are using the BSR protocol for automatic RP discovery, configure a bootstrap router to support the IPv6 address family.

  7. (Optional) If you are using a route reflector and the route reflector does not have a full mesh of RSVP LSPs tunnels, it might be necessary to add a static route. The static route is used to ensure that no updates are dropped by BGP dbecause no next-hop attribute are present. Configure the static route in the inet6.3 routing table with the 0::0/0 prefix. Set the next-hop attribute to discard and give the route a metric of 65000. The high metric used in this example allows the router to use the other routes with a lower metric if they exist.
  8. After you have configured the network to transport IPv6 multicast customer traffic across an IPv4 core network and allowed time for the routes to be discovered, use the show route table instance_name.mvpn-inet6.0 command to see the type 1 autodiscovery routes.
  9. Use the show mvpn instance command to verify that tthe provider tunnels have been established.
  10. Use the show route table bgp.mvpn-inet6.0 command to verify that the correct BGP routes have been learned from MVPN.
  11. After multicast traffic is flowing, use the show multicast route instance instance_name extensive inet6 command to verify that the multicast state, group address, source address, upstream interface list, and downstream interface list are correct.
  12. Use the show route table instance_name.inet6.1 command to verify that the multicast forwarding table is correct.