Archive

Archive for August, 2013

Busting myths – PAgP desirable runs in silent mode by default

August 14, 2013 5 comments

Time to bust another myth! Supposedly PAgP runs in silent mode by default
in both desirable and auto mode. So what does silent mode do?

“Use the silent mode when the switch is connected to a device that is not PAgP-capable
and seldom, if ever, sends packets. An example of a silent partner is a file server
or a packet analyzer that is not generating traffic. In this case, running PAgP on a
physical port connected to a silent partner prevents that switch port from ever becoming
operational. However, the silent setting allows PAgP to operate, to attach the port to a
channel group, and to use the port for transmission.”

So now for the myth itself. The first quote is from David Hucabys CCNP SWITCH 642-813
Official Certification Guide.

“By default, PAgP operates in silent submode with the desirable and auto modes, and
allows ports to be added to an EtherChannel even if the other end of the link is silent
and never transmits PAgP packets. This might seem to go against the idea of PAgP,
in which two endpoints are supposed to negotiate a channel. After all, how can two
switches negotiate anything if no PAgP packets are received?”

And then from the Cisco configuration guide for 3560 12.12(58)SE.

“If your switch is connected to a partner that is PAgP-capable, you can configure the
switch port for nonsilent operation by using the non-silent keyword. If you do not specify
non-silent with the auto or desirable mode, silent mode is assumed.”

So even Cisco themselves claim that both modes operate in silent mode. Surely Cisco
can’t be wrong?! Doesn’t it seem strange to operate in silent mode by default? The
most common use must be to connect to other switches?

To test this we setup two switches with two trunks between themselves. One side is
set to auto and one side is set to desirable. Then debug pagp all is run to check
what mode they are running in.

SW1(config)#int range f0/13 - 14
SW1(config-if-range)#sh
SW1(config-if-range)#channel-group 1 mode des
SW2(config)#int range f0/13 - 14
SW2(config-if-range)#sh
SW2(config-if-range)#channel-group 1 mode auto
PAgP: Fa0/13 enabling PAgP with mode desirable-nonsl
PAgP: set hello interval from 0 to 1000 for port Fa0/13 
PAgP: Fa0/14 enabling PAgP with mode desirable-nonsl
PAgP: set hello interval from 0 to 1000 for port Fa0/14 
PAgP: Fa0/13 enabling PAgP with mode auto-sl
PAgP: set hello interval from 0 to 1000 for port Fa0/13
PAgP: Fa0/14 enabling PAgP with mode auto-sl
PAgP: set hello interval from 0 to 1000 for port Fa0/14

Myth busted! Desirable runs in non silent mode but auto runs in silent mode.
So this myth exist book in official certification books and in Ciscos documents
which is bad. I’ll look into getting it update if I can. The point of forming
an etherchannel is to negotiate with the other side before forming it to make
sure that the links are not unidirectional and that they agree on all parameters.

Advertisements

RSTP synchronization – behind the scenes

August 8, 2013 20 comments

Intro

It is well known that RSTP uses synchronization to speed up convergence in
switched networks. Not many articles or books give the full picture how this
process really works. The synchronization process is often oversimplified
and readers are left with the IEEE standard if they want to understand all
of the details. This post will give you a better understanding of how the
RSTP synchronization really works.

Initial synchronization

In regular 802.1D when switches first boot up ports are brought online
the switch claims to be root because it has not yet heard any better BPDUs.
This is no different in RSTP or RPVST+ which is Ciscos implementation.
Take a look at the following topology.

RSTP-synch-1

The goal here is to make SW1 the root bridge. But until better BPDUs have
been heard all switches will claim root. That is how STP works, it stores
the best BPDU received in on a port. To emulate a network coming online
to begin we will have all ports shutdown and then try to bring them up
at the same time. Debugs and captures will be run to show how the synchronization
process works. The following debugs have been enabled.

SW1#sh debug
Spanning Tree:
  Spanning Tree event debugging is on
  Spanning Tree state sync support debugging is on

So we start at looking at the debugs from each switch in order.

SW1

setting bridge id (which=3) prio 16385 prio cfg 16384 sysid 1 (on) id 4001.aabb.cc00.0100
RSTP(1): initializing port Et0/0
RSTP(1): Et0/0 is now designated
%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/0, changed state to up
RSTP(1): transmitting a proposal on Et0/0
RSTP(1): received an agreement on Et0/0
STP[1]: Generating TC trap for port Ethernet0/0

SW1 assumes its port is designated and sends out a proposal. SW2 will agree to this
proposal.

SW2

%LINK-3-UPDOWN: Interface Ethernet0/0, changed state to up
%LINK-3-UPDOWN: Interface Ethernet0/1, changed state to up
setting bridge id (which=3) prio 32769 prio cfg 32768 sysid 1 (on) id 8001.aabb.cc00.0200
RSTP(1): initializing port Et0/0
RSTP(1): Et0/0 is now designated
RSTP(1): initializing port Et0/1
RSTP(1): Et0/1 is now designated
%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/1, changed state to up
RSTP(1): transmitting a proposal on Et0/0
RSTP(1): transmitting a proposal on Et0/1
%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/0, changed state to up
RSTP(1): transmitting a proposal on Et0/0
RSTP(1): transmitting a proposal on Et0/1
RSTP(1): received an agreement on Et0/1
STP[1]: Generating TC trap for port Ethernet0/1
RSTP(1): transmitting a proposal on Et0/0
RSTP(1): transmitting a proposal on Et0/0
RSTP(1): updt roles, received superior bpdu on Et0/0 
RSTP(1): Et0/0 is now root port
RSTP(1): syncing port Et0/1
RSTP(1): synced Et0/0
STP[1]: Generating TC trap for port Ethernet0/0
RSTP(1): transmitting an agreement on Et0/0 as a response to a proposal
RSTP(1): transmitting a proposal on Et0/1
RSTP(1): received an agreement on Et0/1

SW2 initializes all ports as designated and starts sending out proposals. It
then receives a better BPDU from SW1 so it has to sync its downstream ports (Et0/1).

SW3

%LINK-3-UPDOWN: Interface Ethernet0/0, changed state to up
%LINK-3-UPDOWN: Interface Ethernet0/1, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/0, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/1, changed state to up
setting bridge id (which=3) prio 32769 prio cfg 32768 sysid 1 (on) id 8001.aabb.cc00.0300
RSTP(1): initializing port Et0/0
RSTP(1): Et0/0 is now designated
RSTP(1): initializing port Et0/1
RSTP(1): Et0/1 is now designated
RSTP(1): transmitting a proposal on Et0/0
RSTP(1): transmitting a proposal on Et0/1
RSTP(1): updt roles, received superior bpdu on Et0/0 
RSTP(1): Et0/0 is now root port
RSTP(1): syncing port Et0/1
RSTP(1): synced Et0/0
STP[1]: Generating TC trap for port Ethernet0/0
RSTP(1): transmitting an agreement on Et0/0 as a response to a proposal
RSTP(1): transmitting a proposal on Et0/1
RSTP(1): transmitting a proposal on Et0/1
RSTP(1): received an agreement on Et0/1
STP[1]: Generating TC trap for port Ethernet0/1
RSTP(1): updt roles, received superior bpdu on Et0/0 
RSTP(1): syncing port Et0/1
RSTP(1): synced Et0/0
RSTP(1): transmitting an agreement on Et0/0 as a response to a proposal
RSTP(1): transmitting a proposal on Et0/1
RSTP(1): received an agreement on Et0/1

SW3 goes through the same process. Claims root at first, then hears a better BPDU
and must sync its downstream port.

SW4

%LINK-3-UPDOWN: Interface Ethernet0/0, changed state to up
setting bridge id (which=3) prio 32769 prio cfg 32768 sysid 1 (on) id 8001.aabb.cc00.0400
RSTP(1): initializing port Et0/0
RSTP(1): Et0/0 is now designated
%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/0, changed state to up
RSTP(1): transmitting a proposal on Et0/0
RSTP(1): updt roles, received superior bpdu on Et0/0 
RSTP(1): Et0/0 is now root port
RSTP(1): synced Et0/0
STP[1]: Generating TC trap for port Ethernet0/0
RSTP(1): transmitting an agreement on Et0/0 as a response to a proposal
RSTP(1): updt roles, received superior bpdu on Et0/0 
RSTP(1): synced Et0/0
RSTP(1): transmitting an agreement on Et0/0 as a response to a proposal

SW4 also claims root, hears a better BPDU. It has not downstream ports to
synchronize so the process ends there.

To visualize the process this is what happens at time 0.

RSTP-synch-2

This can be seen in the BPDUs as well. This is the BPDU that SW1 sends out.

BPDU-SW1-1

The BPDU is a proposal and the designated bit is set. It’s not yet trying to learn or
forward on the port.

SW2 sends out the following BPDU.

BPDU-SW2-1

When SW1 has received agreement BPDU it can start forwarding on its designated port.
SW2 can forward on its root port as soon as it decides that it is root. When SW2
has learned better root information it must synchronize downstream ports so the port
to SW3 is still blocking.

RSTP-synch-3

This is the agreement BPDU that SW2 sends to SW1.

BPDU-SW2-2

The learning and forwarding bits are set and the role is root. The agreement
bit is also set as well as TC so that MAC address tables can be updated. The
TC bit is set for 2x the hello time and is called TcWhile.

The next segment to be synchronized is the one between SW2 and SW3.
At first SW3 claims to be root.

BPDU-SW3-1

Then SW2 sends out a better BPDU.

BPDU-SW2-3

SW2 sends a BPDU with TC set because for a brief period of time SW2 was believed to
be root before SW2 heard a better BPDU from SW1. Then SW3 sends agreement BPDU.

BPDU-SW3-2

After SW2 has received the agreement BPDU it can bring its downstream port (Et0/1)
to forwarding making the topology look like this.

RSTP-synch-4

Finally the segment between SW3 and SW4 is synchronized. SW3 sends out the BPDU
and then SW4 agrees to it. TC is set because for a brief period SW3 as believed
to be root.

BPDU-SW3-3

BPDU-SW4-1

The final topology is then that all links are forwarding because we have no physical
loop in this topology.

RSTP-synch-5

Receiving better root information

So far we had no physical loop in the topology. This is not a very realistic
scenario and to see how RSTP works when receiving better root information we
will add a link between SW1 and SW4 meaning that SW4 has a direct path to the
root like this.

RSTP-synch-6

Before we look at what happens when bringing up the port between SW1 and SW4
let us assign port roles to all the ports on the drawing. This is good practice
to understand how STP works and you should be able to do this manually if you
fully understand STP. We are expecting the topology to converge like this.

RSTP-synch-7

After SW4 receives better root information, which ports do we need to synchronize
to converge the topology? SW1 does not receive better information, it is the root.
SW4 has a designated port towards SW3 so it needs to synchronize that segment.
SW3 has no designated ports so we except the synchronization process to stop
there. Lets look at debugs and I’ll do a play by play with the drawings.

SW1

%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/1, changed state to up
RSTP(1): initializing port Et0/1
RSTP(1): Et0/1 is now designated
RSTP(1): transmitting a proposal on Et0/1
RSTP(1): transmitting a proposal on Et0/1
RSTP(1): received an agreement on Et0/1
STP[1]: Generating TC trap for port Ethernet0/1

SW1 initializes the port and waits for agreement BPDU from SW4 before it can
bring the port into forwarding.

SW4

%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/1, changed state to up
RSTP(1): initializing port Et0/1
RSTP(1): Et0/1 is now designated
RSTP(1): transmitting a proposal on Et0/1
RSTP(1): updt roles, received superior bpdu on Et0/1 
RSTP(1): Et0/1 is now root port
RSTP(1): Et0/0 blocked by re-root
RSTP(1): synced Et0/1
RSTP(1): Et0/0 is now designated
STP[1]: Generating TC trap for port Ethernet0/1
RSTP(1): transmitting an agreement on Et0/1 as a response to a proposal
RSTP(1): transmitting a proposal on Et0/0
RSTP(1): received an agreement on Et0/0
STP[1]: Generating TC trap for port Ethernet0/0

SW4 initializes the port but then receives a better BPDU. Et0/0 is then blocked by
reroot because Et0/1 is now the root port. Et0/0 must be synchronized because it
is now a designated (downstream) port. SW3 then sends an agreement. So looking at
the topology this is what has happened so far.

RSTP-synch-8

Then SW3 sends agreement so that SW4 can bring Et0/0 into forwarding.

RSTP-synch-9

So now the question is, what happens at SW3?

RSTP(1): updt roles, received superior bpdu on Et0/1
RSTP(1): Et0/1 is now alternate

SW3 did not receive any better root information and it has no designated ports.
This means that the synchronization process can stop. Making the final topology
look like this.

RSTP-synch-10

What happens when synchronization fails?

RSTP synchronization is dependant on that all links in the topology are
point to point. This is decided by if the link is running in full duplex or not.
It is possible to force a link to point to point but if you are running your
interfaces in half duplex STP is not your biggest problem!

In the case that the proposal and agreement process fails RSTP has to fall
back on relying on the old timers used in regular STP. There is a timer called
FdWhile which is the same as the forward delay, defaulting to 15s. After trying to
send proposals for 15s it will start to bring the port through discarding, learning
and then to forwarding. I simulated this scenario below by blocking BPDUs between
SW3 and SW4.

20:02:23.338: RSTP(1): Et0/1 is now root port
20:02:23.338: RSTP(1): Et0/0 blocked by re-root
20:02:23.338: RSTP(1): Et0/0 is now designated
20:02:23.338: STP[1]: Generating TC trap for port Ethernet0/1
20:02:23.339: RSTP(1): transmitting a proposal on Et0/0
20:02:23.509: RSTP(1): transmitting a proposal on Et0/0
20:02:25.509: RSTP(1): transmitting a proposal on Et0/0
20:02:27.509: RSTP(1): transmitting a proposal on Et0/0
20:02:29.517: RSTP(1): transmitting a proposal on Et0/0
20:02:31.517: RSTP(1): transmitting a proposal on Et0/0
20:02:33.517: RSTP(1): transmitting a proposal on Et0/0
20:02:35.517: RSTP(1): transmitting a proposal on Et0/0
20:02:37.521: RSTP(1): transmitting a proposal on Et0/0
20:02:38.338: RSTP(1): Et0/0 fdwhile Expired

Every 2 seconds it tries to send a proposal but gets no agreement back.
After 15 seconds the timer expires and RSTP has to go through the regular
phases instead of immediately bringing the port online.

Conclusion

RSTP is a rapid protocol that works by synchronizing the topology. This process
is often overlooked in books on switching and spanning tree. This post describes
in detail how the synchronization process actually works. RSTP is a distance vector
protocol since the cost is learned by listening to BPDUs from other switches. In
some cases this can lead to issues like counting to infinity. For detail on this
refer to INE STP convergence PDF by Petr Lapukhov.
RSTP converges fast as long as the synchronization process works. This process relies
on all links running in full duplex and all switches are running in the same STP mode.

Busting myths – Spanning tree portfast on the interface

August 4, 2013 6 comments

I would like to bust a common myth. One that I’m probably guilty of preaching
before as well. We all know that when portfast is enabled the port will bypass
the listening and learning phase of STP. Portfast can be enabled globally for
all access ports or be configured directly under the interface.

The myth is as follows. When enabling portfast globally the port will lose its
portfast status when receiving BPDUs and go through the regular STP phases
but if BPDUs are received on interface where portfast was enabled specifically
it will continue to use portfast and bridging loops may appear.

Part of the myth is also that portfast enabled ports do not send BPDUs.

So we start out by busting the second part of the myth. To do this I will
simply enable portfast on a port and we will see the number of BPDUs
incrementing.

SW1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
SW1(config)#int fa0/1
SW1(config-if)#span portfast
%Warning: portfast should only be enabled on ports connected to a single
 host. Connecting hubs, concentrators, switches, bridges, etc... to this
 interface  when portfast is enabled, can cause temporary bridging loops.
 Use with CAUTION

%Portfast has been configured on FastEthernet0/1 but will only
 have effect when the interface is in a non-trunking mode.
