SSO--IPv4 Multicast HA Support for Group-to-RP Mappings

Available Languages

Download Options

  • PDF     (219.9 KB)
    View with Adobe Reader on a variety of devices
Updated:November 14, 2008

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

SSO—IPv4 Multicast HA Support for Group-to-RP Mapping

Table Of Contents

SSO—IPv4 Multicast HA Support for Group-to-RP Mapping

Finding Feature Information

Contents

Prerequisites for SSO—IPv4 Multicast HA Support for Group-to-RP Mapping

Information About SSO—IPv4 Multicast HA Support for Group-to-RP Mapping

Overview of SSO—IPv4 Multicast HA Support for Group-to-RP Mapping

Dynamic IPv4 Multicast SSO Synchronization Events That Occur During Normal Operation (Steady State)

IPv4 Unicast and Multicast NSF/SSO Holdoff Period and Resynchronization of the Data Plane Following an RP Switchover

IPv4 Unicast and Multicast NSF/SSO Events That Occur Following an RP Switchover

ISSU Support for IPv4 Multicast

How to Monitor SSO—IPv4 Multicast HA Support for Group-to-RP Mapping

Monitoring SSO—IPv4 Multicast HA Support for Group-to-RP Mapping

Examples

Configuration Examples for SSO—IPv4 Multicast HA Support for Group-to-RP Mapping

Additional References

Related Documents

Standards

MIBs

RFCs

Technical Assistance

Feature Information for SSO—IPv4 Multicast HA Support for Group-to-RP Mapping


SSO—IPv4 Multicast HA Support for Group-to-RP Mapping

First Published: November 14, 2008
Last Updated: November 14, 2008

The SSO—IPv4 Multicast HA Support for Group-to-RP Mapping feature enhances multicast high availability (HA) functionality by providing support for the synchronization of dynamically learned group-to-rendezvous point (RP) mappings and bidirectional PIM (bidir-PIM) designated forwarder (DF) information on the standby Route Processor (RP). In addition, this feature also provides In Service Software Upgrade (ISSU) support for Protocol Independent Multicast (PIM).

These capabilities together enable Cisco nonstop forwarding (NSF) with stateful switchover (SSO) support for IPv4 multicast, which—following an RP switchover—reduces the reconvergence time of the multicast control plane to a level that is transparent to most multicast-based applications.

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the "Feature Information for SSO—IPv4 Multicast HA Support for Group-to-RP Mapping" section.

Use Cisco Feature Navigator to find information about platform support and Cisco IOS and Catalyst OS software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.

Contents

•Prerequisites for SSO—IPv4 Multicast HA Support for Group-to-RP Mapping

•Information About SSO—IPv4 Multicast HA Support for Group-to-RP Mapping

•How to Monitor SSO—IPv4 Multicast HA Support for Group-to-RP Mapping

•Configuration Examples for SSO—IPv4 Multicast HA Support for Group-to-RP Mapping

•Additional References

•Feature Information for SSO—IPv4 Multicast HA Support for Group-to-RP Mapping

•Feature Information for SSO—IPv4 Multicast HA Support for Group-to-RP Mapping

Prerequisites for SSO—IPv4 Multicast HA Support for Group-to-RP Mapping

•This module assumes that your device is configured for IP multicast and is participating in an IP multicast network. For more information about configuring IP multicast, see the "Configuring Basic IP Multicast" module.

•SSO must be configured and working properly. If you do not have SSO enabled, see the "Stateful Switchover" module.

•This module assumes that you are familiar with NSF concepts. For more information about NSF, see the "Nonstop Forwarding" module.

•This module assumes that you are familiar with the Cisco IOS In Service Software Upgrade (ISSU) process. For more information, see the "Cisco IOS In Service Upgrade Software Upgrade Process" module.

Information About SSO—IPv4 Multicast HA Support for Group-to-RP Mapping

Before monitoring and maintaining the SSO—IPv4 Multicast HA Support for Group-to-RP Mapping feature, you should understand the following concepts:

•Overview of SSO—IPv4 Multicast HA Support for Group-to-RP Mapping

•ISSU Support for IPv4 Multicast

Overview of SSO—IPv4 Multicast HA Support for Group-to-RP Mapping

Prior to the introduction of the SSO—IPv4 Multicast HA Support for Group-to-RP Mapping feature, the Cisco IOS software provided SSO support for the synchronization of static group-to-RP mappings for IP multicast. With the introduction of the SSO—IPv4 Multicast HA Support for Group-to-RP Mapping feature, the Cisco IOS software enhances multicast HA functionality by providing support for the synchronization of the following information on the standby RP:

•Dynamically learned group-to-RP mappings learned from either Auto-RP or BSR.

•Bidir-PIM DF information and RP route information.

•Multicast VPN (MVPN) tunnel information.

•PIM register tunnel information.

In addition, this feature also provides ISSU support for PIM.

Note For improved reliability of MVPN and PIM register tunnel-based flows, the SSO—IPv4 Multicast HA Support for Group-to-RP Mapping feature provides support for the synchronization of MVPN and PIM register tunnel information on the standby RP.

These capabilities together enable Cisco NSF/SSO support for IPv4 multicast (PIM sparse mode [PIM-SM], Source Specific Multicast [SSM], and bidir-PIM), which—following a switchover—reduces the reconvergence time of the multicast control plane to a level that is transparent to most multicast-based applications.

Dynamic IPv4 Multicast SSO Synchronization Events That Occur During Normal Operation (Steady State)

During normal operation (steady state), the Cisco IOS software dynamically synchronizes information corresponding to events that modify the multicast forwarding state on the standby RP. Instead of performing periodic bulk synchronization updates, the Cisco IOS software only sends updates for modified entities within internal databases. These updates are triggered by events that cause internal database changes related to the multicast forwarding state.

Note This functionality applies only to the dynamic synchronization on the standby RP for updates to the multicast forwarding state that occur during steady state operation. Bulk synchronization updates, however, are required whenever a standby RP is inserted, reloaded, or reset.

In steady state, the following internal multicast forwarding databases are dynamically synchronized on the standby RP:

•RP Mapping—Internal database that stores group-to-RP mapping information.

•Bidirectional Route Information—Internal database that stores bidir-PIM RP route information.

•Bootstrap Cache—Internal database that stores BSR candidate information.

•AutoRP Discovery IDB—Internal database that stores AutoRP discovery message information.

•RPDF—Internal database that stores the set of interfaces enabled for the reception of bidir-PIM packets for a given bidir-PIM RP.

•MDT Tunnel—Internal database that stores MVPN MDT tunnel information.

•PIM Register Tunnel—Internal database that stores PIM register tunnel information.

IPv4 Unicast and Multicast NSF/SSO Holdoff Period and Resynchronization of the Data Plane Following an RP Switchover

