R&S Blog

Just another WordPress.com site

STP Port Cost

Vlans from 1-10 created on both switches will the default priority with sw2 being the root bridge based on the bridge priority field + Mac.
On SW1 fa 0/2 is blocking state for all vlans which based on the port priority
SW1 Interface        Role Sts Cost      Prio.Nbr Type

—————- —- — ——— ——– ——————————–

Fa0/1            Root FWD 19        128.1    P2p

Fa0/2            Altn BLK 19        128.2    P2p

We want to change fa 0/2 to be the root port for VLANS 1-5 and blocking for VLANS 6-10, we can either change the port-priority or the path cost. We will look at both methods as an example below.

The BPDU are sent by the Root Bridge which include the port-priority field, so we have to make the changes on SW2 fa 0/2 for the vlans 1-5

SW2(config-if)#spanning-tree vlan 1-5 port-priority 64

SW1#sh spanning-tree vlan 1 interface fa 0/2 detail

 Port 2 (FastEthernet0/2) of VLAN0001 is root forwarding

   Port path cost 19, Port priority 128, Port Identifier 128.2 (Local Port Priority)

   Designated root has priority 32769, address 0009.7c0b.9880

   Designated bridge has priority 32769, address 0009.7c0b.9880

   Designated port id is 64.2(SW2 Port Priority)

   Timers: message age 15, forward delay 0, hold 0

   Number of transitions to forwarding state: 3

   Link type is point-to-point by default

   BPDU: sent 10, received 1066

 Port 2 SW1 are in the blocking state as the command includes only vlans 1-5

SW1#sh spanning-tree vlan 6 interface fa 0/2 detail

 
 Port 2 (FastEthernet0/2) of VLAN0006 is alternate blocking

   Port path cost 19, Port priority 128, Port Identifier 128.2.

   Designated root has priority 32774, address 0009.7c0b.9880

   Designated bridge has priority 32774, address 0009.7c0b.9880

   Designated port id is 128.2, designated path cost 0

   Timers: message age 16, forward delay 0, hold 0

   Number of transitions to forwarding state: 0

   Link type is point-to-point by default

   BPDU: sent 1, received 936

Option 2 Changing the Pathc

Change the path cost on Interface fa 0/2 for vlans 1-5

Interface        Role Sts Cost      Prio.Nbr Type

—————- —- — ——— ——– ——————————–

Fa0/1            Root FWD 19        128.1    P2p

Fa0/2            Altn BLK 19        128.2    P2p

 

SW1(config-if)#spanning-tree vlan 1-5 cost 16

Interface        Role Sts Cost      Prio.Nbr Type

—————- —- — ——— ——– ——————————–

Fa0/1            Altn BLK 19        128.1    P2p

Fa0/2            Root FWD 16        128.2    P2p

 

 

EtherChannels

EtherChannel is Cisco’s term for bundling two or more physical Ethernet links for the purposes of aggregating available bandwidth and, to a lesser extent, providing a measure of physical redundancy. Under normal conditions, all but one redundant physical link between two switches will be disabled by STP at one end.

without_etherchannel.png

With EtherChannel configured, multiple links are grouped into a port-channel, which is assigned its own configurable virtual interface. The bundle is treated as a single link.

with_etherchannel.png

EtherChannel Negotiation

An EtherChannel can be established using one of three mechanisms:

  • PAgP – Cisco’s proprietary negotiation protocol
  • LACP (IEEE 802.3ad) – Standards-based negotiation protocol
  • Static Persistence (“On”) – No negotiation protocol is used

Any of these three mechanisms will suffice for most scenarios, however the choice does deserve some consideration. PAgP, while perfectly able, should probably be disqualified as a legacy proprietary protocol unless you have a specific need for it (such as ancient hardware). That leaves LACP and “on”, both of which have a specific benefit.

LACP helps protect against switching loops caused by misconfiguration; when enabled, an EtherChannel will only be formed after successful negotiation between its two ends. However, this negotiation introduces an overhead and delay in initialization. Statically configuring an EtherChannel (“on”) imposes no delay yet can cause serious problems if not properly configured at both ends.

