I have this small doubt, I have trunk port configured as below
switchport trunk encapsulation dot1q
switchport trunk native vlan 999
switchport trunk allowed vlan 1,199,542,999
switchport mode trunk
logging event link-status
My question is what will "spanning-tree portfast" do here , will that have any effect since the port is a trunk.
Yes ... it can have an effect. When spanning-tree portfast is applied to an interface the switch will view that interface to have one host and will make it an edge of the topology for each vlan. This can cause switching loops which is what SPT (RSPT) is there to prevent. A trunk port will indeed see multiple users at the other end and if there is another switch trunk to those users then the mac table for each vlan will see those addresses off different port but will not be able to block one of the ports.
Does that make sense?
My question is what will "spanning-tree portfast" do here , will that have any effect since the port is a trunk
R u connecting this Gig1/1 to another switch or a server.
IF connecting to another switch and this is the ONLY connection u have no problem (check your topology).
What i have seen if you define a port trunk it dont take time like access port. It directly goes to forwarding state.
If this port is going to some server etc then there is NO problem.
The topology is Switch X G1/1 to Switch Y G1/1 and G1/2 to Switch Z. Switch X and Z are interconnected. Swictch X is the root.
My question is will switch take any effect since i have already defined trunk first.
Take a look at the attached slide. If that is the topology you describe, then yes it will have adverse effects on your network. A switching loop will occur because all switches will see multiple paths to all mac-addresses. A broadcast storm can, and probably will occur ... which is the main reason you want to employ STP.
Did that help,
switch take any effect since i have already defined trunk first.
Since X is your root, one port of link between Y & Z will be in blocking state.
In my opinion there will be no effect of this portfast (though portfast is not required on trunk) and there will be no loop because of this.
Is there any specific reason u want to define portfast on trunk?
With spanning-tree portfast applied to one on the links between the switches, no port will be in a blocking state since it will see the portfast port as a single host connection. The result will be the CAM for each vlan on each switch having two paths to every mac-address ... which will result in a loop on all vlans applied on that trunk.
With spanning-tree portfast applied to one on the links between the switches, no port will be in a blocking state since it will see the portfast port as a single host connection
I connected 3 switch like X,Y,Z in this case, i have vlan 1,2,3,10,11 on all awitches.
1. When the links interconnecting switches are not trunk,
one port is in block state. Can see the amber light on the port.
Even after changing the port in portfast mode, that port is still in blocking mode.
2. When the links interconnecting switches are in trunk mode.
No port has amber light but that doesnot mean there is loop.
If you use sh spanning-tree int, find that the vlan 1,2,3,10,11 are in blocking state.
Eventhough port is not in blocking state due to trunk mode individual vlan is in blocking mode. These port are also portfast & trunk. No change.
IF you have 2-3 spare switches you can see urself.
If STP is not disabled then switch is making right decisions for us, even though we arenot following rules.
Possible in some cases where the IOS is old it works differently.
How many users did you have in your lab ... other than switches? Labs are great ... but if you do not have the users it can be hard to simulate how a network will react.
No body is encouraging him to go with portfast.
Switch X in the situation given is root and he is defining port fast on link between X & Y. X & Y link is not in blocking state (Link between Y & Z will be in blocking state).
How does it matter if a Vlan goes directly to forwarding state in a link which is not blocked?
Given only these 3 switches (situation will change if there are more switches), even if you connect Billion users to it, will something change?
STP is not going to work differently when created in Lab or in real network.
The link is not blocked. There is a seperate spanning tree for each vlan. While one vlan may be blocked from going through a port, another vlan may have the port in forward mode. The same port can be in a different mode for each vlan.
If portfast is applied on the X-Y trunk then that port will not be considered for STP since it is now handled as a host ... and not a switch. Ports with hosts on it will never be blocked and are not even considered part of the tree. They are dead ends. So from switch X's perspective, the only way to switch Z is through switch Y ... which means it will not place any port on any vlan in a blocking state.
So switch X will see switch Y through switch Z. But the CAM table will see all mac addresses from both ports on all three switches ... for each vlan. What is important to note about that is if a broadcast for a user is sent out the switches will begin forwarding that broadcast both ways and loops will occur.
The link is not blocked. There is a seperate spanning tree for each vlan.
While one vlan may be blocked from going through a port, another vlan may have the port in forward mode. The same port can be in a different mode for each vlan.
If root is same for all the vlans, one vlan will be blocked and other in forwarding state on the same link. Well i have not seen this, do you have example from real network as we can simulate anything in lab.
Can expect different state if for some vlan one switch is root and a different switch is root for other vlan.
"Well i have not seen this, do you have example from real network as we can simulate anything in lab."
Not all switches will have users on all vlans ... that could change the spanning tree for a vlan from the root switch. Also, it may not be best to have the root switch the same for all vlans ... depending on the topology.
"If portfast is applied on the X-Y trunk then that port will not be considered for STP"
that's not strictly true. STP will still run on this port. Portfast allows the port to bypass the listening/learning stages and go straight to forwarding but if there is a loop then the port can still be blocked even with portfast on it.
I do agree with you though that this is a very dangerous situation to be in because if the port can transition to forwarding immmediately then by the time the switch has worked out there is a loop then it is very often too late to do anything about it ie. your network has ceased to function.
So while a lot of things can be replicated in a lab this one is a little harder because you have to generate a lot of traffic.
Thanks for the information. I am a bit confused on that though because according to the BCMSN cert guide (I am not an expert, studying to be though :) ) it states that once the spanning-tree portfast command is applied to an interface that interface will be considered to have a host on it and will be moved to the edge of the topology. Maybe that is just a bad way of wording it on cisco's part in the book but it pretty much says that verbatim. If the interface is treated as a host that means it will never be able to be blocked. I deduce that to mean that a loop will exist and depending on the peak traffic times and typical network load can be very dangerous ... or may be transparent to the user traffic.
Does that make sense?
Have a look at this link and note the bit about portfast not turning off STP -
When you enable portfast on a port you usually get a warning message about the possibility of creating termporary loops and that is the key, it is a temporary loop. STP will still be operational on that port and it will realise there is a loop but as we have said that will very probably be way too late.
I think your books wording is just misleading or it could be read a number of ways. By configuring portfast, especially with RSTP, the device on the port is considered an edge device but that doesn't mean it is.
"I am not an expert, studying to be though :)"
From your previous posts you seem to be well on your way to what you want. The trick is never to consider you have got there because that's when you stop learning :-)
Thanks for the information. It is absolutely true though ... once you think you are really getting a handle on networking an incident happens in the network that makes you feel like a newby. But it sure is rewarding when you figure the problem out. It is a never ending journey of people that just started and those that have been at it a while.
I suppose that you are connected this port to a switch.
Please you can send the output of the command:
show interface gigabitethernet 1/1 switchport
Dependinding on wich type of switch and wich software, the "spanning-tree portfast" is not affecting trunkports. I'm not sure of from wich switchtypes or software but there are a command that should be used if you want portfast on trunks, and that is "spanning-tree portfast trunk".
You can try with a port that is configured as a trunk and also "spanning-tree portfast". When you activate the port (either via shut-no shut or by connect a cable to the port) and then watch the led and see if goes to green in a second, then the command "spanning-tree portfast" is used.
If the port takes approx. 50 seconds to go green then the command is not used fot trunks, and you have newer switch/software that needs "spanning-tree portfast trunk" command.
Here is a reply:
description UPLIKE TO CORE SWITCH
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1-729,731-4094
switchport mode trunk
Enter configuration commands, one per line. End with CNTL/Z.
TECH-SWITCH(config-if)#spanning-tree portfast ?
disable Disable portfast for this interface
trunk Enable portfast on the interface even in trunk mode
%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.
In case of the command spanning-tree portfast trunk it will not negociate, just going up directely.
The spanning-tree portfast will not take effect since this is a trunk port.
If for any reason you need to enable portfast in a trunk port you would need the command: "spanning-tree portfast trunk".