What Does Spanning Tree PortFast Really Do?

As we know, STP generates TCNs every time a link changes (up/down) and changes the state of the port from blocking to forwarding. This state changing mechanism is a slow process which is not needed for edge ports where we don't plug switches. PortFast feature give solution to this problem..

The 2 things PortFast enabled interfaces do are

1. Go to forwarding state immediately

2. Does not generate TCNs

But remember, PortFast will not remove the interface from STP process. So you should not connect any hubs, bridges, switches etc. Only single hosts should be allowed to connect to those ports..

Let's take a 2960 access switch and see what is really happening when there is no PortFast and when there is PortFast..

The switch is not connected to any thing.

I have turned on debug spanning-tree events

When a PC is connected to Fa0/23 of the switch..

You can see it went through the STP states and became a Designated Forwarding port. This operation took 50 seconds by default..

Once it the Fa0/23 is disconnected, you will see the following output..
(click on the images to view in full size)

You can see a TC trap is generated..

Now I am configuring PortFast on the switch..
It can be done globally for all the access ports or for particular interfaces only. Affect is same..

SW-A(config)#spanning-tree portfast default

Now when I connect the PC to Fa0/23 it will say "jump to forwarding from blocking" and it will happen instantly..

Now you can see the port type is shown as P2p Edge instead of P2p..

When the link is removed it will only down the port without generating a TC..

Switch Database Management & Templates of Cisco L3 Switches

Cisco Catalyst switches use TCAM to store information regarding forwarding lookups. There are few templates which are created with different aspects of networking needs. As an example, a L3 switch in a one area will have to perform routing tasks rather L2 switching.

Another switch will need more memory to store L2 information. So to utilize the hardware well to match the networking needs of a particular switch, administrator will have to change the default template the switch is shipped with..

I grabbed a switch from my lab, let's see what is the SDM template of this switch..
Switch#show sdm prefer

It looks like Desktop Default is the SDM template here. You can see 6K is reserved for unicast MAC addresses and 8K is used for IPv4 unicast routes etc..

Let's change this to something else.. How about a routing preferred template?
Switch(config)#sdm prefer routing

After saving and reloading,

As you can see now there are 20K space partitioned for IPv4 unicast routes..

These are pre-built templates. Actually there are 2 versions of each template and they are Desktop version & Aggregator version.. If you enter sdm prefer routing, Aggregator version of routing template will be applied and if you enter sdm prefer routing desktop, Desktop version will be applied.
This is common for every template type..

Following is a chart from Cisco which shows the partitions for desktop and aggregator versions of common 4 templates (access, default, routing, vlan)

SDM Templates in Switch Stacks

All stack members use the same SDM template that is stored on the stack master. When a new switch is added to a stack, as with the switch configuration and VLAN database files, the SDM configuration that is stored on the stack master overrides the template configured on an individual switch..

Initial Convergence of Classic Spanning Tree Protocol

Classic Spanning Tree (802.1d) has 3 steps of convergence to provide a loop free switched network.

1. Elect one root bride
2. Elect one root port per non root bridge
3. Elect one designated port per network segment

But the logic behind all the above 3 steps are very simple and straight forward.
It is the logic of identifying the superior BPDU (Bridge Protocol Data Unit - L2 data frames which contains STP information).

Following is the format of a BPDU..

Switches compare the BPDUs received on their ports and determine which one is better. They are compared in the following order, lower the value is better..

1. Root Bridge ID
2. Root Path Cost
3. Sender Bridge ID
4. Sender Port ID
5. Receiver Port ID (not included in the BPDU, evaluated locally)

Also each port in STP stores the superior BPDU that it has either sent or received. Only the Designated Ports send superior BPDUs while Root Ports & Alternate Ports only receive BPDUs.

Note:- There are 2 types of BPDUs called Configuration BPDUs and TCN BPDUs but in initial convergence, only the Configuration BPDUs will be involved.

Let's power on a switched network..

MAC Addresses are;

SW1: aabb.cc00.1000
SW2: aabb.cc00.2000
SW3: aabb.cc00.3000
SW4: aabb.cc00.4000
SW5: aabb.cc00.5000










STEP 1 : Root Bridge Election

When the switches are turned on each switch thinks it is the root bridge and sends BPDUs out of its ports to neighboring switches..

Because each switch claims itself as root bridge at the initial stage,  Root ID & Bridge ID are same.
Bridge ID is composed of Bridge Priority & MAC Address..

The Root Bridge is the switch which generates the most Superior BPDUs

Of cause it is the switch with the lowest Bridge ID.  Finding the lowest Bridge ID has the following order..

1. Lowest Bridge Priority.
2. Lowest MAC Address.

Default Bridge Priority value is 32768 + system extension ID.
System extension ID is nothing but the VLAN number..
Priority can be changed by the increments or decrements of 4096..

I did not change the priority of above switches, so SW1 which has the lowest MAC address became the root bridge..

When 2 switches exchange their BPDUs and realize one is superior than the other, the inferior BPDU sending switch determines itself as the non-root switch and stops sending it's own BPDUs out of its ports and start relaying the Root's BPDUs downstream to the other switches.

If we see the show spanning-tree output of SW1;

You can see it says "This bridge is the root" & all the ports are Designated Ports..

STEP 2 : Root Port Election per Non Root Bridge

Non Root Bridges elect a one port which is best to reach the Root Bridge based on link cost.

Cost calculation is just like in OSPF..

Root port is the port which receives the Superior BPDU from the Root switch..

Because the Root ID of the BPDU is same now, the Root Path Cost will be the used to find the Superior BPDU at 1st. If the Root Path Cost is equal, Sender Bridge ID, Sender Port ID, Receiver Port ID will be used to find the superior BPDU..

Let's see a show spanning-tree output of a non root bridge like SW5;

E0/3 has become the Root Port. Why is that?

You can see the cost value of E0/3 is 19 but this is not the actual value the decision was taken. Cumulative cost to the Root Bridge was the real value which was taken into the calculation. This 19 is the local value for this switch. To see the root path cost we will have to see the show spanning-tree detail output for the E0/3 interface..

You can see it says "cost to the root path is 119"

Let's see a show spanning-tree output of another non root bridge like SW2;

E0/3 has become the Root Port and E0/0 has become the Alternate. Why is that?

In the diagram, you can see the Cost & the Upstream Bridge ID is equal, so the last tie breaker is the Upstream Bridge Priority.. You cannot decide it by looking the above output because it shows the local interface priorities. So you have to see the show spanning-tree detail output..

You can see the port priority values which were taken to the calculation now on the above output.

STEP 3 : Designated Port Election per Network Segment

Each network segment has one Designated Port to forward traffic. These ports are the downstream ports from the Root Bridge. Other ports in the segment (if not a Root Port) becomes Alternate Ports which blocks the traffic.
Although Alternate Ports block data traffic they still receive BPDUs..

When all ports of switches become either forwarding or blocking, we call STP is converged and data can be transmitted on wards..

Designated port is the port which sends the Superior BPDU into the segment..

Because the Root ID of the BPDU is same now, the Root Path Cost, Sender Bridge ID, Sender Port ID, Receiver Port ID will be used to find the superior BPDU..

So considering the above rules, following ports will be blocked..

Finally the diagram will logically look like the following..

STP Port States, Timers & Roles

When switches are powered on, STP goes from Blocking > Listening > Learning > Forwarding
States..

Here is a quick summary of the Port States..

Timers are set by the Root Switch..

Hello Time is the time frequency which the Configuration BPDUs are sent.. Default is 2s.
Max Age is the time which a BPDU is considered valid by the Root switch.. Default is 20s.
MessageAge is the BPDU's age since it was originated by the Root switch. At the root switch it is set to 0 and other switches increment this value by 1 before forwarding further..
Therefore remaining lifetime of a BPDU after receiving by a switch is (MaxAge - MessageAge)
Forward Delay is the time which it takes to move from Listening State to Learning State and Learning State to Forwarding State.. Default is 15s.
Aging Time is the time which a CAM table entry will be valid.. Switches flush the MAC Address entry from it's CAM table after this time expires.. Default is 300s.

Port Roles are Designated, Root & Alternate..
Designated & Root Ports are opened for the traffic to flow through.. Alternate Ports will be in Blocking State and will be changed to Listening > Learning > Forwarding when a Designated Port is failed and STP decides to forward traffic through it..
It will take 20 + 15 + 15 = 50 Sec to forward traffic by default..

If you want to know how Classic Spanning Tree deals with topology changed please go here.

VSS Related Configuration of Cisco Catalyst 6500 Series Switches

Here are the essential steps to configure Virtual Switching System (VSS) of a Cisco Catalyst 6509 switch. Here in my setup I have 2 6509 switches with 720 Supervisor Engines, one per each chassis. In this setup, only 1 Supervisor engine will be active and the other will stay standby.

STEP1: Assigning Virtual Switch Domain & Switch Numbers

Domain name must be same on both the switches.

ADM-6509-VSS(config)#switch virtual domain 100
ADM-6509-VSS(config-vs-domain)#switch 1
ADM-6509-VSS(config-vs-domain)#switch 1 priority 110
ADM-6509-VSS(config-vs-domain)#switch 2 priority 100

ADM-6509-VSS-2(config)#switch virtual domain 100
ADM-6509-VSS-2(config-vs-domain)#switch 2
ADM-6509-VSS-2(config-vs-domain)#switch 1 priority 110
ADM-6509-VSS-2(config-vs-domain)#switch 2 priority 100

Highest priority value switch will be the priority. If the priority is not configured, the lowest switch number will be the active switch..

STEP2: Configuring VSL Port Channel

Virtual Switch Link (VSL) is the port channel which the VSS parameters will be exchanged to sync data & management planes. They are configured as L3 port-channels.

ADM-6509-VSS(config)#int port-channel 11
ADM-6509-VSS(config-if)#no switchport
ADM-6509-VSS(config-if)#switch virtual link 1

ADM-6509-VSS-2(config)#int port-channel 12
ADM-6509-VSS-2(config)#no switchport
ADM-6509-VSS-2(config-if)#switch virtual link 2

STEP3: configure the VSL ports

Typically we use 2x10GE links as the members of the VSL portchannel.

ADM-6509-VSS(config)#int range te1/5/4-5
ADM-6509-VSS(config-if-range)#switchport mode trunk
ADM-6509-VSS(config-if-range)#channel-group 11 mode on

ADM-6509-VSS-2(config)#int range te2/5/4-5
ADM-6509-VSS-2(config-if-range)#switchport mode trunk
ADM-6509-VSS-2(config-if-range)#channel-group 12 mode on

STEP4: Converting the Switch to Virtual Switch Mode:

ADM-6509-VSS#switch convert mode virtual 

ADM-6509-VSS-2#switch convert mode virtual

If there are no mismatching parameters, switches will reboot after entering this command..

STEP5: Configuring the Dual Active Fast-Hello

MCEC (Multi Chassis Ether Channel) is created like in this diagram. So if the VSL links fail for some reason, SW2 will think the supervisor engine of SW1 is gone and SW2 will also become active. Because both the supervisor engines are active now it can cause routing & switching loops and black holes. 

To prevent this we have to configure a dedicated link to monitor the active status of the supervisor engines.

It can be any link, usually a Gig port..



ADM-6509-VSS(config)#switch virtual domain 100

ADM-6509-VSS(config-vs-domain)#dual-active detection fast-hello

ADM-6509-VSS(config)#interface GigabitEthernet1/7/48

ADM-6509-VSS(config-if)#no switchport

ADM-6509-VSS(config-if)#no ip address

ADM-6509-VSS(config-if)#dual-active fast-hello

ADM-6509-VSS(config-if)#interface GigabitEthernet2/7/48

ADM-6509-VSS(config-if)#no switchport

ADM-6509-VSS(config-if)#no ip address

ADM-6509-VSS(config-if)#dual-active fast-hello

When dual-active condition is detected, the original active chassis enters into recovery mode and brings down all of its interfaces except the VSL and excluded interfaces.

Verification Commands

Following outputs are from a currently working VSS..

show switch virtual

show switch virtual role

show switch virtual link

show switch virtual link port-channel

show switch virtual redundancy

show redundancy

show switch virtual dual fast-hello

You can also find the mismatch parameters in VSS by issuing the following command
show switch virtual redundancy mismatch

Stackwise Technology of Cisco IOS Switches

Stackwise technology is used to combine several physical switches into a one logical switch.
Layer 3 switches like Cisco 3750, 3750-X, 3850 and layer 2 switches like 2960-X support this technology. 3750 supports maximum of 9 physical switches per stack..

Special cable type called stack cables are used to create a daisy-chain (loop) between switches. They are connected to the stack ports at the back of the switch. Each supported switch has 2 stack ports.
Following picture shows how it is to be done when it has 3 or more switches.

Either way it works..

Anyhow what required is that all the switches must be connected in a ring by stack cables.

I am using 2 Cisco 3750 series switches to experience how it works.. IOS version must be equal.

Before stacking, lets see some the stack details of both switches.. I reset both the switches before starting this lab, but remember even resetting does not change the pre-configured stack priorities..

Default priority is 1 and the highest is 15. Switch with the highest priority becomes the master.

Issuing show switch command;

As you can see, both the switches think they are the Master. Let's stack them with a one cable and see what happens..

SW1 went to an auto reboot, and it became just a member. Now I'm consoling to the SW1 but I can see its name as SW2. This means all the configuration of SW1 is overwritten from the configuration of SW2. Issuing show switch command;

Let's see why it became a member.

Stack Master election process is like the following..

1. Configured priority
we can configure a priority to decide which switch becomes the master.

2. Hardware / software priority
The switch with the most extensive feature set has a higher priority than another switch (for example: IP Services vs IP base).

3. Default Configuration 
A switch that already has a configuration will take precedence over switches with no configuration.

4. Uptime
The switch with the longest uptime.

5. MAC address
The switch with the lowest MAC address.

It looks like the MAC address is the tie breaker here.

Anyhow only one stack cable was needed to bring the stack up for 2 switches..

But why we always see 2 stack cables are used to bring a 2 switch stack in production?

Let's issue another command; show switch stack-ring speed

Now let's connect another stack cable and see what happens..

You can see the ring speed has become 32G and the ring configuration is full. This is the reason we always prefer to add 2 cables even for 2 switches..

My real physical connection is like this..

You can see which switch is connected to which switch by issuing show switch neighbors

Best practice is to change the priority of the switches to be master.  Let's say I want to make the switch 1 to be master,

SW2(config)#switch 1 priority 15

As you can see, it changed the priority, but it did not took over the master role. It will only be the master if the current master is down.

Things to keep in mind:-

1. IOS version must be equal to begin with.
2. Even resetting does not change stack priority values configured.
3. Default priority is 1 and highest is 15 and the highest will be the master.
4. There is no preemption here.
5. Master will overwrite member configuration by its running config.
6. Though you issued a reload command by consoling to a switch in the stack, all the switches will reboot.

Correct Order of L3 Etherchannel Configuration

If you want to know how to configure L2 etherchannels, please visit here

1. Create the logical interface and issue no switchport command and give an ip address

SW1(config )#int po1
SW1(config-if)#no switchport
SW1(config-if)#ip address 12.12.12.1

2. Go to the physical member interfaces with blank configuration  & issue no switchport command and assign the channel group

SW1(config )#int range e0/0-1

SW1(config-if-range)#no switchport
SW1(config-if-range)#channel-group 1 mode on

Configure SW2 in same manner..

If everything went ok, following outputs will be present.

If it says (RU) it's an L2 etherchannel and it is working in Routed mode. (P) after the member interfaces indicate they are correctly bundled in. Protocol will be a blank because I used unconditionally "on" (neither LACP or PAGP).

Here are the 2 protocols to negotiate etherchannels..

1. LACP (active & passive)
2. PAGP (desirable & auto)

Active and desirable modes start negotiation while passive and auto modes listen only..
As an example, if I used LACP, one side must be considered as active while the other end must be configured as active or passive..

Additional load balancing can be done in global configuration mode.
SW1(config)#port-channel load-balance src-ip 

Correct Order of L2 Etherchannel Configuration

Entire networks can go down if the etherchannel is not configured correctly or in correct order.

1. Go to the physical member interfaces with blank configuration  & assign the channel group to the physical member interfaces. Do this on both switches..

SW1(config )#int range e0/0-1

SW1(config-if-range)#channel-group 1 mode active

2. Go to the portchannel interface and apply the configuration after the portchannel is operational, you must do all other configuration (trunk/access, allowing vlans etc) only inside the portchannel interface.

SW1(config )#int po1
SW1(config-if-range)#switchport trunk encapsulation dot1q
SW1(config-if-range)#switchport mode dynamic desirable
SW1(config-if-range)#switchport trunk allowed vlan 10,20

If everything went ok, following outputs will be present.

If it says (SU) it's an L2 etherchannel and it is working. (P) after the member interfaces indicate they are correctly bundled in..

Here the protocol I used is LACP. So the other end must be configured as channel-group mode active or passive..

Here are the 2 protocols to negotiate etherchannels..

1. LACP (active & passive)
2. PAGP (desirable & auto)

Active and desirable modes start negotiation while passive and auto modes listen only..

You can create a channel even without a negotiating protocol by issuing the both ends to be "on"..
Best practice is to use a protocol because "on" can lead to many catastrophes. Even the total network can go down because of a single misconfiguration.

Additional load balancing can be done in global configuration mode.
SW1(config)#port-channel load-balance src-ip 

Assigning Many IP Addresses to a Single Interface

When you have a network on an interface with 192.168.1.0/24 and you run out of IPs and you need to put more servers there, you can use secondary IP on that interface and bring up another range like 192.168.2.0/24. Another practical use of secondary address is during IP address space migrations.

Configuration is simple like the following..

R1(config)#int e0/0

R1(config-if)#ip address 192.168.1.1 255.255.255.0

R1(config-if)#ip address 192.168.2.1 255.255.255.0 secondary 

R1(config-if)#ip address 192.168.3.1 255.255.255.0 secondary 

R1(config-if)#ip address 192.168.4.1 255.255.255.0 secondary

Here I have assigned 192.168.1.1 as the primary interface IP address and other 3 IPs as secondary IP addresses.

This will be shown in the routing table under the same interface..

But you will not see them on show ip interface brief output..

Note that you can assign IP addresses of the same range as secondary IP addresses too..

How ASA Real Time Log Viewer Displays Connections

This post will help you to understand how sessions / connections in ASA are built and teared down in ASA and how they are displayed in Real Time Log Viewer..

Outside router is connected to Internet directly and MGT cloud used here is only to get ASDM access to ASA. If you want to configure this lab, click here to go to the post which explains how to setup ASDM access to an ASA.

Interfaces on ASA are configured as following..

Service Policy to inspect ICMP & ICMP error is configured on ASA.





Configuration on R1..

R1(config)#ip route 0.0.0.0 0.0.0.0 192.168.10.254

R1(config)#int e0/0
R1(config-if)#ip address 192.168.10.1 255.255.255.0

Configuration on R2..

R2(config)#ip route 0.0.0.0 0.0.0.0 192.168.23.3
R2(config)#ip route 192.168.10.0 255.255.255.0 192.168.20.254

R2(config)#int e0/0
R2(config-if)#ip address 192.168.20.2 255.255.255.0
R2(config)#int e0/1
R2(config-if)#ip address 192.168.23.2 255.255.255.0

Configuration on R3..

R3(config)#ip route 0.0.0.0 0.0.0.0 10.1.1.2
R3(config)#ip route 192.168.10.0 255.255.255.0 192.168.20.2

