|
Red Hat Network Ping issue
i have a local network of 6 linux machines running redhat linux 4.4. i attached a new machine with that lan and configured it for networking.my machine is x7.x.com(192.168.1.7). it can ping all other machines (192.168.1.1 to 6) and all other machines can ping back to this but it can't ping srv.x.com(192.168.1.254) which is gateway for all) and srv(192.168.1.254) can't ping it back while others can ping with srv and srv can ping back, i have rechecked /etc/hosts and other networking files but all the enteries are correct.
how can i rectify this issu |
going by the working and non-working IP's I'd guess that your netmask is wrong, a /25 instead of a /24?
|
i dont think netmask is wrong or ip is not working. i am new to linux and networking plz explain your answer. plz note that the machine im talking about was working correctly with the same hostname and ipaddress on this network(im new to this network too), due to some reasons i reinstalled red hat 4.4 and tried to connect it to the network
|
nasim:
just recheck subnetmask if it is uniform between the server and the new machine. reload dhcp if it is running or disable from all. ping again. if still it doesn't work, try check the cables and the hub, swap the outlet to one that is ping-ing correctly. hope this can help. |
rechecked subnet, its same, no dhcp, all are the static ips within this LAN, rechecked everything but no ping to (192.168.1.254 gateway) while all others can ping x.x.x.7 and x.x.x.7 can ping back to others on this LAN.even i am able to mount remote disks on x.x.x.7 but can't ping x.x.x.254 and vice versa. i have noticed a service ldap running on other clients and server but not on x.x.x7. could it be the reason??? or any other services i need to check
|
// The only thing I can suggest is that if you know something is different then by all means do check / enable it and if you have to compare all configs between two machines. Saying "can't ping" doesn't say much. Instead post complete stdout/stderr and if that doesn't show any messages run a strace on it.
|
ping result to 192.168.1.254
xxxxxxx (xxxx) icmp_seq=1 Destination Host Unreachable so on 6 packets transmitted, 0 received, +3 errors, 100% packet loss, time 5001ms, pipe 4 pinging result to 192.168.1.3 64 bytes from xxxxxxxx(xxxxxx) icmp_seq=0 ttl=64 time=0.057 ms so on 7 packets transmitted, 7 received, 0% packet loss, time 5999ms, rtt min/avg/max/mdev=0.047/0.050/0.057/0.008 ms, pipe 2 |
that's clearly not the *COMPLETE* message now is it?
Post full output of ifconfig, route -n, and arp -n |
output from this problematic machine
route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1 0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0 eth1 arp -n Address HWtype HWaddress Flags Mask Iface 192.168.1.11 ether 00:1A:4D:46:51:89 C eth1 ifconfig eth1 Link encap:Ethernet HWaddr 00:1A:4D:45:5D:D1 inet addr:192.168.1.7 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::21a:4dff:fe45:5dd1/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:22930 errors:0 dropped:0 overruns:0 frame:0 TX packets:40135 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4237352 (4.0 MiB) TX bytes:5524946 (5.2 MiB) Interrupt:193 Base address:0x4000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:2194 errors:0 dropped:0 overruns:0 frame:0 TX packets:2194 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:2317688 (2.2 MiB) TX bytes:2317688 (2.2 MiB) output from a machine which can ping 192.168.1.254 and can ping the problematic machine as well route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0 eth0 arp -n Address HWtype HWaddress Flags Mask Iface 192.168.1.254 ether 00:1A:4B:B0:54:68 C eth0 192.168.1.14 ether 00:1A:4D:45:5D:E9 C eth0 192.168.1.11 ether 00:1A:4D:46:51:89 C eth0 ifconfig eth0 Link encap:Ethernet HWaddr 00:1A:4D:46:22:D9 inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::21a:4dff:fe46:22d9/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:28523503 errors:0 dropped:0 overruns:0 frame:0 TX packets:30854263 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2446167612 (2.2 GiB) TX bytes:2720865479 (2.5 GiB) Interrupt:193 Base address:0x4000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:5553 errors:0 dropped:0 overruns:0 frame:0 TX packets:5553 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1838053 (1.7 MiB) TX bytes:1838053 (1.7 MiB) |
If you post output like 'diff --side-by-side file0 file1' it is easier. Here:
Code:
# output from this problematic machine | # output from a machine which can ping 192.168.1.254 and can |
do you need any output from 192.168.1.254?
|
Quote:
I don't have any clues so I'll just fire some shots: Does 192.168.1.11 have an eth0? If so what is it connected to? If not why are you using eth1? Is iptables enabled on 192.168.1.7? Could you, on "the problematic machine", run 'strace -v -T -o /tmp/strace_ping_192.168.1.3 /bin/ping -c1 192.168.1.3' and 'strace -v -T -o /tmp/strace_ping_192.168.1.254 /bin/ping -c1 192.168.1.254' and give use 'diff --side-by-side /tmp/strace_ping_192.168.1.3 /tmp/strace_ping_192.168.1.254'? Another long shot: could you copy over the complete /etc tree from 192.168.1.7 to a machine that works OK, check how many files differ and post filenames? Might want to run a script for that if you copy over the /etc/ tree to /tmp on the "good" machine: Code:
find /etc -type f | while read FILE; do [ -f "/tmp${FILE}" ] && diff --brief "${FILE}" "/tmp${FILE}"; done |
I would personally be running tcpdump on the remote server, and be checking to see if it is getting any arp requests when you do try to ping, as you appear to have no entry already in the arp cache. At the same time it might also be worth running tcpdump on a machine that you can ping, whilst pinging the one you can't, to ensure that that machine does see the arp requests.
in both cases I'd suggest you run "tcpdump -vn -i ethX arp or icmp" as root. |
Good one. I've thought about the arp/tcpdump combo too. Dunno why I didn't offer it.
|
Every single problem I ever encounter I try to fix with tcpdump or wireshark. I have a tcp connection issue, I use tcpdump. I have an ssl handshake issue, I use tcpdump. I have an ldap bind issue, I use tcpdump. My chair squeaks, I use tcpdump. I want some lunch, I use tcpdump.
|
tcpdump output details
Pinging from 192.168.1.5(problematic machine) to 192.168.1.254(Gateway) (destination host unreachable) Tcpdump output at 192.168.1.5(problematic machine)[root@cosmo5 ~]# tcpdump -vn -i eth1 arp tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes 09:48:50.533727 arp who-has 192.168.1.254 tell 192.168.1.5 09:48:52.534360 arp who-has 192.168.1.254 tell 192.168.1.5 09:48:53.534177 arp who-has 192.168.1.254 tell 192.168.1.5 09:48:54.534994 arp who-has 192.168.1.254 tell 192.168.1.5 09:48:55.536810 arp who-has 192.168.1.254 tell 192.168.1.5 09:48:56.536629 arp who-has 192.168.1.254 tell 192.168.1.5 09:48:57.536446 arp who-has 192.168.1.254 tell 192.168.1.5 09:48:57.579118 arp who-has 192.168.2.254 tell 192.168.2.11 09:48:59.537082 arp who-has 192.168.1.254 tell 192.168.1.5 09:49:00.536897 arp who-has 192.168.1.254 tell 192.168.1.5 09:49:01.536715 arp who-has 192.168.1.254 tell 192.168.1.5 09:49:01.572261 arp who-has 192.168.2.254 tell 192.168.2.11 09:49:05.558445 arp who-has 192.168.2.254 tell 192.168.2.11 13 packets captured 13 packets received by filter 0 packets dropped by kernel Tcpdump output at 192.168.1.254(gateway) [root@cosmosrv1 ~]# tcpdump -vn -i eth0 arp tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 11:04:09.372381 arp who-has 192.168.1.254 tell 192.168.1.5 11:04:09.372433 arp reply 192.168.1.254 is-at 00:1a:4b:b0:54:68 11:04:12.372753 arp who-has 192.168.1.254 tell 192.168.1.5 11:04:12.372759 arp reply 192.168.1.254 is-at 00:1a:4b:b0:54:68 11:04:15.912753 arp who-has 192.168.2.254 tell 192.168.2.11 11:04:16.374920 arp who-has 192.168.1.254 tell 192.168.1.5 11:04:16.374925 arp reply 192.168.1.254 is-at 00:1a:4b:b0:54:68 11:04:17.374717 arp who-has 192.168.1.254 tell 192.168.1.5 11:04:17.374721 arp reply 192.168.1.254 is-at 00:1a:4b:b0:54:68 11:04:18.374511 arp who-has 192.168.1.254 tell 192.168.1.5 11:04:18.374515 arp reply 192.168.1.254 is-at 00:1a:4b:b0:54:68 11:04:20.376100 arp who-has 192.168.1.254 tell 192.168.1.5 11:04:20.376105 arp reply 192.168.1.254 is-at 00:1a:4b:b0:54:68 11:04:21.375892 arp who-has 192.168.1.254 tell 192.168.1.5 11:04:21.375896 arp reply 192.168.1.254 is-at 00:1a:4b:b0:54:68 11:04:22.755886 arp who-has 192.168.2.254 tell 192.168.2.11 11:04:24.376275 arp who-has 192.168.1.254 tell 192.168.1.5 11:04:24.376279 arp reply 192.168.1.254 is-at 00:1a:4b:b0:54:68 11:04:25.376066 arp who-has 192.168.1.254 tell 192.168.1.5 11:04:25.376070 arp reply 192.168.1.254 is-at 00:1a:4b:b0:54:68 11:04:26.375860 arp who-has 192.168.1.254 tell 192.168.1.5 11:04:26.375864 arp reply 192.168.1.254 is-at 00:1a:4b:b0:54:68 22 packets captured 22 packets received by filter 0 packets dropped by kernel Pinging from 192.168.1.5(problematic machine) to 192.168.1.2(old machine on the network which can ping to gateway and ping back to problematic machine) (pinging ok) Tcpdump output at 192.168.1.5(problematic machine) [root@cosmo5 ~]# tcpdump -vn -i eth1 arp tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes 09:50:25.743454 arp who-has 192.168.1.5 tell 192.168.1.2 09:50:25.743464 arp reply 192.168.1.5 is-at 00:1a:4d:45:5d:d1 09:50:41.101824 arp who-has 192.168.2.254 tell 192.168.2.11 09:50:42.046476 arp who-has 192.168.2.254 tell 192.168.2.11 09:50:42.937909 arp who-has 192.168.2.254 tell 192.168.2.11 09:50:53.498888 arp who-has 192.168.2.254 tell 192.168.2.11 09:50:57.482055 arp who-has 192.168.2.254 tell 192.168.2.11 09:51:00.586401 arp who-has 192.168.2.254 tell 192.168.2.11 8 packets captured 8 packets received by filter 0 packets dropped by kernel Pinging from 192.168.1.2 to 192.168.1.5(problematic machine) (pinging ok) Tcpdump output at 192.168.1.2 [root@cosmo2 ~]# tcpdump -vn -i eth0 arp tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 11:26:05.558835 arp who-has 192.168.2.254 tell 192.168.2.11 11:26:07.115163 arp who-has 192.168.1.2 tell 192.168.1.5 11:26:07.115172 arp reply 192.168.1.2 is-at 00:1a:4d:46:22:d9 11:26:08.503962 arp who-has 192.168.2.254 tell 192.168.2.10 11:26:13.357358 arp who-has 192.168.2.254 tell 192.168.2.11 11:26:24.013964 arp who-has 192.168.1.230 tell 192.168.1.10 11:26:25.013777 arp who-has 192.168.1.230 tell 192.168.1.10 11:26:26.013590 arp who-has 192.168.1.230 tell 192.168.1.10 11:26:35.236833 arp who-has 192.168.2.254 tell 192.168.2.10 11:26:36.181292 arp who-has 192.168.2.254 tell 192.168.2.10 11:26:36.867693 arp who-has 192.168.2.254 tell 192.168.2.10 11 packets captured 11 packets received by filter 0 packets dropped by kernel Pinging from 192.168.1.2 to 192.168.1.254(gateway) (pinging ok) Tcpdump output at 192.168.1.2 [root@cosmo2 ~]# tcpdump -vn -i eth0 arp tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 11:29:09.023082 arp who-has 192.168.1.230 tell 192.168.1.10 11:29:10.022895 arp who-has 192.168.1.230 tell 192.168.1.10 11:29:11.022708 arp who-has 192.168.1.230 tell 192.168.1.10 11:29:26.873604 arp who-has 192.168.2.254 tell 192.168.2.10 11:29:30.902103 arp who-has 192.168.2.254 tell 192.168.2.10 11:29:31.925150 arp who-has 192.168.2.254 tell 192.168.2.10 11:29:42.024910 arp who-has 192.168.1.230 tell 192.168.1.10 11:29:43.024722 arp who-has 192.168.1.230 tell 192.168.1.10 11:29:44.024536 arp who-has 192.168.1.230 tell 192.168.1.10 9 packets captured 9 packets received by filter 0 packets dropped by kernel Tcpdump output at 192.168.1.254 [root@cosmosrv1 ~]# tcpdump -vn -i eth0 arp tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 11:00:44.807297 arp who-has 192.168.1.230 tell 192.168.1.10 11:00:45.807045 arp who-has 192.168.1.230 tell 192.168.1.10 11:00:46.806818 arp who-has 192.168.1.230 tell 192.168.1.10 11:00:55.168895 arp who-has 192.168.2.254 tell 192.168.2.10 11:00:59.029044 arp who-has 192.168.2.254 tell 192.168.2.10 11:01:03.204153 arp who-has 192.168.2.254 tell 192.168.2.10 11:01:03.804903 arp who-has 192.168.1.254 tell 192.168.1.10 11:01:03.804910 arp reply 192.168.1.254 is-at 00:1a:4b:b0:54:68 11:01:17.807688 arp who-has 192.168.1.230 tell 192.168.1.10 11:01:18.807459 arp who-has 192.168.1.230 tell 192.168.1.10 11:01:19.807227 arp who-has 192.168.1.230 tell 192.168.1.10 11:01:31.737440 arp who-has 192.168.2.254 tell 192.168.2.10 ------------------------------ is this the way to show the output? does ip6tables make any difference coz working machines have both iptables and ip6tables enabled in services while this prolematic one has just iptables. plz note hardware/software details if needed Gateway/Server(multipurpose server,(storage server,nfs,samba) HP Proliant DL380, Generation 5, Enhanced 2xDual Core Intel Xeon, 3.0 Ghz each, L2 Cache=4MB/dual core processor, FSB=1333 MHz 4GB DDR2, 667 Mhz, HP brand Running RHEL 4.4 and VMWare Server 1.0.3 Master Node Clients(all wtih same config) Intel Core 2 Duo 6600, 2.4 Ghz, L2 Cach=4MB, FSB=1066 MHz Water cooled Gigbyte motherboard, PXE boot capable, built in RAID Controller 4GB DDR2, 800 Mhz Running RHEL 4.4 and VMWare Server 1.0.3 Client Nodes(the problematic one doesn't have VMWare Server 1.0.3) |
OK, so the arp reply from the gateway just never gets back inside the original machine. Odd. What does the switching setup look like here? It's possible that if you have slightly cranky switches they might refuse to play ball with their FDB tables or something, certainly getting odd now. I'd be intested to know if the arp reply is seen on the wire, but as the reply is unicast you couldn't just sniff it from a third box, so let's leave that for now.
What I would also query is the .2.11 IP. Why is that appearing on the same network interface? Could well be something of interest there. Finally, let's try bypassing arp and see if it pings once you have a static arp entry in your machine... run "arp -s 192.168.1.254 00:1a:4b:b0:54:68" and try pinging once more. With tcpdumps again if it doesn't work. |
1 Attachment(s)
192.168.2.11 could be virtual computer's node IP on the same interface.i have found a document regarding current network which i am attaching as an image. it might elaborate 192.168.2.11 more. i tried "arp -s" and after that when i ping 254, it didn't give me any answer for aournd 20 minutes and i had to press ctl+c to quit. i configured eth0 instead of eth1 but again i can't ping to 254 and still can ping to 2 and others
|
Hmm, with VMware in the equation as well it seems, that's getting pretty messy, and without the base network infrastructure being consistent and reliable, I wouldn't really want to speculate what else is going on there.
|
no further advice?
|
Try filling the ARP cache (/etc/ethers) with MAC IP pairs on 192.168.1.5(problematic machine) then 'arp -f /etc/ethers' to see if that works?
Lines have one MAC and IP per line, values are space separated and look like: 00:1A:4D:46:229 192.168.1.2 00:1A:4D:46:3A 192.168.1.3 |
Personally from what I can see, your layer 2 networking is most likely to be the issue, you clearly have issues with subnets getting mixed up that .2.11 IP intruding in .1.0/24 so as I can't have any real confidence in the switching, the only advice I can give from here is to fix your switching.
|
| All times are GMT -5. The time now is 10:29 AM. |