Following an RP failure, data plane forwarding information is retained despite the fact that the new primary RP does not have a complete set of control plane information. The retention of this information enables forwarding to continue during unicast and multicast routing protocol reconvergence. While unicast and multicast routing protocol reconvergence is in progress, a holdoff period is observed during which no multicast forwarding updates are sent from the multicast routing protocol layer to the data plane layer. The holdoff period ends after unicast and multicast protocol convergence have completed.

Unicast routing protocol convergence begins before multicast protocol convergence. Multicast routing protocol (PIM) convergence does not begin until the multicast protocol layer receives explicit signaling that unicast routing protocol convergence has completed. Unicast protocols that are not SSO-aware are not covered by this signal and are not taken into account when waiting for convergence.

Note Some SSO-aware routing protocols (for example, BGP) may generate logging messages indicating that the initial convergence has completed (based on an internal timer) before full convergence has occurred. PIM, however, does not provide any explicit indication of reconvergence.

It is possible (and, in many cases, expected) that the holdoff period may terminate before full convergence of unicast routing protocols, which will result in null Reverse Path Forwarding (RPF) interfaces for any affected IP addresses. As additional unicast routing updates are received, the affected multicast routes are updated as needed. This is expected and acceptable behavior for SSO-aware routing protocols that are slower in converging.

Note An RP switchover occurring on a system operating with unicast protocols that are not SSO-aware will cause undesirably long convergence times—but no routing loops—for multicast routes.

At the end of the holdoff period, the multicast data plane layer marks any existing data plane information as stale and that information is subsequently flushed.

IPv4 Unicast and Multicast NSF/SSO Events That Occur Following an RP Switchover

In the event of an RP switchover, even with the continuous synchronization of unicast and multicast routing information from the primary to the standby RP, it is not possible to guarantee that the information most recently updated on the primary RP can be synchronized to the standby RP before a failure occurs on the primary RP. For this reason, following an RP switchover, both unicast and multicast routing protocols trigger the retransmission of routing information from neighboring routers to ensure that the unicast and multicast routing information is current.

For IPv4 multicast protocol retransmission, the Cisco IOS software triggers a refresh of all multicast routing information available from PIM neighbors using the PIM GenerationID (GenID) capability described in RFC 4601. GenID support enables fast mroute reconvergence after a switchover. A GenID is a randomly generated 32-bit value regenerated each time PIM forwarding is started or restarted on an interface. In the event of a switchover, the GenID value is used as a mechanism to trigger adjacent PIM neighbors on an interface to send PIM join messages for all (*, G) and (S, G) mroutes that use that interface as an RPF interface, immediately reestablishing those states on the new primary RP. IGMP group membership information is restored by executing IGMP queries on all IGMP interfaces.

Note In order to process the GenID value in PIM hello messages, PIM neighbors must be running a Cisco IOS software image that supports an implementation of PIM compliant with RFC 4601, Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). GenID support was introduced in the Cisco IOS software in association with the PIM Triggered Joins feature. For more information about the PIM Triggered Joins feature and RFC 4601, see the "Additional References" section.

The following IPv4 multicast NSF/SSO events occur in parallel following an RP switchover:

•The Cisco IOS software empties the queue containing unprocessed synchronization messages for IPv4 multicast sent by the previous primary RP and starts a unicast IGP convergence fail-safe timer to handle the possibility that unicast Interior Gateway Protocol (IGP) convergence never completes.

•As interfaces come up on the new primary RP, unicast routing protocol reconvergence processing proceeds.

•As each PIM enabled interface comes up, PIM hello messages are sent out using a new GenID value for the interface. The modified GenID value triggers PIM join and prune messages from all adjacent PIM neighbors on the network to which the interface is attached. As these messages are received, information about mroute states that were missing on the new primary RP are restored except for last hop shortest path tree (SPT) (S, G) routes and mroutes associated with directly connected hosts with no other intermediate routers. Because this routing information begins to arrive before unicast IGP convergence has occurred, mroutes may initially have NULL RPF ingress interfaces. As this state information is learned, the multicast protocol layer sends the corresponding update messages to the Multicast Routing Information Base (MRIB).

•IGMP group membership information is restored by the execution of IGMP queries on all IGMP interfaces.

ISSU Support for IPv4 Multicast

The ISSU process allows Cisco IOS software to be updated or otherwise modified while packet forwarding continues. In most networks, planned software upgrades are a significant cause of downtime. ISSU allows Cisco IOS software to be modified while packet forwarding continues, which increases network availability and reduces downtime caused by planned software upgrades.

To provide the required ISSU and SSO support necessary for IPv4 multicast, a PIM ISSU client was introduced in association with the IPv4 Multicast HA Group-to-RP Mapping feature. The PIM ISSU client resides on both the primary and the standby RPs and is responsible for enabling PIM synchronization message transmission between two RPs using different versions of software. The PIM ISSU client is responsible for performing transformation of PIM dynamic state synchronization messages sent from or received by the RP having the most recent software version. If synchronization messages are sent to a downlevel RP, the messages are translated to the older format used by the downlevel RP. If messages are received from the downlevel RP, the messages are translated to the newer format used by the receiving RP before being passed to the Cisco IOS PIM HA software for processing.

How to Monitor SSO—IPv4 Multicast HA Support for Group-to-RP Mapping

This section contains the following task:

•Monitoring SSO—IPv4 Multicast HA Support for Group-to-RP Mapping (optional)

Monitoring SSO—IPv4 Multicast HA Support for Group-to-RP Mapping

Perform this optional task to monitor the SSO—IPv4 Multicast HA Support for Group-to-RP Mapping feature.

SUMMARY STEPS

1. enable

2. debug ip multicast redundancy [verbose]

3. show ip pim neighbor

4. show ip multicast redundancy state

5. show ip multicast redundancy statistics

6. clear ip multicast redundancy statistics

DETAILED STEPS

Step 1 enable

Enables privileged EXEC mode. Enter your password if prompted. 

Router> enable

Step 2 debug ip multicast redundancy [verbose]

Use this command to display IP multicast redundancy events.

This command logs events that are important in verifying the operation of NSF/SSO operation for IP multicast. The classes of events logged by debug ip multicast redundancy command include stateful switchover events during an RP switchover and dynamic synchronization events that occur during steady state operation.

Use the optional verbose keyword to log events that may occur very frequently during normal operation, but which may be useful for tracking in short intervals.

The following is output from the debug ip multicast redundancy command. The output displays the logging message that is displayed when the standby RP is recovered after a standby RP transition: 

*Aug  7 02:36:07.843: MCAST-HA-RF: Status event: 
status=RF_STATUS_OPER_REDUNDANCY_MODE_CHANGE  Op=7  RFState=ACTIVE

Step 3 show ip pim neighbor

