1 2 Previous Next 20 Replies Latest reply: Apr 29, 2011 3:40 PM by imatiger1 RSS

    ARP and classless subnets

    imatiger1

      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

        • 1. Re: ARP and classless subnets
          Justin G. Mitchell - CCIE #28160

          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.

          • 2. Re: ARP and classless subnets
            Keith Barker - CCIE RS/Security, CISSP

            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

            • 3. Re: ARP and classless subnets
              Conwyn

              Hi Imatiger

               

              A is within 172.16.10.1 - 254

              B                             129-254

               

              So A should be able to ping B

               

              Regards Conwyn

              • 4. Re: ARP and classless subnets
                Keith Barker - CCIE RS/Security, CISSP
                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?

                • 5. Re: ARP and classless subnets
                  imatiger1

                   

                  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.

                   

                  Best wishes,

                   

                  Keith

                  Hi Keith,

                  but the problem that arp request do not carry any information about the subnet Mask. So PC B do not know that PC A has a different subnet mask !!!!! is it true ???

                  thank you for your help;

                  ima

                  • 6. Re: ARP and classless subnets
                    Conwyn

                    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

                    • 7. Re: ARP and classless subnets
                      imatiger1

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

                      • 8. Re: ARP and classless subnets
                        Keith Barker - CCIE RS/Security, CISSP

                        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

                        • 9. Re: ARP and classless subnets
                          Keith Barker - CCIE RS/Security, CISSP

                          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

                          • 10. Re: ARP and classless subnets
                            Justin G. Mitchell - CCIE #28160

                            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.

                            • 11. Re: ARP and classless subnets
                              Keith Barker - CCIE RS/Security, CISSP

                              <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

                              • 12. Re: ARP and classless subnets
                                Justin G. Mitchell - CCIE #28160

                                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.

                                • 13. Re: ARP and classless subnets
                                  Rockribbed

                                  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.

                                  • 14. Re: ARP and classless subnets
                                    Keith Barker - CCIE RS/Security, CISSP

                                    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

                                    1 2 Previous Next