Showing posts with label switching. Show all posts
Showing posts with label switching. Show all posts

Thursday, 27 May 2010

MST - Multiple Spanning Tree - Don't change the mappings!

MST allows you to create spanning-tree instances and map VLANs into them.

Combined with VTP version 3 means you can advertise the MST mappings automatically, as shown here.

MST has the concept of regions.

Whether a switch is a member of a particular region depends on three things:

  • The configured MST region name.

  • The configured MST revision number.

  • The VLAN to MSTI mappings.


The entire VLAN to MSTI mapping isn't advertised in each BPDU but a checksum of the mapping table is.

So why do I care?


Because if you change the mappings, you change the region.

If you change the region that the root bridge belongs to, it's a topology change and you trigger a total STP re-convergence.


So if you're in a live network and you tweak the VLAN-to-MSTI mappings then you'll cause a complete outage. If it's running VTPv3 then the outage will be longer as the change ripples through the network and switches "re-join" the region.

The solution


The solution in this case is fairly easy, set up all your mappings on day 1 and stick to them!

If you've two switches then you're best off finding a suitable way to distribute the VLANs, e.g.

MSTI 1 - VLANS 1 to 1999 - Root bridge SW1
MSTI 2 - VLANS 2000 to 4096 - Root bridge SW2

Then make sure you set up HSRP/VRRP in future to match where the MSTI is rooted for each particular VLAN.

Read more...

Saturday, 20 February 2010

IBM Blade Centers - CIGESM Configuration

There are lots of docs from IBM explaining the blade center architecture but it's a lot of information to filter through if you're only interested in the network side.

The blade center in this example holds 14 blades which are best thought of as individual physical servers. It can use the Cisco switching module called a Cisco Systems Intelligent Gigabit Ethernet Switch Module, or CIGESM. They do run IOS but they don't behave in quite the same as normal Cisco switches.

Architecture



The CIGESM is a Cisco switch with 20 Gigabit Ethernet ports, these are:

  • 4 Physical ports on the back of the chassis.

  • 14 Ports connecting to the individual blades.

  • 2 Ports connecting to the internal Management Module for managing the switch via the chassis web interface.


Each of the blades is dual homed into the two CIGESM modules.

This architecture of a single blade center is shown below, click for larger version (warning 400kb image). This one assumes two management modules and two CIGESMs.



Management


The blade center itself is configured via a web interface that runs on the management module (MM). To access this initially you connect a copper cable directly into the MM port (has a picture of a network next to it), give your laptop an address in the 192.168.70.0/25 range and browse to 192.168.70.126. The default login is USERID/PASSW0RD (zero).

The CIGESM is a layer 2 switch and has a defined management interface, with the command "management" under the SVI. The Blade Center Management Module (MM) will configure the IP address on this interface. You can change it on the Cisco CLI but it will probably get set back by the MM at some point in future, so set it to the same on both MM and CLI!

CIGESM Management SVI


If you want to change the management interface VLAN then you'll need to do the following:

  1. If the IP is changing then update the network settings via the blade center web interface first.

  2. Create the layer 2 VLAN (for applying config to ports 15/16).

  3. Create the layer 3 SVI.

  4. Run the command "management" under the layer 3 SVI.

  5. Delete the old management interface.


The web interface screen is shown below (names changed to protect the innocent), the network settings are under "I/O Module Tasks" -> "Configuration". Click for larger image:




An example of changing the management VLAN from 1 to 2, note the auto updates to Gi0/15&16 (explained later):

BC-Sw01(config-if)#int vlan 2
BC-Sw01(config-if)#management
Port Gi0/15 allowed vlan list updated to include vlan 2
Port Gi0/16 allowed vlan list updated to include vlan 2

BC-Sw01(config-if)#desc Management Interface
BC-Sw01(config-if)#ip address 192.168.0.25 255.255.255.128
BC-Sw01(config-if)#do show run interface vlan 2
interface Vlan2
description Management Interface
ip address 192.168.0.25 255.255.255.128
no ip route-cache
management
end


