N4000 network connection

[Tim Jaster]

We have four servers connected to a switch (two N4000s, one L2000 and one L3000). Something happened with the switch and all the servers lost connection to it. The two Ls were fine once they regained connection to the switch. The Ns did not reconnect. lanscan showed the lan cards were is an up state. I could ping the IPs and the loopback on the Ns but could not reach any other device on the network. I tried to reset the lan cards by using lanadmin and tried to configure the cards using ifconfig. Is there a known issue with the Ns that does not exist with the Ls? I finally gave up and had to reboot. Then, everything was fine. Any help or advice is greatly appreciated.

[James R. Ferguson]

Hi:

I've had similar problems with 100BT LAN cards on a K-series. Make sure that you don't have auto-negotiation on for the card. Instead, configure your switch *and* your card for the setting you want (e.g. 100MB, full-duplex, no auto-negotiation).

You can also attempt to recover (without a reboot) with:

# ifconfig lanX up

Regards!

...JRF...

[Ron Kinner]

Did you check that the speed and duplex settings matched those of the switch?

Could be a failure of auto-negotiate. Make sure they are locked to 100 Full on both ends.

Pinging the box's ip address or its loopback does not test the connection. The box cheats and does not send the message out. To test the connection use:

linkloop -v macaddressofswitchport

The -v gives you any error messages that the thing experiences during the test.

Also make sure you have the correct and most current config files:

http://techsolutions.hp.com/fe/configs.html#config_files

Also if you are running 11.0 or higher you may want to turn off dead gateway detection.

Ron

[harry d brown jr]

Are the L's and N's close in patches and firmware updates?

Do they all use the same type of lan cards?

what kind of switch? Autonegotiation turned on or off??

What did the switch show? Could the switch communicate to the N's??

live free or die
harry

[Tim Jaster]

Sorry it has taken so long to answer the questions.
The switch and the lan cards are set up the same (100, Full and auto OFF).
The switch is a Cisco Catalyst 3500XL.
We are using the Core IO lan card in the Ns and on one of the Ls. I used xstm to get the Revision ID (is this the firmware version?) and they are all identical. They are at the same patch level. We review the patch level monthly. The config files are identical. I am not in control of the switch and therefore cannot check out any log messages. I was told all the switch logged was that it did reboot and it came back up. Do you know of anything else I can check. I'll still research the issue and see if I can come up with anything. Thanks for your help so far.

[harry d brown jr]

Gretchen,

have them ping the host from the switch and have them check their switch. I know network people hate it when you blame their equipment, but that's life.

live free or die
harry

[rick jones]

Indeed, if the switch powercycled, any settings that were not saved (such as hard-coded duplex settings) would have been lost (much like setting duplex under UX with just the lanadmin command and not editing the config file. so the switch would have merrily rebooted and set things to their prior values for those ports (probably auto or half) and poof, a duplex mismatch. Yet another reason why I don't like hardcoding unless I _know_ there is a _real_ autoneg incompatability between the NIC and the switch.

However, a duplex mismatch would not result in a complete loss of connectivity - even full against half will still have a simple ping command work, just perhaps not very well.

If the switch were down "long enough" and dead gateway detection were on (ip_ire_gw_probe) perhaps the N's marked their routes as dead and they didn't get marked as up when the links came back. You might compare the /etc/rc.config.d/nddconf files between the L's and N's and triple check they are all running the same settings and patch revs.

[Ron Kinner]

Thanks for the points but since I don't see a bunny can I assume that you still have the problem?

Assuming the switch and the servers are at the same speed (which would keep them from talking) the next thing would be a VLAN mismatch. Perhaps the switch guy made changes to the VLAN and didn't save them.

I'd try connecting up the N to the L's network cable just to see if the N can talk with the L's cable. Then if it can you can be sure it's the switch.

Ron