Fortinet white logo
Fortinet white logo

Handbook

6.0.0

FortiGate PIM-SM debugging examples

FortiGate PIM-SM debugging examples

Using the example topology shown below, you can trace the multicast streams and states within the three FortiGate devices (FGT-1, FGT-2, and FGT-3) using the debug commands described in this section. The command output in this section is taken from the FortiGate when the multicast stream is flowing correctly from source to receiver.

PIM-SM debugging topology

Checking that the receiver has joined the required group

From the last hop router, FGT-3, you can use the following command to check that the receiver has correctly joined the required group.

FGT-3 # get router info multicast igmp groups

IGMP Connected Group Membership

Group Address Interface Uptime Expires Last Reporter

239.255.255.1 port3 00:31:15 00:04:02 10.167.0.62

Only 1 receiver is displayed for a particular group, this is the device that responded to the IGMP query request from the FGT-3. If a receiver is active, the expire time should drop to approximately 2 minutes before being refreshed.

Checking the PIM-SM neighbors

Next, the PIM-SM neighbors should be checked. A PIM router becomes a neighbor when the PIM router receives a PIM hello. Use the following command to display the PIM-SM neighbors of FGT-3:

FGT-3 # get router info multicast pim sparse-mode neighbour

Neighbor Interface Uptime/Expires Ver DR

Address Priority/Mode

10.132.0.156 port2 01:57:12/00:01:33 v2 1 /

Checking that the PIM router can reach the RP

The rendezvous point (RP) must be reachable for the PIM router (FGT-3) to be able to send the *,G join to request the stream. This can be checked for FGT-3 using the following command:

FGT-3 # get router info multicast pim sparse-mode rp-mapping

PIM Group-to-RP Mappings

Group(s): 224.0.0.0/4, Static

RP: 192.168.1.1

Uptime: 07:23:00

Viewing the multicast routing table (FGT-3)

The FGT-3 unicast routing table can be used to determine the path taken to reach the RP at 192.168.1.1. You can then check the stream state entries using the following commands:

FGT-3 # get router info multicast pim sparse-mode table

IP Multicast Routing Table

(*,*,RP) Entries: 0

(*,G) Entries: 1

(S,G) Entries: 1

(S,G,rpt) Entries: 1

FCR Entries: 0

(*,*,RP) Entries

This state may be reached by general joins for all groups served by a specified RP.

(*,G) Entries

State that maintains the RP tree for a given group.

(S,G) Entries

State that maintains a source-specific tree for source S and group G.

(S,G,rpt) Entries

State that maintains source-specific information about source s on the RP tree for G. For example, if a source is being received on the source-specific tree, it will normally have been pruned off the RP tree.

FCR

The FCR state entries are for tracking the sources in the <*, G> when <S, G> isn't available for any reason, the stream would typically be flowing when this state exists.

Breaking down each entry in detail:

(*, 239.255.255.1)

RP: 192.168.1.1

RPF nbr: 10.132.0.156

RPF idx: port2

Upstream State: JOINED

Local:

port3

Joined:

Asserted:

FCR:

The RP will always be listed in a *,G entry, the RPF neighbor and interface index will also be shown. In this topology, these are the same in all downstream PIM routers. The state is active so the upstream state is joined.

In this case FGT-3 is the last hop router so the IGMP join is received locally on port3. There is no PIM outgoing interface listed for this entry as it is used for the upstream PIM join.

(10.166.0.11, 239.255.255.1)

RPF nbr: 10.132.0.156

RPF idx: port2

SPT bit: 1

Upstream State: JOINED

Local:

Joined:

Asserted:

Outgoing:

port3

This is the entry for the SPT, no RP IS listed. The S,G stream will be forwarded out of the stated outgoing interface.

(10.166.0.11, 239.255.255.1, rpt)

RP: 192.168.1.1

RPF nbr: 10.132.0.156

RPF idx: port2

Upstream State: NOT PRUNED

Local:

Pruned:

Outgoing:

The above S,G,RPT state is created for all streams that have both a S,G and a *,G entry on the router. This isn't pruned, in this case, because of the topology: the RP and source are reachable over the same interface.

