Here’s a new scenario to think about. I haven’t built it in a lab yet, but I think it might be interesting and it just might work.
Switches A and B are connected by a single link. The configurations for each end of the link are shown in the figure below. PCs A, B, and C are connected to access interfaces assigned to VLANs 10, 20, and 30, respectively, on Switch A. PC X is connected to an interface on Switch B, which has the interface configuration shown.
Assuming that the switches are configured for Layer 2 traffic only, which one of the following can PC X reach?
A. PC A
B. PC B
C. PC C
D. None of the above
Enjoy,
Dave H
Advertisement
June 12, 2010 at 6:32 pm
[...] http://dhucaby.wordpress.com/2010/06/11/new-scenario-vlan-trunking-1/ [...]
June 12, 2010 at 6:36 pm
Hey guys:
I went ahead and lab’ed this up. I didn’t want to give away the answer whether it’s right or wrong so if you want to check it out, feel free to click the link and check out my results.
http://www.brandontek.com/?p=366
June 12, 2010 at 8:18 pm
PLEASE DON’T READ as this may contain the answer.. (then again I may be wrong
)
.
.
.
.
from what I can see it would be PC-A only
my resoning is as follows
traffic comming from PC-A is on vlan 10, and the trunk is set up as native VLAN 10. (traffic in the native vlan is not tagged)
so will be sent acrss the trunk as untaged trafficc. on reaching switch B which has native vlan 20 this untagged traffic will be retagged as VLAN 20, PC-X is also in VLAN 20 so traffic will be forwarded correctly.
This is the basic of VLAN hopping attack, by exploiting the native vlan untagging packets.
for other reasons PC-b and PC-C will not work but I won’t post why here.
June 12, 2010 at 8:23 pm
oh annd switch port host is a macro that among other things set the port mode to access, (so then the switch port access vlan 20 takes affect)
Not labed this up so this is a work it out in my head job.
June 14, 2010 at 9:10 pm
DH::: the frame leaves PCx going thru Switch_B and is tagged with
Vlan 20 right? It’s allowed on the link and travels to Switch_A. When
the frame gets there the tag is removed by Switch_A and forwarded to PCb
But in the book it says native vlans have to match on each sides
if it doesn’t it might create problems, in this case i’m not sure if we’re even
using the native vlan because the frame is tagged originally. Let me know. Thanks
June 15, 2010 at 11:51 am
When NATIVE VLANs do not match on each end of the 802.1q trunk there is a potential for spanning tree loops and the STP will place the mismatching VLANs in inconsistent state. Which are VLANS 10 AND 20 in this case. All other VLANS (VLAN 30) will be tagged as they cross the trunk.
So, in this case PC X will be able to communicate to PC C only.
Dave, to answer the question from your email, I did not take the exam yet, but if i did answer this question right i will schedule the exam today.
)
Regards,
Sinisa
June 15, 2010 at 12:34 pm
but on switch A PC x is in vlan 20? so how could it talk to PC C on vlan 30?
if the switch port to PC x was access valn 30 then yes it could talk to C, but this is not the case?
June 15, 2010 at 12:58 pm
Sinisa::: But the book says that you can definitely have different native Vlans on each ends of the trunk but if you do that it might create problems only when you’re using the native Vlans. These frames are tagged Vlan20, it is not going in untagged, it is not using the native Vlan. right? so why would it go to Vlan 30?
June 15, 2010 at 1:04 pm
Wow, if you were able to make sense out of this scenario, more power to you! First of all, I failed by not double-checking my command syntax for the two switches… I’ve corrected the commands in the blog post figure.
Next, I came up with this idea late at night, sitting in the dark. Here was my original goal: PC-X ends up on access VLAN 20 on switch B. Switch B tries to negotiate a dot1q trunk with switch A, which is successful. B permits VLANs 20 and 30 to cross, but uses VLAN 20 as its native (untagged) VLAN. Switch A trunks unconditionally, allows VLANs 10, 20, and 30 to cross, but uses VLAN 10 as its native VLAN. So far, so good… So PC-X starts out on VLAN 20, but gets crossed over to VLAN 10 because of the misconfigured native VLANs on either end of the trunk. In my mind, only PC-A would be reachable because it sits on VLAN 10.
Well, so much for that. I didn’t count on the switches being so smart. I also didn’t count on STP governing things. The folks who built this scenario in a lab discovered what really happens – both Switches A and B detect the native VLAN mismatch and break the STP topology on some of the VLANs that cross the trunk.
On Switch B:
SwitchB#show spanning-tree int gig1/0/49
Vlan Role Sts Cost Prio.Nbr Type
——————- —- — ——— ——– ——————————–
VLAN0020 Desg BKN*4 128.3 P2p *PVID_Inc
VLAN0030 Root FWD 4 128.3 P2p
SwitchB#
Notice that VLAN 20 is in the “BKN” or broken state on the trunk. And on Switch A:
SwitchA#show spanning int gig1/0/49
Vlan Role Sts Cost Prio.Nbr Type
——————- —- — ——— ——– ——————————–
VLAN0010 Desg BKN*4 128.43 P2p *PVID_Inc
VLAN0020 Desg BKN*4 128.43 P2p *PVID_Inc
VLAN0030 Desg FWD 4 128.43 P2p
SwitchA#
Because the native VLAN didn’t match the other end of the trunk, Switch A has put both VLANs 10 and 20 into the broken state, with only VLAN 30 functioning. PC-X sits on VLAN 20, so he is cut off from the world. To my surprise, answer D (none of the above) is the correct answer!
So, was this scenario a total failure? I hope not. The goal here was to get us thinking about interface and trunk configurations, negotations, and so on. Now we know that we should also think about STP and native VLAN mismatches.
(By the way, this scenario probably isn’t as difficult as what you will find on the exam. I was hoping to stir lots of thought processes, rather than post an accurate representation of an exam question. If you are able to think this scenario through and follow along with why PC-X can’t communicate with anyone, even after this explanation, you should be able to think through any VLAN-based design scenario exam question!)
I’ll make sure the next scenarios work before posting them.
Dave H
June 15, 2010 at 12:56 pm
Hey guys:
Did anyone check out my lab? I went ahead and tried his scenario. I’m not really sure what the “supposed” outcome is suppose to be.
http://www.brandontek.com/?p=366
June 15, 2010 at 1:13 pm
oh i thought i posted on you blog???
I did notice you highlighted the native vlan on the port to pc X
but native vlan is only important on trunks.
the switchport host command means the port is in access mode, so PC x is in vlan 20.
and all the switch port voice vlans are not important as all ports are either access or trunk.
June 15, 2010 at 1:20 pm
Nope I have no comments. =(
DH does commented, looks like in this current scenario, answer “D” is in fact the correct choice!
Whew! I feel a little better now!
June 15, 2010 at 1:21 pm
Sorry,I mean DH “just” commented, not “does” commented…wow, what a typo!
June 15, 2010 at 5:29 pm
DH::: Why do we specify a native vlan on the access switchport? isn’t suppose to be specified in the trunk only?
June 15, 2010 at 1:34 pm
Ahh I think this dependes what switches you use (or what ios version) before you could get the native vlan mismatch to forward traffic and hop vlans
June 15, 2010 at 2:25 pm
Dave,
Why wouldn’t you be able to have “Layer 2″ communication between PC X and PC C?
switchport voice vlan only tells the switch to tag voice traffic and inserts the Cos bits inside the 802.1p encapsulation feild…
I.M.H.O
I am not sure you would ever do something like this but I do belive that you should have Layer 2 connectiviry between PC X and PC C.
To me, “Layer 2 traffic only” were the key words in picking the anwser C..otherwise i would have picked d)none of the above.
Regards,
Sinisa
June 15, 2010 at 2:38 pm
PC x = vlan 20
PC C = vlan 30
so no layer 2 connevticity.
June 15, 2010 at 3:08 pm
switchport voice vlan 30 is there, which would require a phone to be next to the pc x.. and a trunk to be formend in order for VLAN 30 to work…
ahh…i am over-analyzing…….sorry..
June 15, 2010 at 2:28 pm
i might just be over-analyzing and over-thinking…
June 15, 2010 at 11:07 pm
oh of course default mode is pvstp so stp gets broken with native vlan mismatch!!! if you have common stp it all runs over vlan 1 (even if that is not native and disababled). In this case stp will still be ok and mismatched native trunks should work.
October 18, 2010 at 7:09 am
Hello, how are Davied?
i am really happy to find a way to contact you, so many thanks for you.
what’s a great blog to interact with such a great engineer like you.
i have a questions about your lab solution;
1-what is Brocken state?
2-when interface going in brocked state for certain VLAn?
3-Is it blocked port? if so what is the difference bet brocken and blocked?
4-how BPDUs exchange work to determine the brocken state?
i am so sorry for wasting your time, and thank you again.
March 14, 2011 at 1:31 pm
Hello Guys!
Dave, thank you for all the good stuff in this blog!
I have something interesting to share:
Indeed the STP detected the native VLAN mismatch and broke the topology.
The result is different if you prune the native vlan from the trunk on one side only:
On switch A: vlan 10 is pruned from the trunk:
interface FastEthernet1/0/1
switchport access vlan 20
switchport trunk encapsulation dot1q
switchport trunk native vlan 10
switchport trunk allowed vlan 20,30
switchport mode trunk
switchport voice vlan 30
no cdp enable
end
There is a native VLAN mismatch but STP does not complain about it. ALL the ports are in forwarding state everywhere:
SwitchA#sh spanning-tree int fastEthernet 1/0/1
Vlan Role Sts Cost Prio.Nbr Type
—————- —- — ——— ——– ——————————–
VLAN0020 Desg FWD 19 128.3 P2p
VLAN0030 Desg FWD 19 128.3 P2p
SwitchA#
SwitchB#sh spanning-tree int gigabitEthernet 1/0/1
Vlan Role Sts Cost Prio.Nbr Type
—————- —- — ——— ——– ——————————–
VLAN0020 Root FWD 19 128.1 P2p
VLAN0030 Root FWD 19 128.1 P2p
Now, here is the trick, on switchA, I just add the vlan 10 on the trunk:
SwitchA(config)#int fastEthernet 1/0/1
SwitchA(config-if)#swit
SwitchA(config-if)#switchport tru
SwitchA(config-if)#switchport trunk allowed vlan add 10
SwitchA(config-if)#
01:11:03: %SPANTREE-2-RECV_PVID_ERR: Received BPDU with inconsistent peer vlan id 20 on FastEthernet1/0/1 VLAN10.
01:11:03: %SPANTREE-2-BLOCK_PVID_PEER: Blocking FastEthernet1/0/1 on VLAN0020. Inconsistent peer vlan.
01:11:03: %SPANTREE-2-BLOCK_PVID_LOCAL: Blocking FastEthernet1/0/1 on VLAN0010. Inconsistent local vlan.
SwitchA(config-if)#end
SwitchA#sh span int fa
SwitchA#sh span int fastEthernet 1/0/1
Vlan Role Sts Cost Prio.Nbr Type
—————- —- — ——— ——– ——————————–
VLAN0010 Desg BKN*19 128.3 P2p *PVID_Inc
VLAN0020 Desg BKN*19 128.3 P2p *PVID_Inc
VLAN0030 Desg FWD 19 128.3 P2p
SwitchA#
So, it seems that if there is a native vlan mismatch on a trunk, there is no problem as long as the native vlan is not allowed on the trunk (pruned).
Now, if the native vlan is pruned from the trunk (as recommended in SWITCH book Pg 405) and not used for any host, there will be no spanning tree instance
for this VLAN although the VLAN exists and is active:
interface FastEthernet1/0/1
switchport access vlan 20
switchport trunk encapsulation dot1q
switchport trunk native vlan 10
switchport trunk allowed vlan 20,30
switchport mode trunk
switchport voice vlan 30
no cdp enable
end
SwitchA#sh spanning-tree vlan 10
Spanning tree instance(s) for vlan 10 does not exist.
Why not?Does that mean that there is no bridge loop possible for native VLAN 10? Hhmmh….
June 10, 2011 at 7:03 pm
While we’re on the topic of trunking, I had a question about the default DTP mode. According to the 642-813 OCG, the default DTP mode is “Dynamic Desirable”. However, when I attempt to configure DTP on the Catalyst 2960, “Dynamic Auto” shows up as the default setting. My question is: which would be default mode for the purpose of the 642-813 exam?
June 14, 2011 at 3:34 pm
Hi negi,
Thanks for your excellent question. It looks like this is one of those things that Cisco has decided to change over time. I dug through quite a few command references just now and found that the default on most of the current access layer switches is indeed dynamic auto. The default mode used to be dynamic desirable, so I need to get that corrected in the 642-813 OCG book right away.
I apologize for the book’s error. I’ve been writing new editions of it for many years now, as the switching exams get updated. Unfortunately, this is one of those things that slipped on through without getting caught – until now.
Best regards,
Dave H
June 14, 2011 at 7:30 pm
Dave,
Thanks for getting back to me on this one. I bet it’s hard to keep a textbook current when Cisco keeps updating the CLI commands.
Thanks,
Negi