PVST and PVST+ are both Cisco Proprietary and don’t have IEEE standards

There is one basic problem with Per-VLAN Spanning Tree (PVST) and that is when there are many VLANs present the processing required will create considerable load. Also keep in mind (N.B.) that PVST is only supported on ISL and not 802.1Q (this has problems of its own with ISL not supported on all Catalyst switch platforms)

</p>The alternative to this is Multiple Spanning Tree Protocol (MSTP) that creates a single instance of spanning tree (Common Spanning Tree or CST) to run on multiple VLANs. The objective is to reduce the number of instances to match the physical topology thereby reducing CPU load. The instances of spanning tree are reduced to the number of active links available.

Implemented on a large network any given switch would run 4094 instances of spanning tree, each with its own BPDU conversations, root bridge election and path selections. With MSTP one path runs some VLANs and another path runs the other VLANs then there are only 2 instances of spanning tree.

Using this method MSTP converges even faster than PVST+ and is backward compatible with 802.1D STP, 802.1w Rapid Spanning Tree Protocol (RSTP), and the Cisco Proprietary PVST+ architecture. This implementation is not a requirement of ECNM as the number of active VLAN instances in the model is small and very stable due to design.

MSTP allows one to build multiple spanning trees over trunks and grouping them by VLAN. Each instance can be topology independant of other instances. MSTP provides multiple forwarding paths (instances) for data traffic and enables load balancing.

A set of bridges are configured with the same MSTP configuration, which allows them to participate in a specific set of spanning tree instances. Interconnected bridges that have the same MSTP configuration are referred to as a Multiple Spanning Tree (MST) region. Bridges with a different config or legacy bridges (802.1d) are considered a different region.

Network Fault Tolerance is improved over Common Spanning Tree (CST) because failure in one instance (forwarding path) does not affect another instance. This VLAN-to-MSTP must be consistent across bridges within a MST region.

In PVST+ environments, the spanning tree parameters are tuned so that half the VLANs are forwarding on each up-link trunk. With this configuration the following is true:

Load balancing is achieved

One spanning tree for each VLAN is maintained

MST Regions:

MSTP differs from other spanning tree implementations in that it combines some (if not all) VLANs into a logical spanning tree. This brings with it that the BPDU must be tagged with the VLAN information to be able to say which VLAN goes where.

To provide for this each switch running in a MSTP region passes the following information:

An Alphanumeric name (32 bytes)

A configuration revision number (2 bytes)

A 4096-element table that associates the potential VLANs with the given instance.

As said to part of a given MSTP (MST) region the passed information must share the same configuration.

As with PVST the Extended System ID is used in MSTP where the instance number is carried in the Extended ID field. In 802.1D STP each bridge must have a unique identifier. In PVST each VLAN needs a unique identifier. Before only 1023 VLANs were supported now all 4000 VLANs are supported by MAC address reduction.

MST Interactions with 802.1Q

An issue arises with MSTP design with the interoperability with the CST implementation in IEEE 802.1D. According to IEEE 802.1s a MSTP switch must be able to handle at least one Internal Spanning Tree (IST). The MST region consists of one IST and an arbitrary (one or many) number of MSTP instances.

The MSTP instances are simply RSTP instances that only operate within a region (MST). The IST (instance 0) runs on all bridges within a MST. It provides interaction at the boundary with other MST regions and compatibility with 802.1D (CST) and PVST+ networks connected to that given region.

IST receives and sends BPDUs to the CST for compatibility with 802.1D STP. IST is capable of representing the MST as a CST virtual bridge to switches networks outside the MST region. Think of the MST not of many independant switches but one “virtual bridge unit”.

The MST region appears as a single virtual bridge to adjacent CST and MST regions. The MST region uses RSTP port roles and operation.

IST connects all the MSTP switches in the region and any CST switched domains.

MSTP establishes and maintains additional spanning trees within each MST region. These spanning trees are termed MSTP instances. The IST is numbered 0, and the MSTP instances are numbered 1,2,3 up to 15. Any MSTP instance is local to the MST and is independent of other MST regions.

