Skip navigation
Login   |   Register
Cisco Learning Home > Certifications > CCIE Routing & Switching > Discussions

_Communities

This Question is Answered 2 Helpful Answers available (2 pts)
5881 Views 20 Replies Latest reply: Apr 29, 2011 3:40 PM by imatiger1 RSS 1 2 Previous Next

Currently Being Moderated

ARP and classless subnets

Apr 29, 2011 8:05 AM

imatiger1 89 posts since
Feb 22, 2011

Hi all,

Please excuse me if my question is very basic J

I want to understand rally how ARP work !!!

I have two PC connected to the same VLAN 20 :

- PC A with IP address 172.16.10.1/24

- PC B with IP address 172.16.10.129/25

 

The default gateway is not set in the two PC.

 

In my sense when i ping PC B from PC A, I should find in the ARP table of PC A information about PC B Mac address. In fact, PC A will check if PC B is in the same subnet and will flood its ARP request with the IP address of the PC B.

I tested this scenario in a lab, but PC A has not any information about PC B Mac address in its arp table. When I put PC A and PC B in the same subnet (/24), I can see Mac addresses in the arp table. Please can you tell me what this scenario does not work ?

As in know, ARP does not carry any information about Mask. So, how ARP can work in classless subnets ?

 

Thanks,

 

