Troubleshooting Multicast packets to CPU

Overview

This article covers different scenarios where undesirable multicast traffic can be punted to CPU.

 

Topology

PIM (3)

 

Scenarios

1. Unsolicited traffic

When the switch receives multicast traffic, there are two main checks made:
1.Is the source locally connected (i.e. is the source IP of the traffic in the same subnet as the IIF)

OR

2. Is there a valid mroute state for the S,G

If neither or the above apply, the multicast data traffic will be punted to CPU and no mroute state will be created.

Note: Neither of the above checks apply in code versions prior to 4.14.x for a multicast data traffic. The switch will try to form hardware state on the RPT tree and traffic will not be sent to the CPU.

Typically this issue is noticed when the switch is connected to an upstream device which is sending ALL multicast traffic either via static joins upstream or in dense mode.

Example:
Traffic Flow:
Exchange —-> SW02 (No receivers present)
Multicast traffic: Src 1.1.1.1 Group 239.10.10.10

When SW02 receives the traffic:

SW02#show ip mroute
PIM Sparse Mode Multicast Routing Table
Flags: E - Entry forwarding on the RPT, J - Joining to the SPT
R - RPT bit is set, S - SPT bit is set, L - Source is attached
W - Wildcard entry, X - External component interest
I - SG Include Join alert rcvd, P - Ex-Prune alert rcvd
*** No mroute state formed ****

SW02#show ip mfib software
239.10.10.10 1.1.1.1
Unresolved (iif)
pimreg
Packets Received: 0
Bytes Received : 0
RPF Failures : 0

Traffic can be seen at the CPU:

SW02#bash tcpdump -ni et2 udp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on et15, link-type EN10MB (Ethernet), capture size 65535 bytes
13:07:21.458499 00:1c:73:01:a9:49 > 01:00:5e:0a:0a:0a, ethertype IPv4 (0x0800), length 60: 1.1.1.1.50001 > 239.10.10.10.50001: UDP, length 18

Workaround:

The following configurations can be used to prevent traffic punted to CPU:

A) Multicast Border Router (MBR)

If this is legitimate traffic and at any point there will be receivers present to consume the traffic, MBR can be configured. A PIM MBR interface will allow multicast traffic from sources that are outside of the PIM domain. Sources learned through an MBR interface are treated as local sources (directly connected to the switch) and an mroute state will be formed.

For MBR configurations to be effective, the route to the source should be via the MBR interface and “ip pim sparse-mode” should not be configured on the MBR interface.

Configuration:
interface Ethernet2
no switchport
ip address 2.2.2.2/30
ip pim border-router
SW02(config)#show ip mroute
239.10.10.10
1.1.1.1, 0:00:43, flags: SBN ---> B bit indicating MBR is effective
Incoming interface: Ethernet2

SW02#show ip mfib software
239.10.10.10 1.1.1.1
Ethernet2 (iif) → S,G no longer stuck in PimReg
Packets Received: 587
Bytes Received : 27002
RPF Failures : 0

SW02#bash tcpdump -nei et2 udp 
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on et2, link-type EN10MB (Ethernet), capture size 65535 bytes
***** No traffic to CPU *****

B)  Multicast Boundary:
If the traffic is not intended in the network, a multicast boundary statement can be used to prevent traffic from being sent to the CPU. This will also prevent a mroute state from being formed (Please refer to the EOS release notes for platform support).

Configuration:
interface Ethernet2
no switchport
ip address 2.2.2.2/30
ip multicast boundary boundary_acl
ip pim sparse-mode
!
ip access-list standard boundary_acl
10 deny host 239.10.10.10
SW02#show ip mroute
**** No mroute state ****

SW02#bash tcpdump -nei et2 udp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on et2, link-type EN10MB (Ethernet), capture size 65535 bytes
^C
0 packets captured

C) Access List
Configure an access-list on the incoming port to drop the traffic at ingress:

Configuration:
interface Ethernet2
no switchport
ip address 2.2.2.2/30
ip access-group acl_drop in
ip pim sparse-mode
!
ip access-list acl_drop
10 deny ip any host 239.10.10.10
20 permit ip any any

 

2. Multicast TTL == 1

If the multicast traffic is received on the switch and the packets have a TTL of 1, the traffic will be punted to the CPU and dropped. This behavior is platform dependent: For example, on 7100 and 7048 devices, the traffic will not be sent to CPU.

