cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
364
Views
0
Helpful
14
Replies

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 0.0.0.0 0.0.0.0 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 192.168.1.2 255.255.255.0
 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 192.168.1.1
 standby 1 priority 105
 standby 1 preempt
 standby 1 authentication pa55word
 standby 1 track 1 decrement 50

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

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

router#sh ip route 2.2.2.2
Routing entry for 2.2.2.0/24
  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. :)

Everyone's tags (2)
14 REPLIES 14
Highlighted
Advisor

You are missing the actual

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 

Highlighted

Well I already have:

Well I already have:

 track 1 ip route 0.0.0.0 0.0.0.0 reachability

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

Highlighted
Advisor

You missed that critical bit

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?

Highlighted

Ideally, it would be if the

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

Highlighted
Advisor

Because the 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 
Highlighted

track 2 ip route 0.0.0.0/0

track 2 ip route 0.0.0.0/0 metric threshold shows the following:

router#sh track 2
Track 2
  IP route 0.0.0.0 0.0.0.0 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.

Highlighted
Advisor

Can you give me the output of

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

Highlighted

router#sh bgp ipv4 unicast 0

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

I believe it could be related to this bug:

http://www.gossamer-threads.com/lists/cisco/nsp/116278

Highlighted
Advisor

What device do you have and

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

Highlighted

router#sh verCisco IOS

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.

Highlighted
Advisor

Hmm, no gold star releases

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

Highlighted

Out of curiosity,

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.

Highlighted
Advisor

This may work as well.  Give

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 0.0.0.0/0 metric threshold 
Highlighted
Advisor

I think I can see what is

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.

CreatePlease to create content
Content for Community-Ad