Although not seen in this scenario, assert states may be seen when multiple PIM routers exist on the same LAN, which can lead to more than one upstream router having a valid forwarding state. Assert messages are used to elect a single forwarder from the upstream devices.

Viewing the PIM next-hop table

The PIM next-hop table is also very useful for checking the various states, it can be used to quickly identify the states of multiple multicast streams.

FGT-3 # get router info multicast pim sparse-mode next-hop

Flags: N = New, R = RP, S = Source, U = Unreachable

Destination Type Nexthop Nexthop Nexthop Metric Pref Refcnt

Num Addr Ifindex

_______________________________________________________________

10.166.0.11 ..S. 1 10.132.0.156 9 21 110 3

192.168.1.1 .R.. 1 10.132.0.156 9 111 110 2

Viewing the PIM multicast forwarding table

Also, you can check the multicast forwarding table showing the ingress and egress ports of the multicast stream.

FGT-3 # get router info multicast table

IP Multicast Routing Table

Flags: I - Immediate Stat, T - Timed Stat, F - Forwarder installed

Timers: Uptime/Stat Expiry

Interface State: Interface (TTL threshold)

(10.166.0.11, 239.255.255.1), uptime 04:02:55, stat expires 00:02:25

Owner PIM-SM, Flags: TF

Incoming interface: port2

Outgoing interface list:

port3 (TTL threshold 1)

Viewing the kernel forwarding table

Also, the kernel forwarding table can be verified, however this should give similar information to the above command:

FGT-3 # diag ip multicast mroute

grp=239.255.255.1 src=10.166.0.11 intf=9 flags=(0x10000000)[ ] status=resolved

last_assert=2615136 bytes=1192116 pkt=14538 wrong_if=0 num_ifs=1

index(ttl)=[6(1),]

Viewing the multicast routing table (FGT-2)

If you check the output on FGT-2, there are some small differences:

FGT-2 # get router info multicast pim sparse-mode table

IP Multicast Routing Table

(*,*,RP) Entries: 0

(*,G) Entries: 1

(S,G) Entries: 1

(S,G,rpt) Entries: 1

FCR Entries: 0

(*, 239.255.255.1)

RP: 192.168.1.1

RPF nbr: 0.0.0.0

RPF idx: None

Upstream State: JOINED

Local:

Joined:

external

Asserted:

FCR:

The *,G entry now has a joined interface rather than local because it received a PIM join from FGT-3 rather than a local IGMP join.

(10.166.0.11, 239.255.255.1)

RPF nbr: 10.130.0.237

RPF idx: internal

SPT bit: 1

Upstream State: JOINED

Local:

Joined:

external

Asserted:

Outgoing:

external

The S,G entry shows that we have received a join on the external interface and the stream is being forwarded out of this interface.

(10.166.0.11, 239.255.255.1, rpt)

RP: 192.168.1.1

RPF nbr: 0.0.0.0

RPF idx: None

Upstream State: PRUNED

Local:

Pruned:

Outgoing:

External

The S,G,RPT is different from FGT-3 because FGT-2 is the RP, it has pruned back the SPT for the RP to the first hop router.

Viewing the multicast routing table (FGT-1)

FGT-1 again has some differences with regard to the PIM-SM states. There's no *,G entry because it isn't in the path of a receiver and the RP.

FGT-1_primary # get router info multicast pim sparse-mode table

IP Multicast Routing Table

(*,*,RP) Entries: 0

(*,G) Entries: 0

(S,G) Entries: 1

(S,G,rpt) Entries: 1

FCR Entries: 0

Below the S,G is the SPT termination because this FortiGate is the first hop router. The RPF neighbor always shows as 0.0.0.0 because the source is local to this device. Both the joined and outgoing fields show as external because the PIM join and the stream is egressing on this interface.

(10.166.0.11, 239.255.255.1)

RPF nbr: 0.0.0.0

RPF idx: None

SPT bit: 1

Upstream State: JOINED

Local:

Joined:

external

Asserted:

Outgoing:

external

The stream has been pruned back from the RP because the end-to-end SPT is flowing. In this case, there's no requirement for the stream to be sent to the RP.

(10.166.0.11, 239.255.255.1, rpt)

RP: 0.0.0.0

RPF nbr: 10.130.0.156

RPF idx: external

Upstream State: RPT NOT JOINED