SW1(config-if)#^Z
SW1#sh span int fa0/1 portfast
VLAN0001            enabled

Portfast is definitely enabled. Are any BPDUs going out?

SW1#sh span int fa0/1 det | i BPDU
   BPDU: sent 43, received 0
SW1#sh span int fa0/1 det | i BPDU
   BPDU: sent 46, received 0

So clearly that was easy to bust. BPDUs are still sent on portfast enabled ports.
Anyone claiming STP is disabled and that portfast enabled ports don’t send BPDUs
is clearly wrong. All it does is to bypass the listening and learning phase.

So what happens when BPDUs are received? I will enable IRB on a router to
start sending BPDUs. I will set the priority to something better than the
switch so that the router side will become designated.

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#bridge irb
R1(config)#bridge 1 protocol ieee
R1(config)#bridge 1 priority 8192
R1(config)#int fa0/0
R1(config-if)#bridge-group 1

R1 is now running STP:

R1#sh span

 Bridge group 1 is executing the ieee compatible Spanning Tree protocol
  Bridge Identifier has priority 8192, address 000d.bc01.3400
  Configured hello time 2, max age 20, forward delay 15
  We are the root of the spanning tree
  Topology change flag set, detected flag set
  Number of topology changes 1 last change occurred 00:00:13 ago
          from FastEthernet0/0
  Times:  hold 1, topology change 35, notification 2
          hello 2, max age 20, forward delay 15 
  Timers: hello 0, topology change 24, notification 0, aging 15

 Port 4 (FastEthernet0/0) of Bridge group 1 is listening
   Port path cost 19, Port priority 128, Port Identifier 128.4.
   Designated root has priority 8192, address 000d.bc01.3400
   Designated bridge has priority 8192, address 000d.bc01.3400
   Designated port id is 128.4, designated path cost 0
   Timers: message age 0, forward delay 0, hold 0
   Number of transitions to forwarding state: 0
   BPDU: sent 3, received 3

So now we should be receiving BPDUs on SW1.

SW1#sh span int fa0/1 det | i BPDU
   BPDU: sent 221, received 41
SW1#sh span int fa0/1 det | i BPDU
   BPDU: sent 221, received 43

And we are. So what happened to portfast now that we are receiving BPDUs?

SW1#sh span int fa0/1 portfast
VLAN0001            disabled

It’s disabled! Myth busted! Even if portfast is enabled under the interface it
will still lose its portfast status if BPDUs are received. If we debug we
can see that the port did not have to go back through blocking -> listening
-> learning. It stayed in forwarding even though BPDUs were received.

STP CFG: found port cfg FastEthernet0/1 (2E9E1E0)
STP: VLAN0001 heard root  8192-000d.bc01.3400 on Fa0/1
    supersedes 32769-000c.3058.7c80
STP: VLAN0001 new root is 8192, 000d.bc01.3400 on port Fa0/1, cost 19
STP: VLAN0001 Fa0/16 -> listening
STP: VLAN0001 Fa0/17 -> listening
STP: VLAN0001 Fa0/18 -> listening

So bridging loops can form because the listening and learning phase is bypassed
if we enable portfast on Inter Switch Links. They would only be temporary though
because as I showed the ports would lose their portfast status when BPDUs are
received.

Assume that we have a topology like this:

Portfast

Portfast has been enabled on all Inter Switch Links. Which ports keep their portfast
status and which would not? Give me suggestions in the comments section.

I have been awarded the Cisco Learning Network Technical Excellence Award

August 3, 2013 16 comments

Hi guys,

Just a quick one. I’ve been awarded the Cisco Learning Network Technical Excellence Award
for my contributions over there. It’s a great forum so you should check it out. Right now
there are some webinars by members being done. My STP webinars are up as I posted about
earlier. You can read my story at CLN here.

I’m proud to have been awarded this and hope I can keep contributing to the community.
I have some more posts on STP coming up as soon as I can write them.

STP session up @ CLN

August 1, 2013 4 comments

Hi,

I’m done with the two Spanning Tree Protocol webinars at the Cisco Learning Network.
You can find them here. They are located under the Routing&Switching section.

Now on to CCDE studies!