Similar to SPAN except vlan’s are used for the destination on the source switch and vlans are used as the source on the destination switch.
To configure an RSPAN source session, configure a source with an RSPAN VLAN as the destination. To configure an RSPAN destination session, configure an RSPAN VLAN as the source and a port as the destination.

As luck would have it, my plans for trekking in the Himalayas got stunted due to the time of year that I was able to go, but the result of that is that I’m going to be spending New Year and the most part of January in Southern India with a close buddy of mine.

Ironically, having been a disciple of the Goa Trance scene back in the early 90’s, it’s only now, almost 15 years later that I’m actually going to visit the place that spawned the idea’s that made Youth, Alex Patterson, Chris Decker, Mark Allen, Goa Gill etc etc bring back the intoxicating hedonistic vibe that was so prolific, at least for me, back when I were a nipper.

Luckily though I’ve no particular pre-conceptions for the trip. Don’t get me wrong tho, I won’t be saying no to a New Years party in the hills behind Anjuna if Goa Gill’s putting the smack down with some 2010 trance business.

My stay is mostly intended to be a relaxing chillout on some sandy beaches in between the hectic work and study schedule I’ve set over the next 8 months. I’ve got my camera and a lovely new Wide Angle lens and hope to capture some stunning images which I’ll definitely be sharing on here on my return. Whether Indian culture has that intention for me though is still to be seen, but whatever which way, it’s going to be an experience I won’t be forgetting any time soon.

First, let’s cover what auto-negotiation does not do: when auto-negotiation is enabled on a port, it does not automatically determine the configuration of the port on the other side of the Ethernet cable and then match it. This is a common misconception that often leads to problems.

Auto-negotiation is a protocol, and as with any protocol, it only works if it’s running on both sides of the link. In other words, if one side of a link is running auto-negotiation, and the other side of the link is not, auto-negotiation cannot determine the speed and duplex configuration of the other side. If auto-negotiation is running on the other side of the link, the two devices decide together on the best speed and duplex mode. Each interface advertises the speeds and duplex modes at which it can operate, and the best match is selected (higher speeds and full duplex are preferred).

The confusion exists primarily because auto-negotiation always seems to work. This is because of a feature called parallel detection, which kicks in when the auto-negotiation process fails to find auto-negotiation running on the other end of the link. Parallel detection works by sending the signal being received to the local 10Base-T, 100Base-TX, and 100Base-T4 drivers. If any one of these drivers detects the signal, the interface is set to that speed.

Parallel detection determines only the link speed, not the supported duplex modes.

Using auto-negotiation to your advantage is as easy as remembering one simple rule:
Make sure that both sides of the link are configured the same way.If one side of the link is set to auto-negotiation, make sure the other side is also set to auto-negotiation. If one side is set to 100/full, make sure the other side is also set to 100/full.

The Dynamic Trunking Protocol (DTP) is a proprietary networking protocol developed by Cisco Systems for the purpose of negotiating trunking on a link between two VLAN-aware switches, AND for negotiating the type of trunking encapsulation to be used. It works on the Layer 2 of the OSI model. VLAN trunks formed using DTP may utilize either IEEE 802.1Q or Cisco ISL trunking protocols.
DTP should not be confused with VTP, as they serve different purposes. VTP communicates VLAN existence information between switches. DTP aids with trunk port establishment. Neither protocol transmits the data frames that trunks carry.

DTP negotiation can be disabled two ways, with the switchport mode access command, or with the switchport nonegotiate command. This design is most commonly used when a switch is trunking to a device that does not support DTP, such as an IOS router’s routed interface (not an Ethernet Switch interface), or a server’s NIC card.

Types of switchport operational modes are as follows:-

Access
Dynamic desirable (default mode on Catalyst 2950 and 3550)
Dynamic auto (default mode on Catalyst 3560)
Trunk
Non-negotiate
dotq-tunnel (Not an option on the Catalyst 2950.)
Using these different trunking modes, an interface can be set to trunking or nontrunking or using DTP to negotiate trunking with the neighboring interface.

Viewing the trunks on the switch and their respective settings can be achieved using

show interface trunks

DTP Grid:

Switchport Mode

Access

Dynamic Desirable

Dynamic Auto

Trunk

Access

No Trunk

No Trunk

No Trunk

No Trunk

Dynamic Auto

No Trunk

Trunk

No Trunk

Trunk

Dynamic Desirable

No Trunk

Trunk

Trunk

Trunk

Trunk

No Trunk

Trunk

Trunk

Trunk

EtherChannel