Use this command to display the PIM neighbors discovered by PIMv1 router query messages or PIMv2 hello messages that support the GenID capability.

The output of the show ip pim neighbor command displays the "G" flag to indicate GenID support status for each PIM neighbor. The "G" flag is displayed only if the neighbor supports the GenID capabilities provided by PIM.

GenID support enables fast mroute reconvergence after a switchover. A GenID is a randomly generated 32-bit value regenerated each time PIM forwarding is started or restarted on an interface. In the event of a switchover, the GenID value used as a mechanism to trigger adjacent PIM neighbors on an interface to send PIM join messages for all (*, G) and (S, G) mroutes that use that interface as an RPF interface, immediately reestablishing those states on the newly active RP.

Note In order to process the GenID value in PIM hello messages, PIM neighbors must be running a Cisco IOS software image that supports an implementation of PIM compliant with RFC 4601, Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). GenID support was introduced in the Cisco IOS software in association with the PIM Triggered Joins feature. For more information about the PIM Triggered Joins feature and RFC 4601, see the "Additional References" section. 

Router# show ip pim neighbor


PIM Neighbor Table

Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,

      P - Proxy Capable, S - State Refresh Capable, G - GenID Capable

Neighbor          Interface                Uptime/Expires    Ver   DR

Address                                                            Prio/Mode

192.168.10.5      Ethernet0/1              00:01:35/00:01:37 v2    1 / DR B S P G

Step 4 show ip multicast redundancy state

Use this command to display the current redundancy state for IP multicast.

The output displays information about the current multicast redundancy state of the RPs and the current synchronization state of the standby RP. 

Router# show ip multicast redundancy state


Multicast Redundancy state:   SSO

Sync message epoch:           0

Sync message sequence number: 11

Stale NSF state flush timeout: 30000 ms

Current sync state: Synched

Step 5 show ip multicast redundancy statistics

Use this command to display IP multicast redundancy statistics.

The output displays the following information:

•Statistics about the internal multicast forwarding databases that are synchronized between the active and standby RP, including the number of updates that required standby RP synchronization, number of updates synchronized by the standby RP, and number of updates that failed synchronization.

•Statistics about internal synchronization message requests for updates between the active and standby RPs.

•Statistics that measure the load on the internal synchronization message sending mechanism. 

Router# show ip multicast redundancy statistics


Multicast Redundancy Statistics

Sync Type              Updates       Syncs        Sync failures


RP mapping              12           12           0           

Bidir. RP route info    0            0            0           

Bootstrap cache         12           12           0           

Autorp discovery IDB    12           12           0           

RPDF                    0            0            0           

MDT tunnel              9            9            0           

PIM register tunnel     0            0            0 

Requests Awaiting Sync Msg Transmission: 0

Requests Awaiting Sync Msg Acknowledgement: 0

Average Sync Wait Time = 0 ms

Average Sync Ack Time = 70 ms

Step 6 clear ip multicast redundancy statistics

Use this command to reset IP multicast redundancy statistics. 

Router# clear ip multicast redundancy statistics

Examples

The following examples show how to monitor the SSO—IPv4 Multicast HA Support for Group-to-RP Mapping feature:

•Monitoring an IPv4 Multicast NSF/SSO Events During an RP Switchover: Example

•Monitoring the Loss and Subsequent Recovery of a Standby RP: Example

Monitoring an IPv4 Multicast NSF/SSO Events During an RP Switchover: Example

The following example shows how to monitor IP multicast NSF/SSO events during an RP switchover using the debug ip multicast redundancy command. The example shows IP multicast events occurring as a standby RP assumes the role of active RP during an SSO switchover. The events labeled "MCAST-HA" are logged by the IP multicast SSO debug facility.

Initial Switchover Detection

The following output is from the debug ip multicast redundancy command. The output shows the initial logging messages that display when the system detects an RP switchover. 

00:10:33: %REDUNDANCY-3-SWITCHOVER: RP switchover (PEER_DOWN_INTERRUPT)

00:10:33: %REDUNDANCY-5-PEER_MONITOR_EVENT: Standby received a switchover 
(raw-event=PEER_DOWN_INTERRUPT(11))


*Aug  7 02:31:28.051: MCAST-HA: Received cf status CHKPT_STATUS_PEER_NOT_READY

*Aug  7 02:31:28.063: MCAST-HA: Received cf status CHKPT_STATUS_PEER_NOT_READY

*Aug  7 02:31:28.063: MCAST-HA-RF: Status event: status=RF_STATUS_PEER_COMM  Op=0  
RFState=STANDBY HOT 

*Aug  7 02:31:28.063: MCAST-HA-RF: Status event: 
status=RF_STATUS_OPER_REDUNDANCY_MODE_CHANGE  Op=0  RFState=STANDBY HOT 

*Aug  7 02:31:28.063: MCAST-HA-RF: Status event: status=RF_STATUS_REDUNDANCY_MODE_CHANGE  
Op=0  RFState=STANDBY HOT 

*Aug  7 02:31:28.063: MCAST-HA-RF: Status event: status=RF_STATUS_PEER_PRESENCE  Op=0  
RFState=STANDBY HOT 

*Aug  7 02:31:28.063: MCAST-HA-RF: Status event: status=RF_STATUS_MAINTENANCE_ENABLE  Op=0  
RFState=ACTIVE-FAST 

*Aug  7 02:31:28.063: MCAST-HA-RF: Progression event: RF_Event=RF_PROG_ACTIVE_FAST 
RFState=ACTIVE-FAST

*Aug  7 02:31:28.091: MCAST-HA-RF: Progression event: RF_Event=RF_PROG_ACTIVE_DRAIN 
RFState=ACTIVE-DRAIN

*Aug  7 02:31:28.091: MCAST-HA-RF: Progression event: RF_Event=RF_PROG_ACTIVE_PRECONFIG 
RFState=ACTIVE_PRECONFIG

*Aug  7 02:31:28.091: MCAST-HA-RF: Progression event: RF_Event=RF_PROG_ACTIVE_POSTCONFIG 
RFState=ACTIVE_POSTCONFIG

*Aug  7 02:31:28.103: MCAST-HA: Received cf status CHKPT_STATUS_IPC_FLOW_ON

*Aug  7 02:31:28.103: MCAST-HA-RF: Progression event: RF_Event=RF_PROG_ACTIVE 
RFState=ACTIVE

Unicast Convergence Detection and Multicast Route Control Plane Convergence

The following output is from the debug ip multicast redundancy command. As interfaces come up on the new active RP, unicast convergence occurs in parallel with multicast route refresh from PIM neighbors. Unicast convergence is followed by RPF adjustments to the refreshed mroute information. 

*Aug  7 02:31:28.107: MCAST-HA: Triggering unicast convergence notification process 
handling for MVRF IPv4 default