To configure an EtherChannel using LACP negotiation, each side must be set to either active or passive; only interfaces configured in active mode will attempt to negotiate an EtherChannel. Passive interfaces merely respond to LACP requests. PAgP behaves the same, but its two modes are refered to as desirable and auto.

negotiation_modes.png

Only a single line is needed to configure a group of ports as an EtherChannel:

S1(config)# interface range f0/13 -15
S1(config-if-range)# channel-group 1 mode ?
  active     Enable LACP unconditionally
  auto       Enable PAgP only if a PAgP device is detected
  desirable  Enable PAgP unconditionally
  on         Enable Etherchannel only
  passive    Enable LACP only if a LACP device is detected

S1(config-if-range)# channel-group 1 mode active
Creating a port-channel interface Port-channel 1

As noted, a virtual port-channel interface Port-channel1 has been created to represent the logical link. Switchport configurations applied to this interface are replicated to the physical member interfaces. We can inspect the health of the EtherChannel with the show etherchannel summary command:

S1# show etherchannel summary
Flags:  D - down        P - bundled in port-channel
        I - stand-alone s - suspended
        H - Hot-standby (LACP only)
        R - Layer3      S - Layer2
        U - in use      f - failed to allocate aggregator

M - not in use, minimum links not met
        u - unsuitable for bundling
        w - waiting to be aggregated
        d - default port

Number of channel-groups in use: 1
Number of aggregators:           1

Group  Port-channel  Protocol    Ports
------+-------------+-----------+-----------------------------------------------
1      Po1(SD)         LACP      Fa0/13(D)   Fa0/14(D)   Fa0/15(D)

The opposite side of the LACP EtherChannel will typically be configured as passive, however it can be active as well.

S2(config-if-range)# channel-group 1 mode passive
Creating a port-channel interface Port-channel 1

When the member ports on both sides of the EtherChannel are enabled, the port-channel interface also transitions to the up state. However, note the timing of the system messages:

*Mar  1 00:45:50.647: %LINK-3-UPDOWN: Interface FastEthernet0/14, changed state to up
*Mar  1 00:45:50.683: %LINK-3-UPDOWN: Interface FastEthernet0/13, changed state to up
*Mar  1 00:45:50.691: %LINK-3-UPDOWN: Interface FastEthernet0/15, changed state to up
*Mar  1 00:45:53.487: %LINK-3-UPDOWN: Interface Port-channel1, changed state to up

Almost a full three seconds elapsed between the member ports transitioning to the up state and the port-channel interface coming up. Once it did, we can see the state of the EtherChannel has changed to “in use”:

S1# show etherchannel summary
Flags:  D - down        P - bundled in port-channel
        I - stand-alone s - suspended
        H - Hot-standby (LACP only)
        R - Layer3      S - Layer2
        U - in use      f - failed to allocate aggregator

M - not in use, minimum links not met
        u - unsuitable for bundling
        w - waiting to be aggregated
        d - default port

Number of channel-groups in use: 1
Number of aggregators:           1

Group  Port-channel  Protocol    Ports
------+-------------+-----------+-----------------------------------------------
1      Po1(SU)         LACP      Fa0/13(P)   Fa0/14(P)   Fa0/15(P)

Note the S indicating layer two operation; on multilayer platforms, EtherChannel interfaces can be configured for routed operation as well.

For comparison, let’s reconfigure the EtherChannel to function without a negtiation protocol (“on” mode):

S1(config)# no interface po1
S1(config)# interface range f0/13 -15
S1(config-if-range)# channel-group 1 mode on
Creating a port-channel interface Port-channel 1

S1(config-if-range)# no shutdown

This time we observe that the port-channel interface is enabled as soon as its first member port comes up, as there is no delay imposed by negotiation:

*Mar  1 00:56:12.271: %LINK-3-UPDOWN: Interface FastEthernet0/13, changed state to up
*Mar  1 00:56:12.287: %LINK-3-UPDOWN: Interface Port-channel1, changed state to up
*Mar  1 00:56:12.291: %LINK-3-UPDOWN: Interface FastEthernet0/14, changed state to up
*Mar  1 00:56:12.307: %LINK-3-UPDOWN: Interface FastEthernet0/15, changed state to up

