12 Replies Latest reply: Aug 5, 2017 4:02 PM by Navneet.Gaur RSS

    ROAS lab. Unexpected results. Why?

    bav

      Evening folks,

       

      I have been reading the below doc and thought I would lab it on packet tracer. I managed to configure everything and ping between hosts. So far so good.

       

      Fundamentals of VLAN's - Router on a stick

       

      In section 3 part 2 the native vlan on the router is changed to vlan 2 creating a mismatch with the switch trunk link which is still using vlan 1 as the native vlan. According to the document this should result in an unsuccessful ping however I am still able to ping from host 1 to host 3 which are in different subnets. Why is this? Have I configured this wrong or is iOS doing something clever behind the scenes to get around the native vlan mismatch?

       

      i have copied the switch and router running config for reference. The topology is as per the above link. Only difference is my interface to vlan allocation but this shouldn't make a difference. I am using a 2960 switch and 1941 router.

       

      NB For some reason the running config does not show that I've put fa0/1 into vlan 1. Maybe I've missed that somewhere in the OCG but if I've done 'switchport access vlan 1' should it not show up in the running config?

      ----------------------------------------------------------

      Switch#show run

      Building configuration...

       

      Current configuration : 1203 bytes

      !

      version 12.2

      no service timestamps log datetime msec

      no service timestamps debug datetime msec

      no service password-encryption

      !

      hostname Switch

      !

      !

      !

      no ip domain-lookup

      !

      !

      spanning-tree mode pvst

      !

      interface FastEthernet0/1

      !

      interface FastEthernet0/2

      switchport access vlan 2

      !

      interface FastEthernet0/3

      switchport access vlan 3

      !

      interface FastEthernet0/4

      !

      interface FastEthernet0/5

      !

      interface FastEthernet0/6

      !

      interface FastEthernet0/7

      !

      interface FastEthernet0/8

      !

      interface FastEthernet0/9

      !

      interface FastEthernet0/10

      !

      interface FastEthernet0/11

      !

      interface FastEthernet0/12

      !

      interface FastEthernet0/13

      !

      interface FastEthernet0/14

      !

      interface FastEthernet0/15

      !

      interface FastEthernet0/16

      !

      interface FastEthernet0/17

      !

      interface FastEthernet0/18

      !

      interface FastEthernet0/19

      !

      interface FastEthernet0/20

      !

      interface FastEthernet0/21

      !

      interface FastEthernet0/22

      !

      interface FastEthernet0/23

      !

      interface FastEthernet0/24

      !

      interface GigabitEthernet0/1

      switchport mode trunk

      switchport nonegotiate

      !

      interface GigabitEthernet0/2

      !

      interface Vlan1

      no ip address

      shutdown

      !

      !

      !

      !

      line con 0

      logging synchronous

      exec-timeout 0 0

      !

      line vty 0 4

      login

      line vty 5 15

      login

      !

      !

      !

      end

       

       

      Switch#

      ------------------------------------------------------------------------

      Switch#show vlan br

       

      VLAN Name Status Ports

      ---- -------------------------------- --------- -------------------------------

      1 default active Fa0/1, Fa0/4, Fa0/5, Fa0/6

        Fa0/7, Fa0/8, Fa0/9, Fa0/10

        Fa0/11, Fa0/12, Fa0/13, Fa0/14

        Fa0/15, Fa0/16, Fa0/17, Fa0/18

        Fa0/19, Fa0/20, Fa0/21, Fa0/22

        Fa0/23, Fa0/24, Gig0/2

      2 VLAN0002 active Fa0/2

      3 VLAN0003 active Fa0/3

       

      ------------------------

       

      Switch#show int gi0/1 switchport

      Name: Gig0/1

      Switchport: Enabled

      Administrative Mode: trunk

      Operational Mode: trunk

      Administrative Trunking Encapsulation: dot1q

      Operational Trunking Encapsulation: dot1q

      Negotiation of Trunking: Off

      Access Mode VLAN: 1 (default)

      Trunking Native Mode VLAN: 1 (default)

      Voice VLAN: none

      Administrative private-vlan host-association: none

      Administrative private-vlan mapping: none

      Administrative private-vlan trunk native VLAN: none

      Administrative private-vlan trunk encapsulation: dot1q

      Administrative private-vlan trunk normal VLANs: none

      Administrative private-vlan trunk private VLANs: none

      Operational private-vlan: none

      Trunking VLANs Enabled: ALL

      Pruning VLANs Enabled: 2-1001

      Capture Mode Disabled

      Capture VLANs Allowed: ALL

      Protected: false

       

      --------------------------------------------------------

      Router#show run

      Building configuration...

       

      Current configuration : 1069 bytes

      !

      version 15.1

      no service timestamps log datetime msec

      no service timestamps debug datetime msec

      no service password-encryption

      !

      hostname Router

      !

      !

      !

      !

      !

      !

      !

      !

      no ip cef

      no ipv6 cef

      !

      !

      !

      !

      license udi pid CISCO1941/K9 sn FTX1524Q548

      !

      !

      !

      !

      !

      !

      !

      !

      !

      no ip domain-lookup

      !

      !

      spanning-tree mode pvst

      !

      !

      !

      !

      !

      !

      interface GigabitEthernet0/0

      no ip address

      duplex auto

      speed auto

      !

      interface GigabitEthernet0/0.1

      encapsulation dot1Q 1

      ip address 1.1.1.251 255.0.0.0

      !

      interface GigabitEthernet0/0.2

      encapsulation dot1Q 2 native

      ip address 2.1.1.251 255.0.0.0

      !

      interface GigabitEthernet0/0.3

      encapsulation dot1Q 3

      ip address 3.1.1.251 255.0.0.0

      !

      interface GigabitEthernet0/1

      no ip address

      duplex auto

      speed auto

      shutdown

      !

      interface Serial0/0/0

      no ip address

      clock rate 2000000

      shutdown

      !

      interface Serial0/0/1

      no ip address

      clock rate 2000000

      shutdown

      !

      interface Vlan1

      no ip address

      shutdown

      !

      ip classless

      !

      ip flow-export version 9

      !

      !

      !

      !

      !

      !

      !

      line con 0

      exec-timeout 99 0

      logging synchronous

      !

      line aux 0

      !

      line vty 0 4

      login

      !

      !

      !

      end

       

       

      Router#

        • 1. Re: ROAS lab. Unexpected results. Why?
          bav

          Edit. Some more detail on what I can and can't ping.

           

          From PC1 I can ping PC3 only.

          From PC2 I can't ping either PC1 or PC3.

          From PC3 I can only ping PC1.

          • 2. Re: ROAS lab. Unexpected results. Why?
            Navneet.Gaur

            Hi bav.

             

            1. I had done that lab a long time ago using a 2950 or a 3550 coupled with a router - actual gear.

             

            2. It is very late over here, so give me till tomorrow to go through your post & cross check the results. ( I am afraid I just skimmed through it as of now.)

             

            Take care,

            Navneet.

            • 3. Re: ROAS lab. Unexpected results. Why?
              raymond

              Hi Bav

               

              I labbed this up as well in PT and got the same results as you, however i believe that your results are correct with what should happen. I could very well be wrong (and very likely am) but the way i look at this is:

               

              PC1 sends ping to PC3 from 1.1.1.1, to 3.1.1.1, so the source is VLAN1 on the switch so it gets sent to the Router on the native VLAN. To the router, receives this untagged frame and assumes VLAN2, but it doesn't care about the source and routes the packet to the destination 3.1.1.1 on VLAN 3. being a tagged frame, it works fine to get there. On the return, it comes into the switch and router, on VLAN 3, the router has the route for VLAN 1, so it will tag the frame, the switch will receive it, remove the tag etc and know that its on VLAN 1 and pass as normal.

               

              From PC2 to PC1 however, its coming from VLAN 2 from the switch and the Native VLAN on the router. So, what happens, is when the switch receives the frame from PC2, it tags it with VLAN 2 and forwards to the router, all well and good there. The router knows that 1.1.1.1 is on VLAN 1, and tags the frame and again sends to the Switch who receives and removes the VLAN 1 tag etc and forwards as normal. Now, on the return path, PC1 is VLAN 1, so the frame from the switch is sent without a tag to the router, the router assumes this is received on VLAN 2 and sends an untagged frame back to the switch which assumes VLAN 1 and the frame gets lost there as it should be tagged as VLAN2.

               

              I don't think the router really cares where the packet comes from because it can read layer 3 and route the packet as opposed to switching the packet at layer 2.

               

              Thats at least what i would have thought, but i could/am very well be wrong. I'm curious to see the results of the real equipment though. Also, i hope what i said makes sense.

               

              Cheers

              • 4. Re: ROAS lab. Unexpected results. Why?
                Navneet.Gaur

                Hi bav.

                 

                1. I re-ran the lab and the ping results are consistent with the document.

                 

                2. Since both you and Raymond have checked the configuration on packet tracer, I did not try that. I need to mention here that packet tracer is not running an IOS internally.

                 

                https://learningnetwork.cisco.com/message/468871#468871

                 

                3. The IOS version that I used was 'Version 12.4(15)T7' on a 2651. The switches were 2950 & 3550 just as before.

                 

                4. Regarding  {..for scenario 3 would you not get an error message regarding overlapping of IP address when you try to change the address for fa0/1 to 2.1.1.251 and likewise for fa0/2?...}

                 

                That would be true. Therefore you would need to remove the ip address which has previously been configured on one of the interfaces before applying it to the next interface.

                 

                Take care,

                Navneet.

                 

                Note:

                Before you apply any new configuration, always default the configuration on the respective interfaces.

                default interface FastEthernet 0/0.1

                default interface FastEthernet 0/0.2

                default interface FastEthernet 0/0.3

                • 5. Re: ROAS lab. Unexpected results. Why?
                  Navneet.Gaur

                  Hi bav.

                   

                  1. In a purely emulated environment with IOS version 15 on the router, the results are similar to what you are witnessing. But I do not trust an emulated L2 switch.

                   

                  Not applicable.

                  2. That lead me to believe that it might be the IOS version. However, when I tried using IOS v.12.x in the same emulated environment, the results were again similar to the ones you have mentioned in this thread and in contrast with the results from the hardware platform mentioned previously.

                   

                  3. At present I do not have access to IOS v.15 on hardware platform except for predefined remote rack topologies. Finding a topology that is similar to the one I need - a router running IOS v.15, a switch & 3 connected independent end devices might be difficult. There are many that meet the first two requirements. I do not recollect seeing one that meets the underlined requirement, mainly because I never looked for it.

                   

                  4. For now I will leave my interpretation of the results unmodified.

                   

                  Take care,

                  Navneet.

                  • 6. Re: ROAS lab. Unexpected results. Why?
                    Navneet.Gaur

                    I have figured the issue and I am updating the document. The ping should fail, but the reasons are different.

                    • 7. Re: ROAS lab. Unexpected results. Why?
                      Navneet.Gaur

                      Hi bav.

                       

                      1. I have updated the documents Section 3 Situation 2 with the following content. Additional information is included in the narration within the document.

                       

                      The ARP problem

                      ARP can be considered to operate at Layer 2.5 from the perspective of Open System Interconnection model of networking.


                      The reasons are as follows:

                      • An ARP frame is limited to the local network boundary, network that can be reached by directly connected wires.
                      • In the addressing portion, this frame includes mac addresses to propagate itself within the network.
                      • The contents include the senders IP address as well as the Ip address whose MAC address needs to be resolved.


                      And here is the catch.

                      • If somehow an ARP frame reaches an interface that does not have the reverse path back to the sender IP address that is included in the contents section, the router drops that reply.
                      • The interesting part is that the contents of the frame are not "considered | supposed" to influence the routing decision.
                      • The routing decision is influenced by IP addresses in the addressing portion of the frame, which in this case comprises only of MAC addresses.



                      Scenario & Topology

                      *Click on the image to enlarge

                      Arp-1m.png

                      • Consider the above topology. When R1 tries to ping 1.2.1.2, it sends an arp request out of its interface because it considers 1.2.1.2 to be in the local network - 1.0.0.0 because of the mask of 255.0.0.0.
                      • However, when this arp resolution request reaches R2, after reading the contents - not the address field, R2 considers the reply to be directed for a network 1.0.0.0 that is not attached on the interface -{ Network 1.2.0.0 with a mask of 255.255.0.0 }- on which this request was received.
                      • Therefore, R2 drops the reply.

                       

                      R2#debug arp

                      *Mar  1 00:01:33.539: IP ARP req filtered src 1.1.1.1 c001.2ce8.0000, dst 1.2.1.2 0000.0000.0000 wrong cable, interface FastEthernet0/0


                      Conclusion

                      • That is the reason I consider ARP to operate at Layer 2.5 of the OSI model.
                      • Although its scope is limited to the directly connected network - Layer 2,
                      • it is still influenced by the IP networks - Layer 3, included in the contents while replying.

                       

                      2.

                      • The reason, ping fails in situation 2 is because the initial arp request from PC-1.1.1.1 is received by interface 0/0.2 that has an IP network 2.0.0.0.
                      • The request originated from IP network 1.0.0.0 - that information is included in the contents of the ARP frame.
                      • And interface 0/0.2 is unable to prepare the arp reply.
                      • Since the PC-1.1.1.1 fails to resolve the mac address of the gateway IP, it cannot prepare the ping frame directed towards 3.1.1.1 & ping is un-successful.


                      Updated:

                      3. It might be possible that the simulated/emulated network is not sending fresh arp queries to resolve the gateway mac address & using previous entry from the cache - as you have also mentioned in the next post.   tagging native vlans on the switch by default. That would explain the situation witnessed in this thread.


                      The command to attach tags to frames from all the valns on a trunk link is Switch(config)#vlan dot1Q native tag. Perhaps negating that might change the outcome in the simulated/emulated network


                      Take care,

                      Navneet.

                      • 8. Re: ROAS lab. Unexpected results. Why?
                        bav

                        Hi Navneet,

                         

                        Thanks for taking the time to reply and review this. I get what you are saying in theory with the ARP thing. Maybe the arp tables in my PT topology was already populated due to successful pings earlier in the scenario. I will try it again with some real gear at some point.

                         

                        Raymond - thanks also for trying this out.

                         

                        I'm not clear on why PT is behaving differently but will not dwell on that for now so I can continue going through the OCG.

                        • 9. Re: ROAS lab. Unexpected results. Why?
                          Navneet.Gaur

                          Hi bav.

                           

                          1. Not a problem.

                           

                          2. Packet tracer is the least reliable option for learning networking because it works with pre-defined set of scenarios programmed into it unlike GNS3/VIRL/Cisco CCIE Lab builder which run the actual IOS that 'responds' to the commands entered.

                           

                          But all of these to have their limitations as well. Actual hardware is the final option.

                           

                          3. The explanation about address resolution protocol is what really goes on in practice. Most, not all -{ not the router on a stick part, for one }- of it can be verified using emulators running actual IOS - GNS3/VIRL/Cisco CCIE Lab builder.

                           

                          The command that is useful for the given scenario is Router#debug arp.

                           

                          4. There is one more old post that I would suggest that you go through as it may help you.

                          Exam Preparation - My Suggestions

                           

                          Good luck & take care,

                          Navneet.

                          • 10. Re: ROAS lab. Unexpected results. Why?
                            bav

                            That's a very useful doc thanks. Actually I was looking at your index of docs and am going to try go through as many of them as I can as I go along with the material from the OCG.

                             

                            I recently got the following gear on eBay.

                            3 x 2801 (15.1)

                            3550

                            2960

                             

                            I also have a 2950 lying around at home I got previously. Hoping this should all be enough for CCNA.

                            • 11. Re: ROAS lab. Unexpected results. Why?
                              Navneet.Gaur

                              Hi bav.

                               

                              The gist:

                              • Windows PC generates ARP request for the gateway every 30 seconds - (approximately).
                              • Therefore even if the MAC address has been resolved previously, windows PC would still send an arp query for its gateway address.
                              • Accordingly, any changes at the gateway, would impact the ARP entry on the PC approximately every 30 seconds and not after arp timeout duration.

                               

                              1. To conclude this discussion, I need to account for one more factor.

                               

                              2. My setup included a Cisco router, a Cisco switch and three computers running different versions of windows.

                              *Click on the image to enlarge

                              Windows ARP Query.png

                               

                              3. Windows PC running Windows version 7 sent an arp query to resolve the mac address of its gateway - 1.1.1.251, approximately every 30 seconds, irrespective of the fact that it was already present in the arp cache.

                               

                              4. For a setup that would have been modified -{ in contrast with a completely fresh & new configuration where an address resolution protocol (arp) query would be generated by necessity }- that is one of the factors that influenced the new arp request to be generated by the PC and rejected by the routers Fa0/0.2 interface with an IP address of 2.1.1.251 (even though the mac address for 1.1.1.251 was already present in the local cache of the PC & same for all sub-interfaces on router).

                               

                              5. That brings me to the final point.

                              • This applies to a setup, that is modified according to scenarios, with already running devices,
                              • And not a new & fresh configuration on freshly powered on devices, where an arp query would be generated by default.


                              • Had the PC not generated a new arp request,
                              • when it already had the mac address for the main FastEthernet interface of the router
                              • & used the entry from the cache,
                              • it is very much likely that the pings would have succeeded.

                               

                              Take care,

                              Navneet.

                              • 12. Re: ROAS lab. Unexpected results. Why?
                                Navneet.Gaur

                                Hi bav.

                                 

                                1. Fantastic !

                                bav wrote:

                                 

                                That's a very useful doc thanks. Actually I was looking at your index of docs and am going to try go through as many of them as I can as I go along with the material from the OCG.

                                 

                                I recently got the following gear on eBay.

                                3 x 2801 (15.1)

                                3550

                                2960

                                 

                                I also have a 2950 lying around at home I got previously. Hoping this should all be enough for CCNA.

                                 

                                2. That is sufficient gear for studies. 2950's are an extremely 'valuable' asset. Despite being very inexpensive they can still be used to verify outcome of variations in topologies.

                                 

                                3. Although you will have sufficient equipment in your hands very soon, there is one more document that presents a few scenarios to work on with lessor amount of gear. You can work on those as well to get a better understanding.

                                 

                                Document - 21 Simple Lab Suggestions For Beginners

                                https://learningnetwork.cisco.com/docs/DOC-26737

                                 

                                4. Good luck and I am sure that very soon you will be able to work on the router on a stick configuration till it satisfies all your queries.


                                Take care,

                                Navneet.