Identical routes, different metrics

[Rafael Nunes]

Hi.

I have a HP-UX 11 server working as a firewall and it has 3 lan cards connected in 3 differents nets.
I can reach one destination network through two differents paths, i.e:

Result of the netstat -rnv (the interesting piece):

131.1.1.0/255.255.255.0
172.1.1.1 UG 0 0 lan1 1500
131.1.1.0/255.255.255.0
192.1.1.1 UG 0 0 lan0 1500

The first route has metric 5
The second one has metric 1

OK, when I disconnect de ethernet cable from the gateway 192.1.1.1, all the traffic to that network (131.1.1.0) flow throug my lan1, but when I reconnect the cable, the traffic is still over my lan1.

Should the traffic turns to the route with lower metric? If yes, what could be wrong?

Thanks in advance and sorry about my poor english...

Rafael.

[harry d brown jr]

Rafael,

Your english is fine!

Tell me, how are the two different routers, 172.1.1.1 and 192.1.1.1, getting traffic back to the originators, say if 172.1.1.1 is inaccessable?

Are you "pinning" traffic to a gateway?

live free or die
harry

[Rafael Nunes]

No, the originators can reach the destination through the firewall (HP-UX) that forward packets to 172.1.1.1.
But when the 192.1.1.1 is alive again, the packets are forward through him only if I delete de route that points to 172.1.1.1.
I would like that this changes were automatically...

[Duncan Edmonstone]

I have to say I don't know the answer to this one, but I'd like to know...

If I theorise with my (v. sketchy) knowldege of routing here's what I think is happening...

1. The first route has the lower metric, so is always used in pereference to the second...

2. The first router fails, so that route has its route metric increased (or the route is deleted???)

3. Al traffic is now routed through the second router.

4. The first router comes back online, but there's nothing to tell the HP server that this has occurred... If they were both on the same network the second router might start sending out ICMP redirects to send traffic back to the first router, but they're not... If the server itself were a router it would recieve router updates (such as RIP broadcasts/multicasts) which would tell it to start using the route again.

But I don't think there's anything in the standard router alogorithm which checks if routers come back up if there is an alternative route - I know I have had issues where I had two default gateways defined - when the first gateway failed traffic moved to the second, but to get traffic to go back to the first I had to delete the second gateway and then recreate it.

SO....

I'd consider running gated in a passive mode where the server listens for RIP broadcasts and updates its router table accordingly - but be careful how you set up gated, or you could end up routing yourself - definately something to try out in your sanbox first if you have one.

Of course I could me way off the mark with this anyway... I'd be happy for someone to put me straight.

HTH

Duncan

[Jeff Schussele]

Hi Rafael,

I suspect you'll have to setup the routers & your host for Router Discovery Protocol (RDP).
This protocol allows routers to "announce" their availibilty for certain routes.
This will involve changes to your gated.conf & possibly to the routers themselves.

See the following URL for further info:

http://www.docs.hp.com/cgi-bin/fsearch/framedisplay?top=/hpux/onlinedocs/B2355-90147/B2355-90147_top.html&con=/hpux/onlinedocs/B2355-90147/00/00/65-con.html&toc=/hpux/onlinedocs/B2355-90147/00/00/65-toc.html&searchterms=gated&queryid=20020422-134857

HTH,
Jeff

[Ron Kinner]

I think it depends on your arp cache timeout. Once a connection is established the arp used for the IP address of the destination is stored in the arp table. As long as the route is still good and there is traffic over the route the arp will stay in the table. If traffic stops, after a while, the arp entry will timeout and then when it needs to talk to that same IP address it will send the an arp request out the best path.

Try your disconnect of the 0 metric link. Do a traceroute to a distant destination to verify that the new route is being used. Now reconnect and repeat the traceroute to show that it still uses the backup route. Now do
arp -c
which should clear the arp table and try the traceroute again. I suspect it will now go the 0 metric route.

ndd has a setting: arp_cleanup_interval
which sets the timeout period which defaults to 300000 msec or 5 minutes. If no traffic passes through for five minutes then it should drop the entry from the arp cache and the next time it should try to use the better route.

Ron

[Craig Gilmore]

As I understand the question, you are wondering why the 172 router is used for traffic rather than the 192 router. You have disabled and then enabled the 192 router. Why did the routing table not switch back.

There are a couple of issues left unsaid. I'm guessing that rip is being used between the routers instead of ospf. I am also guessing that the system is not using any type of dynamic routing, and the metrics are set at the router level instead of at the system level.

I don't believe that arp or the arp cache would come into play here as the IP level knows that the system is not connected to the 131 network. Just the system routing table would be used.

Since I don't know the exact way this was tested, I would have to guess that dead gateway detection has been invoked, and the 192 router has been marked dead. Once a gateway is marked dead, I don't believe that there is any checking in the network stack to verify if the gateway is still down.

A better check of the routing tables is in order. Instead of netstat use:

ndd /dev/ip -g ip_ire_hash

This should display the ip routing table in memory, with the bottom of the list reporting dead gateways.

If there is an entry in the dead list for the 192 router, a route delete/add should throw the traffic back to the 192 router.

If you are looking for an automatic update of the routing table, you would need to look at gated.

Regards,