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

context

There are 2 servers:

server1 - eth0 10.129.76.16 eth0.2 192.168.0.103

server2 - eth0 10.129.79.1 eth0.2 192.168.62.101

The 192.x.x.x addresses are connected to the same vlan (vlan2) and are able to see eachother. The 10.x.x.x addresses are connected to different vlan's which are not able to see eachother.

on request of David Swartz: the routing table on server 1 is:

~$ sudo route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.129.76.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.0.0     0.0.0.0         255.255.192.0   U     0      0        0 eth0.2
0.0.0.0         192.168.61.254  0.0.0.0         UG    100    0        0 eth0.2

the routing table on server 2 is:

~$ sudo route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         <public IP gw>  0.0.0.0         UG    100    0        0 eth0.11
10.129.79.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
<public IP>     0.0.0.0         255.255.255.128 U     0      0        0 eth0.11
192.168.0.0     0.0.0.0         255.255.192.0   U     0      0        0 eth0.2

Problem:

When I ping from server 1 to server 2, it seems no packets are arriving and vice versa. When I check the routes (route -n) I see the default gw uses eth0.2 on both servers. But when I use arping, I get a response one way (from server 2 to server 1) but no response vice versa.

arping 192.168.62.101
ARPING 192.168.62.101 from 10.129.76.16 eth0
^CSent 2 probes (2 broadcast(s))
Received 0 response(s)

As you can see it uses the 10.x.x.x address instead of the 192.x.x.x. And as I told before, the 10.x.x.x address is unreachable from the other server.

When I force arping to use eth0.2, it does work.

I don't have any problems with ping'ing other servers from any of those 2 servers.

I did see this in the arp tables:

~# arp -n | grep 192.168.0.103
192.168.0.103                    (incomplete)                              eth0

and

~# arp -n | grep 192.168.62.101

Question

quite obvious... How can I make these servers see each other again?

Things I've tied

clear the apropriate entries in the arptable and tried to get rid of the (incomplete) But I think the biggest problem is that eth0 is used instead of eth0.2 for the packets from server 1 to server 2

Because of David Swartz' remark about the routing tables, I added a route in there defining the host. I added

192.168.0.103   0.0.0.0         255.255.255.255 UH    0      0        0 eth0.2

and

192.168.62.101  0.0.0.0         255.255.255.255 UH    0      0        0 eth0.2

to the appropriate servers but this didn't solve the problem so I presume the problem is not in the routing.

My guess

I guess the problem lies in the following.

~$ arp -n | grep 192.168.0.103
192.168.0.103                    (incomplete)                              eth0

but I'm unable to remove this entry. (arp -d 192.168.0.103 has no effect)

Thanks for reading and even more thanks for answering!

share|improve this question
1  
Can you paste the route tables and interface configurations? I suspect you have some bogus routing table entries or interface netmasks. –  David Schwartz Aug 24 '12 at 0:32
    
@DavidSchwartz I changed the question so it contains your requested info. –  Hannes Aug 24 '12 at 6:19
    
What happens when, from server1, you try arping -I eth0.2 192.168.62.101? –  MadHatter Jul 31 '13 at 4:57

2 Answers 2

You didn't mention what kernel you're using or what version of arping, and there is the possibility of a bug in one or the other. The fact that you can successfully arping when you specify the subinterface does indicate that all of your layer-2 networking is behaving correctly.

Try using ip route get 192.168.62.101 on server1 to ask the kernel directly how it would send your traffic. Based on the routing tables you've posted, sending via eth0.2 is clearly the correct behavior, and if ip route get returns a different answer, you may be looking at a kernel bug. If it returns the correct answer, then arping is to blame, but that seems unlikely.

The (incomplete) entry doesn't need to be removed; it is a placeholder that lets the kernel know that it did try to ARP that IP, so that an ARP reply should be considered valid and not an ARP-poison attack, but that it didn't get an answer. It'll time out.

share|improve this answer

Here's a snippet:

arpping doesn't respect the local routing table:

== mbrownnyc [gateway/web/freenode] has joined ##networking
[10:14] <mbrownnyc> mAniAk-_-: any idea why, if his routing table reflects the proper interface to route 192.168.0.0/18 packets, why when he `arping 192.168.62.101` the kernel would think to make the source address that of the other interface?
[10:14] <mbrownnyc> it's very very weird to me
[10:16] <mbrownnyc> tafelpoot: unless arping has a bug in the code or something?
[10:17] <mbrownnyc> can you use another piece of software? like hping?
[10:17] <catphish> mbrownnyc: arping doesn't respect the routing table
[10:17] <catphish> you have to specify the interface manually
[10:17] <mbrownnyc> catphish: voila!
[10:18] <catphish> no idea why, it's just never been a feature of it, it seems to use the first ethernet interface unless you tell it otherwise
[10:19] <mbrownnyc> catphish: interesting catphish that's the whole "problem" here, the testing mechanism, I guess

use icmp to test:

[10:25] <catphish> mbrownnyc: that guy is testing with arping which makes no sense since arping doesn't use the routing table
[10:26] <catphish> it should be ping
[10:26] <catphish> and if ping fails, arping with an interface specified
[10:26] <mAniAk-_-> GG
[10:26] <catphish> oh, it does work when forcing arping to use the right address
[10:27] <catphish> so im not sure what the problem might be
[10:27] <mAniAk-_-> ARPING 192.168.62.101 from 10.129.76.16 eth0
[10:27] <mAniAk-_-> not eth0.2
[10:28] <catphish> indeed
[10:28] <catphish> because the interface wasn't specified
[10:28] <catphish> apparantly it works when the interface is specified
[10:28] <catphish> so i don't see the problem

are your vlans okay?

[10:29] <catphish> it's also possible the the vlan config is messed up, i don't like mixing native and tagged vlans like that
[10:29] <mAniAk-_-> yeah i thought so too
share|improve this answer
    
What is this a snippet of? It certainly isn't an answer to the question... –  voretaq7 Aug 25 '12 at 1:04
    
This is a snippet of the IRC conversation I had on ##networking on the freenode network. It helped me to troubleshoot the problem a little further but, indeed, didn't lead to a direct answer. Still investigating. I had some more conclusions and I will post them here somewhere tomorrow. (no time at the moment.) –  Hannes Aug 25 '12 at 15:50
    
It certainly is a community wiki response, as I tagged it to be such, for future reference by other users of this site; unless I misunderstand what "community wiki" is? voretaq7, was this response flagged? –  mbrownnyc Aug 26 '12 at 16:49

Your Answer

 
discard

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.