Showing results for 
Search instead for 
Did you mean: 

HSRP states that "First-hop interface is unknown" ... when it is known....

Hi all,

I have the following HSRP setup (IPs changed for privacy):

router#sh track 1
Track 1
  IP route reachability
  Reachability is Down (BGP)
    1 change, last change 00:00:10
  First-hop interface is unknown
  Tracked by:
    HSRP GigabitEthernet0/2 1

interface GigabitEthernet0/2
 encapsulation dot1Q 2
 ip address
 no ip redirects
 no ip proxy-arp
 ip flow ingress
 ip pim sparse-mode
 ip igmp helper-address udl GigabitEthernet0/2
 ip igmp version 3
 standby version 2
 standby 1 ip
 standby 1 priority 105
 standby 1 preempt
 standby 1 authentication pa55word
 standby 1 track 1 decrement 50

router#sh ip route
Routing entry for, supernet
  Known via "bgp 123", distance 200, metric 0, candidate default path, type internal
  Last update from 7w0d ago
  Routing Descriptor Blocks:
  *, from, 7w0d ago
      Route metric is 0, traffic share count is 1
      AS Hops 0

router#sh ip route
Routing entry for
  Known via "isis", distance 115, metric 300
  Tag 123, type level-2
  Redistributing via isis
  Last update from on GigabitEthernet0/1, 7w0d ago
  Routing Descriptor Blocks:
  *, from, via GigabitEthernet0/1
      Route metric is 300, traffic share count is 1
      Route tag 123

router#sh ip route
Routing entry for
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via GigabitEthernet0/1
      Route metric is 0, traffic share count is 1

From what I can tell, the HSRP is tracking the default router, which it has, but the next hop interface also appears to be reachable.

There are no logs on the router (or accounting) of anything (or anyone) changing (config or the environment). I have checked the HSRP pair too. So can anyone advise why it is showing as down due to First-hop unreachable?

Thanks in advance. :)


You are missing the actual track command itself, which tells the router what you are tracking.

So either, remove "standby track 1 decrement 50", or add something like:

track 1 interface gigabitEthernet 0/2 ip routing 


Well I already have:

 track 1 ip route reachability

Is that you are talking about? Or will I need to add the specific command you mention above?


You missed that critical bit out.

Lets approach this from a different angle.  Under what circumstances do you want HSRP to go into standby (aka down) mode?


Ideally, it would be if the BGP session fails and the router loses its default route.


Because the default route seems to be coming in via Gigabit0/1 a simple fix might be:

track 1 interface gigabitEthernet 0/1 ip routing 

track 2 ip route metric threshold shows the following:

router#sh track 2
Track 2
  IP route metric threshold
  Metric threshold is Down (BGP/0/255)
    1 change, last change 00:00:21
  Metric threshold down 255 up 254
  First-hop interface is unknown

whereas track 3 interface gigabitEthernet 0/1 ip routing shows the following:

router#sh track 3
Track 3
  Interface GigabitEthernet0/1 ip routing
  IP routing is Up
    1 change, last change 00:00:17

So it looks like the IP routing on the interface is working fine. However the BGP default is not.


Can you give me the output of "show ip bgp" please.


router#sh bgp ipv4 unicast
BGP routing table entry for, version 2269803
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Local, (received & used) (metric 300) from (
      Origin IGP, localpref 100, valid, internal, best

I believe it could be related to this bug:


What device do you have and what software version are you running?


router#sh ver
Cisco IOS Software, 7200 Software (C7200-ADVIPSERVICESK9-M), Version 12.2(33)SRC5, RELEASE SOFTWARE (fc2)

Would not have suggested it otherwise :)

I will upgrade it and advise.


Hmm, no gold star releases for the 7200 platform that I can see, but that software release is pretty old.


Out of curiosity,

...if track 1 was also applied to an interface that was in a VRF, would that make a difference? My understanding was that the tracker is independent of where it is applied.


This may work as well.  Give it a try.  It is looking only at the route metric.  When the entire route is gone, the metric should also be gone.

track 1 ip route metric threshold 

I think I can see what is happening.  The default route is in BGP, but the next hop is in ISIS.

BGP is saying it does not know about the next hop.

Hence the track condition is declared dead.

Content for Community-Ad