In the Campus Network High Availability Design Guide, Cisco recommend forgoing the use of a negotiation protocol and configuring EtherChannels for static “on/on” operation; however they also caution that this approach offers no protection against the effect of misconfigurations.

EtherChannel Load-Balancing

Another consideration to make when implementing EtherChannels is the type of load-balancing in effect. EtherChannel provides load-balancing only per frame, not per bit. A switch decides which member link a frame will traverse by the outcome of a hash function performed against one or more fields of each frame. Which fields are considered is dependent on the switch platform and configuration. For example, a Catalyst 3550 can match only against a frame’s destination or source MAC address:

S1(config)# port-channel load-balance ?
  dst-mac  Dst Mac Addr
  src-mac  Src Mac Addr

The show etherchannel load-balance command reveals that source MAC address load-balancing is default on the Catalyst 3550:

S1# show etherchannel load-balance
EtherChannel Load-Balancing Configuration:
        src-mac

EtherChannel Load-Balancing Addresses Used Per-Protocol:
Non-IP: Source MAC address
  IPv4: Source MAC address

More powerful platforms can match against IP address(es) or layer four port(s). Generally speaking, higher layer fields are more favorable as they tend to be more dynamic, resulting in a more granular distribution of traffic across member links.

Direction of flow is also an important detail. For example, consider the following topology:

topology.png

Routed packets entering the subnet from S1 are always sourced from the MAC address of the VLAN interface. If source MAC load-balancing is in use, these frames will be forwarded down only one member link, because the outcome of the hash function will always be the same. Configuring destination MAC load-balancing on S1 is recommended to achieve a more varied distribution of frames and make better use of the available bandwidth.

The opposite is true on S2: Since all frames entering the EtherChannel from LAN hosts are destined for the MAC address of the gateway (VLAN interface), source MAC address load-balancing works better here.

EtherChannel Bandwidth and Costs

Finally, remember that the perceived bandwidth of a port-channel interface is equal to the sum of its active member links. For example, an EtherChannel with three active 100 Mbps members will show a bandwidth of 300 Mbps. Because members can still fail individually, the bandwidth of a port-channel interface can fluctuate without going down.

FHRP Cheat Sheet

First_Hop_Redundancy

STP Root Guard

In Figure 2, device D begins to participate in STP. For example, software-based bridge applications are launched on PCs or other switches that a customer connects to a service-provider network. If the priority of bridge D is 0 or any value lower than the priority of the root bridge, device D is elected as a root bridge for this VLAN. If the link between device A and B is 1 gigabit and links between A and C as well as B and C are 100 Mbps, the election of D as root causes the Gigabit Ethernet link that connects the two core switches to block. This block causes all the data in that VLAN to flow via a 100-Mbps link across the access layer. If more data flow via the core in that VLAN than this link can accommodate, the drop of some frames occurs. The frame drop leads to a performance loss or a connectivity outage.

Figure 2

74b.gif

The root guard feature protects the network against such issues.

The configuration of root guard is on a per-port basis. Root guard does not allow the port to become an STP root port, so the port is always STP-designated. If a better BPDU arrives on this port, root guard does not take the BPDU into account and elect a new STP root. Instead, root guard puts the port into the root-inconsistent STP state. You must enable root guard on all ports where the root bridge should not appear. In a way, you can configure a perimeter around the part of the network where the STP root is able to be located.

In Figure 2, enable root guard on the Switch C port that connects to Switch D.

Switch C in Figure 2 blocks the port that connects to Switch D, after the switch receives a superior BPDU. Root guard puts the port in the root-inconsistent STP state. No traffic passes through the port in this state. After device D ceases to send superior BPDUs, the port is unblocked again. Via STP, the port goes from the listening state to the learning state, and eventually transitions to the forwarding state. Recovery is automatic; no human intervention is necessary.

This message appears after root guard blocks a port:

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

Default STP Timers

This is pretty basic, but you need to remember a couple of important things when tasked with tweaking spanning-tree timers:

1) Make the changes on the root bridge.
2) The root bridge settings are the timers that are used – not the local settings on the non-root bridge(s).

You can see the timers with the “show spanning-tree vlan x” command.  The timers are set on the root. Non-root bridges will still show the local timer values, but will use the root values:

sw2#sh span v 1

VLAN0001
Spanning tree enabled protocol ieee
Root ID    Priority    24577
Address     0012.018f.d580
Cost        19
Port        15 (FastEthernet0/13)
Hello Time   2 sec  Max Age 20 sec  Forward Delay  4 sec <-note

Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)
Address     0012.009c.ca00 <-sw2 is not the root
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec <-note
Aging Time 300

Interface        Role Sts Cost      Prio.Nbr Type
—————- —- — ——— ——– ——————————–
Fa0/1            Desg FWD 19        128.3    P2p
Fa0/13           Root FWD 19        128.15   P2p
Fa0/14           Altn BLK 19        128.16   P2p
Fa0/15           Altn BLK 19        128.17   P2p

Bring up a port in VLAN 1:
sw2(config)#int fa0/1
sw2(config-if)#no sh
sw2(config-if)#^Z

*Mar  1 22:33:42: %SYS-5-CONFIG_I: Configured from console by console
*Mar  1 22:33:43: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to down
*Mar  1 22:33:44: set portid: VLAN0001 Fa0/1: new port id 8003
*Mar  1 22:33:44: STP: VLAN0001 Fa0/1 -> listening
*Mar  1 22:33:46: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to up
*Mar  1 22:33:47: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to up
*Mar  1 22:33:48: STP: VLAN0001 Fa0/1 -> learning  [listen to learn = 4 seconds]
*Mar  1 22:33:52: STP: VLAN0001 sent Topology Change Notice on Fa0/13
*Mar  1 22:33:52: STP: VLAN0001 Fa0/1 -> forwarding [learn to forward = 4 seconds]

The non-root bridge uses the root bridge’s Forward Delay timer of 4 seconds rather than its local timer of 15 seconds.

**************************
3 different ways to change the forward delay back to default (15 seconds)

We set the forward delay to 4 seconds (sw1 is on the root bridge):

sw1(config)#do sh sp v 1 | i ID|Forward
Root ID    Priority    24577
Hello Time   2 sec  Max Age 20 sec  Forward Delay  4 sec
  Bridge ID  Priority    24577  (priority 24576 sys-id-ext 1)
Hello Time   2 sec  Max Age 20 sec  Forward Delay  4 sec

1) “no spanning-tree vlan 1 forward-time 4″

sw1(config)#no sp v 1 f 4
sw1(config)#do sh sp v 1 | i ID|Forward
Root ID    Priority    24577
Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
  Bridge ID  Priority    24577  (priority 24576 sys-id-ext 1)
Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

2) “default spanning-tree vlan 1 forward-time”

sw1(config)#default sp v 1 f
sw1(config)#do sh sp v 1 | i ID|Forward
Root ID    Priority    24577
Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
Bridge ID  Priority    24577  (priority 24576 sys-id-ext 1)
Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

3) “spanning-tree vlan 1 forward-time 15″

sw1(config)#sp v 1 f 15
sw1(config)#do sh sp v 1 | i ID|Forward
Root ID    Priority    24577
Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
  Bridge ID  Priority    24577  (priority 24576 sys-id-ext 1)
Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Spanning-Tree Root Primary/Seconday

Spanning-tree vlan 1 root primary

Runs a macro and sets the priority lower than the current root, if the primary keyword is used and the current root bridge is more than 24,576 the local switch set it priority to 24,576.  Remember the default priority on all switches will be 32,768.

Example:

SW1#sh sp v 1

VLAN0001

Spanning tree enabled protocol ieee

Root ID    Priority    32769 priority (Default 32768 + Vlan1)

Address     000c.85aa.d6c0

Cost        19

Port        3 (FastEthernet0/2)

Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)

Address     001b.0c8d.3f80

Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Aging Time 300

Interface        Role Sts Cost      Prio.Nbr Type

—————- —- — ——— ——– ——————————–

Fa0/1            Desg FWD 19        128.2    P2p

Fa0/2            Root FWD 19        128.3    P2p

Fa0/7            Desg FWD 19        128.8    Edge P2p

spanning-tree vlan 1 root primary

