An IPv6 address must be configured on an interface before the interface can forward IPv6 traffic. Configuring a site-local or global IPv6 address on an interface automatically configures a link-local address and activates IPv6 for that interface. Additionally, the configured interface automatically joins the following required multicast groups for that link:

• Solicited-node multicast group FF02:0:0:0:0:1:FF00::/104 for each unicast and anycast address assigned to the interface

  Note	The solicited-node multicast address is used in the neighbor discovery process.

• All-nodes link-local multicast group FF02::1
• All-routers link-local multicast group FF02::2

The MLD access group provides receiver access control in Cisco IOS XE IPv6 multicast routers. This feature limits the list of groups a receiver can join, and it allows or denies sources used to join SSM channels.

The explicit tracking feature allows a router to track the behavior of the hosts within its IPv6 network. This feature also enables the fast leave mechanism to be used with MLD version 2 host reports.

IPv6 multicast provides support for intradomain multicast routing using PIM-SM. PIM-SM uses unicast routing to provide reverse-path information for multicast tree building, but it is not dependent on any particular unicast routing protocol.

PIM-SM is used in a multicast network when relatively few routers are involved in each multicast and these routers do not forward multicast packets for a group, unless there is an explicit request for the traffic. PIM-SM distributes information about active sources by forwarding data packets on the shared tree. PIM-SM initially uses shared trees, which requires the use of an RP.

Requests are accomplished via PIM joins, which are sent hop by hop toward the root node of the tree. The root node of a tree in PIM-SM is the RP in the case of a shared tree or the first-hop router that is directly connected to the multicast source in the case of a shortest path tree (SPT). The RP keeps track of multicast groups and the hosts that send multicast packets are registered with the RP by that host's first-hop router.

As a PIM join travels up the tree, routers along the path set up multicast forwarding state so that the requested multicast traffic will be forwarded back down the tree. When multicast traffic is no longer needed, a router sends a PIM prune up the tree toward the root node to prune (or remove) the unnecessary traffic. As this PIM prune travels hop by hop up the tree, each router updates its forwarding state appropriately. Ultimately, the forwarding state associated with a multicast group or source is removed.

A multicast data sender sends data destined for a multicast group. The designated router (DR) of the sender takes those data packets, unicast-encapsulates them, and sends them directly to the RP. The RP receives these encapsulated data packets, de-encapsulates them, and forwards them onto the shared tree. The packets then follow the (*, G) multicast tree state in the routers on the RP tree, being replicated wherever the RP tree branches, and eventually reaching all the receivers for that multicast group. The process of encapsulating data packets to the RP is called registering, and the encapsulation packets are called PIM register packets.

• Designated Router
• Rendezvous Point

PIM routers in a domain must be able to map each multicast group to the correct RP address. The BSR protocol for PIM-SM provides a dynamic, adaptive mechanism to distribute group-to-RP mapping information rapidly throughout a domain. With the IPv6 BSR feature, if an RP becomes unreachable, it will be detected and the mapping tables will be modified so that the unreachable RP is no longer used, and the new tables will be rapidly distributed throughout the domain.

Every PIM-SM multicast group needs to be associated with the IP or IPv6 address of an RP. When a new multicast sender starts sending, its local DR will encapsulate these data packets in a PIM register message and send them to the RP for that multicast group. When a new multicast receiver joins, its local DR will send a PIM join message to the RP for that multicast group. When any PIM router sends a (*, G) join message, the PIM router needs to know which is the next router toward the RP so that the router can direct its (*, G) join message toward it. Also, when a PIM router is forwarding data packets using (*, G) state, the PIM router needs to know which is the correct incoming interface for packets destined for G, because it needs to reject any packets that arrive on other interfaces.

A small set of routers from a domain are configured as candidate bootstrap routers (C-BSRs) and a single BSR is selected for that domain. A set of routers within a domain are also configured as candidate RPs (C-RPs); typically, these routers are the same routers that are configured as C-BSRs. Candidate RPs periodically unicast candidate-RP-advertisement (C-RP-Adv) messages to the BSR of that domain, advertising their willingness to be an RP. A C-RP-Adv message includes the address of the advertising C-RP, and an optional list of group addresses and mask length fields, indicating the group prefixes for which the candidacy is advertised. The BSR then includes a set of these C-RPs, along with their corresponding group prefixes, in bootstrap messages (BSMs) it periodically originates. BSMs are distributed hop-by-hop throughout the domain.