Local:

Pruned:

Outgoing:

FortiGate PIM-SM debugging examples

FortiGate PIM-SM debugging examples

Using the example topology shown below, you can trace the multicast streams and states within the three FortiGate devices (FGT-1, FGT-2, and FGT-3) using the debug commands described in this section. The command output in this section is taken from the FortiGate when the multicast stream is flowing correctly from source to receiver.

PIM-SM debugging topology

Checking that the receiver has joined the required group

From the last hop router, FGT-3, you can use the following command to check that the receiver has correctly joined the required group.

FGT-3 # get router info multicast igmp groups

IGMP Connected Group Membership

Group Address Interface Uptime Expires Last Reporter

239.255.255.1 port3 00:31:15 00:04:02 10.167.0.62

Only 1 receiver is displayed for a particular group, this is the device that responded to the IGMP query request from the FGT-3. If a receiver is active, the expire time should drop to approximately 2 minutes before being refreshed.

Checking the PIM-SM neighbors

Next, the PIM-SM neighbors should be checked. A PIM router becomes a neighbor when the PIM router receives a PIM hello. Use the following command to display the PIM-SM neighbors of FGT-3:

FGT-3 # get router info multicast pim sparse-mode neighbour

Neighbor Interface Uptime/Expires Ver DR

Address Priority/Mode

10.132.0.156 port2 01:57:12/00:01:33 v2 1 /

Checking that the PIM router can reach the RP

The rendezvous point (RP) must be reachable for the PIM router (FGT-3) to be able to send the *,G join to request the stream. This can be checked for FGT-3 using the following command:

FGT-3 # get router info multicast pim sparse-mode rp-mapping

PIM Group-to-RP Mappings

Group(s): 224.0.0.0/4, Static

RP: 192.168.1.1

Uptime: 07:23:00

Viewing the multicast routing table (FGT-3)

The FGT-3 unicast routing table can be used to determine the path taken to reach the RP at 192.168.1.1. You can then check the stream state entries using the following commands:

FGT-3 # get router info multicast pim sparse-mode table

IP Multicast Routing Table

(*,*,RP) Entries: 0

(*,G) Entries: 1

(S,G) Entries: 1

(S,G,rpt) Entries: 1

FCR Entries: 0

(*,*,RP) Entries

This state may be reached by general joins for all groups served by a specified RP.

(*,G) Entries

State that maintains the RP tree for a given group.

(S,G) Entries

State that maintains a source-specific tree for source S and group G.

(S,G,rpt) Entries

State that maintains source-specific information about source s on the RP tree for G. For example, if a source is being received on the source-specific tree, it will normally have been pruned off the RP tree.

FCR

The FCR state entries are for tracking the sources in the <*, G> when <S, G> isn't available for any reason, the stream would typically be flowing when this state exists.

Breaking down each entry in detail:

(*, 239.255.255.1)

RP: 192.168.1.1

RPF nbr: 10.132.0.156

RPF idx: port2

Upstream State: JOINED

Local:

port3

Joined:

Asserted:

FCR:

The RP will always be listed in a *,G entry, the RPF neighbor and interface index will also be shown. In this topology, these are the same in all downstream PIM routers. The state is active so the upstream state is joined.

In this case FGT-3 is the last hop router so the IGMP join is received locally on port3. There is no PIM outgoing interface listed for this entry as it is used for the upstream PIM join.

(10.166.0.11, 239.255.255.1)

RPF nbr: 10.132.0.156

RPF idx: port2

SPT bit: 1

Upstream State: JOINED

Local:

Joined:

Asserted:

Outgoing:

port3

This is the entry for the SPT, no RP IS listed. The S,G stream will be forwarded out of the stated outgoing interface.

(10.166.0.11, 239.255.255.1, rpt)

RP: 192.168.1.1

RPF nbr: 10.132.0.156

RPF idx: port2

Upstream State: NOT PRUNED

Local:

Pruned:

Outgoing:

The above S,G,RPT state is created for all streams that have both a S,G and a *,G entry on the router. This isn't pruned, in this case, because of the topology: the RP and source are reachable over the same interface.

Although not seen in this scenario, assert states may be seen when multiple PIM routers exist on the same LAN, which can lead to more than one upstream router having a valid forwarding state. Assert messages are used to elect a single forwarder from the upstream devices.

