How to decide which port is root port.
1. root cost
2. neighbor bridge identifier
3. neighbor port identifier
4. local port identifier
Showing posts with label Switching. Show all posts
Showing posts with label Switching. Show all posts
Thursday, August 27, 2009
Tuesday, December 09, 2008
PVST+
Cisco switches run different types of STP protocol, depending on whether the connected port is access, ISL trunk or 802.1q trunk. Natively, a Cisco switch runs a separate STP instance for each configured and active VLAN (this is called Per-VLAN Spanning Tree or PVST) and standard IEEE compliant switches run just one instance of STP protocol shared by all VLANs. Due to that, a group of switches running IEEE compatible STP protocol is called MST (Mono Spanning Tree) region.
Access Ports. Cisco switches run classic version of IEEE STP protocol on the access ports. The IEEE STP BPDUs are sent to IEEE reserved multicast MAC address “0180.C200.0000” using IEEE 802.2 LLC SAP encapsulation with both SSAP and DSAP fields equal to “0×42”. (By the way, for the purpose of Layer2 filtering, IEEE BPDUs could be matched using a MAC ACL with LSAP value of ”0×4242”). Note that you can plug any standard IEEE compliant switch into a Cisco switch access port and they will interoperate perfectly, joining the respective access VLAN STP instance with the IEEE STP instance (MST).
ISL Trunks. Across ISL trunks, Cisco switches run PVST (Per-VLAN Spanning Tree). (Note that PVST feature is limited to ISL trunks only). The same IEEE STP BPDUs are sent for each VLAN, encapsulated in additional ISL header (which also carries the VLAN number). The magic part is that ISL header has special flag to distinguish frames carrying STP BPDUs and this is how PVST can re-use the regular IEEE BPDUs to simulate multiple spanning trees. Since PVST BPDUs have the same format as IEEE BPDUs (that is IEEE 802.2 LLC SAP) they can be matched using the same SSAP/DSAP values of “0×42” for the purpose of Layer 2 filtering.The group of Cisco switches connected using ISL trunks only is called PVST region.
802.1q Trunks. Across 802.1q trunks, Cisco switches run PVST+ (Per VLAN Spanning Tree Plus). Now this is where things are getting complicated. The goal of PVST+ is to interoperate with standard IEEE STP (MST) and allow transparent tunneling of PVST instance BPDUs across MST region (to potentially connect to other Cisco switches across the MST region). For further consideration, we call a group of Cisco switches connected using 802.1q trunks as PVST+ region. Note that PVST+ region may connect to a PVST region using an ISL trunk and connect to MST region using a 802.1q trunk. The STP instances in PVST and PVST+ regions maps directly to each other, so no special interoperability solution is required. However, on MST side only one STP instance exists, contrary to many STP instances of PVST+ region. The first question is: if we want to interoperate with MST, which PVST VLAN’s STP instance should be joined with MST? Cisco chooses VLAN 1 for this purpose. The joined together instances of Cisco VLAN 1 STP and MST are called “Common Spanning Tree” or CST (naturally, CST spans PVST, PVST+ and MST regions). As for the detailed PVST+ operations on 802.1q port, consider two following cases.
Lastly, for the purpose of layer 2 filtering, remember that you can match SSTP BPDUs using an ethertype value “0×010B”.This works with multilayer switches even though SSTP BPDUs are SNAP encapsulated, and the actual field is not “ethertype” but rather a SNAP Protocol ID.
mac access-list extended IEEE_STP&PVST&MIST
permit any any lsap 0x4242 0x0
mac access-list extended PVST+
permit any any 0x10B 0x0
Access Ports. Cisco switches run classic version of IEEE STP protocol on the access ports. The IEEE STP BPDUs are sent to IEEE reserved multicast MAC address “0180.C200.0000” using IEEE 802.2 LLC SAP encapsulation with both SSAP and DSAP fields equal to “0×42”. (By the way, for the purpose of Layer2 filtering, IEEE BPDUs could be matched using a MAC ACL with LSAP value of ”0×4242”). Note that you can plug any standard IEEE compliant switch into a Cisco switch access port and they will interoperate perfectly, joining the respective access VLAN STP instance with the IEEE STP instance (MST).
ISL Trunks. Across ISL trunks, Cisco switches run PVST (Per-VLAN Spanning Tree). (Note that PVST feature is limited to ISL trunks only). The same IEEE STP BPDUs are sent for each VLAN, encapsulated in additional ISL header (which also carries the VLAN number). The magic part is that ISL header has special flag to distinguish frames carrying STP BPDUs and this is how PVST can re-use the regular IEEE BPDUs to simulate multiple spanning trees. Since PVST BPDUs have the same format as IEEE BPDUs (that is IEEE 802.2 LLC SAP) they can be matched using the same SSAP/DSAP values of “0×42” for the purpose of Layer 2 filtering.The group of Cisco switches connected using ISL trunks only is called PVST region.
802.1q Trunks. Across 802.1q trunks, Cisco switches run PVST+ (Per VLAN Spanning Tree Plus). Now this is where things are getting complicated. The goal of PVST+ is to interoperate with standard IEEE STP (MST) and allow transparent tunneling of PVST instance BPDUs across MST region (to potentially connect to other Cisco switches across the MST region). For further consideration, we call a group of Cisco switches connected using 802.1q trunks as PVST+ region. Note that PVST+ region may connect to a PVST region using an ISL trunk and connect to MST region using a 802.1q trunk. The STP instances in PVST and PVST+ regions maps directly to each other, so no special interoperability solution is required. However, on MST side only one STP instance exists, contrary to many STP instances of PVST+ region. The first question is: if we want to interoperate with MST, which PVST VLAN’s STP instance should be joined with MST? Cisco chooses VLAN 1 for this purpose. The joined together instances of Cisco VLAN 1 STP and MST are called “Common Spanning Tree” or CST (naturally, CST spans PVST, PVST+ and MST regions). As for the detailed PVST+ operations on 802.1q port, consider two following cases.
Lastly, for the purpose of layer 2 filtering, remember that you can match SSTP BPDUs using an ethertype value “0×010B”.This works with multilayer switches even though SSTP BPDUs are SNAP encapsulated, and the actual field is not “ethertype” but rather a SNAP Protocol ID.
mac access-list extended IEEE_STP&PVST&MIST
permit any any lsap 0x4242 0x0
mac access-list extended PVST+
permit any any 0x10B 0x0
VLAN ACL
1. Tips
ARP are not IP packet, so you must be enabled it using mac ACL.
STP/PVST, PVST+ are something need to be enable too.
2. IP ACL
The CAT 3550 and 3560 switches process IP Packets in a different way than the non-IP Packets. So it is Mandatory to use IP access-list.
We cannot use a MAC access-list to allow IP Packets.
3. Sample
So, we have two different requirements there...
Forward all "non-IP" frames sourced from those two specific MAC Addresses; That requires a MAC Access-List.
Permit only ICMP, denying everyting else. That requires an IP Access-List (the one we´re all used to).
Ok, so let´s create our MAC Access-List:
mac access-list extended Allow Those
permit 000b.dc24.ca47 any
permit 000b.dc25.cb51 any
That will handle the first requirement.
Now the second one IP Access-List allowing ICMP and denying everything else:
access-list 101 permit icmp any any
Ok! Now, we need to create the VACL (or VLAN Maps, which one you prefer to call it) applying those rules:
vlan access-map Filter-VL7 10
action forward
match mac address AllowThose
!
vlan access-map Filter-VL7 20
action forward
match ip address 101
!
vlan access-map Filter-VL7 30
action drop
Now it looks ok, right?! Time to apply it to VLAN7 ?! What do you think about?! Let´s try?!
vlan filter Filter-VL7 vlan-list 7
Now testing! See if you can ping! Not working?! Hmmm... interesting... but why?! Well... I told... The MAC Access-List would bring all the interesting issues to the table! And, in fact, it did! It´s allowing only those two MAC Address and nothing else! How about ARP?! Do we need it to make things work?! Of course we do! And that´s where we have most confusion! Just keep in mind, the end of an Access-List is always deny any any! So if there are no matching instances for ARP in the MAC Access-List, it´ll be dropped!
How to fix it?! Simple, allow it in the MAC Access-List:
permit any any 0x0806 0x0000 permit any any lsap 0xAAAA 0x0000
But wait a minute! What´s that 0x0806 and lsap 0xAAAA ?! That´s the Ethertypes we´re allowing in our MAC Access-List, first one (0x806) is ARP, and the second one (lsap 0xAAAA) is PVST+. You do not want your switch running unprotected from loops right?! So it´s better to allow it!
For the sake of simplicity, the full configuration would be this one:
mac access-list extended AllowThose
permit 000b.dc24.ca47 any
permit 000b.dc25.cb51 any
permit any any 0x0806 0x0000
permit any any lsap 0xAAAA 0x0000 (This is copy from Link. This matches all the snap packet. To be more specifical, use permit any any 0x010b 0x0000).
!
access-list 101 permit icmp any any
!
vlan access-map Filter-VL7 10
action forward
match mac address AllowThose
!
vlan access-map Filter-VL7 20
action forward
match ip address 101
!
vlan access-map Filter-VL7 30
action drop
!
vlan filter Filter-VL7 vlan-list 7
The most common Ethertypes are: (and probably the ones asked in the LAB)
0x0806 = ARP
0x0800 = IP
0x010b = PVST+ (actually is inside the snap packet, lsap 0xAAAA)
0x4242 = STP and PVST
0x86DD = IPv6
Again... we need to understand all the little pieces involved in a particular task, and remember about the basics, OSI Model, ARP, and so on! It´s not difficult, but it´s a little confusing at the first time! Just go ahead, drink some watter (I did it several times) come back again, read over, and try some scenarios yourself, don´t have equipment?! Try it on Notepad, just try some, compare with the example, and you´ll see how easy it can be! The best way to learn is trying it yourself! ;)
You can also find a nice explanation about that in the wonderful Arden Packeer´s Blog, just click here and it´ll direct you to the post.
ARP are not IP packet, so you must be enabled it using mac ACL.
STP/PVST, PVST+ are something need to be enable too.
2. IP ACL
The CAT 3550 and 3560 switches process IP Packets in a different way than the non-IP Packets. So it is Mandatory to use IP access-list.
We cannot use a MAC access-list to allow IP Packets.
3. Sample
So, we have two different requirements there...
Forward all "non-IP" frames sourced from those two specific MAC Addresses; That requires a MAC Access-List.
Permit only ICMP, denying everyting else. That requires an IP Access-List (the one we´re all used to).
Ok, so let´s create our MAC Access-List:
mac access-list extended Allow Those
permit 000b.dc24.ca47 any
permit 000b.dc25.cb51 any
That will handle the first requirement.
Now the second one IP Access-List allowing ICMP and denying everything else:
access-list 101 permit icmp any any
Ok! Now, we need to create the VACL (or VLAN Maps, which one you prefer to call it) applying those rules:
vlan access-map Filter-VL7 10
action forward
match mac address AllowThose
!
vlan access-map Filter-VL7 20
action forward
match ip address 101
!
vlan access-map Filter-VL7 30
action drop
Now it looks ok, right?! Time to apply it to VLAN7 ?! What do you think about?! Let´s try?!
vlan filter Filter-VL7 vlan-list 7
Now testing! See if you can ping! Not working?! Hmmm... interesting... but why?! Well... I told... The MAC Access-List would bring all the interesting issues to the table! And, in fact, it did! It´s allowing only those two MAC Address and nothing else! How about ARP?! Do we need it to make things work?! Of course we do! And that´s where we have most confusion! Just keep in mind, the end of an Access-List is always deny any any! So if there are no matching instances for ARP in the MAC Access-List, it´ll be dropped!
How to fix it?! Simple, allow it in the MAC Access-List:
permit any any 0x0806 0x0000 permit any any lsap 0xAAAA 0x0000
But wait a minute! What´s that 0x0806 and lsap 0xAAAA ?! That´s the Ethertypes we´re allowing in our MAC Access-List, first one (0x806) is ARP, and the second one (lsap 0xAAAA) is PVST+. You do not want your switch running unprotected from loops right?! So it´s better to allow it!
For the sake of simplicity, the full configuration would be this one:
mac access-list extended AllowThose
permit 000b.dc24.ca47 any
permit 000b.dc25.cb51 any
permit any any 0x0806 0x0000
permit any any lsap 0xAAAA 0x0000 (This is copy from Link. This matches all the snap packet. To be more specifical, use permit any any 0x010b 0x0000).
!
access-list 101 permit icmp any any
!
vlan access-map Filter-VL7 10
action forward
match mac address AllowThose
!
vlan access-map Filter-VL7 20
action forward
match ip address 101
!
vlan access-map Filter-VL7 30
action drop
!
vlan filter Filter-VL7 vlan-list 7
The most common Ethertypes are: (and probably the ones asked in the LAB)
0x0806 = ARP
0x0800 = IP
0x010b = PVST+ (actually is inside the snap packet, lsap 0xAAAA)
0x4242 = STP and PVST
0x86DD = IPv6
Again... we need to understand all the little pieces involved in a particular task, and remember about the basics, OSI Model, ARP, and so on! It´s not difficult, but it´s a little confusing at the first time! Just go ahead, drink some watter (I did it several times) come back again, read over, and try some scenarios yourself, don´t have equipment?! Try it on Notepad, just try some, compare with the example, and you´ll see how easy it can be! The best way to learn is trying it yourself! ;)
You can also find a nice explanation about that in the wonderful Arden Packeer´s Blog, just click here and it´ll direct you to the post.
Subscribe to:
Posts (Atom)