IPv6 Multicast Deployment Examples

In this section, the IPv6 multicast concepts discussed so far are applied in the following practical examples:

Descriptions of full-scale IPv6 multicast deployments are presented in Part II of this book. At this point, the goal is to provide a practical sense of how IPv6 multicast is configured and how it works.

SSM in a Service Provider Network

One of the services that service providers are trying to deploy for their broadband subscribers is video and audio content delivery. The bandwidth available with broadband access is sufficient to support applications such as video (which requires 2-4 Mbps) and audio (which requires 192 kbps). The SP deploys content servers in its data center, and they represent the sources of the streams. Each audio/video channel is a multicast stream identified by a (S,G). Subscribers can use a PC with an installed client application or a set-top box that subscribes to the (S,G) that maps to the channel of interest. The application or the set-top box is configured for this mapping, and it handles the process of joining or leaving the (S,G). All the sources and the group IDs are fixed and known to the subscribers.

An SSM deployment best fits such a service model. The multicast protocols used in this example are as follows:

The deployment of this service is presented in the generic topology of an IP service provider shown in Figure 6-7. The network was migrated to dual-stack IPv4/IPv6, and an IPv6 unicast infrastructure is in place. Figure 6-7 shows the subset of routers in this topology used for this example.

The IPv6 IGP is OSPFv3. Two servers are shown in the data center. Two users interested in the content provided by these servers are shown in the access portion of the SP network. The two channels used in this example map to (2001:D:AAAA::1000, FF3A::100) and (2001:D:AAAA:1001, FF3A::101). The SP can choose SSM group addresses without a defined scope, and the multicast traffic is meant to stay only within the provider's network.

Enabling IPv6 Multicast Routing

Only one global command is needed to enable PIM and MDLv2 on all IPv6-enabled router interfaces:

AC(config)#ipv6 multicast-routing

All routers that are meant to forward the multicast traffic need to be enabled for IPv6 multicast routing.

MLD Configuration

With IPv6 multicast routing enabled, the interfaces facing the two subscribers are running MLDv2. If the SP does not want the user to be able to subscribe to groups other than the ones offered through the paid service, FF3A::/96, the SP will enable MLD access control on the user-facing interfaces with the help of the following ACL:

AC#show ipv6 access-list
IPv6 access list mld-acc-control
    permit ipv6 any FF3A::/96 sequence 10

MLD access control is enabled on the interface that connects to subscriber 1 via VLAN 100, as highlighted in the interface configuration and interface MLD information listed in Example 6-11.

Example 6-11. Interface Configuration and MLD Interface Status for the MLD Access Control Feature

interface GigabitEthernet0/2.100
 encapsulation dot1Q 100
 ipv6 address 2001:1:A1:64::1/64
 ipv6 enable
 ipv6 mld access-group mld-acc-control
AC#show ipv6 mld interface gig0/2.100
GigabitEthernet0/2.100 is up, line protocol is up
  Internet address is FE80::201:FF:FE01:1/10
  MLD is enabled on interface
  Current MLD version is 2
  MLD query interval is 125 seconds
  MLD querier timeout is 255 seconds
  MLD max query response time is 10 seconds
  Last member query response interval is 1 seconds
  Inbound MLD access group is: mld-acc-control
  MLD activity: 36 joins, 31 leaves
  MLD querying router is FE80::201:FF:FE01:1 (this system)

Tuning PIM

All three types of supported PIM are running on the routers shown in Figure 6-7. In principle, with PIM-SSM, no other configuration should be needed. However, the topology of this example offers an opportunity to tune PIM a little bit.

Routers AC, E1L, and E2L in Figure 6-7 are all connected via a common, Ethernet broadcast domain. In this case, one router is elected to be a DR (as described in the "Multicast Routing" section of this chapter). The network designer might choose to control the DR election process by modifying the PIM DR priorities. In this example, the intent is to make sure E2L is always the PIM DR for this broadcast domain. The interface configuration and the result of the election can be displayed on E2L (see Example 6-12).

Example 6-12. Interface PIM Status Showing the Result of the DR Election Process

E2L#show ipv6 pim interface gig1/1.501
Interface          PIM  Nbr   Hello  DR
                        Count Intvl  Prior
Gi1/1.501          on   2     30     2
    Address: FE80::20A:8BFF:FE09:FD01
             DR     : this system

Example 6-13. PIM Neighbor Information as Seen on the Elected DR

E2L#sho ipv6 pim nei
Neighbor Address           Interface          Uptime    Expires DR pri Bidir
FE80::208:7CFF:FED9:F81B   Gi1/1.501          00:15:43  00:01:24 1      B
FE80::20A:8BFF:FE0A:101    Gi1/1.501          00:15:44  00:01:24 1      B

Subscriber Joining the (S,G)

This section shows what happens when the first subscriber sends an MLDv2 report message and it joins the (S,G) group (2001:D:AAAA:1::1000, FF3A::100). The access router (AC) shows the fact that it has a member of the FF3A::100 group listening on interface GigabitEthernet 0/2.100, as highlighted in Example 6-14.

Example 6-14. MLD Membership to Group FF3A::100

AC#show ipv6 mld group FF3A::100
MLD Connected Group Membership
Group Address                           Interface          Uptime    Expires
FF3A::100                               Gi0/2.100          00:01:27  00:04:03

The PIM debug is turned on for the FF3A::100 group. The subscriber joining the group triggered a PIM join message to be sent to the PIM DR and up the SPT (2001:D:AAAA:1::1000,FF3A::100), as shown in Example 6-15.

Example 6-15. Output of IPv6 PIM Debug for Group FF3A::100

AC#debug ipv6 pim group FF3A::100
IPv6 PIM: [0] (2001:D:AAAA:1::1000,FF3A::100/128) GigabitEthernet0/2.100 MRIB
update (f=100,c=100)
IPv6 PIM: (2001:D:AAAA:1::1000,FF3A::100) Create entry
IPv6 PIM: (2001:D:AAAA:1::1000,FF3A::100) RPF changed from ::/- to
FE80::20A:8BFF:FE09:FD01/GigabitEthernet0/1.501
IPv6 PIM: [0] (2001:D:AAAA:1::1000,FF3A::100/128) MRIB modify
IPv6 PIM: [0] (2001:D:AAAA:1::1000,FF3A::100/128) NULLIF-skip MRIB modify !A
IPv6 PIM: [0] (2001:D:AAAA:1::1000,FF3A::100/128) GigabitEthernet0/1.501 MRIB
   modify A !NS
IPv6 PIM: (2001:D:AAAA:1::1000,FF3A::100) Source metric changed from [0/0] to [1/110]
IPv6 PIM: [0] (2001:D:AAAA:1::1000,FF3A::100/128) MRIB modify
IPv6 PIM: [0] (2001:D:AAAA:1::1000,FF3A::100/128) GigabitEthernet0/1.501 MRIB modify A
IPv6 PIM: (2001:D:AAAA:1::1000,FF3A::100) GigabitEthernet0/2.100 Local state
  changed from Null to Join  Router AC joined the (S,G) SPT
IPv6 PIM: (2001:D:AAAA:1::1000,FF3A::100) GigabitEthernet0/2.100 Start being last hop
IPv6 PIM: (2001:D:AAAA:1::1000,FF3A::100) GigabitEthernet0/2.100 FWD state change
  from Prune to Forward   The Multicast traffic can now be forwarded down the SPT

After the second subscriber joins (S2,G2), at the AC router the PIM topology looks like Example 6-16.

Example 6-16. IPv6 PIM Topology on Router AC

AC#show ipv6 pim topology
IP PIM Multicast Topology Table
Entry state: (*/S,G)[RPT/SPT] Protocol Uptime Info
Entry flags: KAT - Keep Alive Timer, AA - Assume Alive, PA - Probe Alive,
    RA - Really Alive, LH - Last Hop, DSS - Don't Signal Sources,
    RR - Register Received, SR - Sending Registers, E - MSDP External,
    DCC - Don't Check Connected
