Switches, Hubs, and Modems
1752661 Members
6006 Online
108788 Solutions
New Discussion юеВ

5400 2nd IP Route with distance is not working

 
koppendorfer
Occasional Advisor

5400 2nd IP Route with distance is not working

i have configured serveral 5400 with
ip route 0.0.0.0 0.0.0.0 10.150.152.1
ip route 0.0.0.0 0.0.0.0 10.150.152.2 distance 100

for switching to .2 if .1 is down
this config will not work
the 5400 never switches to 2nd route when 1st is down

any ideas ??
2 REPLIES 2
Matt Hobbs
Honored Contributor

Re: 5400 2nd IP Route with distance is not working

Probably best to use a dynamic routing protocol for this, RIP or OSPF.

If you must use static routes, then I think you'll need to put these default routes into different VLANs and each of these VLANs can only have one port each as the member.

The reason behind this, is that the whole VLAN itself must go down, and for this to happen the port has to go down.

Once the VLAN is down, it will choose the second best route based on the distance you've set.
Andr├й Beck
Honored Contributor

Re: 5400 2nd IP Route with distance is not working

Hi,

> ip route 0.0.0.0 0.0.0.0 10.150.152.1
> ip route 0.0.0.0 0.0.0.0 10.150.152.2 distance 100

I'll assume 10.150.152.1 and 10.150.152.2 are in the same direct connected broadcast domain.

> this config will not work

Well, it does work - to the extent it makes sense, which isn't much ;)

> for switching to .2 if .1 is down

The only reason for a typical router to consider .1 down is the connected route that leads to .1 going down, by loss of the L3 interface, here an SVI (meaning the VLAN into which that SVI is anchored loses link on the last member port). But when this happens, it makes .2 unreachable as well.

What you actually *want* is nothing classic floating static routes can achieve except with individual connected routes like Matt already described. Even then, you will not sense loss of a peer when that loss doesn't down your SVI, which is a typical problem in switched networks: Link to the next L2 hop (switch) stays up, while somewhere else in the broadcast domain, the destination L3 hop becomes unavailable. Black hole.

There are a number of more or less complicated ways to deal with this (ARP tracking, CDP/LLDP tracking, ICMP tracking, tracked floating static routes, BDF) but I'm not aware the yl/zl software implements any of these. Thus, to really solve this problem, do as Matt proposed: cleanly design your L3 network (loopbacks, transit nets, etc) and use dynamic routing. Running a proper IGP on the 5400zl requires the premium license, though.

HTH,
Andre.