Cisco IOS XR Troubleshooting Guide for the Cisco ASR 9000 Aggregation Services Router
Troubleshooting Multicast
Downloads: This chapterpdf (PDF - 315.0KB) The complete bookPDF (PDF - 3.41MB) | Feedback

Troubleshooting Multicast Services

Table Of Contents

Troubleshooting Multicast Services

Troubleshooting IGMP Snooping (Layer 2 Multicast)

Using show Commands

Using the debug, trace, and show tech-support Commands

Troubleshooting Missing Routes and Forwarding Errors

Troubleshooting Native Multicast Routing (Layer 3)

Using show and debug Commands

Multicast PIE Installation Fails

Multicast CLI Unavailable Although PIE Is Installed

"This command not authorized" Error Message

Dynamic IGMP Failure

Traffic Fails on Some Interfaces

Traffic Fails on Some Interfaces—MGID

Throughput Loss at Receiver Interfaces

Reverse Path Forwarding IP Address Problems

Using show and debug Commands

Packets from Wrong IP Address—Loose RPF

Packets Forwarded with Wrong IP Address—Strict RPF


Troubleshooting Multicast Services


This chapter describes techniques that you can use to troubleshoot multicast services. It includes the following sections:

Troubleshooting IGMP Snooping (Layer 2 Multicast)

Troubleshooting Native Multicast Routing (Layer 3)

Troubleshooting IGMP Snooping (Layer 2 Multicast)

This section explains how to troubleshoot problems with Internet Group Management Protocol (IGMP) snooping. IGMP snooping restricts multicast flows at Layer 2 to only those segments with at least one interested receiver.

A prerequisite for implementing IGMP snooping is that the network must be configured with a Layer 2 VPN (L2VPN). IGMP snooping is supported only under L2VPN bridge domains.

This section covers the following topics:

Using show Commands

Using the debug, trace, and show tech-support Commands

Troubleshooting Missing Routes and Forwarding Errors

Using show Commands

SUMMARY STEPS

1. Confirm correct topology and configuration

a. show l2vpn bridge-domain summary

b. show igmp snooping bridge-domain

c. show l2vpn bridge-domain bd-name bd-name

d. show l2vpn bridge-domain bd-name bd-name detail

e. show igmp snooping bridge-domain bd-name detail

f. show igmp snooping port bridge-domain bd-name

g. show igmp snooping profile

2. Confirm that IGMP Snooping is sending and receiving control traffic

a. show igmp snooping summary statistics

b. show igmp snooping bridge-domain bd-name detail statistics

c. show igmp snooping port [if-type if-name] detail statistics

3. Confirm that IGMP Snooping is creating group state as expected

a. show igmp snooping group

b. show igmp snooping group port

c. show igmp snooping group source

d. show igmp snooping group bridge-domain bd-name

e. show igmp snooping port if-type if-name group [detail]

4. Confirm that the forwarding state matches the IGMP Snooping state

a. show l2vpn forwarding bridge-domain [bridge group name:bd-name] mroute ipv4 location lc-name

b. show l2vpn forwarding bridge-domain [bridge group name:bd-name] mroute ipv4 hardware [ingress | egress] location lc-name

5. View the number of packets sent, received, and failed for IGMP from and to l2snoop; determine whether packets are being dropped. Use the command show l2snoop statistics summary.

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

a. show l2vpn bridge-domain summary

b. show igmp snooping bridge-domain

c. show l2vpn bridge-domain bd-name bd-name

d. show l2vpn bridge-domain bd-name bd-name detail

e. show igmp snooping bridge-domain bd-name detail

f. show igmp snooping port bridge-domain bd-name

g. show igmp snooping profile

Confirm correct topology and configuration:

a. List all L2VPN bridge domains

b. View IGMP Snooping state in all bridge domains.

c. View information about the specified bridge domain, including the list of interfaces and VFIs.

d. View detailed information about the specified bridge domain, including the IGMP Snooping profile. Verify that the L2VPN and IGMP configurations are consistent. The profile, bridge-domain, and bridge group specified in the IGMP configuration must be consistent with that specified in the L2VPN configuration.

e. View detailed IGMP Snooping information in the specified bridge domain.

f. See IGMP Snooping view of the ports and port state in the specified bridge domain.

g. View the snooping profile information.

Step 2 

a. show igmp snooping summary statistics

b. show igmp snooping bridge-domain bd-name detail statistics

c. show igmp snooping port [if-type if-name] detail statistics

Confirm that IGMP Snooping is sending and receiving control traffic:

a. View global traffic statistics.

b. View traffic at the bridge domain level.

c. View traffic at the port level.

Step 3 

a. show igmp snooping group

b. show igmp snooping group port

c. show igmp snooping group source

d. show igmp snooping group bridge-domain bd-name

e. show igmp snooping port if-type if-name group [detail]

Confirm that IGMP Snooping is creating group state as expected:

a. View group state in all bridge domains.

b. View the groups created for a given port.

c. View the group created for a given source.

d. View group state in the specified bridge domain.

e. View group state on the specified interface.

Step 4 

a. show l2vpn forwarding bridge-domain [bridge group name:bd-name] mroute ipv4 location lc-name

b. show l2vpn forwarding bridge-domain [bridge group name:bd-name] mroute ipv4 hardware [ingress | egress] location lc-name

Confirm that the forwarding state matches the IGMP Snooping state:

a. View forwarding state in the L2FIB on the specified line card.

b. View forwarding state installed in the hardware on the specified line card.

Step 5 

a. show l2snoop statistics summary

View the number of packets sent, received, and failed for IGMP from and to l2snoop; determine whether packets are being dropped.

Using the debug, trace, and show tech-support Commands

The following commands are useful for debugging IGMP snooping.


Note These commands might cause a large amount of information to be displayed on your output terminal.


This command gathers information about the IGMP control packets in the system, for example, whether JOIN and QUERY packets are being received and transmitted.

debug igmp snooping {all | error | event | init | management | packet | packet-error | proto | topo}

all—All debugging

error—Error debugging