Viewing the PIM next-hop table

The PIM next-hop table is also very useful for checking the various states, it can be used to quickly identify the states of multiple multicast streams.

FGT-3 # get router info multicast pim sparse-mode next-hop

Flags: N = New, R = RP, S = Source, U = Unreachable

Destination Type Nexthop Nexthop Nexthop Metric Pref Refcnt

Num Addr Ifindex

_______________________________________________________________

10.166.0.11 ..S. 1 10.132.0.156 9 21 110 3

192.168.1.1 .R.. 1 10.132.0.156 9 111 110 2

Viewing the PIM multicast forwarding table

Also, you can check the multicast forwarding table showing the ingress and egress ports of the multicast stream.

FGT-3 # get router info multicast table

IP Multicast Routing Table

Flags: I - Immediate Stat, T - Timed Stat, F - Forwarder installed

Timers: Uptime/Stat Expiry

Interface State: Interface (TTL threshold)

(10.166.0.11, 239.255.255.1), uptime 04:02:55, stat expires 00:02:25

Owner PIM-SM, Flags: TF

Incoming interface: port2

Outgoing interface list:

port3 (TTL threshold 1)

Viewing the kernel forwarding table

Also, the kernel forwarding table can be verified, however this should give similar information to the above command:

FGT-3 # diag ip multicast mroute

grp=239.255.255.1 src=10.166.0.11 intf=9 flags=(0x10000000)[ ] status=resolved

last_assert=2615136 bytes=1192116 pkt=14538 wrong_if=0 num_ifs=1

index(ttl)=[6(1),]

Viewing the multicast routing table (FGT-2)

If you check the output on FGT-2, there are some small differences:

FGT-2 # get router info multicast pim sparse-mode table

IP Multicast Routing Table

(*,*,RP) Entries: 0

(*,G) Entries: 1

(S,G) Entries: 1

(S,G,rpt) Entries: 1

FCR Entries: 0

(*, 239.255.255.1)

RP: 192.168.1.1

RPF nbr: 0.0.0.0

RPF idx: None

Upstream State: JOINED

Local:

Joined:

external

Asserted:

FCR:

The *,G entry now has a joined interface rather than local because it received a PIM join from FGT-3 rather than a local IGMP join.

(10.166.0.11, 239.255.255.1)

RPF nbr: 10.130.0.237

RPF idx: internal

SPT bit: 1

Upstream State: JOINED

Local:

Joined:

external

Asserted:

Outgoing:

external

The S,G entry shows that we have received a join on the external interface and the stream is being forwarded out of this interface.

(10.166.0.11, 239.255.255.1, rpt)

RP: 192.168.1.1

RPF nbr: 0.0.0.0

RPF idx: None

Upstream State: PRUNED

Local:

Pruned:

Outgoing:

External

The S,G,RPT is different from FGT-3 because FGT-2 is the RP, it has pruned back the SPT for the RP to the first hop router.

Viewing the multicast routing table (FGT-1)

FGT-1 again has some differences with regard to the PIM-SM states. There's no *,G entry because it isn't in the path of a receiver and the RP.

FGT-1_primary # get router info multicast pim sparse-mode table

IP Multicast Routing Table

(*,*,RP) Entries: 0

(*,G) Entries: 0

(S,G) Entries: 1

(S,G,rpt) Entries: 1

FCR Entries: 0

Below the S,G is the SPT termination because this FortiGate is the first hop router. The RPF neighbor always shows as 0.0.0.0 because the source is local to this device. Both the joined and outgoing fields show as external because the PIM join and the stream is egressing on this interface.

(10.166.0.11, 239.255.255.1)

RPF nbr: 0.0.0.0

RPF idx: None

SPT bit: 1

Upstream State: JOINED

Local:

Joined:

external

Asserted:

Outgoing:

external

The stream has been pruned back from the RP because the end-to-end SPT is flowing. In this case, there's no requirement for the stream to be sent to the RP.

(10.166.0.11, 239.255.255.1, rpt)

RP: 0.0.0.0

RPF nbr: 10.130.0.156

RPF idx: external

Upstream State: RPT NOT JOINED

Local:

Pruned:

Outgoing: