MSTP Compatibility. Introduction. Topology. Autunm 2014

Transcription

1 MSTP Compatibility Autunm 2014 Topology Introduction As long as networks has been handled by hubs and switches according to the 802.1D standardization a magical protocol called Spanning-tree has been in effect to prevent bridging loops, they creates a lot of broadcast radiation which is bad. The creation of these bridging loops occur when a network architect wants to connect the networks L2 devices in a circle, use redundant links or even when internal threats wants to lower the performance of the network to a point when it does not operate properly[1]. However for this to work, all the devices in the network has to support STP, if one device does not do it, that device might be a threat to the network as of it will be able to replicate packets and create radiation on the network. The technologies of the networks that were in place in the early 90's, when the 802.1D were created and standardized, and the standards for what is quick on the network is not the same as now in the 2010's. The newer developments of the old STP protocol, like RSTP and MSTP or Cisco's PVST are 1 (7)

2 in fact backwards compatible with STP.[2] Tasks Another thing that might be interesting is to see how vulnerable the protocol is for the network. How the switch reacts to fake BPDU's from a regular client, what I can do with this, and if can prevent this from happening. The practical investigation will be done under this environment. Layer 3 and above configuration do not really matter much 5 switches where two will be 3560's, two 2960's and one 2950 or a 1712 if it has better support for the classic STP than the 2950 Redundant topology connection without redundant links. As explained the Layer 3 configuration has to be there for checking if the Layer 2 is working properly with the basic tools as Ping and later Yersinia, a tool that can attack Layer 2 Protocols as CDP, DTP, VTP and the most important one, STP. The switches is who are planned to run MSTP is SW1, SW2 and SW4, SW3 will run RSTP and SW5 will be using STP. This is for checking compatibility between the technologies and if it works properly, what is negative with the configuration. There is no plan for using redundant links between the switches because in this environment they will add deadweight as of only one of them will be active at one given time, and the focus is not about that in standard configuration the links who will become active are those with the lowest port number. 2 (7)

3 Tests Configuration SW1 - SW2 spanning-tree mode mst spanning-tree mst configuration name RegionZ revision 1 SW3 Spanning-tree mode rapid-psvt SW4 Is kept in default settings, running only PVST on the one default VLAN. During the second test the SW4 gets rapid-pvst activated. SW5 Is only connected during test 2. Tests The first test are done by connecting the network together and watching the output of the Show spanning-tree command. Packets are also captured from one client on the switches to get the BPDU's that the switch sends. The second test is done by using a timer to see how long time it takes for the interfaces to reach an operating FWD or blocked, discarding state in the STP topology when adding new links and when then later removes the link in FWD state. To view it I either watch the output of the Show spanning-tree command or watch the port led where applicable. The last test is done by flooding the switch SW1 with BPDU's from a malicious device (a regular client running the Layer2 attack tool Yersinia, and telling the MST region that it has root-bridge priority 0. Results The first were a success, as shown in the pictures below, MSTP detects that the BPDU's that it intercepts is not from a fellow MSTP-Switch, if it's from a switch running legacy 802.1D (STP) BPDU (version is set to 0), it sets the port to only it sets the port to only send 802.1D BPDU's on that interface, even when it stops to receive it will continue to send that kind of BPDU's on the interface. The results shown are edited to remove uninteresting data, data that just shows the default timers (hello 2, max age 20 and forward delay 15) times, bridge ID and that Switch 2 is the Root bridge for the instance MST0 and also the VLAN 1 and (7)

4 4 (7)

5 As shown on the previous page, The MSTP bridges detects that the interfaces that it receives a different BPDU with a different version and changes that port to operate in that level. As we also can see with the RSTP bridge (Rapid-PVST), it detects that the BPDU is different from the Po2 interface and dumbs it down to simple PVST for maximum compatibility. When all of the Vlans are in the same instance on the MST bridges there's no problems if (viewed from the PVST-bridges) all individual VLANs have the root-bridge on the same bridge. If the configuration is done so that different Switches are the Root-bridge for the different vlans, who are bundled in the MSTP configuration, the network will not operate properly. To make such a configuration we have to split apart that or those VLANs who differ and put them in a different MST Instance in the current region. The results for the second test were not so surprising, a network without Bridges using older STP will both converge faster and have the interfaces jump over to an active port-type thanks to the fact that not only the Root-bridge will send out BPDU's when interfaces goes down or being activated. The Results of this test were good. The time it took when STP were involved were about 30s, however when only having RSTP and MSTP it took less than seconds, the problem with this part were however that I got strange readings, sometimes it were quick and other times it took about seconds with RSTP-MSTP. However the part that were successfully operational were when I disconnected the forwarding cable and measured the time until the blocked/discarding port goes into a FWD state. When pulling a connection between a MSTP RSTP, MSTP MSTP or RSTP RSTP were instantaneous, I could not get the time to measure the downtime. However when pulling a cable connected from a MSTP to a STP or a RSTP to a STP bridge it took about 20 Seconds for the other port from resetting from a blocked state to a forwarding state. The last test were to use a Client equipped with the attacking tool Yersinia to infect the STP protocol and try to hinder this from happening. The first test were just sending out a BPDU from the client to the switch, as expected the client became the Root-bridge for the Spanning-tree. As before it does not mind if you have advanced MSTP configuration, if you dont disable the function that makes it compatible with STP. The first configuration you will think of that can hinder this from happening is to enable PortFast, as of that minimizes the time the port is in the Listening and learning state and immediately move into the forwarding state. However, one of the great features of this mode is that the port still functions as normal and when I sent the BPDU attack again, the port switched to the ROOT role and the client were once again the ROOT of the Spanning-tree. The correct way to protect your spanning-tree is to use the PortFast in combination with the BPDU- GUARD, if a BPDU enters the port it will immediately switch into an error-disabled state, where as the administrator has to enable the port again via the shutdown no shutdown commands after the malicious attacker or wrongfully connected switch are dealt with. Another solution for prevention of other switches becoming the Root-bridge is the Root-guard, If there's misconfiguration or intrusion on the hardware on some switch. When activated on for example the root-bridge on the ports where the next Backup-root is not supposed to be, it will see that the incoming BPDU's is claiming to be the Root-bridge and will never preempt over the role to that new switch, it will even shut down the port for you. 5 (7)

6 Reflection As of the work being a half success as of I have gotten the expected results, however I did not get any kind of reasonable performance numbers. And in retrospect, I can see have done an enormous mistake in that category. To get some more real-life numbers I could have used the ping tool in Ubuntu to send a ping every second or even faster if I wanted to see some real exact digits. However am I glad that the rest of the tests worked out as expected, and it feels like it was kinda a smart implementation on the RSTP and MSTP protocols to have that backwards compatibility, it makes older switches less obsolete even though they can make the entire network experience a bit slower. However, the security of this protocol is kinda lacking, then again you cant really make a network go down easy with just changing the Root-bridge, but you might just cripple it. 6 (7)

7 References [1] I. Pepelnjak, Connecting a switch to itself: does it hurt?, blog, 23 Feb. 2009; [2] D. Huckaby, "Rapid Per-VLAN Spanning Tree Protocol" in CCNP Switch : Official CertificationGuide,Indianapolis: Cisco Press, 2010, pp (7)