Why Doesn't PIM Sparse Mode Work with a Static Route to an HSRP Address?

Introduction

This document explains why multicast packets are not forwarded when you configure a static route to the Hot Standby Router Protocol (HSRP) address of a Protocol Independent Multicast (PIM) sparse mode neighbor.

Prerequisites

Requirements

Readers of this document should have knowledge of these topics:

• HSRP

• PIM sparse mode

Components Used

This document is not restricted to specific software and hardware versions.

Conventions

For more information on document conventions, refer to Cisco Technical Tips Conventions.

Network Diagram

In the figure above, Routers 2 and 3 are talking HSRP on subnet 10.1.3.0, and Router 2 is the active router. Routers 1, 2, and 3 are talking Enhanced Interior Gateway Routing Protocol (EIGRP), and Router 4 has a static default route to the HSRP virtual address.

Configurations

Current configuration:

! 
ip multicast-routing 
! 
! 
interface Loopback0 
ip address 10.10.10.10 255.255.255.255 
no ip directed-broadcast 
! 
interface Ethernet0 
no ip address 
no ip directed-broadcast 
shutdown 
! 
interface Ethernet1 
ip address 10.1.1.1 255.255.255.0 
no ip directed-broadcast 
ip pim sparse-mode 
! 
interface Serial1 
no ip address 
no ip directed-broadcast 
encapsulation frame-relay 
! 
interface Serial1.1 point-to-point 
ip address 10.1.2.1 255.255.255.252 
no ip directed-broadcast 
ip pim sparse-mode 
frame-relay interface-dlci 612 
! 
! 
interface Serial1.2 point-to-point 
ip address 10.1.2.5 255.255.255.252 
no ip directed-broadcast 
ip pim sparse-mode 
frame-relay interface-dlci 613 
! 
router eigrp 1 
network 10.0.0.0 
no auto-summary 
! 
ip classless 
no ip http server 
ip pim rp-address 10.10.10.10 
! 

end

Current configuration:

! 
ip multicast-routing 
ip dvmrp route-limit 20000 
! 
! 
interface Ethernet1 
ip address 10.1.3.1 255.255.255.0 
no ip redirects 
ip pim sparse-mode 
standby 1 priority 110 preempt 
standby 1 ip 10.1.3.3 
! 
interface Serial1 
no ip address 
encapsulation frame-relay 
! 
interface Serial1.1 point-to-point 
ip address 10.1.2.2 255.255.255.252 
ip pim sparse-mode 
frame-relay interface-dlci 621 
! 
router eigrp 1 
network 10.0.0.0 
no auto-summary 
! 
ip classless 
ip pim rp-address 10.10.10.10 
!

end

Current configuration:

! 
ip multicast-routing 
ip dvmrp route-limit 20000 
! 
interface Ethernet1 
ip address 10.1.3.2 255.255.255.0 
no ip redirects 
ip pim sparse-mode 
standby 1 priority 100 preempt 
standby 1 ip 10.1.3.3 
! 
interface Serial1 
no ip address 
encapsulation frame-relay 
! 
interface Serial1.2 point-to-point 
ip address 10.1.2.6 255.255.255.252 
ip pim sparse-mode 
frame-relay interface-dlci 631 
! 
router eigrp 1 
network 10.0.0.0 
no auto-summary 
eigrp log-neighbor-changes 
! 
ip classless 
no ip http server 
ip pim rp-address 10.10.10.10 
!

end

Current configuration:

ip multicast-routing 
ip dvmrp route-limit 20000 
! 
! 
! 
interface Ethernet0 
ip address 10.1.4.1 255.255.255.0 
no ip directed-broadcast 
ip igmp join-group 239.1.2.3 
! 
interface Ethernet1 
ip address 10.1.3.4 255.255.255.0 
no ip directed-broadcast 
ip pim sparse-mode 
! 
no ip http server 
ip classless 
ip route 0.0.0.0 0.0.0.0 10.1.3.3 
ip pim rp-address 10.10.10.10 
!

end

In order to simulate a host on Ethernet 0, the ip igmp join-group command was configured on this interface on Router 4:

router4# ip igmp join-group 

IGMP Connected Group Membership 
Group Address Interface Uptime Expires Last Reporter 
224.0.1.40 Ethernet1 4d23h never 10.1.3.1 
239.1.2.3 Ethernet0 4d23h never 10.1.4.1 

