IP route issue with K 12.02?

[Jim Ruzauskas]

We have one of our 5406zl switches setup to handle routing on our LAN. One evening last week I upgraded it from K 11.33 to K 12.02, everything seemed to go well (I made no changes to the config). The switch's IP is 10.1.0.10.

We have a static route for 192.168.1.0/24 to go to 10.1.0.16, which happens to be a point-to-point T1 router. Ever since the upgrade we are having intermittent issues in being able to talk to 192.168.1.x. It will work fine for a while and suddenly stop working. A little while later it will come back online. We've done our due-diligence in troubleshooting the router and T1, everything appears to be Ok there.

Now for the really weird part. When the connection to 192.168.1.x dies, I then go on the router and ping something in that range and it is immediately back up! Is there some new feature of K 12.02 that could be causing this? Like I said, no config changes have been made. :(

[Mohieddin Kharnoub]

Hi

If you have any doubts to the new firmware version, try to boot to the secondary flash image (if you have K.11.33 saved on it) and check it.

If every thing if fine, then you can open a case with HP.

It sounds to me a Dial on Demand Routing that you have on the router, so when you initiate a ping you may not few replies until the route is ready.

Good Luck !!!

[Jim Ruzauskas]

Dial-on-demand is an interesting idea. I know its not enabled in the config, but it would fall in line with what I'm experiencing.

I did end up opening a case last night. I also set up a monitor session with Wireshark, we'll see if that turns up anything else...

Thanks!
Jim

[Roy CLMCO]

I've just recently installed a 5406zl as well. Firmware is K12.02. I've experienced a similar problem with the default/static route "disappearing" for a while and then "coming back".

Was there a defined resolution identified for Jim's problem/question?

[Jim Ruzauskas]

They've asked me to clear the arp table while running the latest firmware to see if this fixes the issue. Unfortunately I have still not had a chance to try it. In the meantime I set up a work-around by setting up that route on the LAN interface of our firewall.

Hopefully I will get back to it this week - but I'd be curious if you have any luck clearing the arp table. Also try rebooting the switch to see if the fix "sticks".

Jim Ruzauskas

[maik witt]

Hello i think i have the same problem.

The 5406zl router is in ouer backbone. I have build some vlans and routing is enable on the switch. In one vlan i have client pc and the interface of the provider router. When a client make a connection to the Internet, the first hop is the 5406 Switch. The 5406 have a default route to the internet over the interface of the provider router.

The configuration works very fine, but after some hours, no connect are possible over the 5406 to the provider.

A workaround is a telnet session to the 5406 an from the Switch a ping to the provider net. After this, the connection to the provider net works.

By the way, the connection fails the hole night. so it is not possible to transfer mails from the provider network to the local mail server. BAD Thing

A new Firmware (K12.07) doesn´t fix the problem. So, the only way is to make a ticket by HP and hope of an new firmware.

Had somebody an older firmware that will be work ?

[Paulen]

I'd say that HP stick to L2 devices. Think I haven't seen one L3 gadget from HP without quite severe L3 problems.

[Jim Ruzauskas]

maik witt - versions prior to K 12.x did not have this problem for me. I think you can get them by using an FTP client with the download link and "browsing" around on the FTP server.

Paulen - not sure what your opinion has to do with this bug?

[Paulen]

Jim, isn't that quite obvious? You'd expect more from somewhat 'mature' images - and at least that simple routing should work.

I have worked with a lot of L3 devices. The bottom line is that I'd never trust a HP switch to do the routing for me. There are not enough debugging features, and too many spooky failures.

If there was a way to debug the traffic properly (not talking about 3rd party sniffers), you might find the cause of the problem.

Of course - this is my personal opinion :-)

[Matt Hobbs]

Jim,

Since you can see the issue quite easily and can also fix the issue quite easily by pinging the provider network - you're in the perfect position to get the information HP needs to resolve this.

When the problem occurs capture the 'show tech all' via tftp.

After you have corrected it by pinging the provider, capture another 'show tech all'.

HP should be able to compare the two files (I use ExamDiff to highlight the differences in the files) and hopefully be able to see the difference between the working and not working situations.

Matt