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

Bruce Pinsky bep at whack.org
Wed Oct 11 17:45:24 EDT 2006


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

Afsheen Bigdeli wrote:
> 
> Bruce Pinsky wrote:
> 
>>
>> What is IP address of "my.next.hop.address"?  Is it reachable via another
>> interface on switch 1?
> 
> The IP address is that of my ISP's next hop. It's reachable on a
> completely different interface. I mentioned it in passing to show that I
> had a default route already, and that I was adding a second default
> route with a higher administrative distance, pointing to an interface on
> the other side of the Etherchannel instead of my ISP's next hop.
> 
> 

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?

>> Does switch 1 have a route to
>> "next.hop.on.other.side.of.etherchannel"?  If
>> not how do you expect it to be reachable?
> 
> 
> As I said earlier, 10.10.10.3 is the address of the second HSRP
> interface (VLAN 999 as per my previous email), on the other side of the
> switch stack. It is reachable - I can ping and traceroute to and from
> 10.10.10.3 without issue, and VLAN999 is shown as being directly
> connected in the output of "show ip route" on both stacks. I'd _expect_
> it to be reachable because it's directly connected; I have an interface
> in VLAN999 on stack 1, likewise on stack 2, and an Etherchannel between
> them, configured as a dot1q trunk (with VLAN999 allowed across it).
> 
> 

Ok, the terminology you used was kinda ambiguous.  It wasn't clear if you
are pointing to the ISP nexthop address reachable vis switch 2 or an
address on switch 2 itself.

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?

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.

http://www.cisco.com/en/US/products/ps6566/products_feature_guide09186a008063c9bf.html

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

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

iD8DBQFFLWX0E1XcgMgrtyYRAmaFAJwKLSsADY1grGHG4L0AqR9/MzwylQCgrjY/
xyJcqjVT/FMErofO9b/HNtU=
=akah
-----END PGP SIGNATURE-----


More information about the cisco-nsp mailing list