In environments that require redundancy towards clients, HSRP will normally be running. HSRP is a proven protocol and it works but how do we handle when we have clients that need multicast? What triggers multicast to converge when the Active Router (AR) goes down? The following topology is used:
One thing to notice here is that R3 is the PIM DR even though R2 is the HSRP AR. The network has been setup with OSPF, PIM and R1 is the RP. Both R2 and R3 will receive IGMP reports but only R3 will send PIM Join, due to it being the PIM DR. R3 builds the (*,G) towards the RP:
R3#sh ip mroute 239.0.0.1
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,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.0.0.1), 02:54:15/00:02:20, RP 1.1.1.1, flags: SJC
Incoming interface: Ethernet0/0, RPF nbr 13.13.13.1
Outgoing interface list:
Ethernet0/2, Forward/Sparse, 00:25:59/00:02:20
We then ping 239.0.0.1 from the multicast source to build the (S,G):
S1#ping 239.0.0.1 re 3 Type escape sequence to abort. Sending 3, 100-byte ICMP Echos to 239.0.0.1, timeout is 2 seconds: Reply to request 0 from 10.0.0.10, 35 ms Reply to request 1 from 10.0.0.10, 1 ms Reply to request 2 from 10.0.0.10, 2 ms
The (S,G) has been built:
R3#sh ip mroute 239.0.0.1
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,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.0.0.1), 02:57:14/stopped, RP 1.1.1.1, flags: SJC
Incoming interface: Ethernet0/0, RPF nbr 13.13.13.1
Outgoing interface list:
Ethernet0/2, Forward/Sparse, 00:28:58/00:02:50
(41.41.41.10, 239.0.0.1), 00:02:03/00:00:56, flags: JT
Incoming interface: Ethernet0/0, RPF nbr 13.13.13.1
Outgoing interface list:
Ethernet0/2, Forward/Sparse, 00:02:03/00:02:50
The unicast and multicast topology is not currently congruent, this may or may not be important. What happens when R3 fails?
R3(config)#int e0/2 R3(config-if)#sh R3(config-if)#
No replies to the pings coming in until PIM on R2 detects that R3 is gone and takes over the DR role, this will take between 60 to 90 seconds with the default timers in use.
S1#ping 239.0.0.1 re 100 ti 1 Type escape sequence to abort. Sending 100, 100-byte ICMP Echos to 239.0.0.1, timeout is 1 seconds: Reply to request 0 from 10.0.0.10, 18 ms Reply to request 1 from 10.0.0.10, 2 ms.................................................................... ....... Reply to request 77 from 10.0.0.10, 10 ms Reply to request 78 from 10.0.0.10, 1 ms Reply to request 79 from 10.0.0.10, 1 ms Reply to request 80 from 10.0.0.10, 1 ms
We can increase the DR priority on R2 to make it become the DR.
R2(config-if)#ip pim dr-priority 50 *Feb 13 12:42:45.900: %PIM-5-DRCHG: DR change from neighbor 10.0.0.3 to 10.0.0.2 on interface Ethernet0/2
HSRP aware PIM is a feature that started appearing in IOS 15.3(1)T and makes the HSRP AR become the PIM DR. It will also send PIM messages from the virtual IP which is useful in situations where you have a router with a static route towards an Virtual IP (VIP). This is how Cisco describes the feature:
HSRP Aware PIM enables multicast traffic to be forwarded through the HSRP active router (AR), allowing PIM to leverage HSRP redundancy, avoid potential duplicate traffic, and enable failover, depending on the HSRP states in the device. The PIM designated router (DR) runs on the same gateway as the HSRP AR and maintains mroute states.
In my topology, I am running HSRP towards the clients, so even though this feature sounds as a perfect fit it will not help me in converging my multicast. Let’s configure this feature on R2:
R2(config-if)#ip pim redundancy HSRP1 hsrp dr-priority 100 R2(config-if)# *Feb 13 12:48:20.024: %PIM-5-DRCHG: DR change from neighbor 10.0.0.3 to 10.0.0.2 on interface Ethernet0/2
R2 is now the PIM DR, R3 will now see two PIM neighbors on interface E0/2:
R3#sh ip pim nei e0/2
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
10.0.0.1 Ethernet0/2 00:00:51/00:01:23 v2 0 / S P G
10.0.0.2 Ethernet0/2 00:07:24/00:01:23 v2 100/ DR S P G
R2 now has the (S,G) and we can see that it was the Assert winner because R3 was previously sending multicasts to the LAN segment.
R2#sh ip mroute 239.0.0.1
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,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.0.0.1), 00:20:31/stopped, RP 1.1.1.1, flags: SJC
Incoming interface: Ethernet0/0, RPF nbr 12.12.12.1
Outgoing interface list:
Ethernet0/2, Forward/Sparse, 00:16:21/00:02:35
(41.41.41.10, 239.0.0.1), 00:00:19/00:02:40, flags: JT
Incoming interface: Ethernet0/0, RPF nbr 12.12.12.1
Outgoing interface list:
Ethernet0/2, Forward/Sparse, 00:00:19/00:02:40, A
What happens when R2’s LAN interface goes down? Will R3 become the DR? And how fast will it converge?
R2(config)#int e0/2 R2(config-if)#sh
HSRP changes to active on R3 but the PIM DR role does not converge until the PIM query interval has expired (3x hellos).
*Feb 13 12:51:44.204: HSRP: Et0/2 Grp 1 Redundancy "hsrp-Et0/2-1" state Standby -> Active
R3#sh ip pim nei e0/2
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
10.0.0.1 Ethernet0/2 00:04:05/00:00:36 v2 0 / S P G
10.0.0.2 Ethernet0/2 00:10:39/00:00:36 v2 100/ DR S P G
R3#
*Feb 13 12:53:02.013: %PIM-5-NBRCHG: neighbor 10.0.0.2 DOWN on interface Ethernet0/2 DR
*Feb 13 12:53:02.013: %PIM-5-DRCHG: DR change from neighbor 10.0.0.2 to 10.0.0.3 on interface Ethernet0/2
*Feb 13 12:53:02.013: %PIM-5-NBRCHG: neighbor 10.0.0.1 DOWN on interface Ethernet0/2 non DR
We lose a lot of packets while waiting for PIM to converge:
S1#ping 239.0.0.1 re 100 time 1 Type escape sequence to abort. Sending 100, 100-byte ICMP Echos to 239.0.0.1, timeout is 1 seconds: Reply to request 0 from 10.0.0.10, 5 ms Reply to request 0 from 10.0.0.10, 14 ms................................................................... Reply to request 68 from 10.0.0.10, 10 ms Reply to request 69 from 10.0.0.10, 2 ms Reply to request 70 from 10.0.0.10, 1 ms
HSRP aware PIM didn’t really help us here… So when is it useful? If we use the following topology instead:
The router R5 has been added and the receiver sits between R5 instead. R5 does not run routing with R2 and R3, only static routes pointing at the RP and the multicast source:
R5(config)#ip route 1.1.1.1 255.255.255.255 10.0.0.1 R5(config)#ip route 41.41.41.0 255.255.255.0 10.0.0.1
Without HSRP aware PIM, the RPF check would fail because PIM would peer with the physical address but R5 sees three neighbors on the segment, where one is the VIP:
R5#sh ip pim nei
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
10.0.0.2 Ethernet0/0 00:03:00/00:01:41 v2 100/ DR S P G
10.0.0.1 Ethernet0/0 00:03:00/00:01:41 v2 0 / S P G
10.0.0.3 Ethernet0/0 00:03:00/00:01:41 v2 1 / S P G
R2 will be the one forwarding multicast during normal conditions due to it being the PIM DR via HSRP state of active router:
R2#sh ip mroute 239.0.0.1
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,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.0.0.1), 00:02:12/00:02:39, RP 1.1.1.1, flags: S
Incoming interface: Ethernet0/0, RPF nbr 12.12.12.1
Outgoing interface list:
Ethernet0/2, Forward/Sparse, 00:02:12/00:02:39
Let’s try a ping from the source:
S1#ping 239.0.0.1 re 3 Type escape sequence to abort. Sending 3, 100-byte ICMP Echos to 239.0.0.1, timeout is 2 seconds: Reply to request 0 from 20.0.0.10, 1 ms Reply to request 1 from 20.0.0.10, 2 ms Reply to request 2 from 20.0.0.10, 2 ms
The ping works and R2 has the (S,G):
R2#sh ip mroute 239.0.0.1
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,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.0.0.1), 00:04:18/00:03:29, RP 1.1.1.1, flags: S
Incoming interface: Ethernet0/0, RPF nbr 12.12.12.1
Outgoing interface list:
Ethernet0/2, Forward/Sparse, 00:04:18/00:03:29
(41.41.41.10, 239.0.0.1), 00:01:35/00:01:24, flags: T
Incoming interface: Ethernet0/0, RPF nbr 12.12.12.1
Outgoing interface list:
Ethernet0/2, Forward/Sparse, 00:01:35/00:03:29
What happens when R2 fails?
R2#conf t Enter configuration commands, one per line. End with CNTL/Z. R2(config)#int e0/2 R2(config-if)#sh R2(config-if)#
S1#ping 239.0.0.1 re 200 ti 1 Type escape sequence to abort. Sending 200, 100-byte ICMP Echos to 239.0.0.1, timeout is 1 seconds: Reply to request 0 from 20.0.0.10, 9 ms Reply to request 1 from 20.0.0.10, 2 ms Reply to request 1 from 20.0.0.10, 11 ms.................................................................... ...................................................................... ............................................................
The pings time out because when the PIM Join from R5 comes in, R3 does not realize that it should process the Join.
*Feb 13 13:20:13.236: PIM(0): Received v2 Join/Prune on Ethernet0/2 from 10.0.0.5, not to us *Feb 13 13:20:32.183: PIM(0): Generation ID changed from neighbor 10.0.0.2
As it turns out, the PIM redundancy command must be configured on the secondary router as well for it to process PIM Joins to the VIP.
R3(config-if)#ip pim redundancy HSRP1 hsrp dr-priority 10
After this has configured, the incoming Join will be processed. R3 triggers R5 to send a new Join because the GenID is set in the PIM hello to a new value.
*Feb 13 13:59:19.333: PIM(0): Matched redundancy group VIP 10.0.0.1 on Ethernet0/2 Active, processing the Join/Prune, to us
*Feb 13 13:40:34.043: PIM(0): Generation ID changed from neighbor 10.0.0.1
After configuring this, the PIM DR role converges as fast as HSRP allows. I’m using BFD in this scenario.
The key concept for understanding HSRP aware PIM here is that:
- Initially configuring PIM redundancy on the AR will make it the DR
- PIM redundancy must be configured on the secondary router as well, otherwise it will not process PIM Joins to the VIP
- The PIM DR role does not converge until PIM hellos have timed out, the secondary router will process the Joins though so the multicast will converge
This feature is not very well documented so I hope you have learned a bit from this post how this feature really works. This feature does not work when you have receiver on a HSRP LAN, because the DR role is NOT moved until PIM adjacency expires.
Tried this with a pair of CISCO router and found that PIM will not join property if the AR router do not configure with the PIM redundancy command. After several test, it is better to have both Active and Backup router configured with PIM redundancy. if not, PIM join will not send by Active Router once if failover back. Hope anyone can share their finding
Tried this with a pair of CISCO router in Active-Backup approach and found that Primary Router will not forward multicast property if the Primary router do not configure with the PIM redundancy command. After several test, it is better to have both Active and Backup router configured with PIM redundancy with different dr-prority. if not, I guess PIM join will not send by Primary Router once if failover back. Hope anyone can share their finding
With this configuration I was unable to get R5 in your topology to send the PIM joins to the RP when the receiver joined the group. After going round and round with the issue I found this article:
https://www.cisco.com/c/en/us/support/docs/ip/ip-multicast/13783-hsrpmcast.html
Seems the only way it worked was to set a static mroute with the VIP of the HSRP group as the next hop on the FHR. (ip mroute 0.0.0.0 0.0.0.0 10.0.0.1)
Did you do the same on your end for this example?