Interface state: Name, Uptime, Fwd, Info
Interface flags: LI - Local Interest, LD - Local Dissinterest,
    II - Internal Interest, ID - Internal Dissinterest,
    LH - Last Hop, AS - Assert, AB - Admin Boundary
(2001:D:AAAA:1::1000,FF3A::100)
SSM SPT UP: 00:01:59 JP: Join(now) Flags:
RPF: GigabitEthernet0/1.501,FE80::20A:8BFF:FE09:FD01
  Gi0/2.100          00:01:59  fwd LI LH
(2001:D:AAAA:1::1001,FF3A::101)
SSM SPT UP: 00:00:06 JP: Join(00:00:43) Flags:
RPF: GigabitEthernet0/1.501,FE80::20A:8BFF:FE09:FD01
  Gi0/2.101          00:00:06  fwd LI LH

The PIM topology will look similar throughout the rest of the network. It is interesting, however, to observe it at a node that has two equal-cost paths to the source. This is the case with the AG2L router (see Example 6-17).

Example 6-17. PIM Topology on a Node with Two Equal-Cost Paths to the Multicast Source

AG2L#show ipv6 route 2001:D:AAAA:1::/64
IPv6 Routing Table - 188 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
       U - Per-user Static route
       I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
       O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
OE2  2001:D:AAAA:1::/64 [110/20]
     via FE80::20B:60FF:FEA7:D81A, GigabitEthernet0/2
     via FE80::204:6DFF:FE7F:7C1A, GigabitEthernet0/1
AG2L#show ipv6 pim neighbor
Neighbor Address           Interface          Uptime    Expires DR pri Bidir
FE80::204:6DFF:FE7F:7C1A   Gi0/1              10:29:06  00:01:23 255 (DR) B
FE80::283:AFFF:FE47:401A   Gi0/0              10:29:06  00:01:36 1      B
FE80::20B:60FF:FEA7:D81A   Gi0/2              00:57:58  00:01:18 255 (DR) B

In this case, it is expected that (S1,G1) and (S2,G2) are balanced, as shown in Figure 6-7, based on the path of the PIM join messages. The PIM topology does indeed reflect this per-source balancing. The output of show ipv6 pim topology indicates that one group's traffic is received over interface GigabitEthernet0/1 and the other's over GigabitEthernet0/2, as highlighted in Example 6-18.

Example 6-18. PIM Topology with Redundant Paths to the Multicast Source

E2L#show ipv6 pim topology
(2001:D:AAAA:1::1000,FF3A::100)
SSM SPT UP: 00:01:08 JP: Join(00:00:46) Flags:
RPF: GigabitEthernet0/2,FE80::20B:60FF:FEA7:D81A
  Gi0/0          00:01:08  fwd Join(00:03:21)
(2001:D:AAAA:1::1001,FF3A::101)
SSM SPT UP: 00:01:07 JP: Join(00:00:46) Flags:
RPF: GigabitEthernet0/1,FE80::204:6DFF:FE7F:7C1A
  Gi0/0          00:01:07  fwd Join(00:03:22)

IPv6 Multicast Traffic Forwarding

When the sources start transmitting the multicast traffic, you can monitor its forwarding via the MFIB counters, as shown below for AG2L in Example 6-19.

Example 6-19. IPv6 Multicast Forwarding Information Based on MFIB Counters

AG2L#show ipv6 mfib | b FF3A::100
(2001:D:AAAA:1::1000,FF3A::100) Flags:
   Forwarding: 199/8/1482/98, Other: 0/0/0
   GigabitEthernet0/2    Flags: A
   GigabitEthernet0/0    Flags: F NS
     Pkts: 199/0
(2001:D:AAAA:1::1001,FF3A::101) Flags:
   Forwarding: 199/8/1482/98, Other: 0/0/0
   GigabitEthernet0/1    Flags: A
   GigabitEthernet0/0     Flags: F NS
     Pkts: 199/0

This output indicates that the subscribers are enjoying the content they expressed interest in. The SSM-based service is deployed with little configuration, and it is easy to manage.

ASM in an Enterprise Network

For the ASM deployment example, the topology chosen is that of an enterprise network (EN). Typical applications deployed in an EN are videoconferencing, remote learning, distribution of information and news, and collaborative tools. The servers supporting all the corporate applications are located in data centers that are distributed across the network. This makes the deployment more suitable as an ASM model.

To describe an ASM-based deployment, a subset of routers was selected from an EN example topology, as shown in Figure 6-8. The network diagram in Figure 6-8 depicts two topological elements: the main campus and a remote office.

As far as routing is concerned, OSPFv3 is used in the main campus, and eBGP is used to exchange routing information with the remote offices. One PIM domain spans the entire network, but BSR flooding is contained within the main campus network.

The setup steps and information common to both the ASM and the SSM examples are not explicitly presented here. All routers that have to support the service should be enabled for IPv6 multicast routing.

Configuring BSR

In the main campus shown in Figure 6-8, at least two PIM RPs have to be configured to avoid downtime in case of RP failure. Multiple RPs deployed in a PIM domain require a mechanism that informs routers as to which RP serves a given group. BSR has been selected for this example to provide dynamic RP-to-group mapping and RP redundancy.

Router C1 and C2 in the core of the network are set to be candidate BSRs, as highlighted in the configuration in Example 6-20.

Example 6-20. BSR Configuration of Two Candidate Routers

Router C1:
ipv6 pim bsr candidate bsr 2001:1:FFFF:FFFF:2:: 128 priority 2
Router C2:
ipv6 pim bsr candidate bsr 2001:1:FFFF:FFFF:1:: 128 priority 1

The two routers go through the BSR election process, at the end of which C1 becomes the BSR because of its configured higher priority. The result of the BSR election process is highlighted in the output of show ipv6 pim bsr election shown in Example 6-21.

Example 6-21. Outcome of the BSR Election Process

C1#show ipv6 pim bsr election
PIMv2 BSR information
BSR Election Information
  Scope Range List: ff00::/8
  This system is the Bootstrap Router (BSR)
     BSR Address: 2001:1:FFFF:FFFF:2::
     Uptime: 00:00:27, BSR Priority: 2, Hash mask length: 128
     RPF: FE80::20F:35FF:FE3F:441B,Loopback0
     BS Timer: 00:00:32
  This system is candidate BSR
      Candidate BSR address: 2001:1:FFFF:FFFF:2::, priority: 2, hash mask length
        : 128
C2#show ipv6 pim bsr election
PIMv2 BSR information
BSR Election Information
  Scope Range List: ff00::/8
     BSR Address: 2001:1:FFFF:FFFF:2::
     Uptime: 00:00:19, BSR Priority: 2, Hash mask length: 128
     RPF: FE80::204:6DFF:FE7F:7C1A,Gi0/1.10
     BS Timer: 00:01:50
  This system is candidate BSR
      Candidate BSR address: 2001:1:FFFF:FFFF:1::, priority: 1, hash mask length
       : 128

The intent is to run BSR only within the main campus. To contain the BSR flooding within the main campus, the M1 interface for the link to the remote site is configured to drop the BSR traffic with the Cisco IOS command ipv6 pim bsr border.

Configuring Candidate RP routers

With the BSR infrastructure in place, it is time to enable several routers to advertise their willingness to be RP for certain multicast groups. For this example, routers DC1 and DC2 in the data center are set up as candidate RPs for the groups FF08::1:xxxx/112 identified via ACL bsr-group. This is implemented with the global configuration command shown on router DC1 along with the ACL (see Example 6-22).

Example 6-22. BSR Configuration and Status of a Candidate RP Router

DC1
ipv6 pim bsr candidate rp 2001:D:AAAA:1::1 group-list bsr-group priority 2
DC1#show ipv6 access-list bsr-group
IPv6 access list bsr-group
    permit ipv6 any FF08::1:0/112 sequence 10
DC1#show ipv6 pim bsr candidate-rp
PIMv2 C-RP information
    Candidate RP: 2001:D:AAAA:1::1
      All Learnt Scoped Zones, Priority 2, Holdtime 150
      Advertisement interval 60 seconds
      Next advertisement in 00:00:19
      Group acl: bsr-group

