Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a 4000 series in production with two physical NICs and a group IP.
I have a 6000 series in a DR site with four physical NICs and a group IP.

4000 series NIC1: 10.0.12.2
4000 series NIC2: 10.0.12.4
4000 series Group IP: 10.0.12.3

6000 series NIC1: 10.10.12.5
6000 series NIC2: 10.10.12.6
6000 series NIC3: 10.10.12.8
6000 series NIC4: 10.10.12.9
6000 series Group IP: 10.10.12.7

All the physical NICs on both SANs can ping each other, back and forth without issue.
The 4000 series group IP can ping everything, back and forth without issue.
However, the 6000 series group IP cannot ping the physical NICs on the 4000. It can, however, ping the group IP of the 4000.

Other devices, such as workstations and servers, can ping everything on both sides, physical NICs and both group IPs. It's only the SANs themselves that are having the issue.

When I do a traceroute originating from the 6000 series group IP, destined to the 4000 series physical NICs, I can see it jump from DR switch to DR router, to Primary router, to Primary switch, then it times out.

When I do a traceroute the other way, originating from the 4000 series physical NICs, destined to the 6000 group IP, it times out immediately without making a single hop.

Any ideas or suggestions?

share|improve this question
1  
How is your NLB configured on your switches and/or router ? is it multicast or unicast ? It would be my first port of call, also if you do a route print on the 4000 does it have a route to the 6000 ? Also is there a reason the packet jumps through both your DR and primary switch ? –  user1339378 Nov 20 '12 at 0:03
    
Try disabling each NIC on the 4000, then re-enabling them, one at a time. The EQL firmware before 5.2.4 NEVER and I mean EVER re-arp... stands a good chance that one of them has a bad or invalid arp cache for their default gateway. –  SpacemanSpiff Nov 20 '12 at 0:52
    
Incomplete ARP tables seems to be my best guess at time time as well.<P>I'm currently waiting on a response from Dell to see the best method for refreshing the ARP tables without downtime - disable, re-enable one NIC at at a time, or failover to the standby controller, perhaps... –  DavanW Nov 20 '12 at 15:58
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.