Posts from ‘Switching’
Do you want to see how a CCIE would handle a tricky EtherChannel and 802.1X scenario in the lab exam. Subscribers to the Interactive Video Companion for Volume 2 need to log in and watch the new training modules.
These tasks provide great opportunities to analyze task interpretation, diagramming strategy, and DOC-CD utilization during the CCIE lab exam.
Enjoy your studies!
Tags: 802.1x, ccie, etherchannel, lab, practice
Here ye, here ye, VTP experts. (We are not referring to the Vandenberg Test Program, although they are very likely experts in their field as well. 
)
Can you predict the results of a 3 switch VTP client/server scenario?
SW1-3, are connected, as shown in the diagram.
Here is the initial output of show VTP status, and show VLAN brief on each. Note that SW1 and SW3 are servers, while SW2 is a client. We will be adding a failure to the network in just a moment. Continue Reading
For some time, I believed a companion post to Understanding MSTP is required in order to completely cover all aspects of MSTP. The post should discuss convergence mechanisms employed in RSTP, which is a part of MSTP implementation. When I started that blog post originally, it appeared that it would be beneficial covering STP convergence mechanics beforehand. Word by word, the tutorial evolved into a document over 30 pages of size. In addition to this fact, many readers have been asking for PDF versions of my blog posts, and so I finally decided to make the new one entirely in PDF. You may find the link below:
http://blog.ine.com/wp-content/uploads/2010/04/understanding-stp-rstp-convergence.pdf
The blos post discusses many aspects affecting STP and RSTP convergence processes and outlines some problems found in RSTP. Unlike many previous post, this one is entirely theoretical, and does not feature any hands-on configuration sections. However, I believe it is still helpful in closing some gaps of fundamental Layer 2 protocol understanding. Have fun reading!
Introduction
Over time I was thinking of putting together the two blog posts made in the past about MSTP and adding more clarification for MSTP multi-region section. This new blog post recaps the information posted previously and provides more details this time. Additionally, it discusses some MSTP design-related questions. Both single-region and multiple-region MSTP configurations are reviewed in the post. The reader is assumed to have good understanding of classic STP and RSTP protocols as well as Cisco’s PVST/PVST+ implementations.
Table of Contents
Due to the large size of the document, a table of contents is provided for the ease of navigation.
Historical Review
Logical and Physical Topologies
Implementing MSTP
Caveats in MSTP Design
MSTP Single-Region Configuration Example
Common and Internal Spanning Tree (CIST)
Common Spanning Tree (CST)
Mapping MSTI’s to CIST
MSTP Multi Region Design Considerations
Interoperating with PVST+
Scenario 1: CIST Root and CIST Regional Root
Scenario 2: MSTIs and the Master Port
Scenario 3: PVST+ and MSTP Interoperation
Conclusions
Further Reading
Tags: 802.1s, ccie.mstp, cist, cst, multiple spanning tree
Introduction
Recently, there were discussions going around about Cisco’s new datacenter technology – Overlay Transport Virtualization (OTV), implemented in Nexus 7k data-center switches (limited demo deployments only). The purpose of this technology is connecting separated data-center islands over a convenient packet switched network. It is said that OTV is a better solution compared to well-known VPLS, or any other Layer 2 VPN technology. In this post we are going to give a brief comparison of two technologies and see what benefits OTV may actually bring to data-centers.
VPLS Overview
We are going to give a rather condensed overview of VPLS functionality here, just to have a baseline to compare OTV with. A reader is assumed to have solid understanding or MPLS and Layer 2 VPNs, as technology fundamentals are not described here.
Tags: 802.1aq, ccie, otv, overlay transport virtualization, trill, vpls
We are putting the final touches together for the CCSP bootcamp that is launching soon. (PS, it is going to ROCK! ) As I was going through the demo’s on L2 security, I was reminded of how this topic is often an Achilles heel for many CCIE candidates, both R/S and Security.
This blog post is to refresh your memories and provide some examples for layer 2 security on the Catalyst switch. We will begin with DHCP snooping. Continue Reading
Fast Convergence for Designated Ports
RSTP protocol’s fast convergence depends on the use of point-to-point links connecting switches. In order to quickly transition a designated port into non-discarding state, the upstream switch needs to make sure that the downstream neighbor agrees with that idea. This constitutes the process known as handshake (or proposal/agreement):
- Upstream bridge sends a proposal out of a designated port. As a matter of fact, it just sets the proposal bit in outgoing configuration BPDUs.
- Downstream bridge receives the proposal, and if it agrees with the upstream port role, it starts the process known as synchronization.
- Synchronization implies the downstream bridge blocking all non-edge designated ports, prior to sending an agreement to the upstream bridge.
- Synchronization is needed to make sure there are no loops in the topology, after the upstream bridge unblocks its designated port.
- If the downstream bridge does not agree with the proposal, it will continues sending it’s own configuration BPDUs with the proposal bit set. Eventually one of the bridges will accept the superior information and send an agreement.
Fast Convergence for Other Port Types
See more detailed overview at: http://blog.ine.com/wp-content/uploads/2010/04/understanding-stp-rstp-convergence.pdf
Tags: ccie, convergence, pvst, rstp
In this blog post, we will obtain some good solid Tier 1 level knowledge regarding VLAN Access Control Lists or VACLs. These are often also referred to as VLAN Access Maps or just VLAN Maps; thanks to the syntax that is used in their creation.
When you want to filter traffic that is moving from one VLAN to another, things are real CCNA-like and friendly We use an Access Control List. In fact, we should elaborate on that term a bit now in light of this discussion. We actually use a Router-based Access Control List or RACL.
But what if we want to filter traffic that is flowing within a VLAN? On no, a Router-based Access Control List cannot help us! This is when we turn to the VLAN Access Control List. To help us understand this feature, let us create a topology and a sample scenario. Here is the simple topology:
We are going to discuss Cisco’s proprietary extensions to STP algorithm, namely UplinkFast and BackBone Fast. Those two features aim to reduce the time it takes STP to re-activate topology after a link failure. While UplinkFast seems pretty intuitive, BB Fast is more complicated.
See more detailed overview at: http://blog.ine.com/wp-content/uploads/2010/04/understanding-stp-rstp-convergence.pdf
UplinkFast
Tags: backbone-fast, bpdu, ccie, convergence, rlq, stp, uplink-fast
In this post we are going to look into STP convergence process. Many people have perfect understanding of STP, but yet face difficulties when they see questions like “How many seconds will it take for STP to recover connectivity if a given link fails?”. The post will follow the outline below:
1) General overview of STP convergence process
2) How STP converges if a directly connected link fails
3) How STP converges when it detects indirect link failure
4) Topology changes and their effect
See more detailed overview at: http://blog.ine.com/wp-content/uploads/2010/04/understanding-stp-rstp-convergence.pdf
Loading ...