event—Event debugging

init—Init debugging

management—Management debugging

packet—Packet debugging

packet-error—Packet error debugging

proto—Proto debugging

topo—Topology debugging

If IGMP control packets are not being received and transmitted as expected, use this command to help locate the cause of the problem.

debug l2snoop {call | error | events | init | packet}

call—L2snoop function call related debugging

error—L2snoop error debugging

events—L2snoop events debugging

init—L2snoop init debugging

packet—Decode L2snoop packet sends and receives

The following commands provide additional information for advanced troubleshooting.

show igmp snooping trace

all—Show IGMP snoop trace all

error—Show IGMP snooping trace error

file—Specific file

hexdump—Display traces in hexadecimal

last—Display last <n> entries

location—Card location

packet-error—Show IGMP snooping trace packet error

reverse—Display latest traces first

stats—Display statistics

tailf—Display new traces as they are added

unique—Unique entries with counts

verbose—Display internal debugging information

wrapping—Wrapping entries

show tech-support igmp snooping {file | terminal}

file—Specify a valid file name (for example, disk0:tmp.log)

terminal—Send output to terminal

Troubleshooting Missing Routes and Forwarding Errors

This section explains what to do if packets are not being directed to the expected routes or are not being received by the RSP card.


Step 1 Check the L2VPN configuration to verify that the IGMP snooping profile is configured on the bridge domain and optionally on one or more bridge ports. The snooping profile must be present in the bridge domain for IGMP snooping to be enabled.

RP/0/RSP0/CPU0:router# show run l2vpn
 
   

Step 2 Verify that IGMP snooping is enabled, that is, attached to the bridge-domain and optionally to one or more bridge ports.

RP/0/RSP0/CPU0:router# show l2vpn bridge-domain detail
 
   

Step 3 Verify that Layer 2 multicast routes (mroutes) are present in the bridge-domain.

RP/0/RSP0/CPU0:router# show l2vpn forwarding bridge-domain [bridge-domain-id] mroute ipv4 
summary location node-id 
 
   

Step 4 Verify the status of flood forwarding. Confirm that the forwarding state matches the snooping state.

RP/0/RSP0/CPU0:router# show l2vpn forwarding bridge-domain [bridge-domain-id] detail 
location node-id
 
   

Step 5 Verify that the querier is enabled in the snooped domain. Without a querier, the system drops all IGMP reports with reason No Querier.

RP/0/RSP0/CPU0:router# show igmp snooping summary statistics  
include-zeroes | include Reports No
Thu Jan  6 12:03:10.715 MEZ
      Reports No Querier:                               0
      V3 Reports No Querier:                            0
      V3 Reports No Sources:                            0
 
   

Tip Use variations of this command (for example, omitting the include modifier) to show other types of errors, such as time to live errors (TTL not 1), which are useful in troubleshooting.


Step 6 Verify that the bridge domain, number of mrouters, ports, and IP addresses are as expected. Run the snooping statistics several times to notice any trends and the corresponding locations.

RP/0/RSP0/CPU0:router# show igmp snooping bridge-domain [bridge-domain-id] detail 
statistics
 
   

Step 7 Verify that packets are being received and transmitted as expected, and that there are no failed packets. Clear the counters and rerun them several times to notice any trends and the corresponding locations.

RP/0/RSP0/CPU0:router# show l2snoop statistics pcb all location active-RSP-location
 
   

The output of this command is an aggregate of all Layer 2 snoop counters, therefore, further investigation is needed to determine if any observed failures are related to IGMP snooping. (In this command, PCB = protocol control block.)

Step 8 Check whether the IGMP_SNOOP packet counters are incrementing on the network processors (NPs). If so, this indicates that the packets are being punted. Clear the counters and rerun them several times to notice any trends and the corresponding locations.

RP/0/RSP0/CPU0:router# show controller np counters <np number or all> location <LC 
location where punts are expected>
 
   

Examples

1. This example shows that the IGMP snooping profile is configured in the bridge domain.

RP/0/RSP0/CPU0:router# show run l2vpn
Tue Jan  4 09:59:49.849 PST
l2vpn
 router-id 10.144.144.144
 pw-class CW_enable
  encapsulation mpls
   control-word
  !
 !
xconnect group g1
  p2p p1
   neighbor 10.1.1.1 pw-id 100
    pw-class c1
   !
  !
 !
bridge group 215
  bridge-domain 215
   mtu 9000
   igmp snooping profile default
   interface GigabitEthernet0/1/0/3.215
    storm-control multicast pps 500
    storm-control broadcast pps 4500
   !
   interface GigabitEthernet0/1/0/7.215
   !
   interface GigabitEthernet0/1/0/30.215
   !      
   vfi 215
    neighbor 10.19.19.19 pw-id 215
    !
   !
  !
 !
.
.
.
 
   

2. This example shows that IGMP snooping profile is present in the bridge domain, therefore IGMP snooping is enabled.

RP/0/RSP0/CPU0:router# show l2vpn bridge-domain detail
.
.
.
Bridge group: 215, bridge-domain: 215, id: 4, state: up, ShgId: 0, MSTi: 0
  MAC learning: enabled
  MAC withdraw: enabled
    MAC withdraw for Access PW: enabled
  Flooding:
    Broadcast & Multicast: enabled
    Unknown unicast: enabled
  MAC aging time: 300 s, Type: inactivity
  MAC limit: 4000, Action: none, Notification: syslog
  MAC limit reached: no
  MAC port down flush: enabled
  MAC Secure: disabled, Logging: disabled
  Split Horizon Group: none
  Dynamic ARP Inspection: disabled, Logging: disabled
  IP Source Guard: disabled, Logging: disabled
  DHCPv4 snooping: disabled
  IGMP Snooping profile: default
  Bridge MTU: 9000
  MIB cvplsConfigIndex: 5
  Filter MAC addresses:
  Create time: 24/11/2010 15:47:48 (5w5d ago)
  No status change since creation
  ACs: 3 (3 up), VFIs: 1, PWs: 1 (1 up), PBBs: 0 (0 up)
  List of ACs:
.
.
.
 
   

3. This example shows that Layer 2 multicast routes (mroutes) are present in the bridge-domain.

RP/0/RSP0/CPU0: router# show l2vpn forwarding bridge-domain 215:215 mroute ipv4 summary 
location 0/1/CPU0 
Tue Jan  4 10:20:57.264 PST
Global Mroute Stats:
-----------------------------------------------------------------------------------
     Message                         Count   Info1        Info2     Time               
     =======                         =====   =====        =====     ====               
     mcast route count               7       0x4          0x0       Jun 28 01:48:14.324
     mcast route update dropped      0       0x0          0x0       -                  
     mcast route delete dropped      0       0x0          0x0       -                  
     mcast route del all drop        0       0x0          0x0       -                  
     mcast route add                 27      0x4          0x0       Jun 28 01:48:14.324
     mcast route delete              20      0x4          0x0       Jan  9 14:49:08.761
     mcast route delete all          0       0x0          0x0       -                  
     mcast xid add                   124     0x4          0x0       Jun 28 01:48:14.324
     mcast xid delete                15      0x4          0x0       Jan 17 10:41:06.123
     mcast stale xid delete          0       0x0          0x0       -                  
     mcast stale delete              0       0x0          0x0       -                  
     mcast bulk messages             48      0x0          0x0       Jun 28 01:48:14.324
 
   
Per Bridge Mroute Stats:
 Bridge-domain: 215:215 ,id: 4 
 L2 Multicast Route entries: 7
  mroute add: 27, delete: 20
  xid add: 124, delete: 15
  mroute delete all: 0
  mroute update dropped: 0
  mroute delete dropped: 0
  mroute delete all dropped: 0
 Deleted stale mroute entries: 0
 Deleted stale xid entries: 0
 
   

4. This example shows that IGMP snooping is enabled and flooding is disabled.

RP/0/RSP0/CPU0:router# show l2vpn forwarding bridge-domain 215:215 detail location 
0/1/CPU0 
Mon Jan  3 14:49:50.332 PST
 
   
Bridge-domain name: 215:215, id: 4, state: up
 MAC learning: enabled
 MAC port down flush: enabled
 Flooding:
   Broadcast & Multicast: enabled
   Unknown unicast: enabled
 MAC aging time: 300 s, Type: inactivity
 MAC limit: 4000, Action: none, Notification: syslog
 MAC limit reached: no
 MAC Secure: disabled, Logging: disabled
 DHCPv4 snooping: profile not known on this node
 Dynamic ARP Inspection: disabled, Logging: disabled
 IP Source Guard: disabled, Logging: disabled
 IGMP snooping: enabled, flooding: disabled
 Bridge MTU: 9000 bytes
 Number of bridge ports: 4
 Number of MAC addresses: 0
 Multi-spanning tree instance: 0
.
.
.

5. This example shows the bridge domain, number of mrouters, ports, and IP addresses.

RP/0/RSP0/CPU0:router# show igmp snooping bridge-domain 215:215 detail statistics
Mon Jan  3 10:56:17.534 PST
 
   
Bridge Domain        Profile              Act  Ver  #Ports  #Mrtrs  #Grps   #SGs
-------------        -------              ---  ---  ------  ------  -----   ----
215:215              default                Y   v2       4       3      6      0
 
   
  Profile Configured Attributes:
    System IP Address:                   10.144.144.144
    Minimum Version:                     2
    Report Suppression:                  Enabled
    Unsolicited Report Interval:         1000 (milliseconds)
    TCN Query Solicit:                   Enabled
    TCN Membership Sync:                 Disabled
    TCN Flood:                           Enabled
    TCN Flood Query Count:               2
    Router Alert Check:                  Disabled
    TTL Check:                           Disabled
    Internal Querier Support:            Enabled
    Internal Querier Version:            3
    Internal Querier Timeout:            0 (seconds)
    Internal Querier Interval:           60 (seconds)
    Internal Querier Max Response Time:  10.0 (seconds)
    Internal Querier Robustness:         2
    Internal Querier TCN Query Interval: 10 (seconds)
    Internal Querier TCN Query Count:    2
    Internal Querier TCN Query MRT:      0 (seconds)
    Querier Query Interval:              60 (seconds)
    Querier LMQ Interval:                1000 (milliseconds)
    Querier LMQ Count:                   2
    Querier Robustness:                  2
    Startup Query Interval:              15 seconds
    Startup Query Count:                 2
    Startup Query Max Response Time:     10.0 seconds
    Mrouter Forwarding:                  Enabled
  Querier:
    IP Address:                          10.161.161.161
    Port:                                Neighbor 10.19.19.19 pw-id 215
    Version:                             v2
    Query Interval:                      60 seconds
    Robustness:                          2
    Max Resp Time:                       10.0 seconds
    Time since last G-Query:             30 seconds
  Internal Querier Statistics (elapsed time since last cleared 5w4d):
    Rx General Queries:                     142074
    Rx General Queries When Disabled:       142072
    Rx General Queries As Querier:               1
    Rx General Queries As Non Querier:           0
    Rx General Queries As Winner:                0
    Rx General Queries As Loser:                 0
    Rx Global Leaves:                         1590
    Rx Global Leaves When Disabled:           1590
    Rx Global Leaves As Non Querier:             0
    Rx Global Leaves Ignored:                    0
    Rx Pim Enabled Notifications:                0
    Rx Pim Disabled Notifications:               0
    Rx Local Query Solicitations:                0
    Tx General Queries:                          0
  Mrouter Ports:                         3
    Dynamic:                             Neighbor 10.19.19.19 pw-id 215
    Dynamic:                             GigabitEthernet0/1/0/30.215
    Dynamic:                             GigabitEthernet0/1/0/7.215
  STP Forwarding Ports:                  0
  ICCP Group Ports:                      0
  Groups:                                6
    Member Ports:                        6
  V3 Source Groups:                      0
    Static/Include/Exclude:              0/0/0
    Member Ports (Include/Exclude):      0/0
  Traffic Statistics (elapsed time since last cleared 5w4d):
                                     Received  Reinjected   Generated
    Messages:                          827226      411703        1599
      IGMP General Queries:            142074      124872           4
      IGMP Group Specific Queries:         12           0           0
      IGMP G&S Specific Queries:            0           0           0
      IGMP V2 Reports:                 452290      286719           0
      IGMP V3 Reports:                      0           0           3
      IGMP V2 Leaves:                     159         112           4
      IGMP Global Leaves:                   2           -        1588
      PIM Hellos:                      232689           0           -
    Rx Packet Treatment:
      Packets Flooded:                             124874
      Packets Forwarded To Members:                     0
      Packets Forwarded To Mrouters:               286841
      Packets Consumed:                            398308
      Reports Suppressed:                          165570
    Rx Errors:
      Packets Missing Router Alert:                452268
      Leaves Non-Member:                              109
    Rx Other:
      None
    Tx Errors:
      No Querier in BD:                                 5
  Startup Query Sync Statistics:
    None
 
   

