cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3752
Views
0
Helpful
9
Replies

Can't ping a device in VLAN

wcgsoperations
Level 1
Level 1

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

9 Replies 9

Peter Paluch
Cisco Employee
Cisco Employee

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

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

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

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)

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

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

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.

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

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