Two negotiation protocols exist for EtherChannel, PAgP and LACP. This is analogous to the trunk protocols of ISL and 802.1q. PAgP is proprietary as is ISL, LACP is an open standard and is used by 802.3ad and 802.1q is also an open standard.

Negotiation can also be turned off and ports forced into EtherChannel.

Standard VLANs from 1 – 999 Extended VLANs from 1000 – 4094
To create VLANs 1000 – 4094 you must be in VTP Transparant mode in you’re running VTP 1 or 2, otherwise you must be using VTP v 3 to create VLANs in this range.

If a client, SW2, sees two VTP Servers SW1 and SW3 which are not themselves directly connected, but are connected through SW2 and SW2 loses connection with SW1, then the client receives an update to add vlan 999 from the SW3, the client will UPDATE the SW1 that’s been offline with that new VLAN information when it comes back on!

SW1, will see that its configuration revision number is lower than SW2, and even though SW2 is a “client” SW1 will use the updated information in the VTP advertisement from SW2 to update to its VLAN database, and get in “sync” with the rest of the VTP domain, including knowing about VLAN 999. So even though Clients cannot modify the VLAN database, they can pass changes to other servers if the configuration revision is higher than the server assuming the security credentials – domain and VTP password are correct.

Default for a new switch is to startup in VTP Server mode with a NULL domain name and no password.
If a switch in this condition is connected using a trunk port with a switch to a VTP domain with no password, that switch will automagically assume a role within that domain and add information from that domain to its VLAN database.

Should a switch with the correct domain name, no password (or the correct current password for the domain) and a higher VTP revision number attach itself to the network – client OR Server remember! – that switch will overwrite the other swtiches VLAN database information with the information that it holds, which could be disastrous!

A non-root bridge only generates BPDUs when it receives one on the root port.

Cisco enhanced the original 802.1D specification with features such as Uplink Fast, Backbone Fast, and Port Fast to speed up the convergence time of a bridged network. The drawback is that these mechanisms are proprietary and need additional configuration.

The port that receives the best BPDU on a bridge is the root port. This is the port that is the closest to the root bridge in terms of path cost. A port is designated if it can send the best BPDU on the segment to which it is connected A blocked port receives a more useful BPDU than the one it sends out on its segment. Remember that a port absolutely needs to receive BPDUs in order to stay blocked.

Port Roles:-

Root Designated Blocking

Port States:- A port moves through these five states as follows with disabled always being a possibility:- From initialization to blocking From blocking to listening or to disabled From listening to learning or to disabled From learning to forwarding or to disabled From forwarding to disabled

The timers are :-

20 secs Blocking 15 secs Listening 15 secs Learning

802.1w

Each switch can report STP failures to the topology, not having to report back to the root as in 802.1d

3 port States:-

Discarding Learning Forwarding

RSTP Port Roles:- Root port: This port role exists in 802.1D (STP), too, and is the best path back to the root bridge; it must exist on all nonroot bridges. Designated port: This port role exists in 802.1D (STP), too, and there must be a DP on all segments in the topology. By default, all ports on the root bridge are DPs. Alternative port: This port role is new to 802.1w (RSTP) and is a quickly converging port to the Root port for a system. Backup port: This port role is new to 802.1w (RSTP) and is a quickly converging port to the current Designated port on a segment.

Root Designated Alternate Backup

This distinction is already made internally within 802.1D. This is essentially how Cisco UplinkFast functions. The rationale is that an alternate port provides an alternate path to the root bridge and therefore can replace the root port if it fails. Of course, a backup port provides redundant connectivity to the same segment and cannot guarantee an alternate connectivity to the root bridge. Therefore, it is excluded from the uplink group.

Adjusting the STP Root

(config)#spanning-tree vlan X root primary|secondary Runs as a macro, simply surveys the current topology and adjusts the configuration as a once off operation.

Or to manually adjust the STP Priority use :- (config)#spanning-tree vlan X priority <0-61440> bridge priority in increments of 4096

Port Priority & Port Cost

Remember this is an interface level configuration to influence the election of Root Ports.

Priority affects the downstream switch, so assuming all costs are equal on the downstream switch, your priority command which is between 0 & 240 in value influences the downstream switches choice of root port.

Cost affects your own switch, assuming you have four Fast Ethernet links costing an equal 19 each, simply setting one of the non-root ports to a cost of 18 will influence your switch into choosing that port as the root port.

