Wednesday, I blogged about how you can infer that the frame from Monday’s question is in VLAN 2 based on the contents of the MAC address table. Today, I’ll pick up the story, and follow the frame’s path – both to find the “right” answers in the list, as well as refine a few points beyond those answers about why the network is working like it is.
Let’s start with a description of what I configured in the lab when building this question. I built this late last week, in part for one of the new videos I’m adding to a new edition of the CCNA Video Mentor product. Anyway, for perspective: I configured SW1 to be the root of the STP topology for VLAN 2, and I removed VLAN 2 from the allowed VLAN list on SW3’s Gi0/2 interface (using the “switchport trunk allowed vlan remove 2” interface subcommand). Other than that, I took all default settings for anything that mattered to this lab.
(By the way, that new edition of the CCNA video mentor is in progress. It’ll have 4-ish hours of video instruction, essentially powerpoint depictions of a network followed by explanations of the configuration and show commands from the CLI. You can see a sample here. The new edition will be out in December-ish.)
Anyway, one key to analyzing the question is to realize the 3 sets of information about VLANs listed in the output of the “show interfaces trunk” command. If a VLAN is missing from the last little section of output of this command, for a given trunk, then that switch will not forward or process received frames in that VLAN for that trunk. If a VLAN is listed in the last list in the output of the “show interfaces trunk” command, then the switch may forward/receive traffic for that VLAN, using that trunk, if appropriate based on the current MAC table.
Knowing those facts, you can answer Monday’s question by looking at the switches’ MAC tables and the end of the show interfaces trunk commands. First, a quick summary with a figure showing where the frames flow over the trunks:
SW1 floods the frame, including sending it out all three trunks.
SW2 ignores one frame, and floods the other. The frame it floods is sent out only 1 of the 3 trunks – the trunk to SW3 (Gi0/1).
SW3 receives two copies of the frame, forwarding one out its Fa0/2 interface, and ignoring the other (the one received from SW2).
Now on to the detail, starting with SW1: SW1 does not have a MAC table entry for destination 0200.BBBB.BBBB, so SW1 floods the frame. SW1’s “show interfaces trunk” command lists VLAN 2 in the bottom of the command’s output, on all three trunks – Gi0/1 (to SW2), Gi0/2 (to SW3), and Fa0/8 (also to SW2). So, when SW1 floods the unknown destination unicast, it forwards the frame out all three trunks.
SW2 receives one of its two received copied of the frame in SW2′ Gi0/2 interface. SW2 determines the VLAN (2) based on the incoming frame’s trunking header. Because 0200.BBBB.BBBB isn’t in SW2’s MAC table entries for VLAN 2, SW2 floods the frame. The show interfaces trunk command on SW2 lists three trunks: Gi0/1 (link to SW3), Gi0/2 (link to SW1), and Fa0/9 (other link to SW1). However, VLAN 2 is missing from the Fa0/9 entry in the last part of the output of the “show interfaces trunk” command, meaning that SW2 cannot forward frames in VLAN 2 out Fa0/9. So, SW2 floods the frame, sending it out Gi0/1 (to SW3). SW2 doesn’t forward it out Gi0/2, because it’s the interface in which the frame arrived, and SW2 doesn’t forward the frame out Fa0/9 because VLAN 2 is missing from that last part of the output of SW2’s “show interfaces trunk” command.
Next, consider the second frame that arrives at SW2 – the one SW1 sent over its fa0/8 interface, entering SW2’s Fa0/9 interface. As mentioned earlier, the end of SW2’s “show interfaces trunk” command omits VLAN 2 for trunk fa0/9. As a result, SW2 ignores this frame. (By the way, the underlying reason is that SW2’s Fa0/9 is blocking in VLAN 2.)
Taking a brief pause, so far, we’ve shown that answer C is correct, because we’ve seen that both SW1 and SW2 forward frames to SW3. SW3 ends up ignoring the frame received from SW2, as described in the next few paragraphs, but answer C clearly refers to what SW1 and SW2 do, not what SW3 does.
Next, consider the frame that arrives at SW3 in its Gi0/1 interface – the frame sent by SW1. SW3 determines the VLAN from the incoming frame’s trunking header (VLAN 2), and finds 0200.BBBB.BBBB in its MAC table in VLAN 2, outgoing interface Fa0/2. So, SW3 won’t even try to flood the frame, instead just sending the frame out Fa0/2.
Finally, consider the frame arriving in SW3’s Gi0/2 interface – the frame sent by SW2. The end of SW3’s “show interfaces trunk” command omits VLAN 2 for trunk Gi0/2. As a result, SW3 ignores this frame. (By the way, the underlying reason is that SW3’s Gi0/2 has been configured to remove VLAN 2 from the allowed VLAN list.)
Just to be complete, there’s now enough explanation here to make a few claims about the answers. First, SW1 did indeed forward frames over several trunks, making answer A incorrect. SW2 indeed receives 2 copies of the frame from SW1, but none from SW3, making answer B correct. Finally, if you follow the frames around the trunks in the figure, you’ll see that none of the frames loop, so answer D is incorrect.
Sorry this one’s such a long entry – I know it’s a blog, so things are typically shorter than today’s entry, but it’s helpful to see the analysis of each copy of the frame all in one sitting. So, now that you see the answer, any more comments? Did you think this sample question was too difficult for a CCNA question? just right? Too easy? If this had been a Simlet questions, what other commands would you have wanted to use, besides the show commands I showed this week?