M-Record is a sub-field, within the BPDU of MSTP instances that enables corresponding instances to calculate a final topology.

MSTP instances combine at the MST regions to become the CST: M-Records are encapsulated within MSTP BPDUs. The original spanning trees (M-trees) are active only within the MST. M-trees merge with the IST at the MST Region to form the CST.

MSTP supports some of the PVST extensions: PortFast is supported, BPDU filter and BPDU Guard supported in MSTP mode, Loop guard and root guard supported in MSTP mode, and private VLANs (PVLANs), you must map a secondary VLAN to the same instance as the primary.

Configuration of MSTP

Entering the MSTP configuration Mode:switch(config)#spanning-tree mst configuration
Displaying the current MSTP configuration on the Switch:switch(config-mst)#show current
Setting the MST region name:switch(config-mst)#name region_1
Set the MSTP configuration revision number:switch(config-mst)#revision 1

Take note of the revision number, treat this number like a software version number in programming start from 1 and work upwards (1,2,3,4 etc). Keep in mind that you have to change it manually (this isn’t VTP) on all MST switches it doesn’t update automatically

Map the MSTP instance to VLANs:instance 1 vlan 1-50 OR 1
Show the configuration that hasn’t been applied yet:switch(config-mst)#show pending
Assign the current switch you are on as the primary or secondary Root:switch(config-mst)#spanning-tree mst 1 root primary secondary
Apply the configuration and exit MSTP configuration mode:switch(config-mst)#end
Enable MAC Address reduction (a.k.a Extended System ID):switch(config)#spanning-tree extend system-id
If a neighbouring switch is using a pre-standard version of 802.1s:switch(config-if)#spanning-tree mst pre-standard
Display general spanning-tree information for MSTP:switch#show spanning-tree mst
Displaying the spanning-tree configuration:switch#show spanning-tree mst configuration
Displaying the spanning-tree configuration for a specific instance:switch#show spanning-tree mst 1
Displaying the spanning-tree configuration for a specific interface:switch#show spanning-tree mst interface fastethernet 1/1
Displaying the spanning-tree configuration for a specific instance on a specific interface:switch#show spanning-tree mst 1 interface fastethernet 1/1
Finally for DETAILED information on a specific instance:switch#show spanning-tree mst 1 detail
In a situation when a legacy switch is placed then removed and it doesn’t revert back to PVRST+ or MSTP mode:switch#clear spanning-tree detected-protocols

Notes and Notices:
This is a part of my personal BCMSN notes and research to assist myself in learning and understanding the concepts and theory for the BCMSN exam. I learn by making notes reading and writing things down and wish to file them where I can’t lose them. These notes are not to be seen, judged or mistaken for replacements to Cisco recognized and authorized training which I personally support and attend and suggest you undertake if you are going for the BCMSN Certification.

The problem with STP as you might have picked up in the previous post was the transition between blocking and forwarding. This state change and convergence takes time where end-users are left with their lights and water shut-off.

Use it don’t use it, STP is great it makes loop-free networks easy; in real life don’t just unplug (port state change) or plug (port state change) into any production switch on a network running STP because it will prompt the network into figuring convergence which is the reason STP is a hassle.

To make good on the STP disadvantages Rapid Spanning Tree Protocol (RSTP) is based on IEEE802.1w there are numerous differences between STP and RSTP

RSTP and STP have port differentiators. RSTP uses alternate and backup port designations which are not in the STP environment. Also ports that are not participating in RSTP are known as edge-ports, they are either statically configured or recognized by PortFast. A edge-port changes from being one as soon as a BPDU is heard on the port making it a non-edge port. In the non-edge state the port participates in the spanning tree algorithm (STA) and generates topology change notifications (TCNs)

RSTP speeds the recalculation of the spanning tree when layer-2 changes occur to topology.

RSTP is proactive and negates the need for the 802.1D delay timers. RSTP (802.1w) supersedes STP (802.1d) but is still backward compatible with legacy switches on a per-port basis.