In this example, the RPs are identified by their interface addresses on the same network with the multicast servers: 2001:D:AAAA:1::1 (for DC1) and 2001:D:AAAA:1::2 (for DC2). The same group address range is covered by both RPs, which provides a level of redundancy for the deployment. If one of the RPs goes away, the BSR does not advertise it anymore. The elected BSR learns about all candidate RPs highlighted in Example 6-23.

Example 6-23. List of RPs Advertised via BSR

C1#show ipv6 pim bsr rp-cache
PIMv2 BSR C-RP Cache
BSR Candidate RP Cache
Group(s) FF08::1:0/112, RP count 2
  RP 2001:D:AAAA:1::1
    Priority 2, Holdtime 150
    Uptime: 00:04:35, expires: 00:01:55
  RP 2001:D:AAAA:1::2
    Priority 1, Holdtime 150
    Uptime: 00:03:18, expires: 00:02:12

Then it distributes the RP-to-group mapping information throughout the entire main campus network. The B2 edge router learns the BSR and RP-to-group mapping information, and it can be viewed in the output of show ipv6 pim group-map (see Example 6-24).

Example 6-24. RP-to-Group Mapping Information Learned by a Router via BSR

B2#show ipv6 pim group-map
FF08::1:0/112*
    SM, RP: 2001:D:AAAA:1::2
    RPF: Gi0/1.501,FE80::20F:35FF:FE3F:441A
    Info source: BSR From: 2001:1:FFFF:FFFF:2::(00:02:15), Priority: 1
    Uptime: 00:00:14, Groups: 0
FF08::1:0/112 
    SM, RP: 2001:D:AAAA:1::1
    RPF: Gi0/1.501,FE80::20F:35FF:FE3F:441A
    Info source: BSR From: 2001:1:FFFF:FFFF:2::(00:02:15), Priority: 2
    Uptime: 00:00:14, Groups: 0

The routers enabled for multicast routing throughout the PIM domain create a virtual tunnel for the known active RPs. They use this interface to register directly connected sources. Example 6-25 shows the tunnel built by router C1 to the RP.

Example 6-25. Tunnel Built by C1 to the RP for Registration Purposes

C1#show ipv6 pim tunnel
Tunnel1*
  Type  : PIM Encap
  RP    : 2001:D:AAAA:1::1
  Source: 2001:1:FFFF:FFFF:2::

The main campus is now ready to support multicast traffic for groups FF08::1:xxxx using RP 2001:D:AAAA:1::1.

PIM Topology and Traffic Forwarding

The FF08::1:100 multicast group is used to exemplify the operation of the main campus multicast network. Suppose the users join groups, as shown in Example 6-26 for interface GigabitEthernet0/2.100, but there are no registered sources yet.

Example 6-26. IPv6 MLD Registration State When No Sources Are Registered

B2#show ipv6 mld group FF08::1:100
MLD Connected Group Membership
Group Address                             Interface        Uptime    Expires
FF08::1:100                               Gi0/2.100        00:00:16  00:04:03

Because there are no sources, the only information available in the PIM topology is that of the ST (*, FF08::1:100) highlighted in Example 6-27.

Example 6-27. PIM Topology When No Sources Are Registered

B2#show ipv6 pim topology | b FF08::1:100
(*,FF08::1:100)
SM UP: 00:00:21 JP: Join(00:00:28) Flags: LH
RP: 2001:D:AAAA:1::1
RPF: GigabitEthernet0/1.501,FE80::20F:35FF:FE3F:441A
              Gi0/2.100          00:00:21  fwd LI LH

As soon as a source 2001:D:AAAA:1::1000 registers for this group, an (S,G) SPT is built for it, as shown by the highlighted output in the new PIM topology output in Example 6-28.

Example 6-28. PIM Topology When a Source Registered

