CCIE R&S Written 1.50 Implement SPAN, RSPAN and Flow Control


Configuration of SPAN as follows:-

Single port source:
(conf)#monitor session 1 source interface fastethernet 0/1  both|rx|tx
Range of ports source:
(conf)#monitor session 1 source interface fastethernet 0/1  – 2 both|rx|tx
Non sequential list of ports source:
(conf)#monitor session 1 source interface fastethernet 0/1 , fastethernet 0/4  both|rx|tx

(conf)#monitor session 1 destination interface fastethernet 0/2


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.

(config)#vlan 998
(config-vlan)#name RSPAN

On the source switch

(config)#monitor session 1 source interface fastethernet 0/1
(config)#monitor session 1 destination remote vlan 998

On the remote switch

(config)#monitor session 1 source remote vlan 998
(config)#monitor session 1 destination interface fastethernet 0/12 {encapsulation|ingress}

Flow Control

Devin’s post on Flow-Control here

Configuring flow control is completed in interface config mode. In the lab, 3560’s are used and flowcontrol ‘send’ is unsupported using 12.44(SE6), so it’s only receive that can be configured.

(config-if)#flowcontrol receive desired|on|off

To view flow control on your switch:

#show flowcontrol



Don’t you go to Goa

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.

CCIE R&S Written 1.40 Implement Ethernet Technologies

Speed and Duplex

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.


Stretch’s article here

Leased Line DataLink (L2) Protocols – HDLC and PPP
HDLC is the default on all Cisco RoutersHDLC is Cisco Proprietary, Low Overhead, No Features

PPP Industry StandardModerate OverheadFeature-iffic! e.g. Authentication, Compression, Multilink
PAP Clear Text AuthenticationCHAP Clear Text Username, MD5 hashing of password
Older PPP examples use VPDN (Virtual Private Dial Network)Newer examples use BBA (Broad Band Access) aka PPPoE Profiles
PPPoE Active Discovery Initiation/PPPoE Active Discovery Request (PADI/PADR)
PPPoE Active Discovery Offer (PADO) and PPPoE Active Discovery Session (PADS) frames

Configuration CLIENT (BBA)

interface Dialer1
ip address dhcp
encapsulation ppp
dialer-pool 6

interface Ethernet0/0
pppoe enable
pppoe-client dial-pool-number 6

Configuration SERVER (BBA)

ip dhcp pool VLAN146

interface virtual-template 1
ip add
peer default ip address dhcp-pool VLAN146

bba-group pppoe MYPPP
virtual-template 1

interface fastethernet 0/0
pppoe enable group MYPPP

To add authentication to the configuration,


interface virtual-template 1
ppp authentication chap

username R4 password cisco


interface dialer 1
ppp chap hostame R4
ppp chap password cisco

Configuration Client (VPDN)

interface Ethernet0/0
pppoe enable
pppoe-client dial-pool-number 1
interface Dialer1 ip address
encapsulation ppp
dialer-pool 1
dialer persistent

Configuration Server (VPDN)

vpdn enable
vpdn-group CISCO
protocol pppoe
virtual-template 1
interface Ethernet0/0
pppoe enable
interface Virtual-Template1
ip address

To view configuration and use of the dialer interface, use:-

show ip route
show pppoe session
show ip interface brief
show ip dhcp binding
show run | sec bba-group

CCIE R&S Written 1.30 Implement Trunk and Trunk Protocols, EthernChannel and load-balance

DTP – Dynamic Trunking Protocol

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:-

Dynamic desirable (default mode on Catalyst 2950 and 3550)
Dynamic auto (default mode on Catalyst 3560)
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.

Commands of interest are :-

Operational Modes

switchport nonegotiate
switchport mode access
switchport mode dot1q-tunnel
switchport mode dynamic auto
switchport mode dynamic desirable
switchport mode trunk

Encapsulation Negotiation

switchport trunk encapsulation negotiate
switchport trunk encapsulation dot1q
switchport trunk encapsulation isl

Viewing the settings of a port would be achieved using :-

show interface fastethernet 0/1 switchport

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


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.

channel-group 1 mode active                                                            LACP
channel-group 1 mode auto | auto non-silent                            PAgP
channel-group 1 mode desirable | desirable non-silent         PAgP
channel-group 1 mode on
channel-group 1 mode passive                                                         LACP

Verification of the mode used on your EtherChannel configuration can be viewed by :-

show etherchannel protocol

A more comprehensive overview of EtherChannel configuration would be to use:-

show etherchannel summary

Configuration of the EtherChannel group is then completed using the command:-

interface port-channel 1

Where you can find normal interface configuration commands which get propagated to all interfaces in the channel group should they be executed.

Configuring Load-Balancing for the EtherChannel can be configured using the global command:-

port-channel load-balance dst-ip
port-channel load-balance dst-mac
port-channel load-balance src-dst-ip
port-channel load-balance src-dst-mac
port-channel load-balance src-ip
port-channel load-balance src-mac

Number of Ports Load Balancing
8 EQUAL 1:1:1:1:1:1:1:1
7 2:1:1:1:1:1:1
6 2:2:1:1:1:1
5 2:2:2:1:1
4 EQUAL 2:2:2:2
3 3:3:2
2 EQUAL 4:4

CCIE R&S Written Section 1.20 – Implement VLAN and VTP


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!

#show vtp status
#show vtp password
(config)#vtp version 1|2
(config)#vtp domain NAME
(config)#vtp password PASSWORD

These are the main configuration commands for VTP.

VTP pruning

VTP pruning can only be enabled on switches that are VTP 2 capable. They don’t actually have to be running VTP v2, but they must be capable.

Enabling VTP pruning on the VTP Server in a Client/Server topology will enforce pruning throughout the VTP domain.

To enable VTP Pruning, either visit the server or transparant mode VTP switch and enter:-

(config)#vtp pruning

Confirm it’s in effect using simply

#show vtp status

In the output of this command you should expect to see

VTP Pruning Mode                : Enabled

CCIE R&S Written Section 1.10 – Implement STP

This is the first of my Written exam posts to summarize my understanding of the technologies before entering the exam on the 23/12/10.

Here’s the current v4.0 Exam Topics so you can match my rantings with the syllabus.


Phase 1 – Root Bridge Election
Phase 2 – Root Port Election

Switches report STP failures to the root for further propogation.

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 FastBackbone 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:-


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


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

3 port States:-


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.


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.

Read here for a longer explanation.

Root Port Selection

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:-
#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.

Per Interface:-

(config-if)#spanning-tree guard root
Quick views as to whether RootGuard is configured:-
#sh spanning-tree detail | i Root

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

(config)#mac-address-table unicast-flood {limit kfps} {vlan vlan} {filter timeout | alert | shutdown}

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.