Multicast - PIM Assert

Overview

When multiple multicast devices attempt to simultaneously send multicast traffic onto the same LAN segment the potential for packet duplication can occur. PIM employees a mechanism called PIM assert to prevent this scenario by electing a designated sender for the LAN segment responsible for forwarding multicast traffic onto the shared LAN segment. This lab will focus on this mechanism

Concepts tested

• PIM dense mode configuration
• PIM assert election metric manipulation

Topology

Lab Tasks

• Enable PIM dense mode on all interfaces from the receiver to the source
• Ensure the R3 is elected the PIM assert winner on the 120.0.0.0/24 shared network
• Do not modify any dynamic routing configuration or metrics to do this.
• For testing purpose have the reciever join the group 232.0.0.2 on its G0/0 interface
• Have the source ping the group 232.0.0.2 and confirm R3 win's the assert election and the ping is successful.

GNS3 configuration file, requires IOS v15 for the 7200 router: Link


Solution

Begin by configuring our PIM neighbors.

Source(config)#ip multicast-routing
Source(config)#int g0/0
Source(config-if)#ip pim dense-mode
Source(config-if)#ip igmp join-group 232.0.0.2

R4(config)#ip multicast-routing

R4(config-if)#int g1/0

R4(config-if)#ip pim dense-mode
R4(config-if)#int g2/0
R4(config-if)#ip pim dense-mode
R4(config-if)#int s3/0
R4(config-if)#ip pim dense-mode

R3(config)#ip multicast-routing

R3(config)#int g0/0

R3(config-if)#ip pim dense-mode

R3(config-if)#int g1/0

R3(config-if)#ip pim dense-mode

R2(config)#ip multicast-routing

R2(config)#int g0/0

R2(config-if)#ip pim dense-mode

R2(config-if)#int s2/0

R2(config-if)#ip pim dense-mode

Receiver(config)#ip multicast-routing

Receiver(config)#int g0/0

Receiver(config-if)#ip pim dense-mode

Verification

You can confirm PIM neighbor with the following command.

Receiver#sho 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

120.0.0.2         GigabitEthernet0/0       00:22:38/00:01:43 v2    1 / S P G

120.0.0.3         GigabitEthernet0/0       00:47:59/00:01:44 v2    1 / DR S P G

Do this for the remaining routers and confirm you see neighbors for every interface on each router where PIM was enabled.

Next you can confirm that the reciever has successfully registered with the following command.

Now lets test our receiver is properly getting multicast packets via our preferred path.

Source#ping 232.0.0.2 rep 500

Type escape sequence to abort.

Sending 500, 100-byte ICMP Echos to 232.0.0.2, timeout is 2 seconds:

Reply to request 0 from 120.0.45.5, 48 ms

Reply to request 1 from 120.0.45.5, 8 ms

Reply to request 1 from 120.0.0.1, 244 ms

Reply to request 2 from 120.0.45.5, 12 ms

Reply to request 2 from 120.0.0.1, 116 ms

Below indicates that R2 has actually won the election so it is forwarding multicast traffic onto the 120.0.0.0/24 network which is not what we want.

R2#sh ip mroute 232.0.0.2

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

       L - Local, P - Pruned, R - RP-bit set, F - Register flag,

       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,

       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,

       U - URD, I - Received Source Specific Host Report,

       Z - Multicast Tunnel, z - MDT-data group sender,

       Y - Joined MDT-data group, y - Sending to MDT-data group,

       V - RD & Vector, v - Vector

Outgoing interface flags: H - Hardware switched, A - Assert winner

 Timers: Uptime/Expires

 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 232.0.0.2), 00:33:53/stopped, RP 0.0.0.0, flags: DC

  Incoming interface: Null, RPF nbr 0.0.0.0

  Outgoing interface list:

    GigabitEthernet0/0, Forward/Dense, 00:11:57/00:00:00

    Serial2/0, Forward/Dense, 00:33:53/00:00:00

(120.0.45.5, 232.0.0.2), 00:00:33/00:02:26, flags: T

  Incoming interface: Serial2/0, RPF nbr 120.0.24.4

  Outgoing interface list:

    GigabitEthernet0/0, Forward/Dense, 00:00:33/00:00:00, A

We can see this if we enable debug.

R3#debug ip pim

R$#debug ip pim

R2 output:

*Nov 15 16:53:39.623: PIM(0): Send v2 Assert on GigabitEthernet0/0 for 232.0.0.2, source 120.0.45.5, metric [90/2170112]

*Nov 15 16:53:39.627: PIM(0): Assert metric to source 120.0.45.5 is [90/2170112]

*Nov 15 16:53:39.631: PIM(0): We win, our metric [90/2170112]

*Nov 15 16:53:39.631: PIM(0): (120.0.45.5/32, 232.0.0.2) oif GigabitEthernet0/0 in Forward state

R3 output:

*Nov 15 16:53:39.251: PIM(0): Received v2 Assert on GigabitEthernet0/0 from 120.0.0.2

*Nov 15 16:53:39.255: PIM(0): Assert metric to source 120.0.45.5 is [90/2170112]

*Nov 15 16:53:39.255: PIM(0): We lose, our metric [110/2]

*Nov 15 16:53:39.259: PIM(0): Prune GigabitEthernet0/0/232.0.0.2 from (120.0.45.5/32, 232.0.0.2)

So how do we fix this to meet the lab requirements?

When a multiple routers attempt to simultaneously send multicast traffic onto the same network with the same (S,G) each router will immediately send a PIM assert message to prevent duplication of traffic. The election is won based on the following criteria.

First, the IGP AD is compared, with the better AD winning the election

If the AD is equal then the metric is compared the better metric winning the election

If both AD and Metric are equal then the router with the higher IP address wins.

The loser of the election it will remove its (S,G) state and prune its interfaces.

So to fix this issue we need to get R3 to win this election. So to do this and meet the lab requirements we need to have R3 have a better multicast route with a better AD. 

R3(config)#ip mroute 120.0.45.0 255.255.255.0 120.0.34.4

The above command should fix this problem.

R3#sh ip mroute 232.0.0.2

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

       L - Local, P - Pruned, R - RP-bit set, F - Register flag,

       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,

       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,

       U - URD, I - Received Source Specific Host Report,

       Z - Multicast Tunnel, z - MDT-data group sender,

       Y - Joined MDT-data group, y - Sending to MDT-data group,

       V - RD & Vector, v - Vector

Outgoing interface flags: H - Hardware switched, A - Assert winner

 Timers: Uptime/Expires

 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 232.0.0.2), 00:49:13/stopped, RP 0.0.0.0, flags: DC

  Incoming interface: Null, RPF nbr 0.0.0.0

  Outgoing interface list:

    GigabitEthernet1/0, Forward/Dense, 00:49:13/00:00:00

    GigabitEthernet0/0, Forward/Dense, 00:49:13/00:00:00

(120.0.45.5, 232.0.0.2), 00:00:37/00:02:22, flags: T

  Incoming interface: GigabitEthernet1/0, RPF nbr 120.0.34.4, Mroute

  Outgoing interface list:

    GigabitEthernet0/0, Forward/Dense, 00:00:37/00:00:00, A


R2:

*Nov 15 17:08:55.835: PIM(0): Received v2 Assert on GigabitEthernet0/0 from 120.0.0.3
*Nov 15 17:08:55.835: PIM(0): Assert metric to source 120.0.45.5 is [0/0]
*Nov 15 17:08:55.835: PIM(0): We lose, our metric [90/2170112]

R3:

*Nov 15 17:08:56.367: PIM(0): Send v2 Assert on GigabitEthernet0/0 for 232.0.0.2, source 120.0.45.5, metric [0/0]
*Nov 15 17:08:56.367: PIM(0): Assert metric to source 120.0.45.5 is [0/0]
*Nov 15 17:08:56.367: PIM(0): We win, our metric [0/0]