ARP reply problem

[teo_simon]

Hi all,

I am using red hat enterprise linux and i have a problem which I'm puzzled and can't solve.

I have a server with 4 ethernet ports, eth0, eth1, eth2, eth3. Each of them has an IP in a different subnet (255.255.255.0). They are all connected to the same CISCO switch.

I have another equipment which needs to send UDP packets to one of the ethernet ports in this server. The equipment sends out an ARP request packet to ask for the MAC address of the IP port. Using ethereal, I captured and analyzed the packets sent and received. I realised that 2 ports from the server will respond to the ARP request. Therefore, the IP will exist on 2 different MAC cards. This will result in the UDP packets being routed to the wrong ethernet port sometimes, depending on which packet reaches my equipment first.

How do I solve this problem of 2 ports from the server replying to a single ARP request? Is it a Red Hat Enterprise Linux problem? If yes, is there a solution to it?

Many thanks... hope someone can help...

Regards,
Simon

[dilbert]

I'm sure I haven't fully understood the problem, but here a few hints or questions:

Usinfg arping, can you specify the port to send to with the "-I" option?

Arping sends first a broadcast and then, from the second packet on, only unicast pings.

On the other hand, what's wrong getting the arptable populated? Can't you send the UDP packet not simply specifying it's unique IP address?

Did you doublecheck on the server with ifconfig that all Ethernet ports have a unique IP address?

Well. more questions than hints ...

[teo_simon]

I'm sure I haven't fully understood the problem, but here a few hints or questions:

Usinfg arping, can you specify the port to send to with the "-I" option?

Arping sends first a broadcast and then, from the second packet on, only unicast pings.

On the other hand, what's wrong getting the arptable populated? Can't you send the UDP packet not simply specifying it's unique IP address?

Did you doublecheck on the server with ifconfig that all Ethernet ports have a unique IP address?

Well. more questions than hints ...

Hi thanks for replying..
I will try the arping when i get my hands on the server...

the UDP packets ride on ethernet packets.. so it needs a destination MAC.. if it's the wrong MAC, it will get routed to the wrong port

i am sure that all ports have unique IP addresses...

The problem I'm having is that more than one port from my server replies to an ARP request (broadcast)... when the packet containing the WRONG arp reply packet reaches the equipment requesting for the MAC address first, the destination MAC for the UDP packets would then be WRONG...

[dilbert]

Hi thanks for replying..
the UDP packets ride on ethernet packets.. so it needs a destination MAC.. if it's the wrong MAC, it will get routed to the wrong port

[...]

The problem I'm having is that more than one port from my server replies to an ARP request (broadcast)... when the packet containing the WRONG arp reply packet reaches the equipment requesting for the MAC address first, the destination MAC for the UDP packets would then be WRONG...

The arp table matches IP addresses to MAC addresses.

So, there are no "wrong" arp replies.

When you use the standard Linux network funktions before sending an UDP packet, the network stack looks at the arp table to get the IP address from the MAC address or even sends an arp ping beforehand, if you want it or not.

This happens if you open a socket. If you want to avoid that then you have to open the socket as raw Ethernet instead of TCP/IP.

I suggest you send the UDP packet and watch with ethereal what's going on.

[teo_simon]

The arp table matches IP addresses to MAC addresses.

So, there are no "wrong" arp replies.

When you use the standard Linux network funktions before sending an UDP packet, the network stack looks at the arp table to get the IP address from the MAC address or even sends an arp ping beforehand, if you want it or not.

This happens if you open a socket. If you want to avoid that then you have to open the socket as raw Ethernet instead of TCP/IP.

I suggest you send the UDP packet and watch with ethereal what's going on.

hi the "wrong" replies come in when more than 1 port replies to the ARP request... this is the problem i'm facing...

[dilbert]

hi the "wrong" replies come in when more than 1 port replies to the ARP request... this is the problem i'm facing...

Did you look with ethereal at those ARP replies?

It is actually a year ago that I crafted my own tests with ARP packets, but when I simply monitor with ethereal the ongoing network traffic on the NFS client I am sitting now, there are ARP packets und replies, and a reply has that form:

destination MAC
source MAC
type 0x0806 (=ARP)
hardware type 0001 (=Ethernet)
protocol type 0800 (=IP)
hardware size
protocol size
opcode 0002 (=reply)
sender MAC address
sender IP address
target MAC address
target IP address

All those addresses have unique and senisble values!

What do you get?

If those ports have all a unique IP address and a unique MAC address, what kind of mismatch do you see?

All four ports can reply simultaneously with their respective MAC and IP addresses. If not the whole ARP protocol would depend on timing issues and would be therefore completely useless.

The problems you describe can only happen if someone discards the generic ARP protocol and starts doing his own ARP-equivalent table. I've seen such a approach done for "security by obscurity", using raw Ethernet instead of IP.

Is your protocol type "0x0800", i.e., IP ?

[teo_simon]

Did you look with ethereal at those ARP replies?

It is actually a year ago that I crafted my own tests with ARP packets, but when I simply monitor with ethereal the ongoing network traffic on the NFS client I am sitting now, there are ARP packets und replies, and a reply has that form:

destination MAC
source MAC
type 0x0806 (=ARP)
hardware type 0001 (=Ethernet)
protocol type 0800 (=IP)
hardware size
protocol size
opcode 0002 (=reply)
sender MAC address
sender IP address
target MAC address
target IP address

All those addresses have unique and senisble values!

What do you get?

If those ports have all a unique IP address and a unique MAC address, what kind of mismatch do you see?

All four ports can reply simultaneously with their respective MAC and IP addresses. If not the whole ARP protocol would depend on timing issues and would be therefore completely useless.

The problems you describe can only happen if someone discards the generic ARP protocol and starts doing his own ARP-equivalent table. I've seen such a approach done for "security by obscurity", using raw Ethernet instead of IP.

Is your protocol type "0x0800", i.e., IP ?

Hi thanks for replying.. I'll go back to examine the packets in greater detail..

Previously, I used ethereal to monitor the ARP packets.. while I did not examine the packet structure thoroughly, I tried to read from ethereal the info section.. when an ARP request comes in, it would have something like "who has x.x.x.x? tell y.y.y.y" then I would see two different ARP replies from different MAC cards, saying "x.x.x.x is at Q:Q:Q:Q:Q:Q" and Q for the two different packets would be unique MAC addresses from the two different ports that replied to the ARP request.. That's the problem I face...

[dilbert]

Well, still I'm not really sure what's going on on your system, but if you see two replies, "[IP addr] is at [MAC addr]", then the addresses SHOULD all be different.

If you send a ping or a UDP from an IP socket, than silently the network stacks looks up the ARP table and if you specify an IP packet to an IP address for location A, the Ethernet packet is sent to the MAC address of location A.

If the ARP table is empty, ARP packets are sent to populate the ARP table. You can check all this traffic with ethereal, too, if you simply send a UDP from an IP socket.

[teo_simon]

Well, still I'm not really sure what's going on on your system, but if you see two replies, "[IP addr] is at [MAC addr]", then the addresses SHOULD all be different.

If you send a ping or a UDP from an IP socket, than silently the network stacks looks up the ARP table and if you specify an IP packet to an IP address for location A, the Ethernet packet is sent to the MAC address of location A.

If the ARP table is empty, ARP packets are sent to populate the ARP table. You can check all this traffic with ethereal, too, if you simply send a UDP from an IP socket.

"[IP addr] is at [MAC addr]" ... for the same [IP addr], the [MAC addr] should be the same for both ARP replies right? BUT, i got DIFFERENT [MAC addr] for both ARP replies for the SAME [IP addr]

[dilbert]

No, all should be different.

A.A.A.A - 1:1:1:1:1:1
B.B.B.B - 2:2:2:2:2:2

But, all depends what ifconfig says for your ports. To get a picture what's going on, the addresses from the ports gained by ifconfig need to match the values inside the ARP reply.

Different MAC addresses for the same IP address shouldn't happen. Compare the MAC and IP addresses from the ARP reply with the output of ifconfig