6. This example shows that packets are being received and transmitted, and that there are no failed packets.

RP/0/RSP0/CPU0:router# show l2snoop statistics pcb all location 0/RSP0/CPU0
Tue Jan  4 10:48:17.423 PST
 
   
 Statistics for PCB 0x50026960 
Send:   0 packets received from application
        0 xipc pulse received from application
        0 packets sent to network (NetIO)
        0 packets failed getting queued to network (NetIO)
Rcvd:   238504 packets received from network
        238504 packets queued to application
        0 packets failed queued to application
 
   
 Statistics for PCB 0x50024fe0 
Send:   424768 packets received from application
        423062 xipc pulse received from application
        424768 packets sent to network (NetIO)
        0 packets failed getting queued to network (NetIO)
Rcvd:   611715 packets received from network
        611715 packets queued to application
        0 packets failed queued to application
 
   

7. This example shows the IGMP_SNOOP control packet counters on the network processors (NPs).

RP/0/RSP0/CPU0:router# show controllers np counters np2 location 0/1/CPU0
Mon Jan  3 12:10:40.215 PST
 
   
                Node: 0/1/CPU0:
----------------------------------------------------------------
 
   
Show global stats counters for NP2, revision v3
 
   
Read 56 non-zero NP counters:
Offset  Counter                                         FrameValue   Rate (pps)
-------------------------------------------------------------------------------
  22  PARSE_ENET_RECEIVE_CNT                             163222344          43
  23  PARSE_FABRIC_RECEIVE_CNT                            77489373          22
  24  PARSE_LOOPBACK_RECEIVE_CNT                            114662           0
  29  MODIFY_FABRIC_TRANSMIT_CNT                          75222687          22
  30  MODIFY_ENET_TRANSMIT_CNT                           146294912          42
  31  PARSE_INGRESS_DROP_CNT                              17654881           1
  33  RESOLVE_INGRESS_DROP_CNT                                  44           0
  34  RESOLVE_EGRESS_DROP_CNT                               407520           0
 112  DIAGS                                                  56853           0
 134  IGMP_SNOOP                                                 3           0 <<< snoop
 148  IPV4MC_DO_ALL                                           5860           0
 149  IPV4MC_DO_ALL_EXCD                                     13590           0
 170  PUNT_IFIB                                           69828282          20
 172  PUNT_ADJ                                                   2           0
 224  PUNT_STATISTICS                                      5667050           2
 225  PUNT_STATISTICS_EXCD                                       1           0
 226  PUNT_DIAGS_RSP_ACT                                     57337           0
 230  NETIO_RP_TO_LC_CPU_PUNT                                 1011           0
 313  BFD_NOT_ENABLED                                           24           0
.
.
.
 
   

Troubleshooting Native Multicast Routing (Layer 3)

This section explains how to troubleshoot native multicast. Native multicast routing (also called IP multicast) is a bandwidth-conserving technology that reduces traffic by simultaneously delivering a single stream of information to thousands of corporate recipients and homes.

This section contains the following subsections:

Using show and debug Commands

Multicast PIE Installation Fails

Multicast CLI Unavailable Although PIE Is Installed

"This command not authorized" Error Message

Dynamic IGMP Failure

Traffic Fails on Some Interfaces

Traffic Fails on Some Interfaces—MGID

Throughput Loss at Receiver Interfaces

Reverse Path Forwarding IP Address Problems

Using show and debug Commands

This section explains how to use the show and debug commands.

Figure 11-1 illustrates the flow of information in the native multicast process, along with some of the important show commands.

On the RSP card, the IGMP and PIM send control packet information, including joins, queries, reports, leaves and join-prune, to the MRIB. The MRIB populates the global routing tables and allocates multicast group IDs (MGIDs).

On the LC, the MFIB receives routing information from the MRIB and programs the necessary tables and structures in the hardware (network processors or NP) and sets up the multicast routes and groups.

Figure 11-1 Native Multicast Process and Corresponding CLI Commands

SUMMARY STEPS

1. show igmp {global-interface | groups | | interface | nsf | old-output | snooping | ssm | summary | traffic | vrf name}

2. show pim [vrf vrf-name] {bgp-safi | bsr | context | df | global | group-map | interface | ipv4 | ipv6 | join-prune | ma | mdt | mstatic | multicast | neighbor | nsf | old-output | range-list | rpf | safi-all | summary | table-context | topology | traffic | tunnel | unicast}

3. show mrib [vrf vrf-name] {client | ipv4 | ipv6 | label-table-info | mdt-interface | mpls | nsf | old-output | platform | route | route-collapse | table-info |tlc }

4. show mfib [vrf vrf-name] {bundle-hash | connections | counter | encap-info | hardware | interface | ipv4 | ipv6 | lsm | mdt | nsf | route | svd | table-info}

5. show mfib hardware {adjacency | connection | interface | ltrace | resource-counters | route | table} location node-id

6. show mfib hardware route { accept-bitmap | internal | mofrr | olist | statistics | summary } {* | A.B.C.D | A.B.C.D/length | detail | hex-dump} location node-id

