Server/Network Guru's

[KDF]

Here is a strange one for you.

Server 1 - Primary Domain Controller (192.168.1.1/24)
Server 2 - Centralised File server (192.168.1.2/24)

Server 1 can NOT ping server 2, server 2 CAN ping server 1.

Every other server and workstation can ping both servers. There are no firewalls running, and there is a single layer 2 switch between server 1 and server 2.

Server 1 arp table is correctly populated with a dynamic entry when pinged by server 2. Server 2 arp is not populated when pinging server 1.

All servers and workstations are on the same subnet. I have connected the second NIC on server and server 2 via a crossover cable, put them on a 192.168.5.0/24 subnet and they ping each other fine....Any ideas ?

 

[Marv-C]

Sounds like a simple question but are you pinging server 2 by name or IP address?

 

[KDF]

Both.

Done a wireshark packet capture on server 2. It definitely receives icmp packets from server 1 but doesn't seem to send a reply :S

Source MAC and dest MAC are correct in the ICMP packets. :S :S

 

[KDF]

More info after I ran packet sniffer on Server 1

when pinging server 2 from server 1 the ICMP packets are going out the interface with a checksum of 0x0000 which is totally wrong it's like it is not generating an checksum for the outgoing packets ?? but only for that IP ?? wtf ?

 

[DMS]

Are you 100% sure there's no additional configuration on the switch that could be affecting it? Sounds very dodgy that, it's simply not normal behaviour.

Tried a different switch port? An obvious suggestion I guess.

Also, I know it sounds pointless since all other workstations can ping the server fine, but have you tried resetting the TCP/IP stack? ("netsh int ip reset", then reboot) I've seen a lot of weird TCP/IP behaviour solved by doing this in the past.

 

[KDF]

Aha.. tracked down the problem !

Header checksum problem was due to TCP offload engine on server NIC;s due to ISCSI traffic.. false alert really.

A Virtual VMWare adaptor on server 2 gave itself a private internal ip of 192.168.1.1 by default and there is no way to see this through normal channels.. awesome bit of programming that.

So internally when sending traffic to that IP it didn't even leave the NIC !! hence no visible echo replies. Grrr ! Checking the IP routes pointed me in the right direction should anyone else come across this issue. So you were sorta right when pointing to the TCP stack as it had been modified by VMWare.

Thanks for chipping in to help though DMS.

 

[DMS]

NP

 

[Longy]

I installed two new Dell Poweredge servers last week for 30 users and 30 IP Phones. Setup DHCP all nice with reservations etc. However 1 phone kept getting an IP conflict! 192.168.0.120/24 I disconnected the phone and pinged the 192.168.0.120 and got a response!! God knows what device this was.

Anyway I got the mac address from the arp table. I then pinged it again and got a different mac address! s**t thats at least two devices with the same IP somewhere!!! Mangaged to trace it back to the servers. I couldn't see any virtual IP's on the server using that address (no load balance active)- so I rebooted one server and would you believe the DELL has a virtual IP on the NIC that you can only see in the bios!!! hence both servers had 192.168.0.120 on the NIC port. It's like a virtual ILO port.

 

[KDF]

That will be the drac controller.. but those at least have a dedicated nic on the back. Nightmare to track things like that down though !

 

[Longy]

You'd think it would show up in the OpenManager but it doesn't.