The IPv6 BSR ability to configure RP mapping allows IPv6 multicast routers to be statically configured to announce scope-to-RP mappings directly from the BSR instead of learning them from candidate-RP messages. Announcing RP mappings from the BSR is useful in several situations:

• When an RP address never changes because there is only a single RP or the group range uses an anycast RP, it may be less complex to configure the RP address announcement statically on the candidate BSRs.
• When an RP address is a virtual RP address (such as when bidirectional PIM is used), it cannot be learned by the BSR from a candidate-RP. Instead, the virtual RP address must be configured as an announced RP on the candidate BSRs.

Cisco IOS XE IPv6 routers provide support for the RPF flooding of BSR packets so that a Cisco IOS XE IPv6 router will not disrupt the flow of BSMs. The router will recognize and parse enough of the BSM to identify the BSR address. The router performs an RPF check for this BSR address and forwards the packet only if it is received on the RPF interface. The router also creates a BSR entry containing RPF information to use for future BSMs from the same BSR. When BSMs from a given BSR are no longer received, the BSR entry is timed out.

Bidirectional BSR support allows bidirectional RPs to be advertised in C-RP messages and bidirectional ranges in the BSM. All routers in a system must be able to use the bidirectional range in the BSM; otherwise, the bidirectional RP feature will not function.

BSR provides scoped zone support by distributing group-to-RP mappings in networks using administratively scoped multicast. The user can configure candidate BSRs and a set of candidate RPs for each administratively scoped region in the user's domain.

For BSR to function correctly with administrative scoping, a BSR and at least one C-RP must be within every administratively scoped region. Administratively scoped zone boundaries must be configured at the zone border routers (ZBRs), because they need to filter PIM join messages that might inadvertently cross the border due to error conditions. In addition, at least one C-BSR within the administratively scoped zone must be configured to be a C-BSR for the administratively scoped zone's address range.

A separate BSR election will then take place (using BSMs) for every administratively scoped range, plus one for the global range. Administratively scoped ranges are identified in the BSM because the group range is marked to indicate that this is an administrative scope range, not just a range that a particular set of RPs is configured to handle.

Unless the C-RP is configured with a scope, it discovers the existence of the administratively scoped zone and its group range through reception of a BSM from the scope zone's elected BSR containing the scope zone's group range. A C-RP stores each elected BSR's address and the administratively scoped range contained in its BSM. It separately unicasts C-RP-Adv messages to the appropriate BSR for every administratively scoped range within which it is willing to serve as an RP.

All PIM routers within a PIM bootstrap domain where administratively scoped ranges are in use must be able to receive BSMs and store the winning BSR and RP set for all administratively scoped zones that apply.

PIM-SSM is the routing protocol that supports the implementation of SSM and is derived from PIM-SM. However, unlike PIM-SM where data from all multicast sources are sent when there is a PIM join, the SSM feature forwards datagram traffic to receivers from only those multicast sources that the receivers have explicitly joined, thus optimizing bandwidth utilization and denying unwanted Internet broadcast traffic. Further, instead of the use of RP and shared trees, SSM uses information found on source addresses for a multicast group. This information is provided by receivers through the source addresses relayed to the last-hop routers by MLD membership reports, resulting in shortest-path trees directly to the sources.

In SSM, delivery of datagrams is based on (S, G) channels. Traffic for one (S, G) channel consists of datagrams with an IPv6 unicast source address S and the multicast group address G as the IPv6 destination address. Systems will receive this traffic by becoming members of the (S, G) channel. Signaling is not required, but receivers must subscribe or unsubscribe to (S, G) channels to receive or not receive traffic from specific sources.

