Options

ARP table

notgoing2failnotgoing2fail Member Posts: 1,138
Ok so I wanted to do a little ARP testing.

My main network is 192.168.1.0/24

When I pinged one of my laptops from another laptop I got a successful response.

Then I went to the command prompt and typed: arp -a

I saw in the ARP table the IP to MAC addressing. Things look good.

I have another network: 192.168.3.0/24

Here I also pinged a PC from the 192.168.1.0 network to the 192.168.3.0 network and got a successful response.

So again, I go to my command prompt and type: arp -a

Low and behold, NOTHING. Other than my other original entries, there is no mapping to my 192.168.3.5 PC that I successfully pinged.


WHY??


Now I'll try to answer my question a bit but I'd like a little help. I understand that pinging a device in the same network does not require my gateway to be involved. The ARP will just find the local PC(via broadcast) in my subnet and send the ICMP packets on its way.

But I thought that the same principles applied when asking the router where 192.168.3.5 is? I would have thought that my ARP table would show the address with the successful PING, and the MAC address would be a entered as the routers interface(the gateway). This is not the case.

My ARP table has NO entry at all. I kept hitting arp -a over and over again perhaps it takes time to get into the table. Nope!! It never went in....

So from a fundamental standpoint, if there is no ARP entry, then how the heck did my PC be able to have a successful PING to another subnet?

BTW: I've also tried arp -g, but that's the same thing....

And I also went to the other PC and pinged back, got successful result, and THAT PC had no entry in ARP either...

I believe this is a CRUCIAL fundamental question that I hope someone here could explain, I know one of you guys know the answer...and I'm hoping this post will help others too who thought they had ARP all figured out....

