STP and sharing Vlans with client infrastructure

[patramirezort]

I have a question regarding STP Vlan Root.

I work in a Call Center (CC), this organization uses Cisco SWs to manage their L2 infrastructure; some clients use a hybrid topology (uses Call Center L2 SW to connect end users but made a connection to their L3 SW and FW to reach their network services).

The CC uses as Admin the Vlan 10, with STP Root Bridge was placed as default (the lowest SW Mac Add  management).

By doing some Root Bridge traceroute, I found that Vlan 10 reaches another Sw from the company:

Example:

Switch_Core#sh spanning-tree root

!

Vlan                   Root           ID                   Cost    Time  Age Dly  Root Port

VLAN0010         32768 0026.995a.fb00        42    2   20  15  Gi0/48

!

!

Switch_Dist#sh spanning-tree root | i VLAN0010

VLAN0010         32768       0026.995a.fb00        38    2   20  15  Gi0/8

!

This Vlan root bridge as next step Switch reaches a client Switch (which is unable to access) with a Cost of 38.

My question is if this CC may be exposed to any attack since Admin Vlan Root Bridge (Vlan 10) is under another Switch topology?

I do not create this topology but found these configurations mistakes and Spanning Tree redesign for the Root Bridge rearrangement to provide the highest value for the switch core and upgrade to RSTP that I proposed was approved just recently. But wonder what consequences will produce that Admin Vlan has been exposed for so long.

Please don't rate my question as a SPAM (yesterday I posted this question and someone marked as a SPAM), it took me months to understand how STP works as CCNA level but book does not provide explanation about sharing Root Vlans and STP with other clients topologies. If Cisco believes I am broking some rule kindly please tell me.

Beyond that a STP change managemente was approved, I want to understand better what consequences might have that client's topology have this Admin Vlan Root (Call Center servers are running on this vlan).

Thank you.

[Giuseppe Larosa]

Hello @patramirezort ,

on switch under your control the one that should be the Root Bridge you can use

( I am assuming here you are using PVST or Rapid PVST you can check this with show spannig-tree summary)

conf t

spanning-tree vlan 10 priority 0

Wanring: this will cause an STP recalculation in VLAN 10 but it will make your switch the Root Bridge as it should be.

Do it out of business hours but it will take a minute

Eventually on a second switch under your control that you would like to be the backup of the primary root bridge you can use:

conf t

spanning-tree vlan 10 priority 4096

Hope to help

Giuseppe

[patramirezort]

Hi, well my question goes with the possible consequences of a third party (client infrastructure) is been owned the Call Center Admin Root Vlan for so long and to know if Call Center has been exposed to some kind of attack since Call Center VTP domain has no password enable.

A STP change management was approved (but with pending date to implement) to modify the Root bridge and provide the Switch core the Vlan Root Bridge management as should be.

Thank you

[patramirezort]

Kindly please someone mentioned what are the possible consequences of a third party (client infrastructure) been owned the Call Center Admin Root Vlan for so long and to know if Call Center has been exposed to some kind of attack since Call Center VTP domain has no password enable.

A STP change management was approved already to reorganize the Root Bridge management to reroute to Core Switch (with the upgrade to RSTP), but meantime I am interesting to know if the Call Center network has been exposed to some sort of attack.

Thank you.

[Peter Paluch · Accepted solution]

Hello,

As for the VTP domain without password, VTP and STP are independent. Your VTP could have been attacked regardless of who the root switch is. This being said, I think that if someone attempted to do something bad to your VTP, you would have noticed already because an attack on VTP would result into new VLANs being created or existing VLANs being deleted. Such changes are relatively easy to spot.

As for the root switch being located in a 3rd party network, well... The placement of the root switch has no impact on the reachability of end hosts or the switches themselves. Regardless of who the root switch is in a network, the resulting loop-free topology still contains all switches and all end hosts attached to the network, and provides connectivity between any pair of devices. From this point of view, just by having the root switch located in a 3rd party network, an attacker would not have gained any additional access to devices on top of what was already available. However, based on how the resulting loop-free topology looks like, and what are the traffic patterns in the network, an attacker could have gained access to traffic flows he would not have had access before - that is because for some pair of devices, their traffic flow may need to go through the 3rd party root switch which would not happen if the root switch was someone else. However, if such eavesdropping happened, it would be almost impossible to prove.

Best regards,
Peter

[patramirezort]

Thank you for your feedback.

[Giuseppe Larosa]

Hello @patramirezort ,

usind a password for protection of VTP domain if using VTP version 2 is something I would suggest and that can be added.