VLAN0001

Spanning tree enabled protocol ieee

Root ID    Priority    24577 (priority 24576 + 1)

Address     001b.0c8d.3f80

This bridge is the root

Bridge ID  Priority    24577  (priority 24576 sys-id-ext 1)

Address     001b.0c8d.3f80

(spanning-tree vlan 1 priority 24576 is what is actually displayed in the running config)

 

 The secondary root bridge is used to set the bridge to a lower value of 28,672, again the default is 32,768

On SW2 if we run the secondary keyword

 spanning-tree vlan 1 root secondary

 vlan 1 bridge priority set to 28672 (Telling me what the new bridge priority)

VLAN0001

Spanning tree enabled protocol ieee

Root ID    Priority    24577

Address     001b.0c8d.3f80

Cost        19

Port        1 (FastEthernet0/1)

Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Bridge ID  Priority    28673  (priority 28672 sys-id-ext 1)

Address     000c.85b5.bb00

Just to recap spanning-tree vlan 1 root primary will set the root bridge to 24,576 + Vlan Number

The spanning vlan 1 root secondary will set the bridge priority to 28,672 + Vlan Number

 

 

VTP

As the layer 2 network grows managing the vlan numbers and allowed list involves large administration overhead. The Vlan trunking protocol is a way to manage vlans across multiple switches to ensure all vlan’s are consistent.

VLAN Trunk Protocol used to dynamically advertise the addition,removal, deletion of Vlan properties by incrementing the revision number and then replicates those changes to other switches in the same VTP domain. This does not affect the actual vlan port assignment.

Negotiate Trunking allowed list VTP Pruning discussed later…

How it Works ?

VTP Mode
– Controls who can advertise new/modified information modes are…
• Server
• Client
• Transparent

VTP Revision Number
– Sequence number to ensure consistent databases
– Higher revision indicates newer database

VTP Server Mode
• Default mode
• Allows addition, deletion, and modification of VLAN information
• Changes on server overwrite the rest of the domain
• Configured as vtp mode server

VTP Client Mode
• Cannot add, remove, or modify VLAN information
• Listens for advertisements originated by a server, installs them, and passes them on
• Configured as vtp mode client

VTP Transparent Mode
• Keeps a separate VTP database from the rest of the domain
• Does not originate advertisements
• “Transparently” passes received advertisements through without installing them
• Needed for some applications like Private VLANs
• Configured as vtp mode transparent

VTP Security
• VTP susceptible to attacks or misconfiguration where VLANs are deleted
– Access ports in a VLAN that does not exist cannot forward traffic
• MD5 authentication prevents against attack
– vtp password [password]
• Does not prevent against misconfiguration
– VTP transparent mode recommendation

When does VLAN pruning occur

what triggers VLAN pruning? Specifically, will a switch only allow pruning of a VLAN from a trunk if it has no access ports configured for that VLAN? Or is it enough to have merely no active ports?

Consider a simple trunking scenario:

vtp_pruning_lab.png

Switch 1 is the VTP server, and has propagated VLANs 10, 20, and 30 to switch 2. The interfaces to which hosts A and B attach are configured as access ports in VLAN 10, and an 802.1Q trunk is formed between the two switches. By examining the trunk status on either switch we can verify that VLANs 1 and 10 are being passed while the others are pruned in both directions.

S1# show interface trunk

Port        Mode         Encapsulation  Status        Native vlan
Gi0/1       on           802.1q         trunking      1

Port      Vlans allowed on trunk
Gi0/1       1-4094

Port        Vlans allowed and active in management domain
Gi0/1       1,10,20,30

Port        Vlans in spanning tree forwarding state and not pruned
Gi0/1       1,10

Switch 2:

S2# show interface trunk
...
Port        Vlans in spanning tree forwarding state and not pruned
Fa0/1       1,10

When host B is disconnected, its interface on switch 2 becomes inactive. As switch 2 has no remaining active ports in VLAN 10, VLAN 10 becomes eligible for pruning. After roughly 30 seconds pass, we can see that switch 1 is now pruning VLAN 10 from the trunk (VLAN 10 is absent from the last line of the output):