In order to select a root port (best path towards root bridge) you look at: 1. Lowest cumulative cost to root (this means adding up the link’s costs hopping through the domain to the root) If a tie between more than one links: 2. Lowest received bridge ID (this is only helpful if you have links to more than one upstream switch. Same switch = same received bridge id) If a tie here: 3. Port Information – this includes port ID and port priority information To influence these behaviors, you can change the cost of a link locally (local change = local influence) or you can change the port priority remotely (local change = remote influence). Port priority is evaluated before the port ID is.

Loop and Root Guard

The root guard is mutually exclusive with the loop guard. The root guard is used on designated ports, and it does not allow the port to become non-designated. The loop guard works on non-designated ports and does not allow the port to become designated through the expiration of max_age. The root guard cannot be enabled on the same port as the loop guard. When the loop guard is configured on the port, it disables the root guard configured on the same port.

Loop Guard

The STP loop guard feature provides additional protection against Layer 2 forwarding loops (STP loops). An STP loop is created when an STP blocking port in a redundant topology erroneously transitions to the forwarding state. This usually happens because one of the ports of a physically redundant topology (not necessarily the STP blocking port) no longer receives STP BPDUs. In its operation, STP relies on continuous reception or transmission of BPDUs based on the port role. The designated port transmits BPDUs, and the non-designated port receives BPDUs. When one of the ports in a physically redundant topology no longer receives BPDUs, the STP conceives that the topology is loop free. Eventually, the blocking port from the alternate or backup port becomes designated and moves to a forwarding state. This situation creates a loop. The loop guard feature makes additional checks. If BPDUs are not received on a non-designated port, and loop guard is enabled, that port is moved into the STP loop-inconsistent blocking state, instead of the listening / learning / forwarding state. Without the loop guard feature, the port assumes the designated port role. The port moves to the STP forwarding state and creates a loop.

Per Interface (config-if)#spanning-tree guard {loop|none|root}

Or globally for Loopguard only (config)#spanning-tree loopguard default Then use (config-if)#spanning-tree guard none To disable it on ports that you don’t want the global default to affect.

Quick views as to whether LoopGuard is configured:- Globally:- #sh spanning-tree summary Per Interface:- #sh spanning-tree detail | i Loop To give you an idea of whether it’s on anywhere.Root Guard When root guard is enabled, if spanning-tree calculations cause an interface to be selected as the root port, the interface transitions to the root-inconsistent (blocked) state to prevent the customer’s switch from becoming the root switch.

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.

BPDU Guard The BPDU guard feature provides a secure response to invalid configurations because you must manually put the interface back in service. Use the BPDU guard feature in a service-provider network to prevent an interface from being included in the spanning-tree topology. Globally (config)#spanning-tree portfast bpduguard default Then use this command per-interface to disable bpuguard (config-if)#spanning-tree bpduguard disable Per interface (config-if)#spanning-tree bpduguard enable Quick Views on BPDUGuard activityGlobally:- #sh spanning-tree summary Per Interface #sh run | i bpduguard

Storm Control Storm control is supported only on physical interfaces – ingress. You can also configure storm control on an EtherChannel. When storm control is configured on an EtherChannel, the storm control settings propagate to the EtherChannel physical interfaces. On each interface, a maximum threshold can be configured in bits or packets per second, or as a percentage of the interface bandwidth. If incoming traffic of the specified type exceeds its threshold during a polling interval (one second), traffic is blocked until the incoming rate drops below the configured falling interval. Multicast limits must be higher than Broadcast limits (if they are both configured). Per Interface:- (config-if)#storm-control unicast|broadcast|multicast level rising falling

The switch will generate a log message notifying administrators of the detected storm:

%STORM_CONTROL-3-FILTERED: A Broadcast storm detected on Fa0/5. A packet filter action has been applied on the interface.

Additionally you can configure storm control actions which do either or both send snmp traps and/or shut down the interface. (config-if)#storm-control action shutdown|trap

Quick views on Storm Control configuration:- #sh storm-control Further filters on this command simply target the show command onto interfaces or uni\broad\multicasts but do not make the output any more verbose than the base show command.

Unicast Flooding Current lab IOS and Equipment:- http://www.cisco.com/web/learning/le3/ccie/rs/lab_equipment.html Currently the lab features only 3560 switching equipment and this command is not available in the 3560 IOS version 12.2(44)SE6 which is being used in my or INE’s reccommended study topologies. It’s only available in the 6500 series switches and above from my understanding.

An alternative configuration approach found on some Catalyst model devices (such as the 6500 series) is to use Unknown Unicast Flood Blocking (UUFB), which is configured with the following simple interface command:

(config-if)#switchport block unicast

Hope this is useful to some peeps other than me. I’ll post section 1.20 in the coming days.