[c-nsp] Floating static routes, Etherchannel, and HSRP

Bruce Pinsky bep at whack.org
Wed Oct 11 18:01:09 EDT 2006


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Afsheen Bigdeli wrote:
> 
>> Ok, so as an example, your end of the connection might be 192.168.1.1 and
>> the ISP's would be 192.168.1.2 and you are using the .2 as the nexthop.
>> Correct?
> 
> 
> Yes, that's correct.
> 
>> The only time I'd expect to see the floating static in the table is if
>> reachability to the ISP nexthop address on switch 1 wasn't present. 
>> Since
>> you are pointing at an IP address of a route on a directly connected
>> interface, the only time the route would not be present is when that
>> interface is down.  So that being the case, are you testing this by
>> shutting down the interface that is connected to the ISP?
> 
> Nope. Both links are up at the moment.
> 

Then the floating static will not appear in the table.  The static route to
the ISP nexthop will have an admin distance of 1 and the static route to
the switch 2 IP address has an admin distance of 180.  1 trumps 180 and the
only time it will not be in the table is if the route to the ISP nexthop
goes away which is when the interface to the ISP goes down.

> 
>> A better solution here would probably be to put a default route on each
>> switch pointing to its respective ISP nexthop address and use the
>> "standby
>> track" feature to adjust the HSRP gateway address based on the status of
>> the ISP interface.  When the interface goes down, the HSRP priority would
>> be adjusted so that instead of switch1 being the default gateway,
>> switch 2
>> would become the default gateway.  Additionally, with Enhanced Object
>> tracking, you can even monitor the IP reachability over the ISP
>> connection
>> and make adjustments based on reachability in addition to interface
>> status.
> 
> 
> Heh, I'd actually just started doing that as a workaround... I'd still
> like to know _why_ floating static routes aren't working, but the track
> option gives me quite a bit more flexibility in terms of what actions I
> can take based on what criteria, etc., so I think I may stick with it.
> Now to test all of my failure scenarios again....
> 

Unless I'm missing something, my explanation above is why your floating
static is not working.

> (The maddening thing is that I have this same config in another
> environment, with the only differences being that the link to the second
> switch is in access mode, not a trunk, and it's a regular link, not an
> Etherchannel. I'm going to test those two points when I get a chance.)
> 

Maybe it doesn't really work either :-)

- --
=========
bep

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFLWmlE1XcgMgrtyYRArOzAKD9AN64LIwiunuDSACu/5TDdaNlogCfbCvJ
CkjKuliqtXudnpQt2jgHs4U=
=aaG6
-----END PGP SIGNATURE-----


More information about the cisco-nsp mailing list