The RSTP BPDU is the same except for the Version field being set to 2, and Flags field using 8 bits.

As with STP, RSTP elects on root bridge in a similar fashion. The difference is that the Cisco Proprietary enhancements on RSTP are integrated into the low level protocol are transparent and require no additional configuration with the BPDU carrying port roles to neighbour switches similar functioning features do not play at all with RSTP like UplinkFast and BackboneFast.

RSTP BPDU:

The RSTP (802.1w) BPDU is the type 2, version 2 variety this means that a RSTP switch can in effect communicate with a STP (802.1d) switch. There are some variations between the two standards:

An RSTP bridge sends a BPDU with its current information (hellotime) every 2 seconds (default), even without a BPDU from the Root Bridge.

Protocol Information can be immediately aged on a port if hellos are not received (x3) or if MAX AGE expires

Because BPDU are now used as keepalives, 3x missed BPDUs indicate lost connectivity between neighboring switch or designated bridge. This allows for faster failure detection.

As mentioned earlier RSTP uses a Flag Field size of 8 bits (version 2). It works in the following way.

Bit 0 and Bit 7 are used for TCN and acknowledgement (ACK), same as with STP 802.1d

Bit 1 and Bit 6 are used for proposal and agreement.

Bits 2-5 encode the role and state of the port.

The difference between STP and RSTP is that in STP the flag field contained enough space for TCN and TCA whereas with RSTP it contains proposal/agreement designations between switches.

The BPDU is send between switches every 2 seconds and switches only need interaction between direct neighbours (BPDUs act also as keepalives) and every switch in the tree generates BPDU unlike in STP where only the root generated BPDUs. This led to a situation where if BPDUs stop coming along any given switch would know that a problem existed just not exactly where the problem was.

RSTP Port Roles

There are three port roles at it were:

Discarding: This state is seen in stable, synchronizing and changes in topology. This state prevents the forwarding of frames.

Learning: This state is seen in stable, synchronizing and change in topology. This state accepts frames to populate MAC tables.

Forwarding: This state is seen in only stable active topologies. The forwarding switch ports determine the topology.

The port differences between STP and RSTP:

Operational Port State

STP Port State

RSTP Port State

Enabled

Blocking

Discarding

Enabled

Listening

Discarding

Enabled

Learning

Learning

Enabled

Forwarding

Forwarding

Enabled

Disabled

Discarding

The Port Roles:

The Root Ports (R) is the switch port on every non-root bridge that is the chosen path to the Root Bridge. There can be only one Root port per switch. This port assumes the forwarding state in an active directory.

Each Segment has at least on switch port as a designated port (D) for that segment. In a stable, active topology the switch with the designated port receives frames destined for the Root Bridge. There can only be one designated port per segment. The designated port is in the forwarding state.

The alternate port (A) gives as the name suggests an alternate path to the Root Bridge should anything happen to the dedicated port (D). The alternate port assumes a discarding state in a stable, active topology.

A backup port (B) is present on the same switch as the designated port (D) with the same redundant link to the same segment. The backup port has a higher port ID than the designated port on the designated switch (that’s how the role is elected). The backup port becomes active when the designated port and alternate port are both down. In a stable, active topology it is in the discarding state.

What is an Edge Port:

An edge-port is a port that is not connected to a switch. It is a port that immediately goes to the forwarding state when enabled. This is the same as the PortFast feature. This means that the normal STP listening and learning states are skipped.

Unlike PortFast, an edge port that receives a BPDU immediately loses its edge port status and becomes a normal spanning tree port. When an edge port receives a BPDU it generates a TCN.

Implementing PVRST:

As described in the previous post for STP the PVRST config is basically the same with an extra commands. One start off by enabling Spanning Tree in global for a vlan:

switch(config)#spanning-tree vlan 1

Then set the spanning tree mode from STP 802.1d to PVRST 802.1w

switch(config)#spanning-tree mode rapid-pvst