*Aug  7 02:31:28.107: MCAST-HA: Triggering unicast convergence notification process 
handling for MVRF blue

*Aug  7 02:31:28.107: MCAST-HA: Triggering unicast convergence notification process 
handling for MVRF green

*Aug  7 02:31:28.107: MCAST-HA: Triggering unicast convergence notification process 
handling for MVRF red

*Aug  7 02:31:28.107: MCAST-HA: Triggering unicast convergence notification process 
handling for all MVRFs

*Aug  7 02:31:28.111: MCAST-HA: Beginning unicast convergence notification process 
handling.

*Aug  7 02:31:28.111: MCAST-HA: Unicast convergence completed for MVRF IPv4 default:  
Triggering RPF updates

*Aug  7 02:31:28.111: MCAST-HA: Beginning unicast convergence notification process 
handling.

*Aug  7 02:31:28.111: MCAST-HA: Unicast convergence completed for MVRF blue:  Triggering 
RPF updates

*Aug  7 02:31:28.111: MCAST-HA: Beginning unicast convergence notification process 
handling.

*Aug  7 02:31:28.111: MCAST-HA: Unicast convergence completed for MVRF green:  Triggering 
RPF updates

*Aug  7 02:31:28.111: MCAST-HA: Beginning unicast convergence notification process 
handling.

*Aug  7 02:31:28.111: MCAST-HA: Unicast convergence completed for MVRF red:  Triggering 
RPF updates

*Aug  7 02:31:28.111: MCAST-HA: Unicast convergence notification has been received for the 
only unconverged VRF.

Stopping the unicast routing convergence failsafe timer.

*Aug  7 02:31:28.111: MCAST-HA: Beginning unicast convergence notification process 
handling.

*Aug  7 02:31:28.111: MCAST-HA: Unicast convergence notification received for the wildcard 
tableid (all VRFs).

Triggering RPF updates for all MVRFs and stopping the unicast IGP convergence failsafe 
timer.

00:10:34: %PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 172.16.1.1 on interface 
Loopback0

00:10:34: %PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 172.31.10.1 on interface 
Loopback1

00:10:35: %PIM-5-DRCHG: VRF green: DR change from neighbor 0.0.0.0 to 172.16.1.1 on 
interface Tunnel1

00:10:35: %PIM-5-DRCHG: VRF red: DR change from neighbor 0.0.0.0 to 172.16.1.1 on 
interface Tunnel2

00:10:35: %LINK-3-UPDOWN: Interface Null0, changed state to up

00:10:35: %LINK-3-UPDOWN: Interface Loopback0, changed state to up

00:10:35: %LINK-3-UPDOWN: Interface Loopback1, changed state to up

00:10:35: %LINK-3-UPDOWN: Interface Tunnel0, changed state to up

00:10:35: %LINK-3-UPDOWN: Interface Tunnel1, changed state to up

00:10:35: %LINK-3-UPDOWN: Interface Tunnel2, changed state to up

00:10:35: %LINK-5-CHANGED: Interface Ethernet0/0, changed state to administratively down

00:10:35: %LINK-5-CHANGED: Interface Ethernet0/1, changed state to administratively down

00:10:35: %LINK-5-CHANGED: Interface Ethernet0/2, changed state to administratively down

00:10:35: %LINK-5-CHANGED: Interface Ethernet0/3, changed state to administratively down

00:10:35: %LINK-5-CHANGED: Interface Ethernet1/0, changed state to administratively down

00:10:35: %LINK-5-CHANGED: Interface Ethernet1/1, changed state to administratively down

00:10:35: %LINK-5-CHANGED: Interface Ethernet1/2, changed state to administratively down

00:10:35: %LINK-5-CHANGED: Interface Ethernet1/3, changed state to administratively down

00:10:36: %LINEPROTO-5-UPDOWN: Line protocol on Interface Null0, changed state to up

00:10:36: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to up

00:10:36: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback1, changed state to up

00:10:36: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up

00:10:36: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up

00:10:36: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel2, changed state to up

00:10:38: %PIM-5-DRCHG: VRF blue: DR change from neighbor 0.0.0.0 to 172.16.1.1 on 
interface Tunnel0

IGMP Queries, Termination of the NSF Holdoff Period, and Flushing of Stale Forwarding Information

The following output is from the debug ip multicast redundancy command. After the processing of unicast and multicast route convergence, time is allowed for IGMP reporting. After this processing completes, the control plane waits for the NSF holdoff time period to terminate. The refreshed multicast control plane information is then downloaded to the forwarding plane; once completed, the stale multicast forwarding plane information is subsequently flushed. 

*Aug  7 02:31:43.651: MCAST-HA: IGMP response timer expired. Ready for DDE replay for MVRF 
red

*Aug  7 02:31:43.651: MCAST-HA: Sending DDE replay request for MVRF red.

*Aug  7 02:31:43.651: MCAST-HA: MFIB DDE replay completed for mvrf red

*Aug  7 02:31:43.651: MCAST-HA: No NSF Holdoff extension requested for mvrf red at 
completion of DDE replay.

*Aug  7 02:31:43.651: MCAST-HA: Terminating multicast NSF holdoff for MVRF red

*Aug  7 02:31:43.651: MCAST-HA: Still awaiting MFIB DDE replay for mvrf green

 DDE replay: NOT COMPLETED, MRIB update: NOT PENDING

*Aug  7 02:31:43.651: MCAST-HA: IGMP response timer expired. Ready for DDE replay for MVRF 
green

*Aug  7 02:31:43.651: MCAST-HA: Sending DDE replay request for MVRF green.

*Aug  7 02:31:43.651: MCAST-HA: MFIB DDE replay completed for mvrf green

*Aug  7 02:31:43.651: MCAST-HA: No NSF Holdoff extension requested for mvrf green at 
completion of DDE replay.

*Aug  7 02:31:43.651: MCAST-HA: Terminating multicast NSF holdoff for MVRF green

*Aug  7 02:31:43.651: MCAST-HA: Still awaiting MFIB DDE replay for mvrf blue

 DDE replay: NOT COMPLETED, MRIB update: NOT PENDING

*Aug  7 02:31:43.651: MCAST-HA: IGMP response timer expired. Ready for DDE replay for MVRF 
blue

*Aug  7 02:31:43.651: MCAST-HA: Sending DDE replay request for MVRF blue.

*Aug  7 02:31:43.651: MCAST-HA: MFIB DDE replay completed for mvrf blue

*Aug  7 02:31:43.651: MCAST-HA: No NSF Holdoff extension requested for mvrf blue at 
completion of DDE replay.

*Aug  7 02:31:43.651: MCAST-HA: Terminating multicast NSF holdoff for MVRF blue

*Aug  7 02:31:43.651: MCAST-HA: Still awaiting MFIB DDE replay for mvrf IPv4 default

 DDE replay: NOT COMPLETED, MRIB update: NOT PENDING

