07-11-2012 05:36 AM - edited 03-07-2019 07:43 AM
Hi Folks,
I have a pair of 3560's configured with dot1q trunks between them carrying a number of VLANs.
Once deployed there will be a requirement for these physical trunks to be disconnected from time to time. Knowing that this is inevitable I am trying to minimise the period of time for the trunks to recover once the physical connectivity is reinstated.
All of the VLANs on the switches are configured for Spanning Tree Rapid PVST.
Current time for the trunks/VLANs to come up is around the 4 second mark.
Is this as quick as I can expect it to be?
Cheers,
Paul
07-11-2012 06:49 AM
Probably. There's an option to enable portfast on a trunk port though. You need to be careful with this option, but it's there:
spanning-tree portfast trunk
The problem with this command is that you really don't want to use it on uplinks between switches.
HTH,
John
07-11-2012 07:37 AM
Thanks John.
It is my understanding that "spanning tree portfast trunk" shouldn't really be used on trunks between switches as I think it effectively disables spanning tree on the trunk?
Cheers,
Paul
07-11-2012 07:48 AM
I would not recommend using Portfast for switch -switch interconnectivity. typically we configure portfast only on Edge ports. since this is not an edge port i would just configure "switchmode mode trunk" on both the links connnecting those two switches.
Since you are using Rapid PVST, the convergence should happen faster. I'm not sure if you can further improve upon.
Will let the experts to comment more on this.
-Vijay
07-11-2012 07:49 AM
Paul and John,
I am somewhat surprised about the 4 second delay with this trunk. To me, it seems inappropriately long.
Running RPVST is a must, and this RPVST should take care of putting the trunk into forwarding state rapidly. Therefore, I strongly oppose against using spanning-tree portfast trunk on this trunk - let RPVST handle it, and RPVST should be able to react well under 1s time.
A couple of recommendations:
Best regards,
Peter
07-11-2012 08:03 AM
Peter,
All good solutions Correct me if I'm wrong, but I think the only time you would use the spanning-tree portfast trunk command would be when connecting to devices such as phones that would also have a workstation connected to it. In that scenario, you would need a trunk for the voice and data traffic. (Sorry, I don't have many Cisco switches and can't use voice vlan on some of the older models.) In this case, the switchport portfast trunk would be appropriate, but never to interconnect switches.
John
07-11-2012 08:25 AM
Hi John,
Correct me if I'm wrong, but I think the only time you would use the spanning-tree portfast trunk command would be when connecting to devices such as phones that would also have a workstation connected to it. In that scenario, you would need a trunk for the voice and data traffic.
Absolutely correct. And also think about a trunk port connecting to a router-on-stick, or to a computer running several virtual machines, each communicating on a separate VLAN. In all these cases, an end device that does not perform traditional L2 switching is connected to the switch - only in these cases, the device is capable of communicating using multiple VLANs at once. In these situations, using the spanning-tree portfast trunk is appropriate. However, this command should indeed never be put onto inter-switch links - it could lead to switching loops, and also, as soon as a PortFast-enabled port receives a BPDU, the PortFast is deactivated until the port is disconnected and connected again.
Regarding the IP phones, there were two ways of configuring a switchport that connects an IP phone. One of them was to configure this port as trunk with two allowed VLANs - the one being the voice VLAN, the other - also used as a native VLAN - was the data VLAN used by the PC. Another way that is also preferred today is to configure the port as an access port in the data VLAN, and add the voice VLAN using the switchport voice vlan command.
Best regards,
Peter
07-11-2012 08:14 AM
Hello Paul,
to speed up convergence a useful command to be used on both ends is:
switchport nonegotiate
that disables the use of DTP and avoids DTP negotation. This should save some time . If you haven't it already in place it can help to reduce that time further,
All the suggestions by Peter are valid ones if the links are not fiber based using cross-over cables is appropriate, but cross-over cables for GE speeds need to cross all 4 pairs of wires as they are all used.
Using spanning-tree portfast is not recommended
Hope to help
Giuseppe
07-11-2012 08:34 AM
Hello Giuseppe,
to speed up convergence a useful command to be used on both ends is:
switchport nonegotiate
I have recommended that myself but there is a thing I am not entirely sure of - perhaps you know more here: when the port is already configured statically as trunk using the switchport mode trunk command, does the deactivation of DTP bring any additional time saving?
cross-over cables for GE speeds need to cross all 4 pairs of wires as they are all used.
Exactly. That's what I meant by calling them proper crossover cables But thanks for pointing that out!
Best regards,
Peter
07-11-2012 08:48 AM
Hello Peter,
I had missed that you had already suggested the command!
According to recommendations from other colleagues like Jon Marshall, even if we use switchport mode trunk the DTP negotiation takes place just to state that "we are trunk in our side and you are trunk in your side". This DTP conversation requires up to few seconds so disabling it should minimize trunk recovery time.
Hope to help
Giuseppe
07-12-2012 06:01 AM
Hi Folks,
Many thanks for all of the replies.
I've tried various combinations of the suggested settings in a test environment with trunk connectivity between a 3560 and a 4948. Spanning tree mode RSTP (verified type as P2P).
The test involved physically disconnecting the trunk interface, wait a couple of minutes and then reconnect.
Results when trunk on both the 4948 and 3560 is configured as below:
interface GigabitEthernet1/37
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 900
switchport mode trunk
logging event link-status
end
~2 sec uptime delay from the initial message of physical interface logged as being up (verified a few times):
SW1#
Jul 12 11:03:29.291: %LINK-3-UPDOWN: Interface GigabitEthernet1/37, changed state to up
Jul 12 11:03:30.295: setting bridge id (which=3) prio 33668 prio cfg 32768 sysid 900 (on) id 8384.001e.7abc.a1c0
Jul 12 11:03:30.295: RSTP(900): initializing port Gi1/37
Jul 12 11:03:30.295: RSTP(900): Gi1/37 is now designated
Jul 12 11:03:30.311: RSTP(900): transmitting a proposal on Gi1/37
Jul 12 11:03:30.323: RSTP(900): received an agreement on Gi1/37
Jul 12 11:03:31.295: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/37, changed state to up
SW1#
I then configured the trunk ports on both the 3560 and 4948 to nonegotiate:
interface GigabitEthernet1/37
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 900
switchport mode trunk
switchport nonegotiate
logging event link-status
end
Strangely enough this seemed to add a second, now taking ~3 secs to come up (verified a few times):
SW1#
Jul 12 11:08:19.291: setting bridge id (which=3) prio 33668 prio cfg 32768 sysid 900 (on) id 8384.001e.7abc.a1c0
Jul 12 11:08:19.291: RSTP(900): initializing port Gi1/37
Jul 12 11:08:19.291: RSTP(900): Gi1/37 is now designated
Jul 12 11:08:19.307: RSTP(900): transmitting a proposal on Gi1/37
Jul 12 11:08:19.319: RSTP(900): received an agreement on Gi1/37
Jul 12 11:08:21.287: %LINK-3-UPDOWN: Interface GigabitEthernet1/37, changed state to up
Jul 12 11:08:22.287: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/37, changed state to up
I then hardset speed and duplex (removed nonegotiate):
interface GigabitEthernet1/37
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 900
switchport mode trunk
logging event link-status
speed 1000
duplex full
end
Back to 2 seconds:
Jul 12 11:58:06.216: %LINK-3-UPDOWN: Interface GigabitEthernet1/37, changed state to up
Jul 12 11:58:07.220: setting bridge id (which=3) prio 33668 prio cfg 32768 sysid 900 (on) id 8384.001e.7abc.a1c0
Jul 12 11:58:07.220: RSTP(900): initializing port Gi1/37
Jul 12 11:58:07.220: RSTP(900): Gi1/37 is now designated
Jul 12 11:58:07.236: RSTP(900): transmitting a proposal on Gi1/37
Jul 12 11:58:07.248: RSTP(900): received an agreement on Gi1/37
Jul 12 11:58:08.220: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/37, changed state to up
I also tried this with hardset duplex/speed settings - resulting in a delay of 3 secs.
Then tried with carrier-delay at 100 msec:
interface GigabitEthernet1/37
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 900
switchport mode trunk
logging event link-status
carrier-delay msec 100
speed 1000
duplex full
end
Seemed to adversely affect the recovery time, pushing it out to ~4 secs:
Jul 12 12:11:15.296: %LINK-3-UPDOWN: Interface GigabitEthernet1/37, changed state to up
Jul 12 12:11:18.200: setting bridge id (which=3) prio 33668 prio cfg 32768 sysid 900 (on) id 8384.001e.7abc.a1c0
Jul 12 12:11:18.200: RSTP(900): initializing port Gi1/37
Jul 12 12:11:18.200: RSTP(900): Gi1/37 is now designated
Jul 12 12:11:18.216: RSTP(900): transmitting a proposal on Gi1/37
Jul 12 12:11:18.228: RSTP(900): received an agreement on Gi1/37
Jul 12 12:11:19.200: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/37, changed state to up
Interesting ....
Cheers,
Paul
07-13-2012 12:55 AM
Hi Paul,
Hmmm... this is puzzling indeed. My personal feeling about this is, though, that we should not rely on timestamps of the logging messages of the %LINK-3-UPDOWN and %LINEPROTO-5-UPDOWN to measure the true delay in bringing the link up. These logging messages may be delayed with respect to the event they describe, and their timestamps may thus be skewed.
I am thinking of measuring the delay using some sort of generated traffic. The biggest problem I am having now is correlating the moment of inserting the cable into the switchport with the flow of data so that we can know what is the exact moment since which to start measuring the delay. I will think of something and will update you here.
Best regards,
Peter
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide