Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Trunk Port Recovery Time

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

11 REPLIES

Re: Trunk Port Recovery Time

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

HTH, John *** Please rate all useful posts ***
New Member

Trunk Port Recovery Time

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

New Member

Trunk Port Recovery Time

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

Cisco Employee

Re: Trunk Port Recovery Time

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:

  1. Be sure to configure the trunk statically using switchport trunk encapsulation dot1q and switchport mode trunk commands, and deactivate the DTP using switchport nonegotiate. Otherwise, the operating mode of the port will need to be determined using DTP, leading to a few seconds' delay.
  2. Make sure that the link between switches is recognized as point-to-point link by RPVST (in the show spanning-tree, it should say p2p in the very right column). If the link is identified as shared, you should inspect the duplex mode of the link.
  3. Some people recommend configuring the speed and duplex setting statically, thereby saving the time otherwise spent on autonegotiation. However, this configuration needs to be performed on both sides of the link and additionally requires using a proper crossover cable, as the auto-MDIX function is often deactivated if speed/duplex are set manually.
  4. Use a proper crossover cable anyway - this might save a few (tens of) milliseconds until the circuitry of the interface autosenses the need to cross a straight-through cable.
  5. Try using the carrier-delay msec 100 command to decrease the delay until the interface is accepted by IOS as being up (or down) to 100 milliseconds. I am, honestly, not sure though if this command is honored by switches - but trying it out should not do any harm.

Best regards,

Peter

Re: Trunk Port Recovery Time

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

HTH, John *** Please rate all useful posts ***
Cisco Employee

Re: Trunk Port Recovery Time

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

Hall of Fame Super Silver

Trunk Port Recovery Time

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

Cisco Employee

Re: Trunk Port Recovery Time

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

Hall of Fame Super Silver

Re: Trunk Port Recovery Time

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

New Member

Trunk Port Recovery Time

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

Cisco Employee

Re: Trunk Port Recovery Time

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

783
Views
5
Helpful
11
Replies
CreatePlease to create content