ima

  • Justin G. Mitchell - CCIE #28160 166 posts since
    Jun 26, 2008
    Currently Being Moderated
    1. Apr 29, 2011 8:37 AM (in response to imatiger1)
    Re: ARP and classless subnets

    PC B views the address of PC A as being in a different subnet. When it goes to communicate with it, PC B will try and send its response to the default gateway for routing. In this case, you don't have a default gateway set on PC B so it drops the packet as unrouteable.

    Join this discussion now: Login / Register
  • Keith Barker - CCIE RS/Security, CISSP 5,327 posts since
    Jul 3, 2009
    Currently Being Moderated
    2. Apr 29, 2011 10:34 AM (in response to imatiger1)
    Re: ARP and classless subnets

    Hello ima-

     

    When PC A sends an ARP request, PC B will see it, but due to the fact that ARP is for an IP on a non local subnet, the PC won't respond.

     

    When done with 2 routers, directly connected, it would look like this (which includes the debug of arp):

     

    R1#show ip int fa0/0 | include Internet address

      Internet address is 172.16.10.1/24

    R1#


    R1#debug arp

    ARP packet debugging is on

    R1#ping 172.16.10.129

     

    Type escape sequence to abort.

    Sending 5, 100-byte ICMP Echos to 172.16.10.129, timeout is 2 seconds:

     

    IP ARP: creating incomplete entry for IP address: 172.16.10.129 interface FastEthernet0/0

    IP ARP: sent req src 172.16.10.1 c200.0202.0000,

                     dst 172.16.10.129 0000.0000.0000 FastEthernet0/0.

    IP ARP: sent req src 172.16.10.1 c200.0202.0000,

                     dst 172.16.10.129 0000.0000.0000 FastEthernet0/0.

    IP ARP: sent req src 172.16.10.1 c200.0202.0000,

                     dst 172.16.10.129 0000.0000.0000 FastEthernet0/0.

    IP ARP: sent req src 172.16.10.1 c200.0202.0000,

                     dst 172.16.10.129 0000.0000.0000 FastEthernet0/0.

    IP ARP: sent req src 172.16.10.1 c200.0202.0000,

                     dst 172.16.10.129 0000.0000.0000 FastEthernet0/0.

    Success rate is 0 percent (0/5)

    R1#


    *******************


    R2#show ip int fa 0/0 | inc Internet address

      Internet address is 172.16.10.129/25

    R2#

    R2#debug arp

    ARP packet debugging is on

    R2#

    IP ARP req filtered src 172.16.10.1 c200.0202.0000, dst 172.16.10.129 0000.0000.0000 wrong cable, interface FastEthernet0/0

    R2#

    IP ARP req filtered src 172.16.10.1 c200.0202.0000, dst 172.16.10.129 0000.0000.0000 wrong cable, interface FastEthernet0/0

    R2#

    IP ARP req filtered src 172.16.10.1 c200.0202.0000, dst 172.16.10.129 0000.0000.0000 wrong cable, interface FastEthernet0/0

    R2#

    IP ARP req filtered src 172.16.10.1 c200.0202.0000, dst 172.16.10.129 0000.0000.0000 wrong cable, interface FastEthernet0/0

    R2#

     

    ARP is always local to the network segment, so a PC B (in this case R2) sees the broadcast request, but doesn't respond due to the wrong subnet/network.

     

    R1/PC A believes it is on 172.16.10.0

    R2/PC B believes it is on 172.16.10.128

     

    Best wishes,

     

    Keith

     

    Message was edited by: Keith Barker - CCIE RS/Security, CISSP, CCSI

    Join this discussion now: Login / Register
  • Conwyn 9,675 posts since
    Sep 10, 2008
    Currently Being Moderated
    3. Apr 29, 2011 9:07 AM (in response to imatiger1)
    Re: ARP and classless subnets

    Hi Imatiger

     

    A is within 172.16.10.1 - 254

    B                             129-254

     

    So A should be able to ping B

     

    Regards Conwyn

    Join this discussion now: Login / Register
  • Keith Barker - CCIE RS/Security, CISSP 5,327 posts since
    Jul 3, 2009
    Currently Being Moderated
    4. Apr 29, 2011 9:17 AM (in response to Conwyn)
    Re: ARP and classless subnets
    A is within 172.16.10.1 - 254

    B                             129-254

     

    Is it possible that PC B sees that the ARP request is from an IP (embedded in the request) that is in a non local network (not off its 172.16.10.129/25 interface), and doesn't accept or respond to the ARP, and that is where it all ends?

    Join this discussion now: Login / Register
  • Conwyn 9,675 posts since
    Sep 10, 2008
    Currently Being Moderated
    6. Apr 29, 2011 10:05 AM (in response to imatiger1)
    Re: ARP and classless subnets

    Hi Imatiger

     

    As long as the smallest sub-net contains both address you are OK

     

    Regards Conwyn

     

    R1

     

    !
    interface FastEthernet0/0
    ip address 10.0.0.126 255.255.255.0
    duplex auto
    speed auto
    end

    R1#ping 10.0.0.129  

    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 10.0.0.129, timeout is 2 seconds:
    !!!!!
    Success rate is 100 percent (5/5), round-trip min/avg/max = 92/136/168 ms

    R2

     

    R2#show runn int fa0/0
    Building configuration...

    Current configuration : 95 bytes
    !
    interface FastEthernet0/0
    ip address 10.0.0.129 255.255.254.0
    duplex auto
    speed auto
    end

    Join this discussion now: Login / Register
  • Keith Barker - CCIE RS/Security, CISSP 5,327 posts since
    Jul 3, 2009
    Currently Being Moderated
    8. Apr 29, 2011 10:28 AM (in response to Conwyn)
    Re: ARP and classless subnets

    R1

    interface FastEthernet0/0

    ip address 10.0.0.126 255.255.255.0

     

    R2

    interface FastEthernet0/0

    ip address 10.0.0.129 255.255.254.0

    Ima- You are right, there is no mask identified in the ARP request/reply.

     

    So in the example in the shaded area above,

     

    R1 thinks the network is 10.0.0.0

    R2 thinks the network is 10.0.0.0

     

    Seems like they both believe they are on the same network. 

     

    That is why the 2 devices above can ping each other.

     

    ********************

     

    In your original question,

     

    PCA believes it is on 172.16.10.0

    PCB believes it is on 172.16.10.128

     

    Which is why the PCA and PCB ARPs are failing to complete, and why the ping doesn't work.

     

    At least that is how I see it.     I am always open to learning something new, and often I do.

     

    Best wishes,

     

    Keith

    Join this discussion now: Login / Register
  • Keith Barker - CCIE RS/Security, CISSP 5,327 posts since
    Jul 3, 2009
    Currently Being Moderated
    9. Apr 29, 2011 10:32 AM (in response to imatiger1)
    Re: ARP and classless subnets

    imatiger1 wrote:

     

    in fact, even when i test in the other direction, PC B is not able to ping PC A !!!!

     

     

    PCB doesn't believe it is connected to the 172.16.10.0 network (where the arp would be directed), to it doesn't even send out an arp request.

     

    If PCB, had a default gateway, it would ARP or that, and then forward the ping packet to the L2 address of the default gateway, with the L3 info directing the PING request to 172.16.10.1

     

    Keith

    Join this discussion now: Login / Register
  • Justin G. Mitchell - CCIE #28160 166 posts since
    Jun 26, 2008

    The ARP is sent to the broadcast address and the reply to the ARP is unicast back to the requestor. That is why ARP between devices in different networks don't work.

     

    In the original question, the IP address of PC B falls within the network of PC A. However, PC A is not in PC B's network so PC B will attempt to send the response through a gateway it doesn't have.

     

    In the second example you give, 10.0.0.126 and 10.0.0.129 ARE both covered by the provided subnet masks and won't route the repsonse through a gateway.

    Join this discussion now: Login / Register
  • Keith Barker - CCIE RS/Security, CISSP 5,327 posts since
    Jul 3, 2009
    Currently Being Moderated
    Re: ARP and classless subnets

    <snip>

     

    The ARP is sent to the broadcast address and the reply to the ARP is unicast back to the requestor. That is why ARP between devices in different networks don't work.

     

    In the original question, the IP address of PC B falls within the network of PC A. However, PC A is not in PC B's network so PC B will attempt to send the response through a gateway it doesn't have.


    <snip>

    Hi -

     

    Fun discussion!

     

    It is unicast back to the sender, as a L2 unicast, on the same interface the ARP request was received on.

     

    Two PCs that wont talk.png


    We don't respond to a ARP request seen on interface 1, by routing the response through interface 2.   It is always going to be local.


    R2(config-if)#do show arp

    Protocol  Address          Age (min)  Hardware Addr   Type   Interface

    Internet  23.0.0.2                -   c201.0202.0001  ARPA   FastEthernet0/1

    Internet  172.16.10.129           -   c201.0202.0000  ARPA   FastEthernet0/0

    R2(config-if)#do show ip route

    Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

           D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

           N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

           E1 - OSPF external type 1, E2 - OSPF external type 2

           i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

           ia - IS-IS inter area, * - candidate default, U - per-user static route

           o - ODR, P - periodic downloaded static route

     

    Gateway of last resort is 23.0.0.3 to network 0.0.0.0

     

         23.0.0.0/24 is subnetted, 1 subnets

    C       23.0.0.0 is directly connected, FastEthernet0/1

         172.16.0.0/25 is subnetted, 1 subnets

    C       172.16.10.128 is directly connected, FastEthernet0/0

    S*   0.0.0.0/0 [1/0] via 23.0.0.3

    R2(config-if)#do show debug

    ARP:

      ARP packet debugging is on

     

     


    R1 sends a ping to 172.16.10.129, which R1 believes is local off of its Fa0/0, and we can see the results via debug arp output on R2:

     

    R2(config-if)#

    IP ARP req filtered src 172.16.10.1 c200.0202.0000, dst 172.16.10.129 0000.0000.0000 wrong cable, interface FastEthernet0/0

    R2(config-if)#

    IP ARP req filtered src 172.16.10.1 c200.0202.0000, dst 172.16.10.129 0000.0000.0000 wrong cable, interface FastEthernet0/0

    R2(config-if)#

    IP ARP req filtered src 172.16.10.1 c200.0202.0000, dst 172.16.10.129 0000.0000.0000 wrong cable, interface FastEthernet0/0

    R2(config-if)#

    IP ARP req filtered src 172.16.10.1 c200.0202.0000, dst 172.16.10.129 0000.0000.0000 wrong cable, interface FastEthernet0/0

    R2(config-if)#

     


    Although R2 has a default route, it won't even try to use it regarding the ARP request it received on Fa0/0 as shown above.

     

    Keith

    Join this discussion now: Login / Register
  • Justin G. Mitchell - CCIE #28160 166 posts since
    Jun 26, 2008

    Sorry, yes the ARP is responded to and MAC addresses will appear in the mac-address table on the PCs. What he originally asked is why he can't ping if even the PCs can see each other which is due to the PC subnet issue.

    Join this discussion now: Login / Register
  • Rockribbed 49 posts since
    Apr 20, 2011
    Currently Being Moderated
    13. Apr 29, 2011 11:55 AM (in response to imatiger1)
    Re: ARP and classless subnets

    hope this would help you is clearing the concept ..

     

    ICMP vs. ARP

    If traditional ICMP-based pings are no longer reliable unless you know in advance that there is no firewall blocking ICMP echo requests, what other options exist? One option is an Address Resolution Protocol (ARP) based ping using the arping utility.

    To know why ARP pings are virtually guaranteed to work while ICMP pings may not, one should understand the importance of ARP in networking. ARP is used by hosts on a network to resolve IP addresses into Media Access Control (MAC) addresses, which can be interpreted as a network interface's unique serial number. Hosts on an Ethernet network use MAC addresses rather than IP addresses to communicate.

    When a host tries to create a connection to another host (on the same subnet), it first needs to obtain the second host's MAC address. In this process, Host A sends an ARP request to the broadcast address of the subnet to which it is connected. Every host on the subnet receives this broadcast, and the host with the IP address in question sends an ARP reply back to Host A with its MAC address. After receiving the ARP reply from Host B, Host A can connect to Host B.

    ARP is required for an Ethernet network to function properly, so it typically is not blocked by a firewall. If ARP requests were blocked, no host would be able to "find" a computer on a network and connect to it. For all intents and purposes, the system would be unplugged from the network.

    (Tools do exist to filter ARP. The ebtables project provides these tools. Ebtables is similar in both functionality and syntax to iptables, but whereas iptables works with TCP and UDP protocols, ebtables works with ARP.)

    One possible drawback to this system of using ARP to ping a host is that the ARP protocol is not a routed protocol. If you are not on the same subnet as the host you are trying to connect to, then this method is not going to work without first joining that subnet, which may or may not be physically possible. Thus by sending an ARP request rather than an ICMP echo, you are virtually guaranteed to get a reply.

    Let's explore the most convenient ways to obtain ARP replies.

    ARP table

    When you attempt to ping an IP address, an ARP request is sent at the same time. Your firewall may be blocking the ICMP echo, but chances are the computer will receive an ARP reply. Your computer's ARP table will contain the IP address and MAC address of the host you are trying to reach.

    Join this discussion now: Login / Register
  • Keith Barker - CCIE RS/Security, CISSP 5,327 posts since
    Jul 3, 2009
    Currently Being Moderated
    Re: ARP and classless subnets

    Justin G. Mitchell - CCIE #28160 wrote:

     

    Sorry, yes the ARP is responded to and MAC addresses will appear in the mac-address table on the PCs. What he originally asked is why he can't ping if even the PCs can see each other which is due to the PC subnet issue.

     

    I guess the mac address appearing in the ARP cache would depend on if the other PC responded to the ARP request.   The routers, at least, will not respond to the bogus network ARP request, and as a result, no ARP cache entry for the peer will appear in either device.

     

    Two PCs that wont talk.png

     

    If we hard coded the L3 to L2 mappings, then the ARP wouldn't be a problem, and it would turn into a routing issue at L3 at that point.

     

    Keith

    Join this discussion now: Login / Register

Actions

More Like This

  • Retrieving data ...

Bookmarked By (0)