Internal Connections - Gi0/15 & Gi0/16


As shown in the architecture diagram above ports 15 & 16 are internal links to the management modules. These are used for communications between the MM and the switch, for instance if you click the "telnet" link within the MM web interface.

The management VLAN needs to be allowed over the internal link to the MM. Some parts of the configurations on these ports cannot be configured manually, such as access or native VLAN. These entries are set automatically when you specify an SVI for management.

If you try to reconfigure them on the CLI you'll see errors as below:
BC-Sw01(config)#int range gi0/15 - 16
BC-Sw01(config-if-range)#switchport access vlan 2
User prevented from modifing Ethernet port Gi0/15 access vlan

Command rejected: not allowed on this interface.User prevented from modifing Ethernet port Gi0/16 access vlan

Command rejected: not allowed on this interface.
BC-Sw01(config-if-range)#switchport trunk native vlan 2
User prevented from modifying Native VLAN on Port Gi0/15

Command rejected: not allowed on this interface.User prevented from modifying Native VLAN on Port Gi0/16

Command rejected: not allowed on this interface.
BC-Sw01(config-if-range)#switchport trunk allowed vlan 2
BC-Sw01(config-if-range)#





Read more...

Tuesday, 9 February 2010

VTP Version 3 and MSTP Walkthrough.

This article assumes you are familiar with MSTP and VTP.

The latest incarnation of VTP version 3 is now available on versions of IOS from 12.2(50)SE3 onwards for 3560, 3750 and 2960s.

It supports distribution of two databases:

  • VLAN Database.

  • MSTP Vlan-to-MSTI mapping database.




Other than support for extended ID VLANs the VLAN database functionality is the same as previous versions. The MST mappings were not previously supported however and you had to manually create them on every device before. They show which VLANs are part of which spanning tree (or MSTI).

Another VTP version 3 function is to define a primary server that will not accept updates from any other device. This is meant to stop VTP bombs. When a switch is configured as the primary server it broadcasts itself on the network, the other VTP devices then create an entry with the MAC of this primary server and refuse to accept updates from any other device.

Implementation


The outputs here are from a sup720 running SXI3 IOS.

Previously you only had to set the VTP server, version and spanning-tree mode globally with commands such as:

RTR01(config)#vtp mode server
RTR01(config)#vtp version 3
RTR01(config)#spanning-tree mode mst


This configures the VTP status as follows, VTP server but leaves VTP support for MSTP in transparent mode.

RTR01#sh vtp status
VTP Version : 3 (capable)
VTP version running : 3
VTP Domain Name : VTPDOMAIN
VTP Pruning Mode : Disabled (Operationally Disabled)
VTP Traps Generation : Enabled
Device ID : 0200.0000.000a

Feature VLAN:
--------------
VTP Operating Mode : Server
Number of existing VLANs : 5
Number of existing extended VLANs : 0
Configuration Revision : 0
Primary ID : 0000.0000.0000
Primary Description :
MD5 digest : 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00


Feature MST:
--------------
VTP Operating Mode : Transparent


To set the server as the primary use the command “vtp primary vlan”, in enable mode not config mode.

RTR01#vtp primary vlan
This system is becoming primary server for feature vlan
No conflicting VTP3 devices found.
Do you want to continue? [confirm]

This then shows the log message:

000087: Feb 8 14:12:55.145: %SW_VLAN-SW1_SP-4-VTP_PRIMARY_SERVER_CHG: 0200.0000.000a has become the primary server for the VLAN VTP feature


At this point only the configured primary server can send VTP updates to the networks. Clients should ignore updates from any other device. The VTP status is now updated to show the VTP primary server.

RTR01#sh vtp status
[snip]

