Technical Tip: How to troubleshoot IGMP and PIM Dense Mode issues

[sthampi_FTNT]

Description

This article explains how FortiGate responds to various PIM-dense modes and IGMP messages in a multicast network.

This article assumes that the PIM and IGMP configuration are already in place:

• IGMP is configured on LHR (Last Hop Router) in this diagram R2.
• PIM Dense Mode configured between R1 and R2.
• Multicast source connected to R1.

Diagram:

                                

Scope

FortiGate v6.4.

Solution

In the above diagram.

Multicast server having IP address 10.100.3.75 starts sending a multicast stream towards the group 239.16.10.1 through port2 of R1 (FHR):

R1 # diag sniffer packet any 'host 239.16.10.1' 4
1.370198 port2 in 10.100.3.75.42734 -> 239.16.10.1.12345: udp 46
2.370499 port2 in 10.100.3.75.42734 -> 239.16.10.1.12345: udp 46
3.370885 port2 in 10.100.3.75.42734 -> 239.16.10.1.12345: udp 46

 R1 creates an (S,G) entry in its multicast table and floods the multicast packets towards all its PIM DM neighbors on Port4 and Port3. 

R1 # get router info multicast table 239.16.10.1

IP Multicast Routing Table
Flags: I - Immediate Stat, T - Timed Stat, F - Forwarder installed
Timers: Uptime/Stat Expiry
Interface State: Interface (TTL threshold)

(10.100.3.75, 239.16.10.1), uptime 00:00:05, stat expires 00:03:25
Owner PIM-DM, Flags: TF
Incoming interface: port2
Outgoing interface list:
port3 (TTL threshold 1)
port4 (TTL threshold 1)

R1 # diag sniffer packet any 'host 239.16.10.1' 4
62.417822 port2 in 10.100.3.75.34901 -> 239.16.10.1.12345: udp 46
62.418309 port4 out 10.100.3.75.34901 -> 239.16.10.1.12345: udp 46
62.418335 port3 out 10.100.3.75.34901 -> 239.16.10.1.12345: udp 46

R1 # get router info multicast pim dense-mode table 239.16.10.1
PIM-DM Multicast Routing Table
(10.100.3.75, 239.16.10.1)
MRT life time: 210
Source directly connected on port2
State-Refresh Originator State: Originator
State Refresh Interval (received): 0
Upstream IF: port2
Upstream State: Forwarding
Assert State: NoInfo
Assert timer: 180 seconds
Downstream IF List:
port3, in 'olist':
Flag: IN-OLIST
Downstream State: NoInfo
Assert State: NoInfo
port4, in 'olist':
Flag: IN-OLIST
Downstream State: NoInfo
Assert State: NoInfo

After R2 receives the multicast stream which was flooded by R1, R2 will create an (S,G) entry in its multicast table:

• Notice the outgoing interface list is empty, it is because Multicast Receiver although online, has not sent IGMP Join to the group 239.16.10.1.
• Notice the upstream state for port2 on R2, it is Pruned because R2 has sent a PIM Prune towards R1.

R2 # get router info multicast table 239.16.10.1

IP Multicast Routing Table
Flags: I - Immediate Stat, T - Timed Stat, F - Forwarder installed
Timers: Uptime/Stat Expiry
Interface State: Interface (TTL threshold)

(10.100.3.75, 239.16.10.1), uptime 00:00:03, stat expires 00:03:27
Owner PIM-DM, Flags: TF
Incoming interface: port2
Outgoing interface list:

R2 # get router info multicast pim dense-mode table
PIM-DM Multicast Routing Table
(10.100.3.75, 239.16.10.1)
MRT life time: 210
RPF Neighbor: 10.101.0.39, Nexthop: 10.101.0.39, port2
Upstream IF: port2
Upstream State: Pruned
Assert State: NoInfo
Assert timer: 180 seconds
Downstream IF List: empty

After R1 receives the PIM Prune message from R2, it will wait for a brief period to see if any other router in the same segment requires the same stream.

If not, R1 will prune the interface port3 from the OLIST (Outgoing Interface List) for the multicast stream (10.100.3.75, 239.16.10.1) after which the multicast packets are no longer sent towards R2.

R1 # get router info multicast pim dense-mode table 239.16.10.1
PIM-DM Multicast Routing Table
(10.100.3.75, 239.16.10.1)
MRT life time: 210
Source directly connected on port2
State-Refresh Originator State: Originator
State Refresh Interval (received): 0
Upstream IF: port2
Upstream State: Forwarding
Assert State: NoInfo
Assert timer: 180 seconds
Downstream IF List:
port3:
Flag:
Downstream State: Pruned
Assert State: NoInfo
port4, in 'olist':
Flag: IN-OLIST
Downstream State: NoInfo
Assert State: NoInfo

After some time, the Multicast receiver decides to join the group 239.16.10.1 so that it can receive the stream. Hence it will send an IGMP Join message towards R2.

R2 having received the IGMP Join message, will update its IGMP group table and then send a PIM Graft message to the upstream R1 for this particular (S,G) entry. R1 will respond with Graft ACK.

R2 # get router info multicast igmp groups 239.16.10.1
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter
239.16.10.1 port3 00:05:45 00:00:42 10.102.0.49

After R1 sends the Graft-ACK, R1 will update it is OLIST and start forwarding the multicast stream for (10.100.3.75, 239.16.10.1) through port3.

R1 # get router info multicast table 239.16.10.

IP Multicast Routing Table
Flags: I - Immediate Stat, T - Timed Stat, F - Forwarder installed
Timers: Uptime/Stat Expiry
Interface State: Interface (TTL threshold)

(10.100.3.75, 239.16.10.1), uptime 00:57:19, stat expires 00:03:14
Owner PIM-DM, Flags: TF
Incoming interface: port2
Outgoing interface list:
port3 (TTL threshold 1)
port4 (TTL threshold 1)

R1 # diag sniffer packet any 'host 239.16.10.1' 4
0.723376 port2 in 10.100.3.75.54361 -> 239.16.10.1.12345: udp 46
0.723438 port3 out 10.100.3.75.54361 -> 239.16.10.1.12345: udp 46
0.723476 port4 out 10.100.3.75.54361 -> 239.16.10.1.12345: udp 46

R2 # diag sniff packet any 'host 239.16.10.1' 4
0.864705 port2 in 10.100.3.75.54361 -> 239.16.10.1.12345: udp 46
0.864771 port3 out 10.100.3.75.54361 -> 239.16.10.1.12345: udp 46
1.865020 port2 in 10.100.3.75.54361 -> 239.16.10.1.12345: udp 46
1.865091 port3 out 10.100.3.75.54361 -> 239.16.10.1.12345: udp 46

Note:

Command to see if neighborship is active or not:

For dense-mode: 'get router info multicast pim dense-mode neighbour'.

Example:

Related articles:

Troubleshooting Tip: IGMP and PIM commands and debug in Sparse-Mode

Technical Tip: FortiOS Multicast Resource List