B2#show ipv6 pim topology | b FF08::1:100
(*,FF08::1:100)
SM UP: 00:00:37 JP: Join(00:00:12) Flags: LH
RP: 2001:D:AAAA:1::1
RPF: GigabitEthernet0/1.501,FE80::20F:35FF:FE3F:441A
  Gi0/2.100          00:00:37  fwd LI LH
(2001:D:AAAA:1::1000,FF08::1:100)
SM SPT UP: 00:00:37 JP: Join(00:00:12) Flags: KAT(00:02:52) RA
RPF: GigabitEthernet0/1.501,FE80::20F:35FF:FE3F:441A
  No interfaces in immediate olist
B2#show ipv6 mfib
IP Multicast Forwarding Information Base
Entry Flags: C - Directly Connected, S - Signal, IA - Inherit A flag,
             AR - Activity Required, K - Keepalive
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kbits per second
Other counts: Total/RPF failed/Other drops
Interface Flags: A - Accept, F - Forward, NS - Negate Signalling
             IC - Internal Copy, NP - Not platform switched
             SP - Signal Present
Interface Counts: FS Pkt Count/PS Pkt Count
(*,FF08::1:0/112) Flags: C
   Forwarding: 0/0/0/0, Other: 0/0/0
(*,FF08::1:100) Flags: C
   Forwarding: 0/0/0/0, Other: 0/0/0
   GigabitEthernet0/1.501 Flags: A NS
   GigabitEthernet0/2.100 Flags: F NS
     Pkts: 0/0
(2001:D:AAAA:1::1000,FF08::1:100) Flags:
   Forwarding: 90974/1096/76/651, Other: 0/0/0
   GigabitEthernet0/1.501 Flags: A
   GigabitEthernet0/2.100 Flags: F NS
     Pkts: 94161/10

The MFIB counters indicate the traffic is flowing from the source to the listener over the (2001:D:AAAA:1::1000,FF08::1:100) SPT.

Operation with Embedded RP

MP-BGP offers the means to exchange routing information between the campuses. Because in this example BSR flooding was stopped at the boundary between them, embedded RP is used for RP-to-group mapping. For all multicast applications that span the entire network, the multicast group addresses used should contain the address of the RP based on the format described earlier in the "Embedded RP" section.

You must statically configure the router embedded in the multicast group address to be an RP. For this example, the router chosen to be RP for embedded RP groups is DC2. DC2 is set to be an RP with the following global configuration command

ipv6 pim rp-address 2001:D:AAAA:1::2

Following the procedure described earlier in the chapter, an embedded group address for this RP is FF78:240:2001:D:AAAA:1:0:100. When a subscriber in the remote campus joins the group, the RP-to-group mapping is learned from the multicast address. This mapping is highlighted in the output of show ipv6 pim group-map on the R1 router in Example 6-29.

Example 6-29. RP-to-Group Mapping with Embedded RP

R1#show ipv6 pim group-map
FF78:240:2001:D:AAAA:1::/96*
    RP      : 2001:D:AAAA:1::2
    Protocol: SM
    Client  : Embedded
    Groups  : 1
    Info    : RPF: PO2/0,FE80::20D:66FF:FE40:D8CC

When a source is present for the group, the (S,G) is built for the traffic. Both (S,G) and (*,G) groups can be now seen highlighted in the PIM topology (Example 6-30).

Example 6-30. PIM Topology with a Registered Source for the Embedded RP Group

R1#show ipv6 pim topology
IP PIM Multicast Topology Table
Entry state: (*/S,G)[RPT/SPT] Protocol Uptime Info
Entry flags: KAT - Keep Alive Timer, AA - Assume Alive, PA - Probe Alive,
    RA - Really Alive, LH - Last Hop, DSS - Don't Signal Sources,
    RR - Register Received, SR - Sending Registers, E - MSDP External,
    DCC - Don't Check Connected
Interface state: Name, Uptime, Fwd, Info
Interface flags: LI - Local Interest, LD - Local Dissinterest,
    II - Internal Interest, ID - Internal Dissinterest,
    LH - Last Hop, AS - Assert, AB - Admin Boundary
(*,FF78:240:2001:D:AAAA:1:0:100)
SM UP: 01:59:30 JP: Join(00:00:20) Flags: LH
RP: 2001:D:AAAA:1::2
RPF: POS2/0,FE80::20D:66FF:FE40:D8CC
  Loopback100        01:59:30  fwd LI LH
(2001:D:AAAA:1::1000,FF78:240:2001:D:AAAA:1:0:100)
SM SPT UP: 00:00:42 JP: Join(00:00:08) Flags: KAT(00:02:48) RA
RPF: POS2/0,FE80::20D:66FF:FE40:D8CC
  No interfaces in immediate olist

The tree topology in the preceding example shows an empty immediate OIL for (2001:D:AAAA:1::1000, FF78:240:2001:D:AAAA:1:0:100). This is because the router did not receive any PIM joins or MLD reports for the (S,G), the events that generate entries in the immediate OIL. On the other hand, from a forwarding perspective, the MRIB shows outbound interfaces for the (S,G), as highlighted in the output of show ipv6 mrib route in Example 6-31. These are inherited by the (S,G) from the (*,G).

Example 6-31. Forwarding Information for the Embedded RP Multicast Group

R1#show ipv6 mrib route FF78:240:2001:D:AAAA:1:0:100
IP Multicast Routing Information Base
Entry flags: L - Domain-Local Source, E - External Source to the Domain,
    C - Directly-Connected Check, S - Signal, IA - Inherit Accept, D - Drop
Interface flags: F - Forward, A - Accept, IC - Internal Copy,
    NS - Negate Signal, DP - Don't Preserve, SP - Signal Present,
    II - Internal Interest, ID - Internal Disinterest, LI - Local Interest,
    LD - Local Disinterest
(*,FF78:240:2001:D:AAAA:1:0:100) RPF nbr: FE80::20D:66FF:FE40:D8CC Flags: C
  POS2/0 Flags: A NS
  Loopback100 Flags: F NS LI
(2001:D:AAAA:1::1000,FF78:240:2001:D:AAAA:1:0:100) RPF nbr: FE80::20D:66FF:FE40:D8CC
Flags:
  POS2/0 Flags: A
  Loopback100 Flags: F NS

The IPv6 routing information is exchanged between the main campus and the remote offices via eBGP. In this network example, it was chosen to advertise the source prefix (2001:D:AAAA:1::/64) only for multicast use via the multicast IPv6 address family. The output in Example 6-32 shows the prefix advertised within the BGP multicast address family but not present in the IPv6 unicast routing table.

Example 6-32. IPv6 Prefix Advertised by BGP for Multicast Only

R1#show bgp ipv6 multicast 2001:D:AAAA:1::/64
BGP routing table entry for 2001:D:AAAA:1::/64, version 3154
Paths: (1 available, best #1, table Global-MBGPv6-Table)
  Not advertised to any peer
  200
    2001:11:22:1::1 from 2001:11:22:1::1 (200.200.200.200)
      Origin incomplete, metric 20, localpref 100, valid, external, best
R1#show ipv6 route 2001:D:AAAA:1::/64
% Route not found

Note

It is important to note here that with the 2001:D:AAAA:1:: advertised as a multicast route only, the listeners in the remote campus will be able to join and receive traffic from sources in the main campus. On the other hand, because these routers do not have a unicast IPv6 route to the RP (2001:D:AAAA:1::2), they will not be able to bring up their tunnel interface to the RP. Because of this, the routers in the remote campus will not be able to register any sources with the RP.

The deployment examples discussed in the last two sections show IPv6 as an apt successor of its IPv4 predecessor in terms of offering multicast services. IPv6 builds on the successes of IPv4, and it ignores its failures. Except for a few details, there are no major differences between the two multicast implementations. IPv6's advantage consists of its larger addressing space, its address scoping, and a hindsight perspective on protocol selection. IPv6 multicast has reached a level of maturity that makes it ready for large-scale deployments in both ASM and SSM models. The only scenario for which IPv6 does not have a complete solution at this time is that of a multidomain deployment. It currently has no mechanism in place to exchange source information between PIM domains. This drawback represents one area of the IPv6 protocol that will likely see further development.