Feature VLAN:
--------------
VTP Operating Mode : Primary Server
Number of existing VLANs : 5
Number of existing extended VLANs : 0
Configuration Revision : 1
Primary ID : 0200.0000.000a
Primary Description : RTR01
MD5 digest : 0x87 0xBB 0xDB 0xEC 0xE5 0x9F 0x9C 0xCA
0x75 0xCE 0x4A 0x67 0xA7 0x67 0xBF 0xDA


The VLAN database is being synced but the MST mappings are not. To set up the device as the primary server for MST requires a few more steps:

RTR01(config)#vtp mode server mst
Setting device to VTP Server mode for MST.
RTR01(config)#^Z
RTR01#vtp primary mst
This system is becoming primary server for feature mst
No conflicting VTP3 devices found.
Do you want to continue? [confirm]
000091: Feb 8 14:15:20.932: %SW_VLAN-SW1_SP-4-VTP_PRIMARY_SERVER_CHG: 0200.0000.000a has become the primary server for the MST VTP feature


Now the VTP status is updated to show the primary server for both VLAN and MST.

RTR01#show vtp status
VTP Version : 3 (capable)
VTP version running : 3
VTP Domain Name : VTPDOMAIN
VTP Pruning Mode : Disabled (Operationally Disabled)
VTP Traps Generation : Enabled
Device ID : 0200.0000.000a

Feature VLAN:
--------------
VTP Operating Mode : Primary Server
Number of existing VLANs : 5
Number of existing extended VLANs : 0
Configuration Revision : 1
Primary ID : 0200.0000.000a
Primary Description : RTR01
MD5 digest : 0x87 0xBB 0xDB 0xEC 0xE5 0x9F 0x9C 0xCA
0x75 0xCE 0x4A 0x67 0xA7 0x67 0xBF 0xDA


Feature MST:
--------------
VTP Operating Mode : Primary Server
Configuration Revision : 1
Primary ID : 0200.0000.000a
Primary Description : RTR01
MD5 digest : 0xC6 0x62 0xA6 0x96 0x7E 0x98 0x14 0xCB
0x80 0xA1 0xA6 0x2D 0x60 0x39 0x49 0x39


Any devices on the network running VTP version 3 in the correct VTP domain should now sync VLANs and MST mappings.

EDIT:
Should really include the client configuration as that has also changed slightly, the old way was:

vtp domain XXXX
vtp mode client


To get the MST mappings you also need to run the command:

vtp mode client mst


And because changing the MST mapping later causes a total STP reconvergence you should configure all the MST mappings on day 1, but more about that later :-)


Read more...

Friday, 5 February 2010

Cisco Gotchas - 1800 Virtual Ports

This is a (very late) addition to the article here.

Cisco 6500 doesn't directly limit the number of spanning-tree instances. It has limits on the number of virtual ports per line card.


A virtual port is a VLAN being forwarded on a trunk. So if you have 10 VLANs and 5 active trunks with no pruning then you have 50 virtual ports.

A 6500 is limited to 1800 virtual ports per line-card (with caveats, see below!).

If you have a full 48-port linecard and use PVST then you can only create 37 VLANs before you hit the limit. If you intend to go over this then either manually prune some VLANs or upgrade.

Some of the SX IOS versions have removed the virtual port limit on the newer linecards (6500 and 6700 series), however the per-chassis limits still apply.

The per-chassis limits are shown here.

They are 10000 for RPVST+ and 13000 for PVST+, updated in IOS 12.2(33)SXI to be 12000/15000 respectively.


If you want to get extra lifetime out of older linecards then look into using MST as it drastically simplifies the forwarding. Unless you have a need for a different STP topology for every VLAN then it's a great idea.


Read more...

Cisco Gotchas - Max VLANs and STP Instances

Cisco switches have separate limitations on:

  • The number of VLANs that can exist in the database.

  • The number of Spanning-Tree Instances that can run.


Cisco kit tends to use per-VLAN spanning-tree in which case the two values will be the same.


