We need to connect 2 switches together and have 2 options for them:-
1. Use access port on both sides
2. Use trunk port on both sides
All interfaces in the new switch are in same VLAN and there is no requirement to configure multiple VLAN's on it.
Sw1 (Gi1/48) <--> Sw2 (Gi1/48) (new) (Merki switch with RSTP enabled)
As we know, if we are connecting Sw1 and the interface on Sw1 is access then we need to disable BPDU guard on the interface of Sw1 (on which we are connecting uplink of Sw2). I also have spanning tree port-fast enabled on in the interface on Sw1 and assume I have to remove that as well. Otherwise normal STP steps will be bypassed.
My question here is, is there any probability of loop in the network if we use this configuration or should we use trunk instead?
Sw1 port Gi1/48 configuration is as below:-
switchport access vlan yyy
switchport mode access
switchport voice vlan xxx
qos trust cos
qos trust device cisco-phone
shape percent 30
service-policy input QoS-TEMPLATE
service-policy output DBL
Sw2 port Gi1/48 configuration is as below:-
RSTP = Enabled
STP Guard = disable
Type = access
Vlan = yyy
You do not tell us what kind of switches these are. It might or might not be significant in finding the right answer.
You tell us that switch 2 is set for RSTP. You do not tell us about what spanning tree type is configured on switch 1. This might or might not be an issue.
You mention the possibility of an issue with BPDU guard. It does not show up in the configuration of the port on switch 1 but you have not told us whether this is set as one of the global defaults. This could certainly be an issue.
You seem to ask if configuring the connection as trunk would reduce the probability of loops in the network. I can not think of any way that whether the connection is access port or trunk will change any probability of loops in the network.
If switch 2 will have all of its interfaces in a single vlan and if there is no future requirement in switch 2 for multiple vlans then I see no reason to configure the connection as a trunk. Just configure it as an access port. Switch 1 has a voice vlan configured on the interface. If switch 2 really has all of its interfaces in a single vlan then there would be no need for voice vlan and I would suggest removing it from the interface on switch 1. Also the interface on switch 1 has multiple configuration statements to implement QOS for voice. I would suggest removing these statements on the interface of switch 1 since it would appear that you will not be supporting voice processing on switch 2.
Hi Rick - Thanks for your valuable response.
1. STP type that we are using on Sw1 is "pvst". See below:-
show spanning-tree summary
Switch is in rapid-pvst mode
Root bridge for: none
Extended system ID is enabled
Portfast Default is disabled
PortFast BPDU Guard Default is disabled
Portfast BPDU Filter Default is disabled
Loopguard Default is disabled
EtherChannel misconfig guard is enabled
UplinkFast is disabled
BackboneFast is disabled
Configured Pathcost method used is short
2. I have removed the BPDU guard and spanning-tree portfast from the port on Sw1. But it was there before and we are using BPDU guard and portfast on all interfaces on all access switches in our network.
3. yes, I have to remove all the voice vlan related configuration from Sw1.
I was just checking what would be the best practice to connect switches together in this scenario and make sure I am not missing anything. I think possibility of loop is only if somehow new switch Sw2 is will be connected to my "Core Switch" through any other access switch. Right now, Sw1 is connected to my "Core switch". What you think about it?
Appreciate you time to answer my silly question :)
Thanks for the additional information. To address your points here are my responses
1) based on this line of output I am assuming that the switches will not have an issue about spanning tree
Switch is in rapid-pvst mode
2) using BPDU guard and pordtfast on other ports is fine. Using BPDU guard on this port on switch 1 would be a problem. I am glad that you have removed it. Portfast would not necessarily be an issue but it is probably just as well that you have removed it.
3) I am glad that you have removed the voice vlan from the port on switch 1. Have you also removed the QOS configuration?
I believe that part of the Best Practice is to keep things as simple as possible in configuring switches. Configuring and operating an access port is more simple that a trunk port. So I would suggest that the Best Practice recommendation would be for the connection between these switches to be an access port and not a trunk.
Yes if some port on switch 2 was connected to the Core it might create a loop and that would be a problem. I thought that the question you were asking was about how to connect the switches. Whether it is an access port or is a trunk has no effect on whether a loop would exist. So the question of a possible loop is entirely separate from the question of how to connect the two switches.
Hi Rick - Thanks again for your response.
Yes, I removed that as well - it was old default configuration. Sorry for creating a confusion on the way I put the question :)
It is not a problem. I am glad that we have clarified things. I believe that you are on the correct path to configure this connection as an access port between the switches.
Can you please clarify more about "error-recovery policies" that you are talking about?
Post the complete output to the command "sh run | i errdisable recovery".
Hi Leo - what is the purpose of error recovery policies and why we
The only reason I'd configure error-recovery policy is in a lab environment.
I would not recommend enabling this in production environment unless one knows the consequences if enabled.
I have seen when UDLD auto-recovery was enabled. It was on a 6807 with Sup2T (so it's not an old machine).
The link went into error-disable due to UDLD. The link got auto-recovery and BGP advertisement came flooding into the chassis. A few minutes later, the link went down again due to UDLD.
So this entire thing happened several times in a span of about 15 minutes. The BGP advertisements giving the CPU the "hit" several times finally caught up and the chassis crashed spectacularly.
We were lucky the crash happened in the evening. Imagine what've happened if it occured during the business hours?