S1# show interface trunk
...
Port        Vlans in spanning tree forwarding state and not pruned
Gi0/1       1

The VLAN remains unpruned on switch 2’s end of the trunk, because it knows switch 1 still has at least one active port in VLAN 10:

S2# show interface trunk
...
Port        Vlans in spanning tree forwarding state and not pruned
Fa0/1       1,10

Network Design and Planning

Hierarchical Network Design

Understanding traffic flow is an important step when designing a campus network, The network traffic then can be effectively moved and managed, and you can scale the campus network to support future needs. Ideally you network should be designed, so that the users resources are in the same building.

Traffic flows in a campus network can be classified as three types, based on where the network service or resource is located in relation to the end user. Table 12-2 lists these types, along with the extent of the campus network that is crossed going from any user to the service.

Table 12-2. Types of Network Services

Service Type Location of Service Extent of Traffic Flow
Local Same segment/VLAN as user Access layer only
Remote Different segment/VLAN as user Access to distribution layers
Enterprise Central to all campus users Access to distribution to core layers

Cisco have adopted a there layer hierarchical which makes the network easier to understand,troubleshoot and scale future changes, these are known as the building blocks

What are the building Blocks ?

– Access layer

– Distribution layer

– Core (backbone) layer

Access Layer

The access layer is were the end user connects to the network i.e. PC’s,Printers and IP Phones, the access access layer usually provide layer 2 VLAN’s between the users,sometimes called building access switches, should have the following capabilities:

  • QoS (marking, policing, etc.)
  • Scalable uplinks to higher layers
  • Security (802.1x, port security, DAI, etc.)
  • Multicast traffic management (IGMP Snooping)
  • Broadcast domain segmentation (VLANs)
  • Resiliency through multiple uplinks

Distribution Layer

The distribution-layer switches must be capable of processing the total volume of traffic from all the connected devices, the distribution layer usually is a Layer 3 boundary, where routing meets the VLANs of the access layer.

  • Multiple connections to upstream to Core and downstream to Access
  • Offers services such as
    – Gateway redundancy (HSRP/VRRP/GLBP)
    – Bandwidth aggregation (EtherChannel/802.3ad)
    – Load balancing
    – Topology summarization
  • High Layer 3 throughput for packet handling

Core Layer

A campus network’s core layer provides connectivity of all distribution-layer devices. The core, sometimes referred to as the backbone, must be capable of switching traffic as efficiently as possible. Core devices, sometimes called campus backbone switches, should have the following attributes:

  • Must be fast and reliable as all other blocks depend on it
  • Typically hardware accelerated Layer 3 Switches
  • Offers services such as
    – Wire speed forwarding
    – Fast convergence around a link or node failure
    – Efficient bandwidth utilization

Network Device Roles

To first understand how the different devices interact, we must understand what role different devices play in the network.

Hubs and Repeaters

  • Work at layer 1 of OSI mode
  • When a frame is received it is sent back out all ports– i.e. “multiport repeater”
  • Typically unintelligent and unmanaged
  • Does not inspect frame at all before forwarding
  • Accepts no user-defined configuration
  • Devices connected to a hub are in the same… Collision domain
    • i.e. Ethernet CSMA/CD Half-Duplex transmission Broadcast domain


Layer 2 Bridges & Switches

  • Work at layer 2 of OSI model can be managed or unmanaged
  • For Ethernet, “frames” are forwarded based on destination layer 2 MAC address
  •  “CAM” table used for decisions
  • Devices connected to a bridge/switch are… in the same broadcast domain but not in the same collision domain
  • Operates at Full-Duplex transmission

CAM Table Limitations

  • Switches use the MAC address (CAM) table to do destination based switching
  •  CAM table cannot be summarized like IP routing 50,000 hosts in the network, 50,000 MAC addresses per CAM per switch
  • When CAM is full, switch acts like a hub

Broadcast Domain Limitations

  • Devices in the same VLAN, or everyone in a flat network, are directly addressable via FFFF.FFFF.FFFF
  • Larger the broadcast domain, more likelihood of a “broadcast storm”
  • Limiting hosts per VLAN limits broadcast domain size
  • Usually one VLAN per /24 IP subnet is a good rule