MLD version 2 is required for SSM to operate. MLD allows the host to provide source information. Before SSM will run with MLD, SSM must be supported in the Cisco IPv6 router, the host where the application is running, and the application itself.

• SSM Mapping for IPv6
• PIM Shared Tree and Source Tree (Shortest-Path Tree)
• Reverse Path Forwarding

When an IPv6 interior gateway protocol is used to build the unicast routing table, the procedure to detect the upstream router address assumes the address of a PIM neighbor is always same as the address of the next-hop router, as long as they refer to the same router. However, it may not be the case when a router has multiple addresses on a link.

Two typical situations can lead to this situation for IPv6. The first situation can occur when the unicast routing table is not built by an IPv6 interior gateway protocol such as multicast BGP. The second situation occurs when the address of an RP shares a subnet prefix with downstream routers (note that the RP router address has to be domain-wide and therefore cannot be a link-local address).

The routable address hello option allows the PIM protocol to avoid such situations by adding a PIM hello message option that includes all the addresses on the interface on which the PIM hello message is advertised. When a PIM router finds an upstream router for some address, the result of RPF calculation is compared with the addresses in this option, in addition to the PIM neighbor's address itself. Because this option includes all the possible addresses of a PIM router on that link, it always includes the RPF calculation result if it refers to the PIM router supporting this option.

Because of size restrictions on PIM messages and the requirement that a routable address hello option fits within a single PIM hello message, a limit of 16 addresses can be configured on the interface.

Bidirectional PIM allows multicast routers to keep reduced state information, as compared with unidirectional shared trees in PIM-SM. Bidirectional shared trees convey data from sources to the RPA and distribute them from the RPA to the receivers. Unlike PIM-SM, bidirectional PIM does not switch over to the source tree, and there is no register encapsulation of data from the source to the RP.

A single designated forwarder (DF) exists for each RPA on every link within a bidirectional PIM domain (including multiaccess and point-to-point links). The only exception is the RPL on which no DF exists. The DF is the router on the link with the best route to the RPA, which is determined by comparing MRIB-provided metrics. A DF for a given RPA forwards downstream traffic onto its link and forwards upstream traffic from its link toward the rendezvous point link (RPL). The DF performs this function for all bidirectional groups that map to the RPA. The DF on a link is also responsible for processing Join messages from downstream routers on the link as well as ensuring that packets are forwarded to local receivers discovered through a local membership mechanism such as MLD.

Bidirectional PIM offers advantages when there are many moderate or low-rate sources. However, the bidirectional shared trees may have worse delay characteristics than do the source trees built in PIM-SM (depending on the topology).

Only static configuration of bidirectional RPs is supported in IPv6.

A router configured with PIM will always send out PIM hello messages to all interfaces enabled for IPv6 multicast routing, even if the router is configured not to accept PIM messages from any neighbor on the LAN. The IPv6 PIM passive mode feature allows PIM passive mode to be enabled on an interface so that a PIM passive interface cannot send and receive PIM control messages, but it can act as RPF interface for multicast route entries, and it can accept and forward multicast data packets.

Distributed Multicast Forwarding Information Base (MFIB) is used to switch multicast IPv6 packets on distributed platforms. Distributed MFIB may also contain platform-specific information on replication across line cards. The basic MFIB routines that implement the core of the forwarding logic are common to all forwarding environments.

dMFIB implements the following functions:

• Distributes a copy of the MFIB to the line cards.
• Relays data-driven protocol events generated in the line cards to PIM.
• Provides an MFIB platform application program interface (API) to propagate MFIB changes to platform-specific code responsible for programming the hardware acceleration engine. This API also includes entry points to switch a packet in software (necessary if the packet is triggering a data-driven event) and to upload traffic statistics to the software.
• Provides hooks to allow clients residing on the RP to read traffic statistics on demand. Distributed MFIB does not periodically upload these statistics to the RP.

The combination of distributed MFIB and MRIB subsystems allows the device to have a "customized" copy of the MFIB database in each line card and to transport MFIB-related platform-specific information from the RP to the line cards.

