350-001 Real Exam Prep DEMO

Question 3: A 4096-element table that associates each of the potential 4096 VLANs supported on the chassis
to a given instance.
In order to be part of a common MST region, a group of switches must share the same configuration
attributes. It is up to the network administrator to properly propagate the configuration throughout
the region. Currently, this step is only possible by the means of the command line interface (CLI) or
through Simple Network Management Protocol (SNMP). Other methods can be envisioned, as the
IEEE specification does not explicitly mention how to accomplish that step. Note: If for any reason
two switches differ on one or more configuration attribute, the switches are part of different
regions. For more information refer to the Region Boundary section of this document.
Region Boundary In order to ensure consistent VLAN-to-instance mapping, it is necessary for the
protocol to be able to exactly identify the boundaries of the regions. For that purpose, the
characteristics of the region are included in the BPDUs. The exact VLANs-to-instance mapping is not
propagated in the BPDU, because the switches only need to know whether they are in the same
region as a neighbor. Therefore, only a digest of the VLANs-toinstance mapping table is sent, along
with the revision number and the name. Once a switch receives a BPDU, the switch extracts the
digest (a numerical value derived from the VLAN-to-instance mapping table through a mathematical
function) and compares this digest with its own computed digest. If the digests differ, the port on
which the BPDU was received is at the boundary of a region. In generic terms, a port is at the
boundary of a region if the designated bridge on its segment is in a different region or if it receives
legacy 802.1d BPDUs. In this diagram, the port on B1 is at the boundary of region A, whereas the
ports on B2 and B3 are internal to region B:
MST Instances
According to the IEEE 802.1s specification, an MST bridge must be able to handle at least these
two instances:
One Internal Spanning Tree (IST)
One or more Multiple Spanning Tree Instance(s) (MSTIs)
The terminology continues to evolve, as 802.1s is actually in a pre-standard phase. It is likely
these names will change in the final release of 802.1s. The Cisco implementation supports 16
instances: one IST (instance 0) and 15 MSTIs.
show vtp status
Cisco switches "show vtp status" Field Descriptions has a MD5 digest field that is a 16-byte
checksum of the
VTP configuration as shown below
Router# show vtp status
VTP Version: 3 (capable)
Configuration Revision: 1
Maximum VLANs supported locally: 1005
Number of existing VLANs: 37
VTP Operating Mode: Server
VTP Domain Name: [smartports]
VTP Pruning Mode: Disabled
VTP V2 Mode: Enabled VTP Traps Generation: Disabled MD5 digest : 0x26 0xEE 0x0D 0x84 0x73
0x0E 0x1B 0x69 Configuration last modified by 172.20.52.19 at 7-25-08 14:33:43 Local updater ID is
172.20.52.19 on interface Gi5 / 2 (first layer3 interface fou) VTP version running: 2
Reference
http://www.cisco.com/en/US/tech/tk389/tk621 /technologies_white_paper09186a0080094cfc.shtm
l http://www.cisco.com/en/US/docs/ios-xml/ios/lanswitch/command/lsw-cr-book.pdf
8. Which statement is true about TCN propagation?
A. The originator of the TCN immediately floods this information through the network.
B. The TCN propagation is a two step process.
C. A TCN is generated and sent to the root bridge.
D. The root bridge must flood this information throughout the network.
Correct Answer: C
Explanation:
Explanation New Topology Change Mechanisms When an 802.1D bridge detects a topology change,
it uses a reliable mechanism to first notify the root bridge. This is shown in this diagram:
Once the root bridge is aware of a change in the topology of the network, it sets the TC flag on the
BPDUs it sends out, which are then relayed to all the bridges in the network. When a bridge
receives a BPDU with the TC flag bit set, it reduces its bridging-table aging time to forward delay
seconds. This ensures a relatively quick flush of stale information. Refer to Understanding
Spanning-Tree Protocol Topology Changes for more information on this process. This topology
change mechanism is deeply remodeled in RSTP . Both the detection of a topology change and its
propagation through the network evolve.
Topology Change Detection
In RSTP , only non-edge ports that move to the forwarding state cause a topology change. This
means that a loss of connectivity is not considered as a topology change any more, contrary to
802.1D (that is, a port that moves to blocking no longer generates a TC). When a RSTP bridge
detects a topology change, these occur:
It starts the TC While timer with a value equal to twice the hello-time for all its non-edge
designated ports and its root port, if necessary.
It flushes the MAC addresses associated with all these ports.
Note: As long as the TC While timer runs on a port, the BPDUs sent out of that port have the TC
bit set.
BPDUs are also sent on the root port while the timer is active.
Topology Change Propagation
When a bridge receives a BPDU with the TC bit set from a neighbor, these occur:
It clears the MAC addresses learned on all its ports, except the one that receives the topology
change.
It starts the TC While timer and sends BPDUs with TC set on all its designated ports and root port
(RSTP no longer uses the specific TCN BPDU, unless a legacy bridge needs to be notified).
This way, the TCN floods very quickly across the whole network. The TC propagation is now a one
step process. In fact, the initiator of the topology change floods this information throughout the
network, as opposed to 802.1D where only the root did. This mechanism is much faster than the
802.1D equivalent. There is no need to wait for the root bridge to be notified and then maintain the
topology change state for the whole network for <max age plus forward delay> seconds.
In just a few seconds, or a small multiple of hello-times, most of the entries in the CAM tables of the
entire network (VLAN) flush. This approach results in potentially more temporary flooding, but on
the other hand it clears potential stale information that prevents rapid connectivity restitution.
Reference
http://www.cisco.com/en/US/tech/tk389/tk621 /technologies_white_paper09186a0080094cfa.shtm
l
9. While you are troubleshooting network performance issues, you notice that a switch is
periodically flooding all unicast traffic. Further investigation reveals that periodically the switch is
also having spikes in CPU utilization, causing the MAC address table to be flushed and relearned.
What is the most likely cause of this issue?
A. a routing protocol that is flooding updates
B. a flapping port that is generating BPDUs with the TCN bit set
C. STP is not running on the switch
D. a user that is downloading the output of the show-tech command
E. a corrupted switch CAM table
Correct Answer: B
Explanation:
Spanning-Tree Protocol Topology Changes Another common issue caused by flooding is
Spanning-Tree Protocol (STP) Topology Change Notification (TCN). TCN is designed to correct
forwarding tables after the forwarding topology has changed. This is necessary to avoid a
connectivity outage, as after a topology change some destinations previously accessible via
particular ports might become accessible via different ports. TCN operates by shortening the
forwarding table aging time, such that if the address is not relearned, it will age out and flooding
will occur. TCNs are triggered by a port that is transitioning to or from the forwarding state. After
the TCN, even if the particular destination MAC address has aged out, flooding should not happen
for long in most cases since the address will be relearned. The issue might arise when TCNs are
occurring repeatedly with short intervals. The switches will constantly be fast-aging their forwarding
tables so flooding will be nearly constant. Normally, a TCN is rare in a well-configured network.
When the port on a switch goes up or down, there is eventually a TCN once the STP state of the port
is changing to or from forwarding. When the port is flapping, repetitive TCNs and flooding occurs.
Ports with the STP portfast feature enabled will not cause TCNs when going to or from the
forwarding state. Configuration of portfast on all end-device ports (such as printers, PCs, servers,
and so on) should limit TCNs to a low amount. Refer to this document for more information on TCNs:
Understanding Spanning-Tree Protocol Topology Changes Note: In MSFC IOS, there is an
optimization that will trigger VLAN interfaces to repopulate their ARP tables when there is a TCN in
the respective VLAN. This limits flooding in case of TCNs, as there will be an ARP broadcast and the
host MAC address will be relearned as the hosts reply to ARP .
Reference
http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a00801d080
8. shtml
10. Your network is suffering from regular outages. After troubleshooting, you learn that the
transmit lead of a fiber uplink was damaged. Which two features can prevent the same issues in the
future? (Choose two.)
A. root guard
B. loop guard
C. BPDU guard
D. UDLD
E. BPDU skew detection
Correct Answer: B,D
Explanation:
STP Loop Guard The STP loop guard feature provides additional protection against Layer 2
forwarding loops (STP loops). An STP loop is created when an STP blocking port in a redundant
topology erroneously transitions to the forwarding state. This usually happens because one of the
ports of a physically redundant topology (not necessarily the STP blocking port) no longer receives
STP BPDUs. In its operation, STP relies on continuous reception or transmission of BPDUs based on
the port role. The designated port transmits BPDUs, and the non-designated port receives BPDUs.
When one of the ports in a physically redundant topology no longer receives BPDUs, the STP
conceives that the topology is loop free. Eventually, the blocking port from the alternate or backup
port becomes designated and moves to a forwarding state. This situation creates a loop. The loop
guard feature makes additional checks. If BPDUs are not received on a non-designated port, and
loop guard is enabled, that port is moved into the STP loop-inconsistent blocking state, instead of
the listening / learning / forwarding state. Without the loop guard feature, the port assumes the
designated port role. The port moves to the STP forwarding state and creates a loop.
Loop Guard versus UDLD Loop guard and Unidirectional Link Detection (UDLD) functionality overlap,
partly in the sense that both protect against STP failures caused by unidirectional links. However,
these two features differ in functionality and how they approach the problem. This table describes
loop guard and UDLD functionality:
Based on the various design considerations, you can choose either UDLD or the loop guard feature.
In regards to STP , the most noticeable difference between the two features is the absence of
protection in UDLD against STP failures caused by problems in software. As a result, the designated
switch does not send BPDUs. However, this type of failure is (by an order of magnitude) more rare
than failures caused by unidirectional links. In return, UDLD might be more flexible in the case of
unidirectional links on EtherChannel. In this case, UDLD disables only failed links, and the channel
should remain functional with the links that remain. In such a failure, the loop guard puts it into
loop-inconsistent state in order to block the whole channel.
Additionally, loop guard does not work on shared links or in situations where the link has been
unidirectional since the link-up. In the last case, the port never receives BPDU and becomes
designated. Because this behavior could be normal, this particular case is not covered by loop guard.
UDLD provides protection against such a scenario. As described, the highest level of protection is
provided when you enable UDLD and loop guard.
Reference
http://www.cisco.com/en/US/tech/tk389/tk621 /technologies_tech_note09186a0080094640.
shtml#loop_guard_vs_uld