Layer 3 Routers

  • Work at layer 3 of OSI model
  • “Packets” are forwarded based on destination layer 3 address
  • Rebuilds layer 2 frame header at every hop
  • All router links are in separate collision and broadcast domains

Switch Port Configuration

Port Duplex Mode

If a 10/100 or a 10/100/1000 port is assigned a speed of auto, both it speed and duplex mode will be negotiated.

If port is set to Auto and the other end is set to Full the port will be set to the default of Half Duplex due to duplex mismatch, a general rule of thumb make sure both ends have the same speed and duplex settings to avoid any duplex mismatch.

To configure:

Switch(Config-if)# duplex (Auto | Full | Half)

Switch(config)# interface gig 3/1 Switch(config-if)# speed auto Switch(config-if)# duplex auto Switch(config-if)# interface gig 3/2 Switch(config-if)# speed 100 Switch(config-if)# duplex full

Looking for Speed and Duplex Mismatches

The host was configured at 100 mb Full Duplex and  the switch was set to Auto, the negotiation process fails and sets the port to half duplex on the switch, to fix this issue either set the host port duplex setting to Auto or set the switchport to Full-Duplex

Switch# show interfaces fastethernet 1/0/13
FastEthernet1/0/13 is up, line protocol is up
  Hardware is Fast Ethernet, address is 00d0.589c.3e8d (bia 00d0.589c.3e8d)
  MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
     reliability 255/255, txload 2/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive not set
 Auto-duplex (Half), Auto Speed (100), 100BASETX/FX  ARP type: ARPA, ARP
    Timeout 04:00:00
 Last input never, output 00:00:01, output hang never
  Last clearing of "show interface" counters never
  Queueing strategy: fifo
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 81000 bits/sec, 49 packets/sec
     500867 packets input, 89215950 bytes
     Received 12912 broadcasts, 374879 runts, 0 giants, 0 throttles
     374879 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

Managing Error Conditions On a Switch Port

By default a Catalyst switch detects an error for every possible cause, if an error condition is detected it put the port status into errdiable, you can tune this behaviour on a global level is that only certain causes trigger a port to be errdisabled.

Switch(config)# [no] errdisable detect cause [all | cause-name]

You can repeat this command to enable or disable more than on e cause

List of causes:

  • all— Detects every possible cause
  • arp-inspection— Detects errors with dynamic ARP inspection
  • bpduguard— Detects when a spanning-tree bridge protocol data unit (BPDU) is received on a port configured for STP PortFast
  • channel-misconfig— Detects an error with an EtherChannel bundle
  • dhcp-rate-limit— Detects an error with DHCP snooping
  • dtp-flap— Detects when trunking encapsulation is changing from one type to another
  • gbic-invalid— Detects the presence of an invalid GBIC or SFP module
  • ilpower— Detects an error with offering inline power
  • l2ptguard— Detects an error with Layer 2 Protocol Tunneling
  • link-flap— Detects when the port link state is “flapping” between the up and down states
  • loopback— Detects when an interface has been looped back
  • pagp-flap— Detects when an EtherChannel bundle’s ports no longer have consistent configurations
  • psecure-violation— Detects conditions that trigger port security configured on a port
  • rootguard— Detects when an STP BPDU is received from the root bridge on an unexpected port
  • security-violation— Detects errors related to port security
  • storm-control— Detects when a storm control threshold has been exceeded on a port
  • udld— Detects when a link is seen to be unidirectional (data passing in only one direction)
  • unicast-flood— Detects conditions that trigger unicast flood blocking on a port
  • vmps— Detects errors when assigning a port to a dynamic VLAN through VLAN membership policy server (VMPS)

Automatically Recover From Error Conditions

By default ports in the errdisbale state must be manually shutdown and re-enabled by using the no shut command under the interface, you can configure a port to automatically reenable a port, you first have to specify the errdisable cause:

Switch(config)# errdisable recovery cause [all | cause-name]

If any errdisable causes are configured for automatic recovery, the errdisabled port stays down for 300 seconds, by default. To change the recovery timer, use the following command in global configuration mode:

Switch(config)# errdisable recovery interval seconds