To understand the problem and solution requires knowledge of the different types of spanning-tree available, this subject is huge but very briefly the types are:

  1. Standard 802.1D Spanning-Tree

  2. PVST, Per-VLAN Spanning-Tree (ISL trunking only)

  3. PVST+, Per-VLAN Spanning-Tree plus (compatible with 802.1q trunks)

  4. Rapid PVST - RSTP version of PVST+

  5. MST - Multiple Spanning Tree


The limitations are as follows on switches running PVST, PVST+ or Rapid-PVST:

  • 2950 SI: Maximum 64 STP instances, Maximum 128 VLANs.

  • 2950 EI: Maximum 64 STP instances, Maximum 250 VLANS.

  • 3550, 3560, 3750: Maximum 128 STP instances, Maximum 1005 VLANs.

  • 6500: Based on logical ports. Article here.



If you exceed the number of VLANs then you'll get an error like this:
SPANTREE_VLAN_SW-2-MAX_INSTANCE: Platform limit of 64 STP instances exceeded. No instance created for VLANxxx


Solutions


There are a couple of workarounds:

  • Delete some VLANs!

  • Manually prune VLANs off the trunk links and set the switch to VTP mode transparent so it doesn't know about the extra VLANs.

  • Use MST instead of PVST.



MST is my preferred option. Most networks will only require 2 or 4 Spanning-Tree topologies anyway so it is wasteful to have STP running in every VLAN.




Read more...

Saturday, 16 January 2010

VSS Introduction

VSS stands for Virtual Switching System and is a technology for use on 6500 series switches.

It works in a similar way to stackwise on the 3750s, you have two physical devices that end up with a single logical management plane.


In a large Cisco-style network you would have two core/distribution devices for redundancy. The network topology will typically need an active/standby topology. With Spanning-tree, only one uplink is forwarding for a given VLAN. To avoid unicast flooding the network should then have HSRP/VRRP and the IGP configured so that all traffic for that VLAN is routed via the same distribution (or core) switch.

Traffic is load balanced by alternating VLANs between the two distribution switches.

This topology is shown below for a single VLAN:



The basic VSS topology is shown below, the access device still has redundant uplinks but traffic flows over all links in etherchannels:




This topology it produces is similar to a network built around Nortel kit and the Split Multi-Link Trunking (SMLT) technology. The difference being that SMLT still has two separate management planes but VSS only has one.

There are a few benefits to this system:

Simplified Network Architecture.
  • Single logical device at the core/distribution layer.
  • Behaves as a single unit for management purposes.
  • No need to fudge STP, HSRP and IGP per VLAN.
  • No need of first hop redundancy protocols (FHRP).

Simpler Routing
  • Half as many IGP neighbors.
  • Half as many IGP routes.
  • No IGP load balancing/weighting required.


ISSU.
  • Software upgrades carried out without risky failovers and associated downtimes during convergence.
  • Easier to roll back.

Faster Convergence.
  • No STP convergence delays.
  • Loss of redundant switch does not change logical topology, avoiding convergence entirely.

Reduced function of Spanning-Tree.
  • No blocked ports to distribution/core from access layer.
  • Reduces greatly the chance of bridging loops.
  • Can use portfast trunk on access device uplinks.


The Cisco VSS Design Guide is well worth a read for more detailed information.



Read more...

3750 Stackwise Upgrades

Upgrading a Cisco switch is very easy:
  1. Copy IOS image to the flash drive on the switch.
  2. Point the boot statement at the new image.
  3. Reboot the switch.
The 3750 stack is made up of several physical devices with just a single logical management interface so Cisco has implemented the archive-sw command to make upgrading it easy. It doesn't quite work as well as it should and I wouldn't recommend using it. The method below is much easier and more reliable:

1. Copy IOS image to the flash drive on the switch
Use the same command as usual, but run it once for each switch in the stack. The flash drives are numbered flash1: flash2: flash3: etc.
copy tftp flash1:
copy tftp flash2:

Delete any old images or html files to clear space as necessary.

2. Point the boot statement at the new image
This can be done with a one liner (replace image.bin with whatever file you want to use):
boot system all flash:image.bin