Router 4 also can ping the rendezvous point (RP) address:

Type escape sequence to abort. 

Sending 5, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds: 
!!!!! 
Success rate is 100 percent (5/5), round-trip min/avg/max = 60/61/68 ms

Look at the multicast route (mroute) table:

Router4# show ip mroute 239.1.2.3 

IP Multicast Routing Table 

Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned 
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT 
X - Proxy Join Timer Running 

Timers: Uptime/Expires 
Interface state: Interface, Next-Hop or VCD, State/Mode 
(*, 239.1.2.3), 00:04:28/00:00:00, RP 10.10.10.10, flags: SJCL 
Incoming interface: Ethernet1, RPF nbr 10.1.3.3 
Outgoing interface list: 
Ethernet0, Forward/Sparse, 00:02:12/00:02:53 

Because there is a receiver for this group (due to the ip igmp join-group command used in Router 4), build a (*,G) entry in the mroute table. Note the Reverse Path Forwarding (RPF) neighbor for the (*,G) entry is 10.1.3.3, which is the HSRP standby address. However, there is not a (S,G) entry, which means traffic is not being received from the source.

Since Router 4 has an interested receiver for the group, it now should send a PIM Join/Prune message to its PIM neighbors. Use the show ip pim neighbor command to view Router 4's PIM neighbors, as seen below:

Router4# show ip pim neighbor 

PIM Neighbor Table 
Neighbor Address Interface Uptime Expires Ver Mode 
10.1.3.1 Ethernet1 4d23h 00:01:41 v2 
10.1.3.2 Ethernet1 4d23h 00:01:36 v2

If the debug ip pim 239.1.2.3 command is enabled, Router 4 is building this PIM Join/Prune message, but it does not actually send it:

*Mar 6 18:32:48: PIM: Received RP-Reachable on Ethernet1 from 10.10.10.10 *Mar 6 18:32:48: for group 239.1.2.3 *Mar 6 18:33:14: PIM: Building Join/Prune message for 239.1.2.3 *Mar 6 18:34:13: PIM: Building Join/Prune message for 239.1.2.3

Why is the router not sending the Join/Prune message? RFC 2362 states that "a router sends a periodic Join/Prune message to each distinct RPF neighbor associated with each (S,G), (*,G) and (*,*,RP) entry. Join/Prune messages are sent only if the RPF neighbor is a PIM neighbor."

In the example, the RPF neighbor is 10.1.3.3, which is the HSRP standby address used by the default static route. However, this address is not listed as a PIM neighbor. The reason the HSRP standby address is not listed as a PIM neighbor is because the two routers running HSRP (Routers 2 and 3) will not source the PIM neighbor messages from the HSRP standby address.

To solve the problem, change Router 4's configuration so the RPF neighbor is also a PIM neighbor. Do this by including Router 4 in the EIGRP process so that it now learns the RP address through EIGRP.

Note: Since Router 4 has the capability to run a routing protocol it should not have to rely on an HSRP standby address for connectivity. The development of HSRP was intended to offer a way for hosts to gain quick and efficient redundancy or fail-over.

Below is the new configuration of Router 4 with EIGRP enabled.

ip multicast-routing 
ip dvmrp route-limit 20000 
! 
! 
! 
interface Ethernet0 
ip address 10.1.4.1 255.255.255.0 
no ip directed-broadcast 
ip igmp join-group 239.1.2.3 
! 
interface Ethernet1 
ip address 10.1.3.4 255.255.255.0 
no ip directed-broadcast 
ip pim sparse-mode 
!
router eigrp 1
network 10.0.0.0
no auto-summary
! 
no ip http server 
ip classless 
ip route 0.0.0.0 0.0.0.0 10.1.3.3 
ip pim rp-address 10.10.10.10 
!
end 

Note: Instead of including Router 4 in the EIGRP process (the preferred method), add static mroutes to Router 4 to make it RPF to the real routers' IP addresses because mroutes are preferred over the unicast routing table in RPF checks. For example, add ip mroute 0.0.0.0 0.0.0.0 10.1.3.2.

Related Information

• HSRP Support Page
• IP Routed Protocols Support Page
• Technical Support - Cisco Systems