The threshold notification for mCAC limit feature notifies the user when actual simultaneous multicast channel numbers exceeds or fall below a specified threshold percentage. For example, if the mCAC rate limit is set to 50,000,000 and the configured threshold percentage is 80 percent, then the user is notified if the limit exceeds 10,000,000.

1.    enable

2.    configure terminal

3.    interface type number

4.    ipv6 mld join-group [group-address] [[include | exclude] {source-address | source-list [acl]}

5.    ipv6 mld access-group access-list-name

6.    ipv6 mld static-group [group-address] [[include| exclude] {source-address | source-list [acl]}

7.    ipv6 mld query-max-response-time seconds

8.    ipv6 mld query-timeout seconds

9.    ipv6 mld query-interval seconds

10.    exit

11.    show ipv6 mld groups [link-local] [group-name | group-address] [interface-type interface-number] [detail | explicit

12.    show ipv6 mfib summary

13.    show ipv6 mld interface [type number

Per-interface and global MLD limits operate independently of each other. Both per-interface and global MLD limits can be configured on the same router. The number of MLD limits, globally or per interface, is not configured by default; the limits must be configured by the user. A membership report that exceeds either the per-interface or the global state limit is ignored.

• Implementing MLD Group Limits Globally
• Implementing MLD Group Limits per Interface

1.    enable

2.    configure terminal

3.    interface type number

4.    ipv6 mld explicit-tracking access-list-name

1.    enable

2.    configure terminal

3.    ipv6 multicast group-range [access-list-name

1.    enable

2.    clear ipv6 mld [vrf vrf-name] traffic

3.    show ipv6 mld [vrf vrf-name] traffic

1.    enable

2.    clear ipv6 mld [vrf vrf-name] counters interface-type

1.    enable

2.    configure terminal

3.    ipv6 pim [vrf vrf-name] spt-threshold infinity [group-list access-list-name]

4.    interface type number

5.    ipv6 pim dr-priority value

6.    ipv6 pim hello-interval seconds

7.    ipv6 pim join-prune-interval seconds

8.    exit

9.    show ipv6 pim [vrf vrf-name] join-prune statistic [interface-type]

1.    enable

2.    configure terminal

3.    ipv6 pim [vrf vrf-name] rp-address ipv6-address [group-access-list] [bidir]

4.    exit

5.    show ipv6 pim df [interface-type interface-number] [rp-address]

6.    show ipv6 pim [vrf vrf-name] df winner[interface-type interface-number] [rp-address]

1.    enable

2.    configure terminal

3.    ipv6 multicast pim-passive-enable

4.    interface type number

5.    ipv6 pim passive

1.    enable

2.    clear ipv6 pim [vrf vrf-name] traffic

3.    show ipv6 pim [vrf vrf-name] traffic

1.    enable

2.    clear ipv6 pim topology [group-name | group-address

3.    show ipv6 mrib client filter ] [name {client-name | client-name : client-id}]

4.    show ipv6 mrib route [link-local | summary | source-address | source-name | *] [group-name | group-address [prefix-length]]

5.    show ipv6 pim topology [link-local | route-count | group-name | group-address] [source-address | source-name

1.    enable

2.    configure terminal

3.    ipv6 pim [vrf vrf-name] bsr candidate bsr ipv6-address[hash-mask-length] [priority priority-value]

4.    interface type number

5.    ipv6 pim bsr border

6.    exit

7.    show ipv6 pim [vrf vrf-name] bsr {election | rp-cache | candidate-rp}

1.    enable

2.    configure terminal

3.    ipv6 pim [vrf vrf-name] bsr candidate rp ipv6-address [group-list access-list-name] [priority priority-value] [interval seconds] [scope scope-value] [bidir]

4.    interface type number

5.    ipv6 pim bsr border

• Disabling the Router from Receiving Unauthenticated Multicast Traffic

1.    enable

2.    configure terminal

3.    router bgp as-number

4.    neighbor peer-group-name peer-group

5.    neighbor {ip-address | ipv6-address | peer-group-name} remote-as as-number

6.    address-family ipv6 [unicast | multicast]

7.    neighbor {ip-address | peer-group-name | ipv6-address} activate

8.    neighbor {ip-address | ipv6-address} peer-group peer-group-name

• What to Do Next

1.    enable

2.    configure terminal

3.    router bgp as-number

4.    address-family ipv6 [vrf vrf-name] [unicast | multicast | vpnv6]

5.    network {network-number [mask network-mask] | nsap-prefix} [route-map map-tag]

6.    exit

• What to Do Next

1.    enable

2.    configure terminal

3.    router bgp as-number

4.    address-family ipv6 [vrf vrf-name] [unicast | multicast | vpnv6]

5.    redistribute bgp [process-id] [metric metric-value] [route-map map-name] [source-protocol-options]

6.    exit

• What to Do Next

Caution

Changing the administrative distance of BGP internal routes is not recommended. One problem that can occur is the accumulation of routing table inconsistencies, which can break routing.

1.    enable

2.    configure terminal

3.    router bgp as-number

4.    address-family ipv6 [unicast | multicast}

5.    distance bgp external-distance internal-distance local-distance

1.    enable

2.    configure terminal

3.    router bgp as-number

4.    address-family ipv6 [unicast | multicast}

5.    neighbor ipv6-address translate-update ipv6 multicast [unicast]

1.    enable

2.    clear bgp ipv6 {unicast | multicast} {* | autonomous-system-number | ip-address | ipv6-address | peer-group peer-group-name} [soft] [in | out]

1.    enable

2.    clear bgp ipv6 {unicast | multicast} external [soft] [in | out]

3.    clear bgp ipv6 {unicast | multicast} peer-group name

1.    enable

2.    clear bgp ipv6 {unicast | multicast} dampening [ipv6-prefix prefix-length]

1.    enable

2.    clear bgp ipv6 {unicast | multicast} flap-statistics [ipv6-prefix/prefix-length | regexp regexp | filter-list list]

1.    enable

2.    configure terminal

3.    interface type number

4.    ipv6 address {ipv6-address / prefix-length | prefix-name sub-bits/prefix-length

5.    ipv6 multicast limit [connected | rpf | out] limit-acl max [threshold threshold-value]

1.    enable

2.    configure terminal

3.    ipv6 access-list access-list-name

4.    permit

1.    enable

2.    configure terminal

3.    ipv6 multicast [vrf vrf-name] limit cost access-list cost-multiplier

1.    enable

2.    configure terminal

3.    ipv6 multicast limit rate rate-value

4.    interface type number

5.    ipv6 multicast limit [connected | rpf | out] limit-acl max [threshold threshold-value]

Note	Multicast forwarding is automatically enabled when IPv6 multicast routing is enabled.

1.    enable

2.    show ipv6 mfib [vrf vrf-name] [link-local | verbose | group-address-name | ipv6-prefix / prefix-length | source-address-name| active | count | interface | status | summary]

3.    show ipv6 mfib [vrf vrf-name] [link-local| group-name | group-address] active [kbps]

4.    show ipv6 mfib [vrf vrf-name] [all | linkscope| group-name | group-address [source-name | source-address]] count

5.    show ipv6 mfib interface

6.    show ipv6 mfib status

7.    show ipv6 mfib [vrf vrf-name] summary

8.    debug ipv6 mfib [vrf vrf-name] [group-name| group-address] [adjacency | db | fs | init | interface | mrib [detail] | nat | pak | platform | ppr | ps | signal | table]

1.    enable

2.    clear ipv6 mfib [vrf vrf-name] counters [group-name | group-address [source-address | source-name]]

A user might want to disable embedded RP support on an interface if all of the routers in the domain do not support embedded RP.

Note	This task disables PIM completely, not just embedded RP support in IPv6 PIM.

1.    enable

2.    configure terminal

3.    no ipv6 pim [vrf vrf-name] rp embedded

4.    interface type number

5.    no ipv6 pim

1.    enable

2.    configure terminal

3.    interface type number

4.    no ipv6 pim

1.    enable

2.    configure terminal

3.    interface type number

4.    no ipv6 mld router

1.    enable

2.    configure terminal

3.    no ipv6 mfib