3. Reboot the switch
The "reload" command will restart the entire stack.

So what's wrong with archive-sw?
The upgrade process is just the 3 simple steps above. Last time I used archive-sw I had about 45 minutes of instability while various individual processes restarted on the switch, routing went down but basic IP services stayed up so HSRP couldn't fail over and the network was unreachable until archive-sw had finished doing whatever it was doing. Maybe it was a bug in the archive-sw version I was using, maybe the config on that device triggered it, maybe it's just not very good.

Either way, I'm sticking to the old method of upgrades because it works and only causes an outage for the time it takes the switch to reboot (assuming it comes up again, which doesn't always happen with stacks!).


ISSU - In Service Software Upgrades
ISSU allows devices to be upgraded without outage. Unfortunately it is not available for 3750 stacks.
It may be possible to carry out the instructions above and then just reboot one switch at a time in the stack, if the old and new versions are similar enough then you might get away with it and the stack might re-form, allowing you to reboot the other switch while maintaining connectivity. Personally I wouldn't try it, if you want maximum uptime then you need two separate logical switches or to forget about upgrading them.


This method was worked out with our partners are Cacti Networks Ltd, network and security providers in the Ross-on-Wye area.

Read more...

Monday, 11 January 2010

Rapid Spanning Tree Notes

Just been reading a bit on RSTP, there are plenty of excellent detailed resources around. Here's my summary.




PDF version available here



Rapid Spanning Tree - 802.1w
Port Roles

Role

Description

Detailed

Root

Path to root bridge

The port that is closest to the root bridge in terms of path cost.

Designated

Forwarding to a segment

The port that sends the best BPDU on the segment to which it is connected.

Alternate

Alternative path to root

Alternate route to the root bridge. This port receives more useful BPDUs from another bridge. State blocked. Can be activated if the root port fails (RSTP equivalent to uplinkfast).

Backup

Redundant port

This port receives more useful BPDUs from the local bridge, therefore is redundant. State is blocked.

Disabled

Shutdown

Administratively shut down.


Port States

State

Description

Discarding

Combines the 802.1D disabled, blocking and listening states.

Learning

Drops frames but learns MAC addresses.

Forwarding

Sends frames


Port Types

Type

Description

Edge

End host, selected when portfast is enabled.

Root

Path to root bridge.

Point-to-point

Designated port to another switch. Selected when non-edge port is in full duplex mode.


  • It is assumed that a non-edge port in half-duplex mode may connect to a shared medium with multiple peer switches. These ports will fall back to 802.1D compatibility mode.

  • A non-edge port transitioning to forwarding will generate a TCN.


BPDUs

  • All switches send BPDUs out of all ports.

  • Loss of 3 BPDUs from a neighbour is taken to mean the neighbour is down. All information on that port is aged out.

  • If an 802.1D BPDU is received then that port falls back to 802.1D mode from RSTP.


Read more...

Monday, 22 June 2009

Locating a host

Something that often comes in handy is the ability to physically locate hosts on a large campus network from their IP address. This article assumes the device is correctly configured on the network.

The steps are:

  1. Find the devices MAC address.
  2. Locate the STP root bridge.
  3. On the root bridge follow the path to the MAC address.

1. Find the devices MAC address.


The MAC address can be found in the ARP cache of the hosts default gateway. To find the default gateway you need to run traceroute from any host on the same network (tracert on windows) which will give you something like the following:

matt@host:~$ traceroute 10.10.10.10
traceroute to 10.10.10.10 (10.10.10.10), 30 hops max, 60 byte packets
1 10.0.0.1 (10.0.0.1) 2.598 ms 2.875 ms 3.363 ms
2 10.10.10.10 (10.10.10.10) 3.908 ms 4.684 ms 4.363 ms

If the host is running a firewall then the last line may just show stars.