*Aug  7 02:31:43.651: MCAST-HA: IGMP response timer expired. Ready for DDE replay for MVRF 
IPv4 default

*Aug  7 02:31:43.651: MCAST-HA: Sending DDE replay request for MVRF IPv4 default.

*Aug  7 02:31:43.651: MCAST-HA: MFIB DDE replay completed for mvrf IPv4 default

*Aug  7 02:31:43.651: MCAST-HA: No NSF Holdoff extension requested for mvrf IPv4 default 
at completion of DDE replay.

*Aug  7 02:31:43.651: MCAST-HA: Terminating multicast NSF holdoff for MVRF IPv4 default

*Aug  7 02:31:43.651: MCAST-HA: MFIB DDE replay completed for all MVRFs.

*Aug  7 02:31:43.651: MCAST-HA: Stopping the MFIB DDE replay failsafe timer.


*Aug  7 02:32:13.651: MCAST-HA: Flush timer expired. Starting final RPF check for MVRF 
IPv4 default

*Aug  7 02:32:13.651: MCAST-HA: Flush timer expired. Starting final RPF check for MVRF 
blue

*Aug  7 02:32:13.651: MCAST-HA: Flush timer expired. Starting final RPF check for MVRF 
green

*Aug  7 02:32:13.651: MCAST-HA: Flush timer expired. Starting final RPF check for MVRF red

*Aug  7 02:32:14.151: MCAST-HA: Flushing stale mcast state. RP failover processing 
complete for MVRF IPv4 default.

*Aug  7 02:32:14.151: MCAST-HA: Flushing stale mcast state. RP failover processing 
complete for MVRF blue.

*Aug  7 02:32:14.151: MCAST-HA: Flushing stale mcast state. RP failover processing 
complete for MVRF green.

*Aug  7 02:32:14.151: MCAST-HA: Flushing stale mcast state. RP failover processing 
complete for MVRF red.

*Aug  7 02:32:14.151: MCAST-HA: RP failover processing complete for all MVRFs.

Standby RP Bringup

The following is sample output from the debug ip multicast redundancy command. This output shows events related to the reloading of the standby RP; in particular, events related to ISSU negotiation between the active and standby RP and events related to the synchronization of dynamic multicast forwarding information from the active RP to the standby RP. Synchronization events are also logged in steady state for events that occur which affect dynamic group-to-RP mapping information or dynamic tunnel state. 

00:11:50: %HA-6-MODE: Operating RP redundancy mode is SSO 

*Aug  7 02:32:45.435: MCAST-HA-RF: Status event: 
status=RF_STATUS_OPER_REDUNDANCY_MODE_CHANGE  Op=7  RFState=ACTIVE 

*Aug  7 02:32:45.435: MCAST-HA-RF: Status event: status=RF_STATUS_REDUNDANCY_MODE_CHANGE  
Op=7  RFState=ACTIVE 

*Aug  7 02:32:45.435: MCAST-HA-RF: Status event: status=RF_STATUS_PEER_PRESENCE  Op=1  
RFState=ACTIVE 

*Aug  7 02:32:45.463: MCAST-HA-RF: Status event: status=RF_STATUS_PEER_COMM  Op=1  
RFState=ACTIVE 

*Aug  7 02:32:45.563: MCAST-HA-RF: Progression event: RF_Event=RF_PROG_ISSU_NEGOTIATION 
RFState=ACTIVE

*Aug  7 02:32:46.039: MCAST-HA-RF: Progression event: RF_Event=RF_PROG_PLATFORM_SYNC 
RFState=ACTIVE

*Aug  7 02:32:46.979: MCAST-HA: Received cf status CHKPT_STATUS_PEER_READY

*Aug  7 02:32:46.979: MCAST-ISSU Handling communication up transition for PIM HA transport 
type 0, RF comm = TRUE, renegotiation NOT PENDING

*Aug  7 02:32:46.979: MCAST-HA: Received cf status CHKPT_STATUS_IPC_FLOW_ON

*Aug  7 02:32:47.043: MCAST-HA-RF: Progression event: 
RF_Event=RF_PROG_STANDBY_ISSU_NEGOTIATION_LATE RFState=ACTIVE

*Aug  7 02:32:50.943: MCAST-HA-RF: Progression event: RF_Event=RF_PROG_STANDBY_CONFIG 
RFState=ACTIVE

*Aug  7 02:32:50.947: MCAST-ISSU Negotiation message sent from primary, rc = 0

*Aug  7 02:32:50.947: MCAST-HA-RF: Started PIM ISSU negotiation on the primary RP.

*Aug  7 02:32:50.947: MCAST-ISSU Negotiation message sent from primary, rc = 0

*Aug  7 02:32:50.947: MCAST-ISSU Negotiation message sent from primary, rc = 0

*Aug  7 02:32:50.951: MCAST-ISSU Negotiation message sent from primary, rc = 0

*Aug  7 02:32:50.951: MCAST-ISSU Negotiation message sent from primary, rc = 0

*Aug  7 02:32:50.951: MCAST-ISSU Negotiation message sent from primary, rc = 0

*Aug  7 02:32:50.951: MCAST-ISSU Negotiation message sent from primary, rc = 0

*Aug  7 02:32:50.955: MCAST-ISSU Negotiation message sent from primary, rc = 0

*Aug  7 02:32:50.955: MCAST-ISSU Negotiation message sent from primary, rc = 0

*Aug  7 02:32:50.955: MCAST-ISSU Negotiation message sent from primary, rc = 0

*Aug  7 02:32:50.955: MCAST-ISSU Negotiation message sent from primary, rc = 0

*Aug  7 02:32:50.959: MCAST-ISSU Negotiation message sent from primary, rc = 0

*Aug  7 02:32:50.959: MCAST-ISSU Negotiation message sent from primary, rc = 0

*Aug  7 02:32:50.959: MCAST-ISSU Negotiation message sent from primary, rc = 0

*Aug  7 02:32:50.959: MCAST-ISSU Negotiation message sent from primary, rc = 0

*Aug  7 02:32:50.959: MCAST-ISSU Negotiation message sent from primary, rc = 0

*Aug  7 02:32:50.963: MCAST-ISSU Negotiation message sent from primary, rc = 0

*Aug  7 02:32:50.963: MCAST-ISSU Negotiation message sent from primary, rc = 0

*Aug  7 02:32:50.963: MCAST-ISSU Negotiation message sent from primary, rc = 0

*Aug  7 02:32:50.963: MCAST-ISSU Negotiation message sent from primary, rc = 0

*Aug  7 02:32:50.967: MCAST-ISSU Negotiation message sent from primary, rc = 0

*Aug  7 02:32:50.967: MCAST-ISSU Negotiation message sent from primary, rc = 0