7. show mfib hardware route summary location node-id

8. debug mrib errors

9. debug mrib events

10. debug mfib warning

11. debug mfib errors

12. debug mlib errors

13. debug mlib warning

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

show igmp {global-interface | groups | interface | nsf | old-output | ranges | snooping | ssm | summary | traffic | vrf name}

Example:

RP/0/RSP0/CPU0:router# show igmp groups

View all Internet Group Management Protocol (IGMP)-related information in the control plane. IGMP is a protocol used by IPv4 systems to report IP multicast memberships to neighboring multicast routers.

Filter results using the following parameters and keywords:

global-interface—IGMP global Interface Descriptor Block (IDB) data structures, IDBs have information like IP addresses, interface states, and packet statistics. There is one IDB for each interface and one for each subinterface.

groups—IGMP group memberships.

interface—IGMP interface information.

nsf—Current multicast NSF state for IGMP, either normal or activated for NSF. The latter state indicates that recovery is in progress due to an IGMP failure. The total NSF timeout and time remaining are displayed until NSF expiration.

old-output—Provides backward compatibility.

ranges—IGMP group-map ranges

snooping—IGMP snooping parameters.

ssm—Source Specific Multicast (SSM)-related information.

summary—IGMP summary.

traffic—IGMP traffic counters.

vrf name—Specify a Virtual Private Network (VPN) routing and forwarding (VRF).

Step 2 

show pim [vrf vrf-name]{bgp-safi | bsr | context | df | global | group-map | interface | ipv4 | ipv6 | join-prune | ma | mdt | mstatic | multicast | neighbor | nsf | old-output | range-list | rpf | safi-all | summary | table-context | topology | traffic | tunnel | unicast}

Example:

RP/0/RSP0/CPU0:router# show pim neighbor

View Protocol Independent Multicast (PIM)-related information in the control plane. Filter results using the following parameters and keywords:

bgp-safi—Border Gateway Protocol (BGP) secondary address family (SAFI) database.

bsr—PIM Bootstrap Router (BSR) information.

context—PIM VRF Contexts.

df—Bidirectional Designated Forwarder (DF).

global—PIM global summary

group-map—PIM group-to-protocol mapping information.

interface—PIM interface information.

ipv4—IPv4 Address Family.

ipv6—IPv6 Address Family.

join-prune—PIM Join/Prune information.

ma—PIM Management Agent information

mdt—Data MDT information.

mstatic— Multicast Static Route information.

multicast—SAFI Multicast.

neighbor—PIM neighbor information.

nsf—Non-stop forwarding.

old-output—Provides backward compatibility.

range-list—PIM range-list information.

rpf—RPF information.

safi-all—SAFI wildcard.

summary—PIM summary information.

table-context—PIM Table context.

topology—PIM topology table information.

traffic—PIM traffic counters.

tunnel—Tunnel interfaces.

unicast—SAFI Unicast.

vrf—VRF. If you include vrf, you must include it immediately after show pim, and also specify a vrf-name.

Step 3 

show mrib [vrf vrf-name] {client | ipv4 | ipv6 | label-table-info | mdt-interface | mpls | nsf | old-output | platform | route | route-collapse | table-info |tlc}

Example:

RP/0/RSP0/CPU0:router# show mrib client

View Multicast Routing Information Base (MRIB) information. Filter results using the following parameters and keywords:

client—MRIB client connections.

ipv4—IPv4 address family

ipv6—IPv6 address family

label-table-info—MRIB label table information

mdt-interface—MDT interface handle DB

mpls—MRIB MPLS related information

nsf—Non-stop forwarding

old-output—Display the old show output

platform—Platform-specific data

route—Routing database.

route-collapse—MRIB route collapse database

table-info—MRIB VRF table information.

tlc—MRIB table-linecard database

vrf—VRF. If you include vrf, you must include it immediately after show mrib, and also specify a vrf-name.

Step 4 

show mfib [vrf vrf-name] {bundle-hash | connections | counter | encap-info | hardware | interface | ipv4 | ipv6 | lsm | mdt | nsf | route | svd | table-info}

Example:

RP/0/RSP0/CPU0:router# show mfib nsf

View Multicast Forwarding Information Base (MFIB) information in the control plane. Filter results using the following parameters and keywords:

bundle-hash—Bundle hash for given Interface,S,G tuple

connections—Status of MFIB connections to servers.

counter—MFIB global counters.

encap-info—Multicast Virtual Private Network (MVPN) Encap information.

hardware—Cisco ASR 9000 Series Router hardware.

interface—MFIB interface specific information.

ipv4—IPv4 Address Family.

ipv6—IPv6 Address Family.

lsm—Label Switched Multicast.

mdt—MDT tunnel information.

nsf—Multicast NSF status.

route—Routing database.

svd—Singular Value Decomposition (SVD) events.

table-info—Table information.

vrf—VRF. If you include vrf, you must include it immediately after show mfib, and also specify a vrf-name or all.

Step 5 

show mfib hardware {interface | ltrace | resource-counters | route} location node-id

Example:

RP/0/RSP0/CPU0:router# show mfib hardware route olist location 0/4/CPU0

View all hardware data in the Multicast PD. Filter results using the following parameters and keywords:

interface—Cisco ASR 9000 Series Router hardware.

ltrace—IP Multicast platform specific trace information.

resource-counters—Allocated and freed hardware resources.

route—Platform-specific information for the routing database.

location—Specify the MFIB location.

Note The output of these commands can be large when there are a large number of routes and output interface lists (olists) configured.

Step 6 

show mfib hardware route {accept-bitmap | internal | mofrr | olist | statistics | summary} {* | A.B.C.D | A.B.C.D/length | detail | hex-dump} location node-id

Example:

RP/0/RSP0/CPU0:router# show mfib hardware route olist location 0/4/CPU0

View all hardware ROUTE data in the multicast PD. Filter results using the following parameters and keywords:

accept-bitmap—Accepting interface list for bidir routes.

internal—Display route internal structures