Connect (telnet/ssh) to the last hop before the device itself and check the ARP cache for the device. Remember that ARP entries time out after 4 hours of inactivity, the traceroute will refresh it.


Router# show ip arp 10.10.10.10

Protocol Address Age(min) Hardware Addr Type Interface
Internet 10.10.10.10 2 001e.1234.4321 ARPA VLAN 10


This output is from an MSFC card so the interface is the VLANs SVI. You may get a physical interface so check the CDP neighbors to ensure a switch is attached and not another router, if it is the a router then connect to it and keep tracing the address until you find a switch or VLAN interface. If you can't find it then check the NAT setup.

You now need to hop onto any switch associated with the interface shown above (VLAN 10 in this case). You may need some local knowledge or a bit more CDP investigation to find a suitable device. You may already be on it if it's a 6500 in native mode.

2. Locate the STP root bridge.
If you are working on a nicely designed network with combined routing/switching devices (e.g. 6500) then chances are good you're already logged onto the STP root bridge for that VLAN.

If not then find the VLAN you need by running
show mac-address-table address 001e.1234.4321


The commands needed here are:
show spanning-tree vlan 10
show cdp neighbors x/y

Check the spanning tree output, find the root port for that particular VLAN, check CDP neighbors for that port, connect to that device and repeat until you are sitting on the device that is the root bridge. It will either say clearly "this is the root bridge" or you'll be able to tell because the device MAC and root bridge MAC are identical.

3. On the root bridge follow the path to the MAC address.

In IOS/native mode use
show mac-address-table address 001e.1234.4321

In CatOS/hybrid mode use:
show cam dynamic 001e.1234.4321
or
show cam dynamic 00-1e-12-34-43-21
(the latter if it's really old CatOS and doesn't like new format MAC addresses)

This should give you a port, e.g. in IOS:

Router# show mac-address-table address 001e.1234.4321

vlan mac address type learn qos ports

------+----------------+--------+-----+---+--------------------------

10 001e.1234.4321 dynamic yes -- 2/6

or in CatOS the output looks like the following (if you get no output read the note at the end of this article):

coresw1> (enable) show cam dynamic 001e.1234.4321
* = Static Entry. + = Permanent Entry. # = System Entry. R = Router Entry.
X = Port Security Entry $ = Dot1x Security Entry

VLAN Dest MAC/Route Des [CoS] Destination Ports or VCs / [Protocol Type]
---- ------------------ ----- -------------------------------------------
10 001e.1234.4321 2/6 [ALL]



In this case the MAC is found on port 2/6. Assuming that isn't a copper port run "show cdp neighbors 2/6". Connect to that device and repeat this step until you get an answer pointing to a copper port.

You've now found the device!


Hopefully someone was thoughtful enough to either fill out the SNMP location field, the exec banner, the port description or to create a document telling you where on campus that switch is. It's now a simple matter to trace the cable and locate the device in question.


If you don't have any information beyond the switch name then it's time to start tracing cables and creating the documents yourself.



*note: CatOS will not show any output for "show cam dynamic 001e.1234.4321" if that MAC address is configured for port security on the local device as those addresses are not entered into the dynamic CAM table. In those cases you'll be able to find the port by running "show run | include 001e.1234.4321"

Read more...

Tuesday, 19 May 2009

BDPU Guard Vs Filter

Spanning-tree BPDU Guard or BPDU Filter?

A question that has cropped up on more than one occasion is which of these options should be used? BPDU Guard or BPDU filter?

You may think it safest to use both, however that isn't the case.


BPDU Guard
The port is error disabled when a BPDU is received.

BPDU Filter
If the port receives BPDUs then portfast is disabled and it functions as a normal STP port.


You may think that BPDU filter is the more useful setting as it always results in a functioning port, however consider two switches connected together to form a bridging loop as shown here.

With BPDU guard configured on all four ports, the BPDUs are detected and ports are shut down.

With BPDU filter configured on all four ports, no BPDUs are transmitted. The switches are not aware of each other and happily forward traffic down all links, creating a bridging loop.

