Link to home
Start Free TrialLog in
Avatar of jskfan
jskfanFlag for Cyprus

asked on

portchannel and trunks

I am going to try to explain it the way I saw it.
I have seen this in a video about configuring cisco switch for Cisco USC fabric Interconnect. the steps were:

1- they have configured 2 interfaces as trunk ports
2- they configured the trunk ports with portfast
3-they have configured the 2 interfaces that are trunk ports as etherchannel group 10 (po10)
4-then they configured the etherchanel port as a trunk with dot1q encapsulation.
5- they configured po10 with portfast


I wonder if step 2 is necessary, since portfast applies only to access ports ?
I wonder if step 4 is necessary, since po10 is based on the existing trunk that was already dot1q encapsulated
I wonder if step 5 is necessary ,since po10 does not need to be portfast.


Any clarifications will help.
Thanks
Avatar of rauenpc
rauenpc
Flag of United States of America image

All steps are necessary. Portfast under normal circumstances only applies to access ports, but when configured as portfast trunk it immediately forwards even in trunk mode. Many years ago there was never a need for such a thing but with VM servers everywhere we need to treat many trunks as if they were access ports.

Any command that must be synchronized in a port channel needs to be applied to both the physical interfaces and logical port channel. Logically it would make sense that the commands would just sync themselves, but in the real world you end up repeating all the config on the physical ports to the logical port channels to make sure they match up and join the portchannel successfully.

As to portfast on the portchannel, it is necessary because once the physical ports agree to be in the logical portchannel, it is now the portchannel that participates in spanning tree, and not the physical
Rauenpc is absolutely correct.

I just need to add that most configuration commands applied to an ether channel affects every member interface of that portchannell, but configuration commands applied to individual interfaces only affects that interface.

With that said, portfast could just have been applied to the etherchannel and the same results would be achieved (it gets applied to all member interfaces)
Avatar of jskfan

ASKER

If I understand a Trunk is configured between 2 switches, so if you apply portfast on the Trunk, would not this create an STP loop ? considering that Portfast will not give too much time to STP to do its calculation.
Etherchannels are mostly used as an uplink (eg from an access layer switch to a distribution layer switch OR from distribution switches to Core switches. You would still apply the caution with portfast as you would on regular access port.

Distribution switches and core switches are usually Layer 3 switches (Have mini routers built in). With proper configuration (eg with HSRP, VRRP or GLBP configurations, you can have an excellent redundant topology).

Don't just imagine that portfast causes loop. The purpose of portfast is to eliminate listening - learning - forwarding transition of the ports - loops may occur when wrongly-applied
Just to add in... Although the fabric interconnects are switches, they are more considered end devices just like a VMware server because the interconnects are rarely configured to need or use spanning tree.
Avatar of jskfan

ASKER

I still did not get the Portfast  part, that can be applied to Trunk ports.
When someone applies portfast to an access port , they will get a message that applying port fast to a port that is connectina switch to a hub or to another  switch can cause a loop.
User generated imageUser generated image
Portfast disables spanning tree.

The message is to warn you not to enable portfast on a port connected to other switches if you have redundancy set up because a loop will occur.

Spanning tree is only effective when you have redundancy - that is - multiple connections in case of failure.

In the diagram (Spanning Tree - Not Effective), there is no redundancy, meaning there is no alternate path between the switches.
Switch 1 can only get to switch 2 one way, and to switch 3 one way.
Switch 2 and 3 can only link up through Switch 1

So if the link between Switch 1 and 2 is broken, Switch 2 becomes completely isolated.

In the diagram (Spanning Tree - Effective), the Switches have alternate paths (but Spanning tree only makes one path available) to prevent loop.

If link between switch 1 and 2 breaks, the alternate path from 1 to 2 will be to go through 3.

If you now enable portfast on the switches, all the paths become available as no BPDUs are monitored, so traffic can go round the switches in an endless loop. No router is between these switches to decrement the time to live (ttl) and the switches will crash at some point.

To explain portfast in more simpler terms
Switches have to listen on the port for signal, then learn the signal (ie what port it's coming from and the mac address of devices attached etc) before transitioning into forwarding mode. If the switch sends out a BPDU probe from a port, it never expects to receive it back - if it does, it knows there is redundancy and will try to block the least prioritized port.

With portfast enabled, you are telling the switch not to learn anything but transition immediately to forwarding state to minimize down time as the learning phase could take an average of 20 seconds.
SOLUTION
Avatar of rauenpc
rauenpc
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of jskfan

ASKER

by: rauenpc

<< If it is in Switch Mode, then the access ports should be portfast but uplinks should run spanning-tree and NOT have portfast enabled >>

A Tunk is an Uplink, if I understand, so why can it be configured as Portfast ?
ASKER CERTIFIED SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of jskfan

ASKER

thank you guys!