RSTP convergence may be cause of outage

This post will explain you one of the RSTP behavior, which may or may not be hamper your bridged networks during RSTP convergence.

In this topology previously only one ether channel po217 (2*1G) links were between Bridge A and Bridge B, now we are going to add a new link, ether channel po99 of (2*10G) links, now we will allow only one VLAN (307) on po99.

Find the below logs which we capture which we captured on Bridge A and B after allowing the VLAN.

Bridge A :

Feb 12 11:00:47 BridgeA 1404749: Feb 12 11:00:45 CET: %SPANTREE-SP-6-PORT_STATE: Port Po99 instance 307 moving from disabled to blocking

Feb 12 11:00:49 BridgeA 1404750: Feb 12 11:00:47 CET: %SPANTREE-SP-6-PORT_STATE: Port Po99 instance 307 moving from blocking to forwarding

Bridge B :

Feb 12 11:00:49 BridgeB 1308571: Feb 12 11:00:47 CET: %SPANTREE-SP-6-PORT_STATE: Port Po99 instance 307 moving from disabled to blocking

Feb 12 11:00:49 BridgeB 1308572: Feb 12 11:00:47 CET: %SPANTREE-SP-6-PORT_STATE: Port Gi3/6 instance 307 moving from forwarding to blocking

Feb 12 11:00:49 BridgeB 1308573: Feb 12 11:00:47 CET: %SPANTREE-SP-6-PORT_STATE: Port Gi4/7 instance 307 moving from forwarding to blocking

Feb 12 11:00:49 BridgeB 1308574: Feb 12 11:00:47 CET: %SPANTREE-SP-6-PORT_STATE: Port Gi4/10 instance 307 moving from forwarding to blocking

Feb 12 11:00:49 BridgeB 1308576: Feb 12 11:00:47 CET: %SPANTREE-SP-6-PORT_STATE: Port Po99 instance 307 moving from blocking to forwarding

Feb 12 11:01:04 BridgeB 1308578: Feb 12 11:01:02 CET: %SPANTREE-SP-6-PORT_STATE: Port Gi3/6 instance 307 moving from blocking to learning

Feb 12 11:01:04 BridgeB 1308579: Feb 12 11:01:02 CET: %SPANTREE-SP-6-PORT_STATE: Port Gi4/7 instance 307 moving from blocking to learning

Feb 12 11:01:04 BridgeB 1308580: Feb 12 11:01:02 CET: %SPANTREE-SP-6-PORT_STATE: Port Gi4/10 instance 307 moving from blocking to learning

Feb 12 11:01:19 BridgeB 1308583: Feb 12 11:01:17 CET: %SPANTREE-SP-6-PORT_STATE: Port Gi3/6 instance 307 moving from learning to forwarding

Feb 12 11:01:19 BridgeB 1308584: Feb 12 11:01:17 CET: %SPANTREE-SP-6-PORT_STATE: Port Gi4/7 instance 307 moving from learning to forwarding

Feb 12 11:01:19 BridgeB 1308585: Feb 12 11:01:17 CET: %SPANTREE-SP-6-PORT_STATE: Port Gi4/10 instance 307 moving from learning to forwarding

Note:-- All the highlighted logs belongs to Designated Non-edge ports,

Cause of blocking these ports:- RSTP convergence triggered by this TCN uses a process called SYNC (where all ports on a switch which are non-edge designated are sent to blocking first which was the case on Bridge B)

In this scenario nothing will be impacted because all ports which were gone to blocking states, they are connected to blocked ports to prevent the STP loop.

Note:- All access port (edge port) should be port fast enable to prevent the outage because TCN will not be generated for Edge ports and also the RSTP SYNC process doesn’t effect edge ports during convergence.

In below mention topology outage will be unavoidable.

In above mention diagram Bridge E is connected with bridge C only so, the port which is connecting these two, it would be designated non-edge port, so it will be blocked and all devices which is connected on bridge E will be affected.

Inputs are always welcome; please let me know if anything is there to prevent this outage.

Gre tunnel unable to Ping when cisco 7600 as a PE

Problem:- If you are using cisco 7600 as a PE router and configuring Vrf forwarding over GRE then you will be unable to ping CE side GRE tunnel ip from Remote PE.

Solution:-put a global command on Cisco 7600 PE "mls mpls tunnel-recir".

Cause:-Packet gets corrupted when it is received from CE back to PE, so conversion of IPv4 to MPLS doesn't happen.

IP precedence value over L2tpv3

To reflect ip precedence value over l2tpv3, you can use Ip tos reflect command under psuedowire configuration.

PE to CE eigrp flapping in mpls/vpn scenario

In this post i am explaining one case of Eigrp neighborship is flapping between PE to CE over L2tpv3 in MPLS VPN scenario, it could be the bug if you are using entservicesk9-mz.123-14.T5.bin IOS.

please find the attached scenario.

IP Dialing

Scenario :- in this scenario we are using LNS only (layer2 network server ) for both function authentication and IP assigning).
Here we are considering you have ip reachability of that IP which you are dialing please find below mention diagram for the same.














Required Configuartion for LNS
interface Loopback226
ip address 20.235.21.1 255.255.255.248 (according to this 6 IPs are valid)
(This loopback is created to map a interface with virtual-templete and pool has been created to specify the range of ip assigning. The subnet mask of loopback interface according to the pool)
vpdn enable
vpdn-group 1 (Creates VPDN group for the LNS)
! Default PPTP VPDN group (this command will come automatic)
accept-dialin (Creates an accept dial-in VPDN subgroup.)

protocol pptp--- (Specifies PPTP as the tunneling protocol).

virtual-template 5---- (Instructs the LNS to clone virtual access interfaces for VPDN sessions from virtual template 5).


interface Virtual-Template5 ( Creates virtual template 5, which is used to clone virtual access interfaces for incoming
VPDN sessions).

ip unnumbered Loopback226 (Specifies that the virtual access interfaces will use the IP address of loopback226)


peer default ip address pool TEST1 (Instructs the LNS to assign an IP address to VPDN sessions from the Test1
pool).
ppp authentication pap chap (Specifying ppp autentication method)
ip local pool TEST1 20.235.21.1 20.235.21.6
username cisco privilege 15 password 0 xxxx (Specifying the username & password for PC)