Comments

  • Options
    ConstantlyLearningConstantlyLearning Member Posts: 445
    What OS are you doing this from?

    I did this from an XP SP3 machine and I have an entry for the DG.
    "There are 3 types of people in this world, those who can count and those who can't"
  • Options
    notgoing2failnotgoing2fail Member Posts: 1,138
    What OS are you doing this from?

    I did this from an XP SP3 machine and I have an entry for the DG.


    Ohhh?? Hmm....

    Both my machines are Win7.....

    I just did a ping test from my Mac as well and it doesn't have an ARP entry either....I wonder what is going on?
  • Options
    mikej412mikej412 Member Posts: 10,086 ■■■■■■■■■■
    The internet would be really really really slow if you needed to know the layer 2 address of every other device in the world -- which would imply one big flat shared network.

    As CL mentioned -- look for the default gateway MAC in the arp table

    If the destination source IP is not on your PCs local network, your PC knows it going to send the packet somewhere off of the local network segment (where Layer 2 addresses are used) -- so it uses the Default Gateway. And to send the IP Packet to the Default Gateway, it puts the Default Gateway's MAC address in the destination address of the Layer 2 Frame. And if it doesn't already have the Default Gateway's MAC Address in the ARP Table -- it ARPs for the default gateway.

    Clear your arp table, check your arp table, then ping "off your local network segment," and then check your arp table again and you should find an arp entry for your default gateway.

    Edit: Damn you kalebkspk I'm still editing my typos & CaPs... icon_lol.gif
    :mike: Cisco Certifications -- Collect the Entire Set!
  • Options
    kalebkspkalebksp Member Posts: 1,033 ■■■■■□□□□□
    Does your ARP table have an entry for your router? If you send a packet to another network your computer will ARP for the routers IP address, not the IP address that you are sending traffic to. (Proxy ARP is an exception to this.)

    EDIT: Damn you Mike. :)
  • Options
    notgoing2failnotgoing2fail Member Posts: 1,138
    Ok, I cleared the arp cache. Ran arp-a and it displayed no entries.

    Then I pinged another segment and the gateway indeed showed up.

    I must now sit down in deep thought and try to understand this...

    So the arp cache is only local to your subnet and that's it!!?
  • Options
    notgoing2failnotgoing2fail Member Posts: 1,138
    Ok deep thought over....

    I think I get it now. So when a packet is going to a destination NOT on your local subnet, the PC doesn't even attempt to ARP at all right? It knows based on the subnet mask that it should just simply send the packet on its way to the gateway/router?
  • Options
    kalebkspkalebksp Member Posts: 1,033 ■■■■■□□□□□
    So when a packet is going to a destination NOT on your local subnet, the PC doesn't even attempt to ARP at all right? It knows based on the subnet mask that it should just simply send the packet on its way to the gateway/router?

    Yep, if it doesn't already have an entry it will ARP for the default gateway.
  • Options
    hexemhexem Member Posts: 177
    Just remember layer 2 mapping's are required for local network's, if you want to reach a remote subnet you arp for you're default gateway. Once the packet reaches the router with the remote subnet directly connected it will send out an arp request for the remote host before fowarding the frame's and then vice versa for sending back.
    ICND1 - Passed 25/01/10
    ICND2 - Passed 9/03/10

    Studying CCNA:S
  • Options
    notgoing2failnotgoing2fail Member Posts: 1,138
    Thanks guys, it's starting to become clear now.

    I'm so glad I made this post. I understood ARP only 90% correctly. Thanks for clearing things up for me.
  • Options
    mikej412mikej412 Member Posts: 10,086 ■■■■■■■■■■
    I understood ARP only 90% correctly.
    Wait a minute -- you're not getting off that easy.

    There used to be the 80/20 rule -- 80 percent of traffic was local and 20 percent went elsewhere..... so your original understanding of ARP would have been only 80% correct in the old days of networking.

    But with the rise of the internet (and not just people screwing off at work watching youtube videos and steaming pandora ) and consolidated data centers and enterprise applications, etc.... The 80/20 rule has flipped to the 20/80 rule -- or if it's still the 80/20 rule it's flipped from local/remote to remote/local. So in most modern networks your understanding of ARP was only right about 20% of the time.

    icon_lol.gif

    Yeah icon_cheers.gif -- I finally found a use for that 80/20 -- 20/80 rule stuff I remember from my CCNA 1 Network Academy Daze....
    :mike: Cisco Certifications -- Collect the Entire Set!
  • Options
    hexemhexem Member Posts: 177
    Something extra to look into with ARP is man in the middle attacks and arp posioning and how easy it is for someone to sniff network traffic on a switch using gratious arp's, also remember that ARP is a layer 3 protocol.
    ICND1 - Passed 25/01/10
    ICND2 - Passed 9/03/10

    Studying CCNA:S
  • Options
    notgoing2failnotgoing2fail Member Posts: 1,138
    mikej412 wrote: »
    Wait a minute -- you're not getting off that easy.

    There used to be the 80/20 rule -- 80 percent of traffic was local and 20 percent went elsewhere..... so your original understanding of ARP would have been only 80% correct in the old days of networking.

    But with the rise of the internet (and not just people screwing off at work watching youtube videos and steaming pandora ) and consolidated data centers and enterprise applications, etc.... The 80/20 rule has flipped to the 20/80 rule -- or if it's still the 80/20 rule it's flipped from local/remote to remote/local. So in most modern networks your understanding of ARP was only right about 20% of the time.

    icon_lol.gif

    Yeah icon_cheers.gif -- I finally found a use for that 80/20 -- 20/80 rule stuff I remember from my CCNA 1 Network Academy Daze....

    Never even heard of the 80/20 rule. Does that make me exempt? LOL..

    I can see where you are getting at though. And with apps/servers being hosted at datacenters and even being virtualized puts a wrench into the mix...

    hexem wrote: »
    Something extra to look into with ARP is man in the middle attacks and arp posioning and how easy it is for someone to sniff network traffic on a switch using gratious arp's, also remember that ARP is a layer 3 protocol.


    You know what, I keep forgetting which layer ARP runs on. I guess the most important thing to remember is that since it's mapping an IP to MAC, then it best be a L3 protocol....
  • Options
    EMcCalebEMcCaleb Member Posts: 63 ■■■□□□□□□□
    Ok deep thought over....

    I think I get it now. So when a packet is going to a destination NOT on your local subnet, the PC doesn't even attempt to ARP at all right? It knows based on the subnet mask that it should just simply send the packet on its way to the gateway/router?


    As kalebksp alluded to, this isn't always the case. If there is not a default gateway the node will indeed attempt an ARP to find devices not on its local subnet. And depending on the IP stack implementation, even when there is a default gateway (but i'm shaky on this).

    Routers can be made aware of this issue by allowing them to perform "proxy arp". When proxy arp is used the arp cache starts looking really really strange on the host.

    Below I have turned off routing and not configured a default gateway on a router (thus it is now simply acting as a host). Here is the arp cache:

    Router#sh ip arp
    Protocol Address Age (min) Hardware Addr Type Interface
    Internet 10.10.10.10 2 cc01.11d8.0001 ARPA FastEthernet0/0
    Internet 208.242.1.54 0 cc01.11d8.0001 ARPA FastEthernet0/0
    Internet 187.2.53.11 0 cc01.11d8.0001 ARPA FastEthernet0/0
    Internet 172.16.40.4 - cc05.1204.0000 ARPA FastEthernet0/0

    As you can see, my attached address is 172.16.40.4. Since I have NOT set up a default gateway, and i have proxy-arp enabled up the upstream gateway, the cache is populated with the actual address, and the MAC is that of the gateway.

    Check out rfc 1027: http://tools.ietf.org/html/rfc1027

    HTH
Sign In or Register to comment.