mofrr—Display per-route MoFRR information

olist—Output interface list (olist) stored in the hardware.

statistics—Per route packets and bytes counters.

summary—Summary of routes.

*—Shared tree entries.

A.B.C.D—Source/group IP address.

A.B.C.D/length—Group IP address/prefix length.

detail—Details of each route (requires 140 columns).

hex-dump—Hex dump of the PLU and TLU.

location—Specify the MFIB location.

Note The output of these commands can be large when there are a large number of routes and olists configured.

Step 7 

show mfib hardware route summary location node-id

Example:

RP/0/RSP0/CPU0:router# show mfib hardware route summary location 0/4/CPU0

View all hardware ROUTE data in the multicast PD. Filter results using the following parameters and keywords:

summary—Summary of routes.

location—MFIB location.

Step 8 

debug mrib errors

Example:

RP/0/RSP0/CPU0:router# debug mrib errors

To monitor Multicast Routing Information Base (MRIB) internal errors, use the debug mrib errors command in EXEC mode. To disable debugging output, use the no form of this command.

Step 9 

debug mrib events

Use these debug commands to obtain additional information.

Step 10 

debug mfib warning

Step 11 

debug mfib errors

Step 12 

debug mlib errors

Step 13 

debug mlib warning

Multicast PIE Installation Fails


Step 1 View detailed information for the specified install id.

RP/0/RSP0/CPU0:router# show install log [1-4294967295] detail

Step 2 Ensure that the PIE file name is correct and reissue the command.

Step 3 Ensure that the location of the PIE file is correct and reissue the command

Step 4 Ensure that the PIE file has proper permissions (755) and reissue the command.

Step 5 If you are loading from the TFTP directory, ensure that the following are true:

a. Router has network connectivity.

b. TFTP address is properly configured.

c. TFTP server has connectivity.

RP/0/RSP0/CPU0:router# ping tftp-server-addr

d. If loading locally from a router, ensure that the PIE file is stored on the router.

Step 6 Verify all nodes are in the "IOS XR RUN State"

RP/0/RSP0/CPU0:router# show platform


Multicast CLI Unavailable Although PIE Is Installed

show install active—View active package information

Ensure that the following are correct:

PIE file name.

PIE file location.

PIE file installation on ALL nodes.

"This command not authorized" Error Message