SW02#bash tcpdump -nevvi et2 udp 
tcpdump: listening on et2, link-type EN10MB (Ethernet), capture size 65535 bytes
18:02:02.178324 00:1c:73:01:a9:49 > 01:00:5e:0a:0a:0a, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 1, id 0, offset 0, flags [none], proto UDP (17), length 46)
1.1.1.1.50001 > 239.10.10.10.50001: UDP, length 18

Workaround:

Ensure the TTL of the multicast packet is high enough to traverse through the network

 

3. Traffic received on OIL

Due to misconfiguration, if the multicast traffic is received on an interface this is also an OIL, the switch will not consider this traffic as a candidate for fastdrop and instead will punt it to CPU.

Example:
Traffic Flow:
Traffic received on Vlan 5 and sent to CPU

SW02#show ip mroute
239.10.10.10
0.0.0.0, 0:07:42, RP 100.100.100.100, flags: W
Incoming interface: Register
Outgoing interface list:
Vlan5

SW02#bash tcpdump -nei vlan5 udp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vlan5, link-type EN10MB (Ethernet), capture size 65535 bytes
18:13:49.313033 00:1c:73:01:a9:49 > 01:00:5e:0a:0a:0a, ethertype IPv4 (0x0800), length 60: 1.1.1.1.50001 > 239.10.10.10.50001: UDP, length 18

Workaround
Resolve the traffic coming in on the OIL if it is unexpected.

Add a Multicast Boundary ACL/Access List on the OIL interface to prevent the traffic reaching the CPU if the incoming traffic on OIL cannot be prevented.

 

4. No Route to the RP or back to FHR

On the Source DR (i.e First Hop Router), if there is no route to the RP, all the traffic on the IIF will continue to be punted to CPU as the registration process cannot complete.

Alternatively, if the RP does not have a route back to the FHR, the traffic on both the FHR and the RP will be CPU switched as the register stop will not make it back to the FHR to complete registration.

Example (Consider that SW01 as the current RP with SW02 as the FHR):
Case A) No route to SW01 on SW02

SW02#show ip route 100.100.100.100
Gateway of last resort is not set

SW02(config)#show ip mroute
239.10.10.10
1.1.1.1, 0:04:52, flags: SB
Incoming interface: Ethernet2
Outgoing interface list:
Register ---> indicative that the registration is not complete

SW02(config)#bash tcpdump -nei et2 udp 
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on et2, link-type EN10MB (Ethernet), capture size 65535 bytes
19:38:59.513993 00:1c:73:01:a9:49 > 01:00:5e:0a:0a:0a, ethertype IPv4 (0x0800), length 60: 1.1.1.1.50001 > 239.10.10.10.50001: UDP, length 18

Case B) No route to SW02 from SW01
Note: The route here is to the egress interface IP used by SW02 to reach the RP

On SW02:
interface Ethernet2
no switchport
ip address 2.2.2.2/30
ip pim border-router

SW02#bash tcpdump -nei et2 udp → IIF

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on et2, link-type EN10MB (Ethernet), capture size 65535 bytes
20:08:07.113024 00:1c:73:01:a9:49 > 01:00:5e:0a:0a:0a, ethertype IPv4 (0x0800), length 60: 1.1.1.1.50001 > 239.10.10.10.50001: UDP, length 18

SW02#bash tcpdump -nei vlan5 pim ---> Egress towards RP
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vlan5, link-type EN10MB (Ethernet), capture size 65535 bytes
20:15:39.117092 00:1c:73:90:34:21 > 00:1c:73:01:8d:3b, ethertype IPv4 (0x0800), length 62: 22.22.22.22 > 100.100.100.100: PIMv2, Register, length 28

Sw02#show ip mroute

239.10.10.10
1.1.1.1, 0:02:31, flags: SB
Incoming interface: Ethernet2
Outgoing interface list:
Register

On SW01:
SW01#bash tcpdump -nei vlan5 pim
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vlan5, link-type EN10MB (Ethernet), capture size 65535 bytes
13:41:33.766224 00:1c:73:90:34:21 > 00:1c:73:01:8d:3b, ethertype IPv4 (0x0800), length 88: 22.22.22.22 > 100.100.100.100: PIMv2, Register, length 54
**** No register stop sent as no route to 22.22.22.22 ****

SW01#show ip route 22.22.22.22
Gateway of last resort is not set

Workaround

Resolve any misconfigurations towards the route to RP from the FHR and vice versa.