*Aug  7 02:32:50.967: MCAST-ISSU Negotiation message sent from primary, rc = 0

*Aug  7 02:32:50.967: MCAST-ISSU Negotiation message sent from primary, rc = 0

*Aug  7 02:32:50.967: MCAST-ISSU Negotiation message sent from primary, rc = 0

*Aug  7 02:32:50.971: MCAST-ISSU Negotiation message sent from primary, rc = 0

*Aug  7 02:32:50.971: MCAST-ISSU Negotiation message sent from primary, rc = 0

*Aug  7 02:32:50.971: MCAST-ISSU Negotiation completed for PIM Checkpoint Facility client, 
negotation rc = 4, negotiation result = COMPATIBLE

*Aug  7 02:32:59.927: MCAST-HA-RF: Progression event: RF_Event=RF_PROG_STANDBY_FILESYS 
RFState=ACTIVE

*Aug  7 02:32:59.963: MCAST-HA-RF: Progression event: RF_Event=RF_PROG_STANDBY_BULK 
RFState=ACTIVE

*Aug  7 02:32:59.963: MCAST-HA-RF: Starting Bulk Sync.

*Aug  7 02:32:59.963: MCAST-HA: Successfully created the bulk sync process

*Aug  7 02:32:59.963: MCAST-HA: Starting Bulk sync

*Aug  7 02:32:59.963: MCAST HA Executing RP mapping bulk sync.

*Aug  7 02:32:59.963: MCAST HA Executing Bidir RP route bulk sync.

*Aug  7 02:32:59.963: MCAST HA Executing BSR cache bulk sync.

*Aug  7 02:32:59.963: MCAST-HA BSR cache sync request received for mvrf IPv4 default

*Aug  7 02:32:59.963: MCAST-HA: Creating Bootstrap cache sync request chunk size=112 
max=585 align=8

*Aug  7 02:32:59.963: MCAST-HA: Allocating Bootstrap cache sync request sync request

*Aug  7 02:32:59.963: MCAST-HA Formatting BSR cache sync message:

search for mvrf IPv4 default result is 0 mvrf at 0x4A21680

*Aug  7 02:32:59.971: MCAST-HA BSR cache sync request received for mvrf blue

*Aug  7 02:32:59.971: MCAST-HA: Allocating Bootstrap cache sync request sync request

*Aug  7 02:32:59.971: MCAST-HA Formatting BSR cache sync message:

search for mvrf blue result is 0 mvrf at 0x50EE660

*Aug  7 02:32:59.983: MCAST-HA BSR cache sync request received for mvrf green

*Aug  7 02:32:59.983: MCAST-HA: Allocating Bootstrap cache sync request sync request

*Aug  7 02:32:59.983: MCAST-HA Formatting BSR cache sync message:

search for mvrf green result is 0 mvrf at 0x5103300

*Aug  7 02:32:59.991: MCAST-HA BSR cache sync request received for mvrf red

*Aug  7 02:32:59.991: MCAST-HA: Allocating Bootstrap cache sync request sync request

*Aug  7 02:32:59.991: MCAST-HA Formatting BSR cache sync message:

search for mvrf red result is 0 mvrf at 0x5135FE0

*Aug  7 02:33:00.003: MCAST HA Executing AutoRP discovery IDB bulk sync.

*Aug  7 02:33:00.003: MCAST-HA AutoRP discovery IDB sync request received for

mvrf IPv4 default

*Aug  7 02:33:00.003: MCAST-HA: Creating Autorp discovery IDB sync request chunk size=112 
max=585 align=8

*Aug  7 02:33:00.003: MCAST-HA: Allocating Autorp discovery IDB sync request sync request

*Aug  7 02:33:00.003: MCAST-HA Formatting AutoRP discovery IDB sync message:

search for mvrf IPv4 default result is 0 mvrf at 0x4A21680

*Aug  7 02:33:00.011: MCAST-HA AutoRP discovery IDB sync request received for

mvrf blue

*Aug  7 02:33:00.011: MCAST-HA: Allocating Autorp discovery IDB sync request sync request

*Aug  7 02:33:00.011: MCAST-HA Formatting AutoRP discovery IDB sync message:

search for mvrf blue result is 0 mvrf at 0x50EE660

*Aug  7 02:33:00.023: MCAST-HA AutoRP discovery IDB sync request received for

mvrf green

*Aug  7 02:33:00.023: MCAST-HA: Allocating Autorp discovery IDB sync request sync request

*Aug  7 02:33:00.023: MCAST-HA Formatting AutoRP discovery IDB sync message:

search for mvrf green result is 0 mvrf at 0x5103300

*Aug  7 02:33:00.031: MCAST-HA AutoRP discovery IDB sync request received for

mvrf red

*Aug  7 02:33:00.031: MCAST-HA: Allocating Autorp discovery IDB sync request sync request

*Aug  7 02:33:00.031: MCAST-HA Formatting AutoRP discovery IDB sync message:

search for mvrf red result is 0 mvrf at 0x5135FE0

*Aug  7 02:33:00.043: MCAST HA Executing dummy bulk sync function.

*Aug  7 02:33:00.043: MCAST HA Executing dummy bulk sync function.

*Aug  7 02:33:00.043: MCAST HA Executing dummy bulk sync function.

*Aug  7 02:33:00.043: MCAST HA Executing MDT tunnel bulk sync.

*Aug  7 02:33:00.043: MCAST-HA MDT tunnel sync request received for mvrf blue

*Aug  7 02:33:00.043: MCAST-HA: Creating MDT tunnel sync request chunk size=112 max=585 
align=8

*Aug  7 02:33:00.043: MCAST-HA: Allocating MDT tunnel sync request sync request

*Aug  7 02:33:00.043: MCAST-HA Formatting MDT tunnel sync message:

search for mvrf blue result is 0 mvrf at 0x50EE660

*Aug  7 02:33:00.051: MCAST-HA MDT tunnel sync request received for mvrf green

*Aug  7 02:33:00.051: MCAST-HA: Allocating MDT tunnel sync request sync request

*Aug  7 02:33:00.051: MCAST-HA Formatting MDT tunnel sync message:

search for mvrf green result is 0 mvrf at 0x5103300

*Aug  7 02:33:00.063: MCAST-HA MDT tunnel sync request received for mvrf red

*Aug  7 02:33:00.063: MCAST-HA: Allocating MDT tunnel sync request sync request

*Aug  7 02:33:00.063: MCAST-HA Formatting MDT tunnel sync message:

search for mvrf red result is 0 mvrf at 0x5135FE0

*Aug  7 02:33:00.071: MCAST HA Executing Bidir RP DF bulk sync.

*Aug  7 02:33:00.071: MCAST HA Executing register tunnel bulk sync.