To verify the operation of the PVRST

switch#show spanning-tree

Use a sub command by typing ? otherwise you will get a long list of general information about STP.

Notes and Notices:
This is a part of my personal BCMSN notes and research to assist myself in learning and understanding the concepts and theory for the BCMSN exam. I learn by making notes reading and writing things down and wish to file them where I can’t lose them. These notes are not to be seen, judged or mistaken for replacements to Cisco recognized and authorized training which I personally support and attend and suggest you undertake if you are going for the BCMSN Certification.

If anyone was wondering I have mixed switch and bridge in this post several times please see/read the terms as ambiguous, it was intentional and I know about it.

Before reading this post check this out and you will have a quick overview on what you are going to be doing.

The 802.1DSTP provides the mechanism for switches to reconfigure paths over which they forward (or block) frames. This makes for a loop-free network topology when there are redundant paths through the network in-case of failure. STP prevents loops in the following ways:

STP is implemented through the exchange of bridge protocol data unit (BPDU) messages between adjacent switches.

A single root bridge is elected to serve as the reference point from which STP creates a loop-free topology for all switches exchanging BPDUs.

Each switch, except for the root bridge, determines a root-port that provides the best path to the root bridge.

In a triangular designs the ports linking between two non-root switches make like so; one port on one switch will become a designated port and the other will become a blocking port. Thus eliminating all loops. The designated port will be on the switch with the best path to the root bridge.

Any state changes to ports (up/down) on any switch will be considered topology changing, then the Spanning Tree Algorithm (STA) must me run on all switches to adapt to the new topology.

Describing the Root Bridge:

The Root Bridge, Root Ports, and Designated Ports are used in STP to make for a loop-free network. The main information in the BPDU that the Root Bridge is concerned with is the Root ID, Bridge ID (BID) and Cost of Path. the STP topology is considered converged after a root bridge is elected and each bridge has selected its root port, designated bridge and the ports that will participate in the STP topology.

Describing the Port Roles:

On a non-root bridge there are 4 port roles

Root Port:This port exists on non-root bridges and is the port with the best path to the root bridge. Root ports forward traffic to the root bridge. The source MAC addresses received on this port will populate the MAC table. Only ONE of these ports per switch.

For non-root switches/bridges this is the switch port that will receive and forward frames in the direction towards the root bridge. If more than one switch exists on a segment they have an election process. Designated ports are allowed to populate the MAC table.

Non designated Port is the port that is blocking frames and is not allowed to populate MAC tables.

Disabled Port: A port on the switch that is shut down.

Port States:

Added to the port roles there are 5 port states which STP uses at different times:

Blocking: The layer-2 port is a non-designated port and does not participate in forwarding. The port receives the BPDU to determine the Root ID and which port roles each switch port assumes in the STP topology. (default 20 seconds in state) *defined by MAX AGE

Listening: this port can participate in frame forwarding according to BPDUs. The switch is receiving and sending BPDUs informing adjacent neighbours of its intention of participation in the active topology (default 15 seconds in state) *defined by FORWARD DELAY

Learning: A Layer-2 port that is preparing to participate in frame forwarding and is beginning to populating CAM table. (default 15 seconds in state) *defined by FORWARD DELAY

Forwarding: The port is considered part of the active layer-2 topology

Disabled: The port does not participate in the topology and does not participate in STP.

Port Costs:

STP port costs are calculated by the use of the media (port/interface) speed connecting the two swithes. STP path cost is a value advertised in the BPDU by each bridge. This is the total “value” of links from the root bridge to that switch in sending the BPDUs. It is used to determine the “best path” to the Root Bridge, the switch with the lowest path cost wins.

What is the BPDU:

STP sends BPDU out every port on the switch which are configuration messages to adjacent switches. The graphic above shows the size and field information of a BPDU.

Root ID: The lowest Bridge ID (BID) in the topology

Cost of Path: cost of all links from the transmitting switch to the root bridge

BID: BID of the transmitting switch

Port ID: Transmitting switch port ID

STP Timer Values: Max age, hello-time, forward delay

The first use of the BPDU in electing a root bridge which is done through a combination of the BID which consists of a 2-byte field (also called the priority) and it’s MAC address. The root bridge is normally (by default) elected on the lowest MAC Address in the topology (because the priority is default 32768) another method to force a root bridge election to a specific switch is to manually configure the priority value field to a lower number (default is 32768).

The Command to force a switch into the root bridge primary role:switch(config)#spanning-tree vlan 1 root primary
The Command to force a switch into the root bridge secondary role (backup):switch(config)#spanning-tree vlan 1 root secondary
The Command to set the priority in increments of 4096:switch(config)#spanning-tree vlan 1 priority priority

As discussed above the switch with the lowest combination of Root ID and Bridge ID will become the Root Bridge.

The BID and Root ID are both 8 byte fields and are carried in BPDUs sent between adjacent switches. These fields are used to determine the Root Bridge in the election process. The switch with the lowest BID will assume the Root Bridge role. This process starts with a switch not knowing anything (Root ID = BID) then it sends BPDUs and Receives BPDUs; once it receives a BPDU with lower than its own BID it will place that into the Root ID field.

A root bridge maintains the stability of the forwarding paths between all switches for a single STP instance. A spanning tree instance is a configuration in which all switches exchanging BPDUs and participating in the tree negotiation are associated with a single root bridge. When this is done for all VLANs, it is called Common Spanning Tree (CST); there is also an implementation called Per VLAN spanning tree (PVST) which gives one instance, and one root bridge, for each VLAN.

STP requires each switch to have a unique BID. With Per VLAN Spanning Tree (PVST) requires separate instances of spanning tree per VLAN, the BID must carry VLAN ID (VID) information. Because a MAC Address is always unique (kind of) when priority and extended system ID is appended each STP instance for each VLAN will have a unique BID.

When topology changes happen on the network, the root bridge will send messages throughout the “tree” regarding the change. This allows the content addressable memory (CAM) tables to adjust and provide for the new paths to end-host devices. This process is that a TCN BPDU (0×80 field type) is forwarded towards the root bridge after a topology change (link failure, bridge failure, port transition) the upstream bridge acknowledges with a topology change acknowledgement (TCA). This bridge then forwards to the designated bridge (closest neighbour to the root of a particular bridge). The designated bridge acknowledges with a TCA then forwards to the root bridge. This process repeats until the root bridge learns about topology changes in the network.

Load Sharing/Balancing

Load sharing or balancing is when you divide the bandwidth supplied by parallel links (think 2 connections of any sort that can give you the same end result be they internet connections, Ethernet connections, or fibre connections). In reference to STP; normally STP would block all but one parallel link to stop a loop while load sharing would want to divide the traffic between active links (in this case according to which VLAN the traffic belongs).

You can configure load sharing on trunk ports by using STP port priorities or STP path costs. For load sharing using STP ports priorities, both load-sharing links must be connected to the same switch. For load sharing using STP path costs, each load-sharing link can be connected to the same switch or to two different switches. Here is a link to a Cisco how-to document for the Catalyst 3550.

Load Sharing using Priorities

Using the STP port priority setting, this setting determines which port is enabled and which port is in the blocking state. The trunk port with the higher priority (low value) for a specific VLAN will forward trafffic for that VLAN conversely a trunk port with lower priority (high value) for the same VLAN will block.

In this way you can setup that a network with 20 VLANS in use will use 2 parrallel trunk links sending VLAN 1-10 on trunk 1, and VLAN 11-20 on trunk 2. If one link should fail the other link will send all VLAN information.

Load sharing using Path Costs

Using the above example of 20 VLANS on a network one can setup path costs on a trunk and associate these path costs to individual sets of VLANs. The VLANs keep traffic separate. Because no loop exists, STP will no disable ports and redundancy is maintained in the event of a lost link.

Enhancements

The 802.1D STP standard has been around many moons longer than VLANs. The 802.1D standard though has inherit limitations which can be overcome by using the Cisco Proprietary PVST which allows for separate instances of STP per VLAN, and other features like PortFast and UplinkFast which provide faster convergence.

There are advantages and disadvantages to PVST. An advantage is that it allows switches to be simpler in design and places a lighter load on the CPU. A disadvantage is that single spanning tree precludes load balancing and can lead to incomplete connectivity in VLANs.

There are two IEEE open standards Rapid Spanning Tree Protocol (RSTP) (802.1w) and Multiple Spanning Tree Protocol (MSTP) (802.1s) that improve on the original 802.1D STP standards. The per VLAN Rapid Spanning Tree Protocol (PVRST) allows Rapid Spanning Tree (RST) to be implemented while using the Cisco proprietary Per VLAN Spanning Tree (PVST).

Enhancements Explained PortFast

Spanning Tree PortFast causes an interface configured as a layer-2 access port to transition between blocking and forwarding without hold timers (best practice is to use PortFast on workstations and servers). If an interface receives a BPDU with PortFast configured, then spanning tree can put the port into the blocking state through the use of a feature called BPDU Gaurd.

Configuration for PortFast on a layer-2 access port forcing the port to enter forwarding immediately.switch(config-if)#spanning-tree portfast
Configuration for PortFast globally so all layer-2 access ports are forced into the forwarding state.switch(config)#spanning-tree portfast default
Test the configuration through the use of the following command.switch#show running-config interface fastethernet 0/1

Notes and Notices:
This is a part of my personal BCMSN notes and research to assist myself in learning and understanding the concepts and theory for the BCMSN exam. I learn by making notes reading and writing things down and wish to file them where I can’t lose them. These notes are not to be seen, judged or mistaken for replacements to Cisco recognized and authorized training which I personally support and attend and suggest you undertake if you are going for the BCMSN Certification.

An example VLAN configured through the use of global config mode on a single switch. To support multiple VLANs that span multiple switches one uses trunks. A trunk carries the traffic of multiple VLANs over links (multiplexing) and enable the extension of a single layer-2 VLAN between switches.

A trunk can exist between two switches, a switch and a router, a switch and a trunk-capable NIC (server). If a physical link carries multiple VLANs (trunk) then each frame going onto the link must be market with a VLAN ID (VID) which is added when entering into the link and removed when forwarded to a access port. This is accomplished through the use of trunking protocols. The two trunking protocols are ISL or Cisco ISL (proprietary) and 802.1Q which is IEEE standard trunking protocol.

ISL

802.1Q

Proprietary

Non-proprietary

Encapsulated

Tagged

Protocol Independent

Protocol Dependant

Encapsulates the old frame in a new frame

Adds a field to the frame header

Depending on the trunking protocol as shown above the data sent across a trunk link is either proprietary to cisco, cross platform (dont you know thats going to be an exam question, encapsulated or tagged, and protocol independant or protocol dependant another exam question.

In short the purpose of a trunking protocol is to provide the receiving switch with a method to identify the VLAN from which the frame originated by giving it a VID as reference by which to insert the frames into the right VLAN.

ISL in Detail

Inter-Switch Link (ISL) is a Cisco Proprietary trunking protocol used to configure layer-2 trunk links. It is the original standard for trunking and pre-dates the IEEE 802.1Q standard. ISL takes the original frame and encapsulates them with a new ISL header and trailer (frame check sequence), cyclic redundancy check (CRC) before sending them on the trunk link.

Because an entirely new header is appended to the original frame, the header offers some features not found in 802.1Q like:

When a switch port is configured as ISL the original frame, including header and frame check sequence is encapsulated before it enters the trunk. Encapsulation (CCNA) is the process of adding a additional header and trailer at the end of the original layer-2 frame. At the receiving end the new header and trailer is read and removed.

Getting more technical ISL adds a 26-byte header and a 4-byte trailer to a frame. The source VLAN-ID (VID) that comprises of a 15-bit VID field in the header. The trailer contains a Cyclic redundancy check (CRC) value to ensure data integrity. ISL adds a total of 30 bytes to a frame.

802.1Q in Detail

Like ISL the 802.1Q trunking protocol allows a single physical link to carry multiple VLANs communication. This is the non-proprietary version by the IEEE meaning that other brand kit will support it (note that other players in the market have more or less ability in following the standards even if they are open). This version rather than encapsulate the frame simply insets a tag into the original header and recalculates the frame check sequence (FCS) then retransmits the frame over the trunk link.

In Ethernet, 802.1Q adds a 4 byte tag just after the source address field. The first two bytes are used as Tag Protocol Identifier (TPID) and always have a value of 0×8100 to signify an 802.1Q tag. The remaining two bytes are used as Tag Control Information (TCI) that contains a three bit field for Class-of-Service (COS); One bit of TCI is a Canonical Format Indicator (CFI) flagging whether the MAC Address are in Ethernet or Token Ring. The last 12 bits are used as VLAN ID (VID) to indicate source VLAN. These values can be 0 to 4095. VLANs 0,1 and 4095 are reserved. 802.1Q adds a total of 4 bytes to a frame.

Ethernet Frames cannot (generally) exceed 1518-bytes, known as baby giant frames (if the frame size is near or at that size) adding the 802.1Q header to a baby giant frame makes the frame oversized at 1522-bytes and could cause errors and the frame may be dropped. This shouldn’t be a problem as Cisco Catalyst are compliant with IEEE 802.3ac that extends frame size to 1522-bytes.

802.1Q and ISL

As 802.1Q is an open standard (that favours compatibility inter-vendor) and technically does the same thing (tagging vlans which may be the reason I’ve read in places that Cisco no longer supports ISL on all Switch Platforms). One of the big-ish problems with the use of ISL is that frames that are already big (frames with more than 1518 bytes of payload (MTU) a.k.a jumbo frames or baby giant frames) when encapsulated using ISL (30 bytes) get even bigger. Cisco uses propriotary hardware to deal with this encapsulation method so this shouldn’t be a problem Cisco to Cisco (it’s just so you know).

The problem with trunking Cisco to Cisco may be when one Catalyst Switch Platform supports ISL and another (Catalyst or Non-Cisco) Switch platform doesn’t (apart from the fact that a trunk won’t form). The non-ISL Catalyst switch may report baby “giant” frames and drop the frame. To solve this simply use 802.1Q as Cisco hardware is compliant with 802.3ac.

Similar to the above problem Cisco to Non-Cisco the option to use ISL is eliminated because ISL is propriotary but the Non-Cisco compliance to standards (802.3ac) means that baby giant frames may still be dropped if they exceed the 1518 payload (not actively dissing other vendors, you just don’t want to sit at a clients offices and look clueless when this may be the problem).

Native VLANs

When configuring an 802.1Q trunk, a matching native VLAN must be defined (usually default VLAN 1) on each end of the trunk link. A trunk link is inherently associated with tagging each frame with a VID. The native VLAN is to allow untagged frames across the trunk. If both ends have non-matching Native VLANs problems will arise this is a common configuration error.

Native VLANs have these attributes:

The VLAN that a port is associated with when not in trunking operational mode

The VLAN that is associated with untagged frames that are received on a switch port

The VLAN to which layer-2 frames will be forwarded if received untagged on an 802.1Q trunk port

Comparing this to ISL where no frames will be transported across the trunk unless tagged (encapsulated), and any un-encapsulated frames are dropped.

Notes and Notices:
This is a part of my personal BCMSN notes and research to assist myself in learning and understanding the concepts and theory for the BCMSN exam. I learn by making notes reading and writing things down and wish to file them where I can’t lose them. These notes are not to be seen, judged or mistaken for replacements to Cisco recognized and authorized training which I personally support and attend and suggest you undertake if you are going for the BCMSN Certification.

Search

About

You are currently browsing the Network Ninja weblog archives for 'rstp' tag.