09-22-2011 01:15 PM - edited 03-07-2019 02:23 AM
ok everyone - got a strange one for you:
I have a 6509 with multiple vlans configured. This config has been working fine for months. I have a server (Linux which has 1 nic, 4 addresses configed) which has ip addresses 173.x.x.100, 173.x.x.101, 173.x.x.102 and 173.x.x.103. The machine is part of VLAN101. the vlan's addr is 173.x.x.97 - it is a /27 subnet, BTW. This Linux server is connected to port gi7/7 with 1 ethernet cable.
What baffes me is that I can ping (from everywhere I have tried) to ping all the addresses of this Linux box BUT 173.x.x.100.
I have checked and cleared ARP, checked and cleared the MAC table etc. It just doesnt respond on that first address.
anyone got any ideas
09-22-2011 01:24 PM
Hi Dave,
Interesting. Let's assume you clear the ARP table on the 6509 and subsequently ping the .100 from the 6509. Will the .100 IP address be properly resolved to the appropriate MAC address in the ARP table on the 6509 again? Also, are the ARP requests reaching the Linux server? Can you verify that using the tcpdump -s0 -n eth0 arp command?
Best regards,
Peter
09-22-2011 01:31 PM
Peter,
thanks for your response. I realized I forgot to mention that I can ping the .100 address from the 6509 - this is never an issue. I can also ping it from some networks on the internet, but not others. From my "inside" network (173.x.x.100 is on the "outside") I can ping .101,.102,.103 but cannot ping .100. And yes linux server is receiving
09-22-2011 01:43 PM
Dave,
I see. Can you please post the complete output of the ip route command from the Linux server?
Also it would be very interesting to see if the ICMP ECHO packets to the .100 address are arriving to the server when pinging it from a network where the pings are unsuccessful, and also, it would be interesting to see how are the responses constructed - what is their source IP, what gateway are they addressed to etc. The tcpdump capture of this ping would be most helpful.
Best regards,
Peter
09-22-2011 02:18 PM
peter:
here is the ip route output - i have also included the ifconfig output
<1>:ip route
128.4.40.12 via 10.y.y.1 dev eth0
173.x.x.96/27 dev eth1 proto kernel scope link src 173.x.x.100
172.30.1.0/24 via 10.y.y.1 dev eth0
10.2x.x.0/24 dev eth0 proto kernel scope link src 10.y.y.64
172.e.1.0/24 via 10.y.y.1 dev eth0
64.f.f.0/24 via 10.y.y.1 dev eth0
172.a.a.0/24 via 10.y.y.1 dev eth0
172.b.a.0/24 via 10.y.y.1 dev eth0
172.b.a.0/24 via 10.y.y.1 dev eth0
169.g.0.0/16 dev eth1 scope link
192.h.0.0/16 via 10.y.y.1 dev eth0
172.0.0.0/8 via 10.y.y.1 dev eth0
10.0.0.0/8 via 10.y.y.1 dev eth0
default via 173.x.x.97 dev eth1 src 173.x.x.101
<2>:ifconfig
eth0 Link encap:Ethernet HWaddr 84:2B:2B:09:A2:9E
inet addr:10.y.y.64 Bcast:10.y.y.255 Mask:255.255.255.0
inet6 addr: fe80::862b:2bff:fe09:a29e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:102924401 errors:0 dropped:0 overruns:0 frame:0
TX packets:89743258 errors:20452368 dropped:0 overruns:0 carrier:20452368
collisions:20484636 txqueuelen:1000
RX bytes:8521953769 (7.9 GiB) TX bytes:122928623107 (114.4 GiB)
Interrupt:98 Memory:da000000-da012800
eth1 Link encap:Ethernet HWaddr 84:2B:2B:09:A2:9F
inet addr:173.x.x.100 Bcast:173.x.x.127 Mask:255.255.255.224
inet6 addr: fe80::862b:2bff:fe09:a29f/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:989430221085 errors:3 dropped:33392475 overruns:0 frame:3
TX packets:962329716151 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:193817095789094 (176.2 TiB) TX bytes:189793697396545 (172.6 TiB)
Interrupt:106 Memory:dc000000-dc012800
eth1:0 Link encap:Ethernet HWaddr 84:2B:2B:09:A2:9F
inet addr:173.x.x.101 Bcast:173.x.x.127 Mask:255.255.255.224
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:106 Memory:dc000000-dc012800
eth1:1 Link encap:Ethernet HWaddr 84:2B:2B:09:A2:9F
inet addr:173.x.x.102 Bcast:173.x.x.127 Mask:255.255.255.224
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:106 Memory:dc000000-dc012800
eth1:2 Link encap:Ethernet HWaddr 84:2B:2B:09:A2:9F
inet addr:173.x.x.105 Bcast:173.x.x.127 Mask:255.255.255.224
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:106 Memory:dc000000-dc012800
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:3630394390 errors:0 dropped:0 overruns:0 frame:0
TX packets:3630394390 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1353586688540 (1.2 TiB) TX bytes:1353586688540 (1.2 TiB)
09-22-2011 02:30 PM
Dave,
Just a quick observation: if the Linux box sends packets to the 173.x.x.96/27 network, it sources them from the .100 address. If it sends packets to different networks reachable via the default route, it sources them from the .101 address. I am just wondering if this has any relevance to your issue.
How about that test with pinging the Linux under its .100 IP address from a network from which the ping is unsuccessful - are the ICMP ECHOs received by the Linux server at all?
Best regards,
Peter
09-22-2011 04:32 PM
Peter
The tcpdump output scrolls very fast (there is alot of other traffic on this server) but I looked into it and on a device which can ping i see:
23:25:33.538911 IP 96.x.x.58 > 173.x.x.100: ICMP echo request, id 6998, seq 547, length 40
23:25:33.538939 IP 173.x.x.100 > 96.x.x.58: ICMP echo reply, id 6998, seq 547, length 40
when I try it from a host that cannot ping, i dont see any entry at all. As if pings are not getting to the eth1 interface on the linux box.
btw, I CAN ping anything FROM the .100 linux box
09-22-2011 06:54 PM
Dave Jabob wrote:
Peter
The tcpdump output scrolls very fast (there is alot of other traffic on this server) but I looked into it and on a device which can ping i see:
23:25:33.538911 IP 96.x.x.58 > 173.x.x.100: ICMP echo request, id 6998, seq 547, length 40
23:25:33.538939 IP 173.x.x.100 > 96.x.x.58: ICMP echo reply, id 6998, seq 547, length 40
when I try it from a host that cannot ping, i dont see any entry at all. As if pings are not getting to the eth1 interface on the linux box.
btw, I CAN ping anything FROM the .100 linux box
Just a "It can't it be this easy?" type question - you don't have iptables/ipchains running on the .100 interface but not the others which is denying ICMP traffic, do you?
Cheers.
09-22-2011 11:17 PM
Darren,
This definitely looks like a stateful firewall is in place and filtering flows into the .100 IP address. The interesting thing, however, is that when pinging the .100 from a network where the ping fails, the tcpdump does not, according to Dave, display anything. But the tcpdump would not be influenced by any iptables running on the Linux box itself, so the filtering is probably done on a different device.
Dave, is there any other firewall placed between your Linux and the outside world?
Best regards,
Peter
09-23-2011 06:38 AM
IPTABLES is running but allowing icmp from anywhere. I have stopped the iptables service and i get the same result and cannot ping the .100 , here are the rules:
<3>:iptables --list
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
tss4000 all -- anywhere anywhere
Chain FORWARD (policy DROP)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain tss4000 (1 references)
target prot opt source destination
ACCEPT icmp -- anywhere anywhere
ACCEPT udp -- anywhere anywhere udp
ACCEPT tcp -- anywhere anywhere tcp dpt:sip
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
so even with iptables service stopped we get the same result.
besides iptables there is no other firewal in place between the machine and the public internet
Regards,
Dave
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide