%BPDUs% Archives %%page%%

Tag Archive for 'BPDUs'

Switch Security Layer-2 Attacks – Three

Published

on May 28, 2008

in BCMSN, BPDU Filtering, BPDU Guard, BPDU Root Guard, Certification, Cisco Systems, Concepts and Constructs, DAI, DHCP Snooping, DHCP Spoofing, Dynamic ARP Inspection, IP Source Guard, Loop Guard and Unidirectional Link Detection

. 0 Comments

If the feature talks about trusted/untrusted ports then access ports (facing end-devices or downstream) are untrusted and trunk/other ports (facing distribution/core or upstream) are trusted

DHCP Spoofing and Starvation

DHCP is a protocol that allows end-devices to get network configurations from a central server (router, switch, MS Server). A DHCP server can be spoofed by an attacker whereby end-devices receive network configuration from the attacker DHCP and not the legitimate DHCP server.

The reason why one would want to spoof a DHCP server is because the intruder can configure end-devices with IP Address, Domain Name Service (DNS) and Default Gateway (DG) of their choosing and not the legitimate information; the attacker will then play man in the middle.

Mitigating DHCP Snooping

DHCP Snooping is a Cisco Catalyst feature allowing for configuration of switch ports as either trusted or untrusted so that the ports can respond to DHCP requests. Trusted ports can source all DHCP messages and can host or be an uplink to a DHCP server. Untrusted ports can source requests only. If a rogue device on an untrusted port attempts to send a DHCP response packet, the port is shut down (errdisabled).

Configuration

Step 1:Configure DHCP snooping globally.

switch#configure terminal switch(config)#ip dhcp snooping

Step 2: Configure Trusted and Untrusted ports.

switch#configure terminal switch(config)#interface gigabitethernet 0/1 switch(config-if)#ip dhcp snooping trust By default all ports are untrusted

Step 3:Configure DHCP Option 82 Insertion.

switch#configure terminal switch(config)#ip dhcp snooping information option This is optional and is to let the forwarded DHCP request packet contain information on the switch port where it originated

Step 4:Configure rate limiting on untrusted ports.

switch#configure terminal switch(config)#interface gigabitethernet 0/2 switch(config-if)#ip dhcp snooping limit rate packets per second rate

Step 5:Configure DHCP snooping for selected VLANs.

switch#configure terminal switch(config)#ip dhcp snooping vlan number 1,3-6

Step 6:Confirm the configuration

switch#show ip dhcp snooping

STP Comprimises – STP Operation Protection

STP has two protection methods on ports where PortFast has been enabled. In proper configs PortFast will only be enabled on downstream ports (outward facing) that connect to end-devices. As was discussed in previous posts it is an understood theory that Broadcast Packet Data Unit (BPDU) will not come from these interfaces, if this should happen BPDU guard and BPDU filtering provide protection (this could either signal config error or an attack).

BPDU Guard is used to protect the switched network from problems that may arise from the receipt of BPDUs from ports that they shouldn’t be coming from. This could be from honest mistake or someone trying to add a switch.
BPDU Filtering affects how the switch acknowledges BPDUs seen on PortFast configured ports. The functionality differs depending on whether it is configured globally or per-port.
BPDU Root Guard protects against a switch outside the designated network attempting to become the root bridge by blocking it access until the receipt of its BPDUs ceases.

STP Operation Protection – Configuration of BPDU Guard

Step 1:Enable BPDU Guard Globally

switch#configure terminal switch(config)#spanning-tree portfast bpduguard

Step 2 isplay BPDU Configuration information

switch#show spanning-tree summary totals

STP Operation Protection – Configuration of BPDU Filtering

As mentioned earlier there are two methods of configuring BPDU Filtering, below are the two methods and the differences in how these implementations will affect configuration

STP Operation Protection – Configuration of BPDU Filtering – Global

switch#configure terminal switch(config)#spanning-tree portfast bpduguard default

In a valid config, PortFast ports do not receive BPDUs. If a PortFast enabled port receives a BPDU then it signals an invalid config, BPDU Guard puts the port in errdisabled state.

BPDU Filtering has these affects:

Affects all operational PortFast ports on switches that do not have BPDU filtering configured on the individual ports (i.e. you can have Global and port-based active at the same time)
If BPDUs are seen, port loses PortFast status, BPDU filtering is disabled, and STP sends and receives BPDUs on the port as it should with other STP ports on a switch.
Upon startup, the port transmits 10 BPDUs. If this port receives any BPDUs during that time, PortFast and BPDU filtering is disabled.

STP Operation Protection – Configuration of BPDU Filtering – Port

switch#configure terminal switch(config)#interface gigabitethernet 0/1 switch(config-if)#spanning-tree bpduguard enable

At the interface level (port-level) you can enable BPDU guard without also enabling PortFast. When the port receives a BPDU it is put into a errdisabled state.

BPDU Filtering has these affects:

It ignores all BPDUs received.
It sends no BPDUs.

Config this on ports that connect to known end-points that would/should/will never ever see a BPDU.

AND EXPLICIT configuration of PortFast BPDU filtering on a port that is not connected to an end-device can create bridging loops. The port ignores BPDUs and changes to a forwarding state. This does not happen when PortFast BPDU Filtering is enabled globally. This means that if you config this on a port that may be/is connected to another switch and needs to participate in STP in some way/form then it is always in the forward state.

STP Operation Protection – Configuration of BPDU Filtering – Confirmation
switch#spanning-tree summary totals

Confirming Configuration on a specific port
switch#spanning-tree interface gigabitethernet 0/0 detail

STP Operation Protection – Root Guard

Root Guard is a feature that limits on which switch ports the root bridge can be negotiated on. If a root guard-enabled port receives BPDUs that are better that those of the current root bridge, then the port will transition into a root-inconsistent state (STP listenning state).

Root Guard is configured on a per-port basis, recovery requires no intervention. A root guard port is in an STP-designated port state. When root guard is enabled on a port, the switch does not allow that port to become an STP root port. The port remains an STP-designated port.

Root guard should be enabled on all ports that the root bridge is not anticipated on and never will be.

%SPANTREE-2-ROOTGUARDBLOCK: Port 1/1 tried to become non-designated in VLAN 01. Moved to root-inconsistent state

Configuration

Step 1:Enable Root Guard on an interface

switch#configure terminal switch(config)#interface gigabitethernet 0/1 switch(config-if)#spanning-tree guard root

Step 2:Verify Root Guard on an interface

switch#show running-config interface gigabitethernet 0/1

Step 3:Verify if any port is in the Root Guard inconsistent state

switch#show spanning-tree inconsistentports

STP Forwarding Loops – Unidirectional Link Detection (UDLD)

A unidirectional link occurs when traffic is transmitted between neighbours in only one direction; this can cause spanning tree loops. UDLD allows detection when this occurs and shuts down the affected interface when it is detected.

UDLD is a layer-2 protocol that works with Layer-1 mechanisms to determine the status of a link. The switch periodically transmits UDLD packets on a UDLD enabled interface; if the packets are not echoed back in a specific time frame, the link is flagged as unidirectional and shut down (for this to work devices on both ends must support UDLD).

UDLD falls outside STP but has benifits to STP in detecting unidirectional links which can cause loops. UDLD can do one of two things depending on whether it is configured as “Normal” or “Aggressive”.

Normal Mode UDLD changed the port to undetermined when UDLD messages/echoes stop coming back
Aggressive Mode UDLD errdisables the port after UDLD messages/echoes stop coming back and it makes 8 re-establishing attempts.

UDLD uses MAC 0100.0CCC.CCCC (01-00-0c-cc-cc-cc) with sub-network Access Protocol (SNAP) High Level Data Link Control (HDLC) protocol type 0×0111.

Configuration

Step 1: Enable UDLD

Step 1.1:On fiber and non-fiber (copper) interfaces

switch#configure terminal switch(config)#interface gigabitethernet 0/1 switch(config-if)#udld enable

Step 1.2:Globally on Fiber switch interfaces

switch#configure terminal switch(config)#udld enable

Step 2: Disable UDLD

Step 2.1:On nonfiber interfaces individually

switch#configure terminal switch(config)#interface gigabitethernet 0/1 switch(config-if)#no udld enable

Step 2.2:On Fiber interfaces

switch#configure terminal switch(config)#udld disable

Step 3:Reset all interfaces that have been errdisabled by UDLD

switch#udld reset

Step 4:Verify UDLD

switch#show idld interface gigabitethernet 0/1

STP Forwarding Loops – Loop Guard

Similar to UDLD, Loop Guard grants protection for STP when a link is unidirectional and BPDUs are being sent and not received. Without loop guard a unidirectional link will transition to forwarding when it stops receiving BPDUs. When loop guard is enabled and a link stops receiving BPDUs, the interface will move into a STP loop-inconsistent blocking state.

SPANTREE-2-LOOPGUARDBLOCK: No BPDUs were received on port 0/1 in vlan 2. Moved to loop inconsistent state.

When a BPDU is received again on the port, the port will transition to the appropriate state without intervention.

Configuration

Step 5:Enable Loop Guard

Step 5.1:Globally configure Loop Guard

switch#configure terminal switch(config)#spantree global-default loopguard enable/disable

Step 5.1 er-Port Loop Guard

switch#configure terminal switch(config)#interface gigabitethernet 0/1 switch(config-if)#spanning-tree guard loop

Step 6:Verify Loop Guard

switch#show spantree guard 0/1

E-2-LOOPGUARDBLOCK: port 0/1 restored in vlan 2

Loop guard is enabled on ports that are participating in spanning tree and are redundant at Layer-2. When a switch stops receiving BPDUs on its root or blocking ports, it will transition the ports to loop-inconsistent, which does not pass traffic. Loop Guard is configured per port on, Loop Guard does not work with Root Guard, and should not be enabled on PortFast ports.

With Loopguard and EtherChannel. the first operational port is used for BPDUs; if the link is unidirectional, loop guard transitions ALL links of the channel to loop-inconsistent. This is not desirable because the inherit redundancy gained through channeling is lost.

MAC Spoofing – IP Source Guard

Similar to DHCP snooping, IP Source Guard this feature can be enabled on a untrusted port to prevent IP address Spoofing.

When started all IP traffic on the port is blocked, except DHCP packets that are caputred by the DHCP snooping feature. When a end-device then receives a valid IP Address from the DHCP server, or when a static IP Address is configured by the user, a per-port and VLAN Access Control List (PVACL) is instaled on the port.

This restricts the end-device to those source IP Addresses configured in the binding; any IP traffic with a different source IP address will be dropped.

Step 1:Configure DHCP snooping globally.

switch#configure terminal switch(config)#ip dhcp snooping

Step 2:Configure DHCP snooping for selected VLANs.

switch#configure terminal switch(config)#ip dhcp snooping vlan number 1,3-6

Step 3: Configure Trusted and Untrusted ports.

switch#configure terminal switch(config)#interface gigabitethernet 0/1 switch(config-if)#ip dhcp snooping trust

By default all ports are untrusted

Step 4:Configure IP Source Guard, Source IP, and Source MAC Address filtering on the Port.

switch#configure terminal switch(config)#interface gigabitethernet 0/2 switch(config-if)#ip verify source vlan dhcp-snooping port-security

Step 5:Configure rate limiting on untrusted ports.

switch#configure terminal switch(config)#interface gigabitethernet 0/2 switch(config-if)#ip dhcp snooping limit rate packets per second rate

Step 6 Optional if not a DHCP End-Device) Configure a static IP Binding on the port.
switch#configure terminal Switch(config)#ip source binding mac-address vlan vlan-id ip-address interface interface-name

ARP Spoofing

Address Resolution Protocol (ARP) Operation is that a end-device (A) sends a broadcast to determine the MAC Address of a end-device (B) with a particular IP Address. The end-device (B) at that IP Address replies with a MAC Address. The originating end-device (A) caches the ARP response, uses it to populate the destination Layer-2 header and then goes on to send a packet.

By spoofing ARP operation an attacking system then plays man in the middle and appears to be the destination sought by senders. All packets sent to the attacker will be forwarded to the correct end-device after being relayed through the attacking system.

Dynamic ARP Inspection (DIA)

DIA determines the validity of an ARP packet based on a valid MAC address-to-IP Address binding stored in a DHCP snooping database. To ensure validity these actions are taken:

Forwards ARP packets received on trusted interfaces without any checks.
Intercepts all ARP packets on untrusted ports.
Verifies that each intercepted packet has a valid binding before forwarding the packet that can update a local ARP Cahce.
Drops, logs or drops and logs ARP packets with invalid bindings.

Configuration

Step 0:Enable DHCP Snooping

Step 1:Configure DIA on a VLAN or VLAN Range

switch#configure terminal switch(config)#ip arp inspection vlan 1,2,3,4,5

Step 2:Enable DIA trust on an interface (sets the interface as trusted)

switch#configure terminal switch(config)#interface gigabitethernet 0/1 switch(config-if)#ip arp inspection trust

Step 3:Configures DIA to drop ARP Packets when the IP Addresses are invalid, or when MAC Addresses in the body of the ARP packet do not match the addresses specified in the Ethernet header.

switch#configure terminal switch(config)#ip arp inspection validate src-mac dst-mac ip

A post to do with DIA can be found at Richard Bannisters CCIE Blog

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.

Multiple Spanning Tree Protocol

Published

Deon Botha

on April 18, 2008

in BCMSN, Certification, Cisco Systems, Concepts and Constructs and MSTP

. 2 Comments

I noticed a hole in my notes that I was getting confuzzled with. Here are the standards that link to the protocols

STP IEEE 802.1D
MSTP IEEE 802.1S (MERGED LATER INTO IEEE 802.1Q-2003)
RSTP IEEE 802.1W (NOW IEEE 802.1D-2004)
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.

BID

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.
MSTP switches run IST, augmenting CST information and internal information about the MST region.
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

References:

MST based on IEEE 802.1s

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.

Rapid Spanning Tree Protocol

Published

Deon Botha

on April 18, 2008

in BCMSN, Certification, Cisco Systems, Concepts and Constructs and RSTP

. 2 Comments

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 IEEE 802.1w there are numerous differences between STP and RSTP

RSTP requires full-duplex point-to-point connections between switches.
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.

BPDU-Flag

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:

RSTP Root Ports

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.

RSTP Dedicated Ports

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.

RSTP Alternative Port

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.

RSTP Backup Port

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.

802.1D Spanning Tree Protocol

Published

Deon Botha

on April 16, 2008

in BCMSN, Certification, Cisco Systems, Concepts and Constructs and STP

. 6 Comments

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.1D STP 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.
Designated Port:This port exists on non-root and root switches/bridges.
- For root bridges/switches all switch ports are designated ports.
- 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:

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.

BPDU-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.

BID

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

Resources:
Get the IEEE standards documents mentioned from their website.

VLAN Configuration Errors

Published

Deon Botha

on April 14, 2008

in BCMSN, Certification, Cisco Systems, Concepts and Constructs, Trunk, VLAN and VTP

. 1 Comment

Common VLAN configuration errors made when configuring VLANs are listed below.

802.1Q Native VLAN Problem

An 802.1Q trunk link doesn’t encapsulate frames but adds a tag and re-calculates the frame-check sequence (FCS) of the frame. The 802.1Q trunk also allows for untagged frames to pass through the trunk on the NATIVE VLAN. A common configuration error is when there is a trunk link and the NATIVE VLAN is not the same on both sides of the trunk causing connectivity issues.

802.1Q Native VLAN Resolution

NATIVE VLANs must coincide on both ends of the trunk link otherwise a trunk link may not form.
Cisco NATIVE VLAN is default VLAN 1, for security purposes make the NATIVE VLAN something that is not used for normal purposes.switch(config-if)#switchport trunk native vlan 1-4094
If there is a NATIVE VLAN mismatch CDP (if used and active) will issue a “native VLAN mismatch” error.
On select versions of IOS CDP may not be transmitted if VLAN 1 is not working or automatically be disabled on the trunk.
If there is a NATIVE VLAN mismatch on either side of an 802.1Q trunk, layer-2 loops may occur because VLAN 1 STP bridge protocol data units (BPDUs) are sent to the IEEE STP MAC untagged.
When troubleshooting VLANs note that a link can have one NATIVE VLAN association when in access mode and another when in trunk mode.

Trunk Link Problems

There are certain elements that determine whether a trunk link is formed or not, the elements that determine this are the trunking mode, the encapsulation type, the VTP domain, and the hardware capabilities of the connected ports.

Trunks can be configured to either statically or autonegotiate trunks with the use of Dynamic Trunking Protocol (DTP), for autonegotiation the switches must be in the same VTP Domain. There are however certain other small things to take note of about the configuration with trunk links.

Through the use of the switchport command trunks can be autonegotiated. There are certain variations of the command that will not setup a successful trunk through; the command is below and there are some of the options available: swtich(config-if)#switchport mode dynamic / auto / desirable / trunk We wish to config a trunk link the following options will not create a trunk. swtich1(config-if)#switchport mode auto swtich2(config-if)#switchport mode autoThis shows both interfaces in switchport mode auto and will not config a trunk.swtich1(config-if)#switchport mode dynamic swtich2(config-if)#switchport mode accessThis shows one interface switchport mode dynamic desirable and the other static access and will not config a trunk.swtich1(config-if)#switchport mode trunk swtich2(config-if)#switchport mode auto

This shows one interface switchport mode trunk and the other interface switchport interface auto. This config will not create a trunk because the interface set to trunk will not send DTP frames and then the auto interface will switch to being an access port.

This topic is something I can feel in my bones will come up in tests you either have this topic down or don’t have a clue and guestimate. I think I am going to try and know it because it’s easy enough to make a table and just learn; check out CCIE Pursuit for a table on the 3550/3560 routers and bitmindframes for more info on each DTP config state.

DTP Requirements

The reason a Network Administrator would deploy DTP is to automate to a degree the trunking process. To give you more of an explanation if a port can become a trunk (switch-switch not supported on routers), it may also be able to trunk automatically, and in some cases even negotiate the type of trunk (ISL/802.1Q). This is where DTP comes in to provide the negotiation of the trunking method with the neighbour device.

There are however requirements for DTP the main one being support for ISL or 802.1Q on both ends of the trunk (Switch A and Switch B must support and be configured with one or the other) so that DTP can do its job.

This can be expanded slightly where the switch platform does or doesn’t provide support for ISL but does support 802.1Q trunking and supports DTP like the Catalyst 4500/4000 (CatOS), which includes 2948G/2980G/4912G also the Catalyst 2950/2955/2940 series. This simply means all trunking will be done using 802.1Q.

Lastly where both ISL and 802.1Q is supported but DTP is not like the Catalyst 2900XL/3500XL/2948G-L3/4908G-L3/4840G/8500 Series.

Trunk Link Resolution

Trunk Negotiation is managed by DTP, which is Cisco proprietary, and is a point-to-point protocol (see any problems with this yet) when using DTP make sure that both ends of the link are in the same VTP Domain otherwise it wont work. Secondly because it is Cisco proprietary certain network devices wont support DTP which could cause misconfiguration cross-brands (when configuring on an interface that is connected so something non-cisco turn off DTP). Find some more information here that’s doesn’t assume you know something about DTP before jumping right in and also covers some other topics in the same post.

The correct way then to configure a port to either trunk or not would be for access ports swtich(config-if)#switchport mode access for trunking without DTP swtich(config-if)#switchport mode trunk swtich(config-if)#switchport mode nonegotiate then finally for encapsulation type on the trunk port swtich(config-if)#switchport trunk encapsulation dot1q swtich(config-if)#switchport trunk encapsulation isl. Keeping in mind that dot1q is cross-vendor and isl is also Cisco proprietary.

VTP Problems

Problem	Possible Causes
Updates not received as expected	VTP Domain name and password must match with the server. (case sensitive) VTP version must be compatible with the other switches on the domain. Ensure that there is at least one server in the VTP Domain. check that a trunk link exists to the VTP Server
Missing VLANs	Upon initial configuration, the VTP Server may have been a partial VLAN database, and it overwrote the existing, more complete, database on the existing switch. VLANs were deleted individually at the VTP server, and those deletions will be propagated in the domain. Not all Cisco switches support extended VLANs.
Too many VLANs	The VTP Server has a VLAN list that is more complete than the list needed by other switches in the domain.

The VTP Resolution and best practices are dealt with in a previous post

Trunk and VLAN Specific

Sometimes it is needed to only carry specific/certain VLANs accross trunk links. You will remember from the CCNA that by default all VLANs are allowed across a trunk link when it is created unless specifically told otherwise. This will mean that VLAN 1 through x will traverse a trunk unless you as Admin say otherwise. In some situations having all vlans moving across trunks is not the desired sitatuation.

As an example if you have VLAN 1 through 10, assume 1,3,6, and 9 is actively used on one Switch 1 and 2,4,6,8 and 10 on Switch 2.

There is no “active” users for VLANs 2,4,6,8, and 10 on Switch 1 and no active users for VLaN 1,3,6, and 9 on Switch 2 why then send these VLANs all over the place when this will be wasteful? To change this situation one can use any one of these commands:

Switch(config-if)switchport trunk allowed vlan remove/except/add x,x,x

Using either the remove 2,4,6,8 and 10, except 2,4,6,8,10 or add 1,3,6,9 command will have the same end result of allowing only 1,3,6, and 9 across the trunk link.

Network Ninja

Tag Archive for 'BPDUs'

Switch Security Layer-2 Attacks – Three

Multiple Spanning Tree Protocol

Rapid Spanning Tree Protocol

802.1D Spanning Tree Protocol

VLAN Configuration Errors

Search

About

Latest

Archives

Categories