The change for adding a password will require a maintenance window but there is no real impact during the deployment

At the end you can check that all switches are again in the same VP domain but with a hash ( 16 bytes if I correctly remember ).

On the long term moving to VTP version 3 is the best choice for security as it eliminates the issue of the rogue switch with a greater revision number that can change the VTP database.

Of coiurse before moving to VTP version 3 you should check using

show vtp status

that all of your switches support VTP version 3.

This would be a greater change but it is a wise move on the long term.

Hope to help

Giuseppe

[Peter Paluch]

Giuseppe,

I also agree that if @patramirezort is actively using VTP in his network, it would be best to protect it with a password. At the same time, knowing VTP deficiencies, I personally recommend considering migating away from VTP altogether. If the network size is small (only a handful of switches), and if the VLANs are added or removed infrequently, running VTP there brings little to no advantage. In such case, it would be safer to just disable VTP altogether (or at least move it to transparent mode).

As for the need of a maintenance window to configure a VTP password, I respectfully disagree there. Configuring VTP password is a non-disruptive operation. A VTP password mismatch means that a change to the VLAN database will not be accepted by the switch with a different VTP password, but the existing VLANs won't disappear - they will stay in place. The only real risk is with VTP Pruning. If VTP Pruning is on, a password mismatch could potentially result into blackholing of the broadcast / unknown unicast / multicast (BUM) traffic.

Best regards,
Peter

[Giuseppe Larosa]

Hello Peter,

>> As for the need of a maintenance window to configure a VTP password, I respectfully disagree there

Yes, from a technical point of view there should be no impact in deploying a VTP password .

I expressed my thoughts in a wrong way I should have written: 

"The change for adding a password would not require a maintenance window because there is no real impact during the deployment. However, depending on how change management happens in your company ( ITIL policies for example)  you ( = the original poster) may feel more comfortble to ask for one."

Regarding moving to VTP transparent mode is a possible advice and it can be a good move if the network is small with stable set of VLANs or even in a big environment with the need to create and delete VLANs if network automation is used by IT stuff.

We don't know how many switches are under the admin control of the original poster. We can assume that the set of Vlans is stable being a contact center serving multiple customers we can think that new VLANs are added for new customers.

However, it is difficult to say more.

Hope to help

Giuseppe

[Joseph W. Doherty]

I just wanted to add, some years ago, ran into a production issue with VTP pruning.  Had part of a production network where a VLAN would work for a few minutes, and then stop working.  I did find the issue, and resolved it.

Don't recall the full particulars, but it was due to VTP and pruning.  Cisco was working fine, i.e. wasn't a bug, but it was somehow related to various timers of how long it would take VTP to actually prune vs. VLAN information.  I think (?) it has something to due with a switch, being transversed, that wasn't running VTP (as a client [or server]).

Personally, I like VTP, but have seen a whole production network's VLANs dropped by the classical (and careless) adding a prior lab switch to the production network.  (BTW, at least for that one, it wasn't me.)

VTP, to me, is like "matches".  Can be very useful, but if you're careless, you'll get burned.

I haven't used it, but my reading of VTPv3, addresses most, if not all, of the "classical" "accidents" that can happen with earlier VTP versions.

Oh, I don't recall for sure, but VTP v1 or v2, passwords might be passed at clear text.  I.e. if so, not a super strong security option, but I also recommend using it, as it was another "safeguard" to help insure safe VTP operation (along with defining an actual VTP domain).  Configure both to help preclude "accidents".

[Giuseppe Larosa]

Hello @Joseph W. Doherty ,

I tested in a lab the possible accident of adding a switch with an higer revision number to avoid to rebuild the lab we just demonstrate it was able to update the VLAN DB by adding a new VLAN.

>> I don't recall for sure, but VTP v1 or v2, passwords might be passed at clear text.

My understanding is that the password is used to create an MD5 hash at least in VTP version 2.

Nowdays MD5 is considered breakable but at least passwords are not sent in clear text.

VTPv3 is really a great improvement and it can be combined with MST and using an additional database it can advertsie VLANS to MST instances mappings making life easier in case of a change.

In VTPv3 only the primary server can make changes to the VLAN database and this solves all the issues of older versions.

Hope to help

Giuseppe

[patramirezort]

Hi,

Thank you again for your best practices recommendations.

Regards,

Patricia

[patramirezort]

Good day Giuseppe, 

Thank you for your VTP best practices recommendations.

Patricia

[patramirezort]

Hi,

Thank you all for your VTP recommendations.