If the errdisbale cause is configured for automatic recovery it stay down for 300 sec

you could use the following commands to configure all switch ports to be reenabled automatically in 1 hour after a port security violation has been detected:

Switch(config)# errdisable recovery cause psecurity-violation
Switch(config)# errdisable recovery interval 3600

Looking for Port Sates

Switch# show interfaces fastethernet 1/0/1 FastEthernet1/0/1 is up, line protocol is up Hardware is Fast Ethernet, address is 0009.b7ee.9801 (bia 0009.b7ee.9801) MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, reliability 255/255, txload 1/255, rxload 1/255

The first up tell us that the physical links is up, the 2nd up tells us that line protocol is up this relates to the layer 2 status

To quicky see a list of all states use the show interface status command, to see ports in the errdisable status use the show interface status status err-disabled

Spanning Tree Election

How does STP works?

Spanning Tree Protocol – A network protocol that ensures loop free topology. Switches send BPDUs to discover loops. BPDUs helps elect the core of the network switch which is root bridge.

1st step – Selects a root bridge –

How?

  1. By selecting the Bridge ID (lowest is better)

Each bridge has a unique ID & configurable priority #

Value between 0 & 61440 (default is 32768)

Tie Breaker?

2.By selecting the MAC address (lowest is better)

The older the switch is, the lower its MAC address

2nd step

Selects Root port – Each bridge determines primary port facing root. This is per the lowest path cost to the root bridge.

Root port: used to reach the root bridge

3rd step

Selects Designated port – used to send and received packets on a specific segment

How? Port elects per lower path cost to the root bridge per segment.

Designated port: forwarding port, one per link

4th

Block ports with loops – all non-root and non-designated ports are blocked. The switch with the highest MAC address will block its link.

able 3-2. Three Major 802.1d STP Process Steps

Major Step Description
Elect the root switch The switch with the lowest bridge ID wins; the standard bridge ID is 2-byte priority followed by a MAC address unique to that switch.
Determine each switch’s Root Port The one port on each switch with the least cost path back to the root.
Determine the Designated Port for each segment When multiple switches connect to the same segment, this is the switch that forwards the least cost Hello onto a segment.

How STP finds the Best Path

1st step: Elect the Root Bridge

2nd step: Switches find lowest cost path to root

Bandwidth STP Cost Value
4 Mbps 250
10 Mbps 100
16 Mbps 62
45 Mbps 39
100 Mbps 19
155 Mbps 14
622 Mbps 6
1 Gbps 4
10 Gbps 2

 

3rd step: What if the cost is tie? Bridge ID (priority + MAC address)

4th step: What if Bridge ID is tie? It will look for the lower port. Example: fa0/0 rather than fa0/1

 

We determined the root bridge and compute the port roles. (root, designated or blocked). The bridge sends BPDU to exchange information about the Bridge ID and root path costs.

A bridge sends a BPDU frame using the unique MAC address of the port itself as a source address, and a destination address of the STP multicast address 01:80:C2:00:00:00.

There are three types of BPDUs:

  • Configuration BPDU (CBPDU), used for Spanning Tree computation
  • Topology Change Notification (TCN) BPDU, used to announce changes in the network topology

Informs switches of any (up/down) port changes.

  • Topology Change Notification Acknowledgment (TCA)

BPDU’s are being sent every 2 seconds so that the switches can keep track of the network changes and to start and stop forwarding at ports.

STP switch port states

  • Blocking – A port that blocks a switching loop.
  • Listening – The switch processes BPDUs and awaits possible new information that would cause it to return to the blocking state.
  • Learning – While the port does not yet forward frames (packets)  it does learn source addresses from frames received and adds them to the filtering database (switching database)
  • Forwarding – A port receiving and sending data, normal operation. This happens when you connect a host or a server to a switch.

Types of STP

PVST (Per VLAN Spanning Tree) – A Network switches where multiple VLANs coexist. Run 1 instance per VLAN.

Adds VLAN inside the BPDU header (priority + MAC address). PVST (Priority + VLAN + MAC Address).

Pros: 1 Root Bridge per VLAN & Load balancing

Cons: Cisco proprietary – only works in ISL

Post Navigation