With both options enabled the same thing happens.

The important difference is that BPDU filter prevents transmission of BPDUs.

If you're looking at standard switchport setting then this is not desirable, so the configuration of choice is:

spanning-tree portfast
spanning-tree bpduguard enable



Read more...

Secure Switchport Template

There are several reasons why you might want to use a switch port template.
  • Make life easier for administrators.
  • Standardize configuration.
  • Allow people without specific Cisco knowledge to configure ports.
  • Increase security.

An example template in macro form:


macro name accessport
switchport mode access
switchport nonegotiate
switchport access vlan 99
no cdp enable
spanning-tree portfast
spanning-tree bpduguard enable
storm-control multicast level 20.00
storm-control broadcast level 20.00
@


To apply this to a port run:

configure terminal
interface fa0/xx
macro apply accessport


It is probably advisable to reset the port configuration in advance in which case the commands become:

configure terminal
default interface fa0/xx
interface fa0/xx
macro apply accessport




So what do these commands do?

switchport mode access
Specify the port is an access port.
switchport nonegotiate
Disable Dynamic Trunking Protocol (DTP).
switchport access vlan 99
Set the port into a VLAN to avoid VLAN hopping shenanigens. Replace VLAN 99 with the ID of an unused VLAN on your network (not VLAN 1!).
no cdp enable
Disable CDP to stop attackers flooding the CDP neighbor table using Yersinia or similar tools.
spanning-tree portfast
Turn on portfast for access ports, usually a good idea. If you use boot-from-LAN then you'll need this!
Note that turning on portfast does NOT disable STP on that port, it just allows the port to go directly to the forwarding state. You could still create a temporary bridging loop however so also apply:
spanning-tree bpduguard enable


Turn on BPDU Guard to shut the port down if it gets connected to another switch, but allow this switch to keep sending BPDUs on that port.

You can turn this on globally with the command:
spanning-tree portfast bpduguard default




storm-control multicast level 20.00
storm-control broadcast level 20.00

Configure storm-control.



Further reading:

The NSA guide to Cisco switch security.

Read more...

Storm Control


Storm-control
is a very useful command for all switch-ports which allows you to set limits for Broadcast and Multicast traffic. When those limits are exceeded, traffic of that type is blocked on the interface until the storm has passed.

The configuration for the storm control level as a percentage of the link size is:
storm-control {broadcast|multicast} level {level} [level-low]


You can also set the action to take, either to filter the traffic or just to send an SNMP trap. The default action is to filter traffic and not send a trap.
storm-control action {shutdown|trap}


There are a couple of reasons why you may encounter large amounts of multicast or broadcast traffic on a LAN:
  1. There are lots of Multicast/Broadcast applications
  2. There is a bridging loop
  3. A device is malfunctioning and spamming the network


Some traffic monitoring is needed to check how much multicast/broadcast is normal on the network before configuring storm-control. You should also allow a reasonable amount of contingency so that ports don't start getting blocked if the CEO decides to multicast his video diary out to the company!

So why is it useful?

The major advantage to storm control is in the situation of a bridging loop. Typically it will be broadcast and multicast traffic that takes the network down as it gets perpetually forwarded.

With storm control the damage is limited, hopefully enough to allow LAN access to continue with reduced performance. It may not keep the users happy but it should allow you to remotely troubleshoot the network.

Without it you may be looking at a major outage lasting days while you walk around the site with a laptop trying to find the source of the failure.


Warning

Be careful setting the level-low (falling threshold) value. If this is set too low then you may find that storm-control blocks a port and never unblocks it. The following config looks innocent enough:
storm-control multicast level 20.00 0.00

It tells storm control to block the port if multicast traffic exceeds 20% of the total link size which seems perfectly reasonable.

The second option tells storm control to un-block the port when multicast traffic falls below 0% of the link size. Depending on your network this may never happen so the port will remain permanently blocked until someone runs shut/no shut on it.

Read more...