While issuing certain commands in config or EXEC mode, the "This command not authorized" error message appears, disabling further access. This means the user does not have the appropriate privileges. Check to see that you have "Cisco-Support" and `root" privileges to use the desired command.

show config run—(from admin mode) View current operating admin configuration of the system.

Dynamic IGMP Failure

A dynamic IGMP failure occurs when the dynamic source and group states (*,G) are timing out. There are two scenarios that suggest you need to troubleshoot this problem:

IGMP join messages sent from a host does not resul in creation of a new route or addition of an OLIST member; similarly, IGMP leave messages sent from a host do not result in deletion of an existing route or removal of an existing OLIST member.

The groups and routes are configured and set up correctly, but when traffic is sent to the Cisco ASR 9000 Aggregation Series Router from the tester, it is not received at the Rx tester port.


Step 1 Verify that IGMP packets are being received by the IGMP process on the RSP.

RP/0/RSP0/CPU0:router# show ipv4 traffic 
Thu Jan  6 10:28:24.622 PST
 
   
IP statistics:
  Rcvd:  294930104 total, 3052259 local destination
         0 format errors, 0 bad hop count
         593296 unknown protocol, 0 not a gateway
         0 security failures, 0 bad source, 369473 bad header
         1453418 with options, 0 bad, 0 unknown
  Opts:  0 end, 0 nop, 0 basic security, 0 extended security
         0 strict source rt, 0 loose source rt, 0 record rt
         0 stream ID, 0 timestamp, 1453418 alert, 0 cipso
  Frags: 0 reassembled, 0 timeouts, 0 couldn't reassemble, 0 fragments received
         0 fragmented, 0 fragment count, 0 fragment max drop
  Bcast: 0 sent, 0 received
  Mcast: 9878922 sent, 291744628 received
   Drop: 0 encapsulation failed, 3 no route, 0 too big
   Sent: 13116263 total
.
.
.
 
   
RP/0/RSP0/CPU0:router# show igmp traffic 
Thu Jan  6 10:30:27.821 PST
 
   
IGMP Traffic Counters
Elapsed time since counters cleared: 6w0d
 
   
                                  Received        Sent
Valid IGMP Packets                  491447      777437
Queries                             368364      246191
Reports                             123083      531246
Leaves                                   0           0
Mtrace packets                           0           0
DVMRP packets                            0           0
PIM packets                              0           0
 
   
Errors:
Malformed Packets                                    0
Bad Checksums                                        0
Socket Errors                                        0
Bad Scope Errors                                     0
Auxiliary Data Len Errors                                0
Packets dropped due to invalid socket                0
Packets which couldn't be accessed                   0
Packet allocation failure                            0
Other packets drops                                  0
 
   

Step 2 Verify that IGMP has the specified group/source on the interface.

RP/0/RSP0/CPU0:router# show igmp interface gigabitEthernet 0/1/0/2 
Thu Jan  6 10:34:30.664 PST
 
   
GigabitEthernet0/1/0/2 is up, line protocol is up
  Internet address is 10.147.4.44/24
  IGMP is enabled on interface
  Current IGMP version is 3
  IGMP query interval is 60 seconds
  IGMP querier timeout is 125 seconds
  IGMP max query response time is 10 seconds
  Last member query response interval is 1 seconds
  IGMP activity: 6 joins, 0 leaves
  IGMP querying router is 10.147.4.44 (this system)
 
   

Step 3 Verify that the multicast routing information base (MRIB) has the expected route and outgoing interface list (OLIST).

RP/0/RSP0/CPU0:router# show mrib route 
Thu Jan  6 10:38:42.800 PST
 
   
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,
    IF - Inherit From, D - Drop, MA - MDT Address, ME - MDT Encap,
    MD - MDT Decap, MT - MDT Threshold Crossed, MH - MDT interface handle
    CD - Conditional Decap, MPLS - MPLS Decap, MF - MPLS Encap, EX - Extranet
    MoFE - MoFRR Enabled, MoFS - MoFRR State
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, DI - Decapsulation Interface
    EI - Encapsulation Interface, MI - MDT Interface, LVIF - MPLS Encap,
    EX - Extranet, A2 - Secondary Accept
 
   
(*,10.66.66.66) RPF nbr: 10.114.8.11 Flags: C
  Up: 6w0d
  Incoming Interface List
    TenGigE0/4/0/0 Flags: A, Up: 6w0d
  Outgoing Interface List
    GigabitEthernet0/1/0/8 Flags: F NS, Up: 6w0d
 
   
(10.191.4.1,232.166.166.166) RPF nbr: 10.114.8.11 Flags: MoFE MoFS
  Up: 3w5d
  MOFRR State: Active Sequence No 2856
  Incoming Interface List
    TenGigE0/4/0/0 Flags: A, Up: 3w5d
    GigabitEthernet0/1/0/23 Flags: A2, Up: 3w5d
  Outgoing Interface List
    GigabitEthernet0/1/0/8 Flags: F NS, Up: 3w5d
 
   
(*,10.60.0.0/16) RPF nbr: 10.144.144.144 Flags: IF
  Up: 6w0d
  Incoming Interface List
    Loopback0 Flags: F A, Up: 6w0d
    TenGigE0/4/0/0 Flags: A, Up: 6w0d
    GigabitEthernet0/1/0/18 Flags: A, Up: 3w5d
    GigabitEthernet0/1/0/23 Flags: A, Up: 6w0d
    GigabitEthernet0/1/0/27 Flags: A, Up: 2w5d
  Outgoing Interface List
    Loopback0 Flags: F A, Up: 6w0d
 
   

Step 4 Verify that the multicast forwarding information base (MFIB) on the LC has the interface as an OLIST member.

RP/0/RSP0/CPU0:router# show mfib route location 0/1/CPU0 
Thu Jan  6 10:47:06.989 PST
 
   
IP Multicast Forwarding Information Base
Entry flags: C - Directly-Connected Check, S - Signal, D - Drop,
  IA - Inherit Accept, IF - Inherit From, MA - MDT Address,
  ME - MDT Encap, MD - MDT Decap, MT - MDT Threshold Crossed,
  MH - MDT interface handle, CD - Conditional Decap,
  DT - MDT Decap True, EX - Extranet
  MoFE - MoFRR Enabled, MoFS - MoFRR State
Interface flags: F - Forward, A - Accept, IC - Internal Copy,
  NS - Negate Signal, DP - Don't Preserve, SP - Signal Present,
  EG - Egress, EI - Encapsulation Interface, MI - MDT Interface,
  EX - Extranet, A2 - Secondary Accept
Forwarding/Replication Counts: Packets in/Packets out/Bytes out
Failure Counts: RPF / TTL / Empty Olist / Encap RL / Other
 
   
(*,10.0.0.0/4),   Flags:  C 
  Up: 6w0d
  Last Used: never
  SW Forwarding Counts: 0/0/0
  SW Replication Counts: 0/0/0
  SW Failure Counts: 0/0/0/0/0
 
   
(*,10.66.66.66),   Flags:  C 
  Up: 6w0d
  Last Used: never
  SW Forwarding Counts: 0/0/0
  SW Replication Counts: 0/0/0
  SW Failure Counts: 0/0/0/0/0
  TenGigE0/4/0/0 Flags:  A, Up:6w0d
  GigabitEthernet0/1/0/8 Flags:  NS EG, Up:6w0d
 
   

Step 5 Verify that the MFIB in the hardware has the interface as an OLIST member.

RP/0/RSP0/CPU0:router# show mfib hardware interface gigabitEthernet 0/1/0/27 location 
0/1/CPU0 
Thu Jan  6 10:55:27.723 PST
LC Type: A9K-40GE-L
--------------------------------------------------------------------
Interface       Handle     RefCnt TTL Routes uIDB  Enbld Comment
--------------------------------------------------------------------
Gi0/1/0/27      0x2000740  8      0   3      55    True   success
--------------------------------------------------------------------
ROUTE INFORMATION:
Legend:
 S: Source, G: Group, P: Prefix length, PI: Packets cn, PO: packets out,
 RF: RPF failures, TF: TTL failures, OF: OLIST failures, F: Other failures
Route flags - (Ingress)
 C: Chip ID, IC: BACL check, IP: Punt this packet to LC CPU,
 ID: Directly connected, IS: RPF interface signal, IU: Punt copy to RP,
 IF: Punt to LC CPU if forwarded, IM: Result match, IV: Valid entry,
 IR: RPF IF, IA: Fabric slotmask, IG: Mulicast group ID
Route flags - (Egress)
 ET: Table ID to be used for OLIST lookup, EO: OLIST count bit,
 ER: Route MGID to be used for OLIST/NRPF lookup, EM: Result match,
 EV: Valid entry, EC: Count of OLIST members on this chip,
 BS: Base of the statistics pointer
 
   
Interface: Gi0/1/0/27
 
   
  S:0.0.0.0 G:10.60.0.0 P:16 PI:1784 PO:0 RF:670 TF:0 OF:0 F:0
  ---------------------------------------------------------------------------------
  C  IC IP ID IS IU IF IM IV IR         IA     IG     ET EO ER   EM EV EC   BS      
  ---------------------------------------------------------------------------------
  0  T  F  F  F  F  F  T  T  0x2000740  0x0    0x4208 0  F  4    T  T  0    0x36c6c 
  1  T  F  F  F  F  F  T  T  0x2000740  0x0    0x4208 0  F  4    T  T  0    0x36b04 
  2  T  F  F  F  F  F  T  T  0x2000740  0x0    0x4208 0  F  4    T  T  0    0x36b1c 
  3  T  F  F  F  F  F  T  T  0x2000740  0x0    0x4208 0  F  4    T  T  0    0x36d44 
  ---------------------------------------------------------------------------------
 
   
  S:0.0.0.0 G:10.60.66.66 P:32 PI:113837 PO:999688227 RF:198 TF:0 OF:0 F:0
  ---------------------------------------------------------------------------------
  C  IC IP ID IS IU IF IM IV IR         IA     IG     ET EO ER   EM EV EC   BS      
  ---------------------------------------------------------------------------------
  0  T  F  F  F  F  F  T  T  0x0        0x2    0x420b 0  F  7    T  T  0    0x36c7b 
  1  T  F  F  F  F  F  T  T  0x0        0x2    0x420b 0  T  7    T  T  1    0x36b13 
  2  T  F  F  F  F  F  T  T  0x0        0x2    0x420b 0  F  7    T  T  0    0x36b2b 
  3  T  F  F  F  F  F  T  T  0x0        0x2    0x420b 0  F  7    T  T  0    0x36d53 
  ---------------------------------------------------------------------------------
 
   
  S:0.0.0.0 G:10.60.64.64 P:32 PI:84205 PO:973945464 RF:200 TF:0 OF:0 F:0
  ---------------------------------------------------------------------------------
  C  IC IP ID IS IU IF IM IV IR         IA     IG     ET EO ER   EM EV EC   BS      
  ---------------------------------------------------------------------------------
  0  T  F  F  F  F  F  T  T  0x0        0x2    0x420a 0  F  6    T  T  0    0x36c76 
  1  T  F  F  F  F  F  T  T  0x0        0x2    0x420a 0  T  6    T  T  1    0x36b0e 
  2  T  F  F  F  F  F  T  T  0x0        0x2    0x420a 0  F  6    T  T  0    0x36b26 
  3  T  F  F  F  F  F  T  T  0x0        0x2    0x420a 0  F  6    T  T  0    0x36d4e 
  ---------------------------------------------------------------------------------
 
   

Step 6 One possible cause could be that the IGMP group is timing out. One way to check is to create a static route for the (*,G) and see if traffic is now received. If it is, it means that the groups are timing out.

Step 7 To confirm the result from Step 6, remove the static route and decrease the query interval (resulting in more queries per minute) to make it clearer:

RP/0/RSP0/CPU0:router# conf
RP/0/RSP0/CPU0:router(config)# router igmp
RP/0/RSP0/CPU0:router(config-igmp)# query-interval 1
RP/0/RSP0/CPU0:router(config-igmp)# commit

Step 8 Ensure that packets are going out of interface at the interval set.

Step 9 Check that the tester responds with an IGMP membership report. If the packets are received at the tester, the result from Step 6 is confirmed. Use the workaround.


Workaround

Configure static groups as a temporary workaround.

Traffic Fails on Some Interfaces

Traffic is failing on some interfaces or channels. You determine that

Groups and routes are configured and set up correctly.

Traffic is sent to the ASR 9000 from the tester.

Traffic is received correctly on some interfaces but not on others or some video channels are received correctly on an interface while others are not.

Possible causes could be:

OLIST may not be properly configured.

UIDB values not correctly set in hardware.

MGID not correctly set up.


Step 1 Ensure that packets are going from the ingress network processor (NP) through the fabric to the egress NP.

RP/0/RSP0/CPU0:router# show mfib hardware route statistics location {ingress node-id | egress node-id }

Step 2 View olist interfaces for the route.

RP/0/RSP0/CPU0:router# show mfib hardware route olist location {ingress node-id | egress node-id }

Step 3 View the statistics for the specific route and source.

RP/0/RSP0/CPU0:router# show mfib hardware route stat [src ip addr] location {ingress node-id | egress node-id }


Traffic Fails on Some Interfaces—MGID


Step 1 Ensure that packets are going from the ingress NP through the fabric to the egress NP.

RP/0/RSP0/CPU0:router# show mfib hardware route statistics location {ingress node-id | egress node-id }

Step 2 View olist interfaces for the route.

RP/0/RSP0/CPU0:router# show mfib hardware route olist location {ingress node-id | egress node-id }

Step 3 Ensure that packets are transmitted out of ingress NP to fabric and received by egress NP from the fabric.

RP/0/RSP0/CPU0:router# show mfib hardware route statistics location {ingress node-id | egress node-id }

Step 4 View the MGID for the route.

Throughput Loss at Receiver Interfaces

Traffic is sent and received on routes but there is a loss of throughput at the receiver.


Step 1 Ensure that packets are going from the ingress NP through the fabric to the egress NP.

RP/0/RSP0/CPU0:router# show mfib hardware route statistics location {ingress node-id | 
egress node-id}
 
   

Step 2 The preceding command checks if if packets are punted to the RP. If so, check if the source of that channel is setting some IP options or not.


Reverse Path Forwarding IP Address Problems

Reverse Path Forwarding (RPF) ensures loop-free forwarding of multicast packets in multicast routing. This section contains the following subsections:

Using show and debug Commands

Packets from Wrong IP Address—Loose RPF

Packets Forwarded with Wrong IP Address—Strict RPF

Using show and debug Commands

show cef ipv4 interface—View IPv4 Cisco Express Forwarding (CEF)-related information for an interface.

Packets from Wrong IP Address—Loose RPF

In loose RPF, the packets incoming on that particular interface are checked to determine if the source IP of the packet is reachable through some interface on the box. If not, the packet is dropped.

RP/0/RSP0/CPU0:router# show cef {ipv4} prefix hardware egress detail location node-id 
 
   

Workaround

Unconfigure and configure loose RPF on the interface.

Packets Forwarded with Wrong IP Address—Strict RPF

In strict RPF, the packets incoming on that particular interface are checked to determine if the source IP of the packet is reachable through the same interface on the box on which the packet came in. If not, the packet is dropped.

Verify non-null rpf_ptr and uidb list with the show cef command.

RP/0/RSP0/CPU0:router# show cef {ipv4 | ipv6} prefix hardware egress detail location 
node-id 
 
   

Workaround

Unconfigure and configure strict RPF on the interface.