*Aug  7 02:33:00.071: MCAST-HA: Completed enqueuing of bulk sync messages.

*Aug  7 02:33:00.071: MCAST-HA: Bulk sync message queue has drained.

*Aug  7 02:33:00.071: MCAST-HA: Received acknowledgement from standby for all bulk sync 
messages.

*Aug  7 02:33:00.071: MCAST-HA Creating bulk sync completion message for peer.

*Aug  7 02:33:00.071: MCAST-HA: Primary has notified standby of bulk sync completion. 
Waiting for final bulk sync ACK from stby.

*Aug  7 02:33:00.075: MCAST-HA: Received cf status CHKPT_STATUS_SEND_OK

*Aug  7 02:33:00.075: MCAST-HA: Sent message type is 2

*Aug  7 02:33:00.075: MCAST-HA Searching for sync request corresponding to the 
successfully received message.

*Aug  7 02:33:00.075: MCAST-HA Transmission from primary and reception by standby 
confirmed for sync type 2. Cleanup is complete.

*Aug  7 02:33:00.075: MCAST-HA: Received cf status CHKPT_STATUS_SEND_OK

*Aug  7 02:33:00.075: MCAST-HA: Sent message type is 2

*Aug  7 02:33:00.075: MCAST-HA Searching for sync request corresponding to the 
successfully received message.

*Aug  7 02:33:00.075: MCAST-HA Transmission from primary and reception by standby 
confirmed for sync type 2. Cleanup is complete.

*Aug  7 02:33:00.075: MCAST-HA: Received cf status CHKPT_STATUS_SEND_OK

*Aug  7 02:33:00.075: MCAST-HA: Sent message type is 2

*Aug  7 02:33:00.075: MCAST-HA Searching for sync request corresponding to the 
successfully received message.

*Aug  7 02:33:00.075: MCAST-HA Transmission from primary and reception by standby 
confirmed for sync type 2. Cleanup is complete.

*Aug  7 02:33:00.087: MCAST-HA: Received cf status CHKPT_STATUS_SEND_OK

*Aug  7 02:33:00.087: MCAST-HA: Sent message type is 2

*Aug  7 02:33:00.087: MCAST-HA Searching for sync request corresponding to the 
successfully received message.

*Aug  7 02:33:00.087: MCAST-HA Transmission from primary and reception by standby 
confirmed for sync type 2. Cleanup is complete.

*Aug  7 02:33:00.087: MCAST-HA: Received cf status CHKPT_STATUS_SEND_OK

*Aug  7 02:33:00.087: MCAST-HA: Sent message type is 3

*Aug  7 02:33:00.087: MCAST-HA Searching for sync request corresponding to the 
successfully received message.

*Aug  7 02:33:00.087: MCAST-HA Transmission from primary and reception by standby 
confirmed for sync type 3. Cleanup is complete.

*Aug  7 02:33:00.087: MCAST-HA: Received cf status CHKPT_STATUS_SEND_OK

*Aug  7 02:33:00.087: MCAST-HA: Sent message type is 3

*Aug  7 02:33:00.087: MCAST-HA Searching for sync request corresponding to the 
successfully received message.

*Aug  7 02:33:00.087: MCAST-HA Transmission from primary and reception by standby 
confirmed for sync type 3. Cleanup is complete.

*Aug  7 02:33:00.087: MCAST-HA: Received cf status CHKPT_STATUS_SEND_OK

*Aug  7 02:33:00.087: MCAST-HA: Sent message type is 3

*Aug  7 02:33:00.087: MCAST-HA Searching for sync request corresponding to the 
successfully received message.

*Aug  7 02:33:00.087: MCAST-HA Transmission from primary and reception by standby 
confirmed for sync type 3. Cleanup is complete.

*Aug  7 02:33:00.087: MCAST-HA: Received cf status CHKPT_STATUS_SEND_OK

*Aug  7 02:33:00.087: MCAST-HA: Sent message type is 3

*Aug  7 02:33:00.087: MCAST-HA Searching for sync request corresponding to the 
successfully received message.

*Aug  7 02:33:00.087: MCAST-HA Transmission from primary and reception by standby 
confirmed for sync type 3. Cleanup is complete.

*Aug  7 02:33:00.087: MCAST-HA: Received cf status CHKPT_STATUS_SEND_OK

*Aug  7 02:33:00.087: MCAST-HA: Sent message type is 8

*Aug  7 02:33:00.087: MCAST-HA Searching for sync request corresponding to the 
successfully received message.

*Aug  7 02:33:00.087: MCAST-HA Transmission from primary and reception by standby 
confirmed for sync type 8. Cleanup is complete.

*Aug  7 02:33:00.087: MCAST-HA: Received cf status CHKPT_STATUS_SEND_OK

*Aug  7 02:33:00.087: MCAST-HA: Sent message type is 8

*Aug  7 02:33:00.087: MCAST-HA Searching for sync request corresponding to the 
successfully received message.

*Aug  7 02:33:00.087: MCAST-HA Transmission from primary and reception by standby 
confirmed for sync type 8. Cleanup is complete.

*Aug  7 02:33:00.087: MCAST-HA: Received cf status CHKPT_STATUS_SEND_OK

*Aug  7 02:33:00.087: MCAST-HA: Sent message type is 8

*Aug  7 02:33:00.087: MCAST-HA Searching for sync request corresponding to the 
successfully received message.

*Aug  7 02:33:00.087: MCAST-HA Transmission from primary and reception by standby 
confirmed for sync type 8. Cleanup is complete.

*Aug  7 02:33:00.087: MCAST-HA: Received cf status CHKPT_STATUS_SEND_OK

*Aug  7 02:33:00.087: MCAST-HA: Sent message type is 11

*Aug  7 02:33:00.087: MCAST-HA Process: Primary RP received standby ACK for reception of 
bulk sync completion message.

*Aug  7 02:33:00.087: MCAST-HA Notifying RF to continue progression.

*Aug  7 02:33:00.087: MCAST-HA: Wakeup received for bulk sync completion.

major = 4, minor = 2.

*Aug  7 02:33:00.091: MCAST-HA Process: Primary RP received bulk sync completion 
confirmation from standby.

*Aug  7 02:33:00.091: MCAST-HA RF notification previously sent.

*Aug  7 02:33:00.455: MCAST-HA-RF: Progression event: RF_Event=RF_PROG_STANDBY_HOT 
RFState=ACTIVE

00:12:05: %HA_CONFIG_SYNC-6-BULK_CFGSYNC_SUCCEED: Bulk Sync succeeded

00:12:05: %HA-6-STANDBY_READY: Standby RP in slot 7 is operational in SSO  mode

00:12:05: %RF-5-RF_TERMINAL_STATE: Terminal state reached for (SSO)

Monitoring the Loss and Subsequent Recovery of a Standby RP: Example

