PIM Hellos

Load base.ipv4.and.ipv6.cfg

#IOS-XE
config replace flash:base.ipv4.and.ipv6.cfg

#IOS-XR
configure
load bootflash:base.ipv4.and.ipv6.cfg
commit replace

Configure PIM on R5, R6 and XR1 as follows:

  • Use a hello timer of .333/1 on R5 and R6

  • Use a hello timer of 1/3 on XR1

Enable PIM on the following interfaces:

  • R5-R6

  • R6-XR1

Will all adjacencies come up?

Answer

#R5
int gi1.56
 ip pim sparse-mode
 ip pim query-interval 333 msec

#R6
int gi1.56
 ip pim sparse-mode
 ip pim query-interval 333 msec
!
int gi1.619
 ip pim sparse-mode
 ip pim query-interval 333 msec

#XR1
multicast-routing
 address-family ipv4
  interface GigabitEthernet0/0/0/0.619
   enable
!
router pim
 address-family ipv4
  interface GigabitEthernet0/0/0/0.619
   hello-interval 1

Explanation

PIM Hellos are quite simple. The hold time is always 3.5 times the hello-interval. This cannot be changed. The hold time must be a whole number, and appears to be rounded down. (A hold time of 3.5 seconds is rounded down and signaled as 3 seconds).

The PIM hold time can mismatch between neighbors. PIM Hellos also do not have a 2-way adjacency check which almost every other protocol does, making them quite basic.

On IOS-XE, we have the ability to set a subsecond Hello interval. Similar to OSPF and ISIS, the minimum hold time we can send in the Hello is always 1 second. The command on IOS-XE to set the PIM hello interval is, unintuitavely, ip pim query-interval. If we want to send subsecond Hellos but use a hold time higher than 1 second, we can specify this using neighbor-holdtime.

! This sets the hello-interval to 333msec but the hold time to 2 seconds

ip pim query-interval 333 msec neighbor-holdtime 2

Between R5 and R6, they send hellos at 333msec intervals. The hold time they advertise to each other is 1 second. We can see the hold time never reaches below 666 msec.

Between R6 and XR1, their hold times mismatch, but this is not an issue. OSPF is one of the only protocols which requires the timers to match and also does not negotiate the timers. (BGP requires matching timers but negotiates the value).

Interestingly, on XR1, the “expires” field always says “now” for R6, I assume because the time is always some value less than 1 second.

On R6, we can see that XR2 has a hold time of 3 seconds, which never falls below 2 seconds.

Above, we see that R5’s holdtime is apparently 19 minutes which doesn’t make sense. It might be due to the fact that we are not really setting the hello-interval on IOS-XE, but instead the query-interval. In PIMv1, the Query was used to discover neighbors, but in PIMv2 the Hello is used to discover neighbors. Still, it should work correctly. Maybe this is a bug on IOS-XE when you use a sub-second Hello.

If I change R5 to a more sane interval, such as 5 seconds, now R6 properly uses a hold time of 16 seconds.

Summary

At this point we have explored the Hello intervals for the major protocols. OSPF requires values to always match. ISIS and PIM do not require values to match - instead the hold time is reported, allowing for asymmetric intervals between neighbors. BGP negotiates the hold time and sets keepalive to 1/3 the hold time value.

On IOS-XE, for OSPF, ISIS and PIM we can set subsecond intervals. This is not recommend because it is too CPU intensive. On IOS-XR, we can never set subsecond intervals. Instead, it is understood that you would use BFD instead. BFD is both lighter-weight than Hello protocols and allows you to achieve much faster failure detection (subsecond). We’ll explore how to configure and use BFD next.

Last updated