R3(config)#int e0/0
R3(config-if)#ip address 10.1.1.10 255.255.255.0
R3(config-if)#ip nat inside
R3(config)#int e0/1
R3(config-if)#ip address 192.168.23.3 255.255.255.0
R3(config-if)#ip nat outside

R3(config)#access-list 10 permit any
R3(config)#ip nat inside source list 10 interface Ethernet0/0 overload

What happens when I send ICMP packets from R1?

Let's now ping 8.8.8.8 from R1 and see how it is displayed in Log Viewer..
(click on the image to view in full readable size)

Connection is built from source of 192.168.10.1 to the destination of 8.8.8.8
Connection is Teared down from source of 8.8.8.8 to the destination of 192.168.10.1
You can see that the port numbers are 0 because ICMP works at network layer.
However there can be a source port number sometimes for the 192.168.10.1 from the next time you send traffic.

Only these 2 lines will be displayed even for 1000 packets sent continuously because an ASA session is created for a flow, not to a single packet..

What happens when I send TCP packets from R1?

Let's try to telnet 8.8.8.8 from R1..

Connection is built from source of 192.168.10.1 to the destination of 8.8.8.8
Connection is Teared down from source of 8.8.8.8 to the destination of 192.168.10.1
You can see that the destination port number is 23 on google.

What happens if an ACL blocks the outgoing traffic on path?

R3's e0/0 is configured with an ACL as following..

R3(config)#access-list 20 deny any
R3(config)#int e0/0
R3(config-if)#ip access-group 20 out

I am pinging 8.8.8.8 from R1. 5 denies imply the 5 icmp packets generated from R1.

Connection is built from source of 192.168.10.1 to the destination of 8.8.8.8
Next 5 logs say it is denied from 192.168.23.3 which is the firewall side interface of R3
Final log says Connection is Teared down from source of 8.8.8.8 to the destination of 192.168.10.1 which means that tearing down log does not really say its a packet originated from 8.8.8.8, It is built from the ASA..

What happens if an ACL blocks the incomming traffic on path?

Now I removed the access-group command on e0/0 interface and applied it in e0/1 interface on R3.

It is the same as before. That means if it is blocked from an ACL on any interface on a router in the path, that router will send the deny log from its firewall side interface.

Is this "Deny" log comes just because it is denied from an ACL?

Well let's findout, I just deleted the ACL 20 from R3 router and shut the e0/0 interface of OUT.

It looks like the "Deny" log is not just saying it is blocked by an ACL. It just says it is unreachable..

But if you looked closer you will notice that the details say Type 3 Code 13 for the ACL blocking instances & it says Type 3 Code 1 when the interface is shut.

Let's see what are those, (source from iana.org)

Ah, now you can say what has really happened ryt? It's an Administration Prohibit when it is blocked by an ACL and it is a destination unreachable when the e0/0 is shut.

If that was a TCP session, how will it be displayed?

Well, let's telnet to 8.8.8.8 while e0/0 of R3 is down..

It looks almost same. Denied packets will display an ICMP error & the connection will be displayed as a TCP connection.

What will be displayed if  the firewall side interface is down on a router?

Now let's see what will happen when the e0/1 interface of R3 is down..

Well, you don't see any issue. It looks exactly like it is working correctly. But It is not.

Let's continue the lab..

What will happen if a route is missing to the incoming path?

Let's findout, I removed the ip route 192.168.10.0 255.255.255.0 192.168.23.2 route from R3.

Well it looks like working too. But really it is not.. Let's continue with another scenario before we come to a conclusion..

What will happen if a route is missing to the outgoing path?

I removed the ip route 0.0.0.0 0.0.0.0 10.1.1.2 route from R3.

It is just same as scenario which the e0/0 of R3 was down. A destination unreachable from the firewall side interface of R3.

So it looks like  you can't really say it is working just by looking the log viewer. Log will not say anything if the firewall side interface of a router is down or a route to the firewall side is missing in the path.. Aslo the final tearing connection down log will be sourced from the real destination which the connection was to be initiated even though it was a failure, that one is just a firewall log (does not tell it is a packet came from a real host)