The following example shows how to monitor the loss and recovery of the standby RP and confirm the IP multicast redundancy state and the status on the standby RP after its recovery.

Standby RP Loss

The following output is unconditionally logged by the Cisco IOS Redundancy Facility (RF) software when loss of the standby RP occurs. The output shows the messages used to indicate that a standby RP has gone down. 

00:14:59: %REDUNDANCY-3-STANDBY_LOST: Standby processor fault (PEER_DOWN_INTERRUPT)

00:14:59: %REDUNDANCY-5-PEER_MONITOR_EVENT: Active detected standby down or crashed 
(raw-event=PEER_DOWN_INTERRUPT(11))

The following output is from the show ip multicast redundancy state command after a standby RP goes down. In the sample output, notice that the "Current sync state" field displays "Not synching," indicating that the active and standby RP are not synchronizing data (because the standby RP is down). 

Router# show ip multicast redundancy state


Multicast Redundancy state:   SSO

Sync message epoch:           0

Sync message sequence number: 11

Stale NSF state flush timeout: 30000 ms

Current sync state: Not synching

Standby RP Recovery

The following is sample output from the debug ip multicast redundancy command. The output shows the messages used to indicate that a standby RP has recovered.

Note The number of synchronization messages sent from the new active RP to standby RP will increase as the standby RP resynchronizes. 

00:15:13: %HA-6-MODE: Operating RP redundancy mode is SSO *Aug  7 02:36:07.843: 
MCAST-HA-RF: Status event: status=RF_STATUS_OPER_REDUNDANCY_MODE_CHANGE  Op=7  
RFState=ACTIVE 

.

.

.                                         

00:15:28: %RF-5-RF_TERMINAL_STATE: Terminal state reached for (SSO)

The following is output from the show ip multicast redundancy state command after the standby RP has completed resynchronization with the new active RP. Notice that the "Current sync state" field displays "Synched," indicating that the standby has resynchronized with the new active RP. 

Router# show ip multicast redundancy state

Multicast Redundancy state:   SSO

Sync message epoch:           0

Sync message sequence number: 11

Stale NSF state flush timeout: 30000 ms

Current sync state: Synched

The following is output from the show ip multicast redundancy statistics command after the standby RP has completed resynchronization with the new active RP. 

Router# show ip multicast redundancy statistics

Multicast Redundancy Statistics

Sync Type              Updates       Syncs        Sync failures


RP mapping              0            0            0           

Bidir. RP route info    0            0            0           

Bootstrap cache         12           12           0           

Autorp discovery IDB    12           12           0           

RPDF                    0            0            0           

MDT tunnel              9            9            0           

PIM register tunnel     0            0            0           


Requests Awaiting Sync Msg Transmission: 0

Requests Awaiting Sync Msg Acknowledgement: 0

Average Sync Wait Time = 0 ms

Average Sync Ack Time = 70 ms

Configuration Examples for SSO—IPv4 Multicast HA Support for Group-to-RP Mapping

There are no configuration examples for the SSO— IPv4 Multicast HA Support for Group-to-RP Mapping feature.

Additional References

The following sections provide references related to the SSO—IPv4 Multicast HA Support for Group-to-RP Mapping feature.

Related Documents

Related Topic
Document Title

Overview of the IP multicast technology area

"IP Multicast Technology Overview" module

Concepts, tasks, and examples for configuring an IP multicast network using PIM

"Configuring a Basic IP Multicast Network" module

Concepts about PIM GenID Support

"PIM Triggered Joins" module

Multicast commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples

Cisco IOS IP Multicast Command Reference


Standards

Standard
Title

No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.

—


MIBs

MIB
MIBs Link

No new or modified MIBs are supported by this feature.

To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:

http://www.cisco.com/go/mibs


RFCs


Technical Assistance

Description
Link

The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies.

To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds.

Access to most tools on the Cisco Support website requires a Cisco.com user ID and password.

http://www.cisco.com/techsupport


Feature Information for SSO—IPv4 Multicast HA Support for Group-to-RP Mapping

Table 1 lists the release history for this feature.

Not all commands may be available in your Cisco IOS software release. For release information about a specific command, see the command reference documentation.

Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which Cisco IOS and Catalyst OS software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.

Note Table 1 lists only the Cisco IOS software release that introduced support for a given feature in a given Cisco IOS software release train. Unless noted otherwise, subsequent releases of that Cisco IOS software release train also support that feature.

Table 1 Feature Information for SSO—IPv4 Multicast HA Support for Group-to-RP Mapping 

Feature Name
Releases
Feature Information

SSO—IPv4 Multicast HA Support for Group-to-RP Mapping

12.2(33)SXI

The SSO—IPv4 Multicast HA Support for Group-to-RP Mapping feature enhances multicast HA functionality by providing support for the synchronization of dynamically learned group-to-RP mappings and bidir-PIM DF information on the standby RP. In addition, this feature also provides ISSU support for PIM.

These capabilities together enable Cisco NSF with SSO support for IPv4 multicast, which—following a switchover—reduces the reconvergence time of the multicast control plane to a level that is transparent to most multicast-based applications.

In 12.2(33)SXI, this feature was introduced on the Catalyst 6500 series switch.

The following commands were introduced or modified: clear ip multicast redundancy statistics, debug ip multicast redundancy, show ip multicast redundancy state, show ip multicast redundancy statistics, show ip pim neighbor.


CCDE, CCENT, CCSI, Cisco Eos, Cisco HealthPresence, Cisco IronPort, the Cisco logo, Cisco Nurse Connect, Cisco Pulse, Cisco SensorBase, Cisco StackPower, Cisco StadiumVision, Cisco TelePresence, Cisco Unified Computing System, Cisco WebEx, DCE, Flip Channels, Flip for Good, Flip Mino, Flipshare (Design), Flip Ultra, Flip Video, Flip Video (Design), Instant Broadband, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn, Cisco Capital, Cisco Capital (Design), Cisco:Financed (Stylized), Cisco Store, Flip Gift Card, and One Million Acts of Green are service marks; and Access Registrar, Aironet, AllTouch, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Lumin, Cisco Nexus, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, Continuum, EtherFast, EtherSwitch, Event Center, Explorer, Follow Me Browsing, GainMaker, iLYNX, IOS, iPhone, IronPort, the IronPort logo, Laser Link, LightStream, Linksys, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, PCNow, PIX, PowerKEY, PowerPanels, PowerTV, PowerTV (Design), PowerVu, Prisma, ProConnect, ROSA, SenderBase, SMARTnet, Spectrum Expert, StackWise, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.

All other trademarks mentioned in this document or website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0910R)

Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.

© 2008 Cisco Systems, Inc. All rights reserved.

Was this Document Helpful?

FeedbackFeedback

Contact Cisco