Link to home
Start Free TrialLog in
Avatar of iamuser
iamuser

asked on

switch and ARP question

Here's a situation, our network has a extreme blackdiamond box. And all the switches on the network are extreme switches. We also run vlans through the network.

recently we purchase a device which seems to die after a while on the network (yes on a vlan). You can't ping it after an hour and all network connectivity ends. Computers, printers and so on do not have this problem excet this device. And after much testing we determined that it's not the vlan but the device that was causing this.

We talked to the manufacture and they issued a XML configuration file to us to load on the device. I took a look at the XML file and all it does is tell the device to do a gratiutious arp every 2 mins. The manufacturer tells me that this arp will keep arp cached updated in the switch with the device Mac.

Now that the file has been loaded the device functions perfertly fine with no issues on the network.


I had a chance to talk to one of our network consultants about this and the tells me that none of the switches keep an arp table and that the manufacturer is lying and that it's something else. But ever since we did the upload the unit has been working fine with no issues.

So part of what he says make sense because when we were testing the unit, we have a continous ping going from a pc to the device and it still timed out eventually. But if what our consultants say is true then how do you explain the arp keeping the clock alive on the network?



ASKER CERTIFIED SOLUTION
Avatar of saw830
saw830

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of iamuser
iamuser

ASKER

so while a ping from a machine to the device won't keep it alive, an arp coming from the device to the network will keep the device alive?

in general what protocol or network issues would cause this to happen on a device?

SOLUTION
Avatar of Cyclops3590
Cyclops3590
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of iamuser

ASKER

but a layer 3 switch would have both I assume right?
not really.  again this is mostly semantics.

MAC Table

MAC           Port
-----------      -----------
XXXX          Fa0/1
YYYY          Fa0/10

ARP Table

MAC          IP
---------       -------------
XXXX       192.168.1.1
YYYY       192.168.1.2

L3 Devices version of MAC Table, or a routing table

Subnet                  Interface
----------------            -------------------------
192.168.1.0/24      eth0
0/0                         eth1

So a mac table tells an L2 device which port to forward the packet out of, an arp table tells an L3 device which mac address to communicate to for a given IP, and the routing table tells the L3 device which of its interfaces to go out to communicate to that mac address.
Avatar of iamuser

ASKER

I assume that all devices including pc's do an arp/broadcast out to the network from time to time to let the layer 2, layer 3 switches, other devices  know that they exist on the network. if they didn't the arp table would be cleared out right? I mean the arp table isn't there for weeks or even hours on a swtich or router.
Hi all,

Cyclops3590 -  wouldn't the router need to know that the arp translation for 192.168.1.5 (another router in the same subnet) so that the packet could be forwarded?  Or is this the difference between a L3 switch and a Router?

Switches learn about MAC addresses on it's ports by hearing responses from those devices.  When a switch is powered up (or otherwise freshly cleared it's arp cache) it broadcasts all messages on all ports.  As devices begin answering those messages the switch learns about them and stops broadcasting messages to those devices.

Want to see how this can fall over?  Connect a two hubs to two ports on a switch.  connect a pc switch, and connect another pc or whatever into one of the hubs.  using the PC (on the switch), talk to the device (a ping is enough) and note that the first packet is sent out all ports until the device answers.  The switch has not found the device connected through a hub.  Now unplug the device from the hub and connect it to the other hub (the hubs keep the switch from seeing the port change).  talk to the device again.  the device will not hear the message because the switch will be sending the message to the old port.

I don't know how long this will remain, but I believe that items do expire from ARP caches but I don't know how fast.
arp timeouts can vary.  however I remember right, the devices don't technically broadcast out the way I believe you're thinking.  For example, you have device A, B, and C.  A ping C.  A sends an arp broadcast out asking who is <ip address of C>.  C sees that packet and tells A its mac info so that A can now talk to C.  A and C now have each others information in their arp table cached for so long (since you don't know how long a MAC to IP mapping is good for it needs to expire to keep things accurate).  However B knows nothing of A or C.  Also, the switch should now know of A and C. If A pings B. Then A knows of B and C, B knows of A, and C knows of A, but B and C don't know of each other yet.  And the switch should now know of all three.  Keep in mind that switches learn mac addresses via source addresses in L2 packets.  This is the only trustworthy way of knowing where devices are at (yes macs can be spoofed, but its still a far more accurate method learning by source than destination address).

This is typically why switches mac table entries generally expire after a fairly short while, because they see so many host address.  Some devices are on the order of minutes, some hours.  But generally I would think you're looking at under 30 minutes for most all devices.  However that's just from my experience.  I could be full of it as well.
>>Cyclops3590 -  wouldn't the router need to know that the arp translation for 192.168.1.5 (another router in the same subnet) so that the
>>packet could be forwarded?  Or is this the difference between a L3 switch and a Router?
same method.  router A thru its routing table knows the next hop is 192.168.1.5.  sends arp request to see who has 192.168.1.5.  gets that answer and forwards the packet via that mac address.  That is why I say the mac table for a switch (L2 device) is like the routing table of a router (L3 device).  It is used for routing/switching(that's a whole new semantics issue of which I'm not getting into) purposes only.
okay... firstly, my last post is a classic example of why not to try doing two things at once.....

to wit:

Firstly, the paragraph that starts with "Cyclops3590" was for intended for Cyclops3590, but the following paragraphs were actually intended for iamuser.  I forgot to show that when I typed it.

Secondly, I kept referring to the ARP cache on the switch, which L2 switches don't actually have, since they don't give a hoot about IP addresses (management consoles aside).  They do have a MAC address to "last known port" lookup table.  And Cyclops3590 is correct that they learn from looking at the packets coming through.

sorry for the confusion....
If you're capable, here's a test you could do.

Change the device back the way it was - without the gratuidous ARP.
Put in a static arp entry on a PC on the SAME layer 2 net/vlan like this:
   arp -s 157.55.85.212   00-aa-00-62-c6-09  .... Adds a static entry.
Then, wait for the device to "die" - disappear from the net.
Now, from the machine with the static arp, can it see it - ping it?

If yes, then the issue may very well be the ARP table - resolving the IP address to a MAC address.

If no, then the issue is NOT the ARP table, but possibly the MAC forwarding table on the local switch.  However, the behavior for an incoming ping to a layer 2 unknown address is to forward the frame to ALL ports on the switch (except where it came from) and presumably, the "dead" device would see the ping and respond.

For the whole ARP table discussion - on a pure layer 2 switch, it has a MAC forwarding table - called different things by different vendors (CAM table for instance).  Basically, a table matchine MAC address to ports.  Learned by observing source addresses from traffic passing through.

A router - a layer 3 device - has an ARP table, and Address Resolution Protocol table which resolves IP address to MAC addresses.

If you combine routing functionality on a switch, then you have a layer 3 switch which has both an ARP table and a MAC forwarding table.  Sometimes these are combined on ONE table.
Avatar of iamuser

ASKER

We did that earlier, after the device died on the vlan we checked the computer that was attempting to ping it. THe computer still had the mac address in it's arp table. But when we took a look at the switch side, we couldn't see the Mac address in it's Mac forwarding table.

What's weird is that even if i do a continous ping on the device from a pc, it will eventually die. And when I check the switch it shows the Mac missing again.

Now what's weirder is if i plug the device into a hub with a computer and do a continous ping, the device never dies, it's constantly alive.





Perhaps the problem is not as it appears.  Are you able to confirm that the PINGs actually make it to the device or not?  Suppose that the PING reaches the device, but that the device is not able to respond.  If that is the case, then no amount of adjustment on the PC is going to fix this, hence the fix on the device.

Another thought....
You say that it stops working when connected to your black diamond switch, but continues to work when connected through a hub.  Have you tried a different switch?  I'm not sure what this test will tell you, but it might suggest that the device doesn't play well with black diamond, or that the device does play well with switches in general.  Although it is my understanding that netword devices (PCs, printers, routers, etc.) are not supposed to be able to tell the difference, there's is compatable and then there's compatable..