| 0 comments ]

RADIUS Server: Network Policy configuration

In this example, the Microsoft NPS Server is used. Install the NPS Server role on a Windows system and define a RADIUS client for the switch (steps not included in article).
Open the Network Policy Server management console.
  • Next, define a new Access Policy:
20140315-cmw7-radius-rbac-002
  • Enter a descriptive name for the policy.
20140315-cmw7-radius-rbac-003
  • Next you need to set the matching conditions for this policy. This example will check on:
    • Windows group “net-admins”
    • Service-type “login”
20140315-cmw7-radius-rbac-004
  • First add the Windows group condition:
20140315-cmw7-radius-rbac-005

20140315-cmw7-radius-rbac-006
  • The test group “net-admins” is selected.
20140315-cmw7-radius-rbac-007
20140315-cmw7-radius-rbac-008
  • Next add the service-type condition:
20140315-cmw7-radius-rbac-009
20140315-cmw7-radius-rbac-010
  • For the Service-Type, select “Login”
20140315-cmw7-radius-rbac-011
  • Verify the 2 conditions:
20140315-cmw7-radius-rbac-012
  • Leave the access permission to “access granted
20140315-cmw7-radius-rbac-013
  • Admin logins are basic RADIUS login requests, so make sure to enable the clear text PAP/SPAP methods:
20140315-cmw7-radius-rbac-014
  • No other constraints need to be configured:
20140315-cmw7-radius-rbac-015
  • In the settings which will be applied, select the “Vendor Specific” category.
20140315-cmw7-radius-rbac-016
  • Select the vendor “Cisco” and the “Cisco-AV-Pair” Attribute:
20140315-cmw7-radius-rbac-017

20140315-cmw7-radius-rbac-018
  • For the attribute value, set shell:roles=”network-admin”
20140315-cmw7-radius-rbac-019

  • Review the Vendor Specific settings and finish the wizard.
20140315-cmw7-radius-rbac-020
  • In the Network policy list, make sure the new policy is placed in front of the block all default policies:
20140315-cmw7-radius-rbac-021

Comware7 Device: RADIUS Server configuration
On the comware7 device, define a radius scheme. The simple password will be automatically saved with a ciphered version. Make sure the key matches the RADIUS Client definitions on the NPS server.
radius scheme nps
 primary authentication 10.0.1.100
 primary accounting 10.0.1.100
 key authentication simple hp
 key accounting simple hp
 user-name-format without-domain
#
Comware7 Device: Domain and line configuration
Next, configure an isp domain (in this example, the default domain system is updated) to use the radius server for administrative logins. Backup authentication is set to none in this example.
domain system
 authentication login radius-scheme nps none
 authorization login radius-scheme nps none
 accounting login radius-scheme nps none
#
Configure the line vty range to use the domain authentication scheme
line vty 0 63
 authentication-mode scheme
Verify the authentication
Now a telnet client connection is opened, and the test user “net-admin” can login to the device:
20140315-cmw7-radius-rbac-022

RADIUS network trace
  • In the network trace, the access request shows the service-type login20140315-cmw7-radius-rbac-023
  • And the access accept shows the assigned network role
20140315-cmw7-radius-rbac-024

Comware roles
Admin roles can be listed on the comware device with the “display role” command.
This is the filtered example:
<device2>dis role | i Role
Role: network-admin
Role: network-operator
Role: level-0
Role: level-1
Role: level-2
Role: level-3
Role: level-4
Role: level-5
Role: level-6
Role: level-7
Role: level-8
Role: level-9
Role: level-10
Role: level-11
Role: level-12
Role: level-13
Role: level-14
Role: level-15
Role: security-audit
And this would be the detail of the role network-admin:
<device2>dis role name network-admin
Role: network-admin
  Description: Predefined network admin role has access to all commands on the device
  VLAN policy: permit (default)
  Interface policy: permit (default)
  VPN instance policy: permit (default)
  -------------------------------------------------------------------
  Rule    Perm   Type  Scope         Entity
  -------------------------------------------------------------------
  sys-1   permit       command       *
  sys-2   permit RWX   web-menu      -
  sys-3   permit RWX   xml-element   -
  sys-4   deny         command       display security-logfile summary
  sys-5   deny         command       system-view ; info-center securi
                                     ty-logfile directory *
  sys-6   deny         command       security-logfile save
  R:Read W:Write X:Execute

<device2>

Refer to http://abouthpnetworking.com/2014/03/16/comware7-radius-based-rbac-user-role-assignment/

Read More ...
| 1 comments ]


Issues related to MTU size, PMTUD and packet fragmentation

The Maximum Transmission Unit (MTU) is the largest number of bytes an individual datagram can have on a particular data communications link. When encapsulation, encryption or overlay network protocols are used the end-to-end effective MTU size is reduced. Some applications may not work well with the reduced MTU size and fail to perform Path MTU Discovery. In response, it would be nice to be able to increase the MTU size of the network links.

MTU Size

The Maximum Transmission Unit (MTU) is the largest possible frame size of a communications Protocol Data Unit (PDU) on anOSI Model Layer 2 data network. The size is governed based on the physical properties of the communications media. Historical network media were slower and more prone to errors so the MTU sizes were set smaller. For most Ethernet networks this is set to 1500 bytes and this size is used almost universally on access networks. Ethernet Version 2 networks have a standard frame size of 1518 bytes (including the 14-byte Ethernet II header and 4-byte Frame Check Sequence (FCS)). It should also be mentioned that other communications media types have different MTU sizes. For example, T3/DS3 (or E3) and SONET/SDH interfaces have an MTU size of 4470 bytes (4474 with header).

Encapsulation Overhead

When one protocol's packets or frames get encapsulated within another protocol there is an overall increase in the frame size. The encapsulation that takes place adds protocol header overhead, and thus the systems sending 1500-byte packets across the network cannot be sent in-tack to the other side. The amount of bytes of protocol overhead vary based on the encapsulation type. Following is a list of protocol and encapsulation overhead added to the frame.
GRE (IP Protocol 47) (RFC 2784) adds 24 bytes (20 byte IPv4 header, 4 byte GRE header)
6in4 encapsulation (IP Protocol 41, RFC 4213) adds 20 bytes
4in6 encapsulation (e.g. DS-Lite RFC 6333) adds 40 bytes
Any time you add another outer IPv4 header adds 20 bytes
IPsec encryption performed by the DMVPN adds 73 bytes for ESP-AES-256 and ESP-SHA-HMAC overhead (overhead depends on transport or tunnel mode and the encryption/authentication algorithm and HMAC)
MPLS adds 4 bytes for each label in the stack
IEEE 802.1Q tag adds 4 bytes (Q-in-Q would add 8 bytes)
VXLAN adds 50 bytes
OTV adds 42 bytes
LISP adds 36 bytes for IPv4 and 56 bytes for IPv6 encapsulation
NVGRE adds 42 bytes
STT adds 54 bytes

There are many other situations where protocol encapsulation occurs so you must be aware that this is happening along the transmission path. Although, this may be difficult to detect, your network documentation should note where the MTU size is smaller than 1500 bytes.

Path MTU Discovery (PMTUD)

Routers are capable of performing fragmentation of packets to cut them down to size so they fit into the smaller MTU-size tunnels, but this is not optimal. When an incoming packet to a network device gets its size increased due to encapsulation the packet then gets sent through the outgoing interface on its way toward the destination. However, if the new total packet size exceeds the MTU of the outgoing interface, the network device may fragment the packet into two smaller packets before being able to forward the packet. The IPv4 router will fragment and forward the packet, but also send back to the source an ICMP “packet too big” error message to inform the source that it should use a smaller MTU size. IPv6 routers do not fragment the packet on behalf of the source and just drop the packet and send back the ICMPv6 error message.

The primary problem with the MTU size being reduced across the network is that some applications may not be able to work well in this environment. Some nodes that send 1500 byte packets into the DMVPN and subsequently receive an ICMPv4 “packet too big” message from the router may choose to ignore this. These nodes are not performing Path MTU Discovery (PMTUD) as prescribed by IETF Internet RFC 1191 orRFC 1981 and are therefore relying on the IPv4 routers to perform this fragmentation on behalf of the source host. RFC 2923 also covers the topic of “TCP Problems with Path MTU Discovery”. If the application cannot function properly in this environment, there could be end-user impacts. Also, if there is a firewall in the middle of the communication path somewhere that is blocking the ICMP error messages, then that would definitely prevent PMTUD from operating properly.

One method to test and detect a reduced MTU size is to use a ping with a large packet size. Here are some examples of how to do this.

C:\Users\ScottHogg> ping -l 1500 192.168.10.1

On a Windows host you can also set the Do Not Fragment (DF) bit to 1 with the “-f” ping parameter.

C:\Users\ScottHogg> ping 192.168.10.1 -l 1500 –f

On Linux the command would be:

RedHat# ping -s 1500 -M do 192.168.10.1

On a Cisco IOS device the command would be:

Router1# ping 192.168.10.1 size 1500 df-bit

On a Cisco NX-OS device the command would be:

Switch7K# ping 192.168.10.1 packet-size 9216 c 10

On a Cisco IOS XR device the command would be:

RP/0/RP0/CPU0:Router1#ping 192.168.10.1 size 1500 donnotfrag

On a JUNOS device the command would look like:

root@J4350-1# run ping 192.168.10.1 size 1500 do-not-fragment rapid

Fragmentation

IPv4 routers fragment on behalf of the source node that is sending a larger packet. Routers can fragment IPv4 packets unless the Do-Not-Fragment (DF) bit is set to 1 in the IPv4 header. If the DF bit is set to 0 (the default), the router splits the packet that is too large to fit into the outgoing interface and send the two packets toward the destination. When the destination receives the two fragments, then the destination's protocol stack must perform reassembly of the fragments before processing the Protocol Data Unit (PDU). The danger is when an application sends its packets with DF=1 and does not pay attention to the ICMP “packet too big” messages and does not perform PMTUD.

All IPv6 networks must support an MTU size of 1280 bytes or greater (RFC 2460). This is because IPv6 routers do not fragment IPv6 packets on behalf of the source. IPv6 routers drop the packet and send back an ICMPv6 Type 4 packet (size exceeded) to the source indicating the proper MTU size. It then falls on the shoulders of the source to perform the fragmentation itself and cache the new reduced MTU size for that destination so future packets use the correct MTU size.

The primary concern with having the routers performing fragmentation on behalf of the source is the added CPU processing overhead on the router. If IPsec is being used, then the routers on both ends of the tunnel will need to handle the fragmentation and reassembly of the packets. If the routers are performing fragmentation on behalf of the source node, it may be desirable to have the encryption performed prior to encryption. This prevents the destination tunnel router from having to reassemble the fragments and then perform the decryption. In other cases, we may want to fragmentation take place after encryption. If fragmentation takes place after encryption, then the destination tunnel router will need to perform reassembly before it can decrypt the packet which can add CPU overhead. Therefore, it is advisable for most networks to fragment before encryption.

The following two Cisco IOS global configuration commands can control this behavior.

Router(config-if)# crypto ipsec fragmentation before-encryption

Router(config-if)# crypto ipsec fragmentation after-encryption

There is a good document from Cisco on the 7600 switches and how to resolve these issues titled. “Configuring IPSec VPN Fragmentation and MTU”.

MTU and MSS

Another method to handle the increase in MTU size due to encapsulation and the resulting fragmentation is to utilize the TCP Maximum Segment Size (MSS) parameter. The MSS is the largest amount of bytes of payload data able to be sent in a single TCP packet. In other words, the MSS is the largest amount of TCP data (in bytes) that can be transported over a computer network. This is negotiated during the TCP 3-way handshake in the SYN packet. The MSS is defined in RFC 879 for IPv4 and in RFC 2460for IPv6. The MSS does not include the TCP header (20 bytes) or the IPv4 header (20 bytes) (IPv6 header is 40 bytes).

In the cases where IPsec is being used, it is customary to set the MTU size on the tunnel interfaces to 1400 bytes and to set the TCP-MSS-adjust to 1360 bytes. This can be configured in a Cisco IOS device using these commands.

Router(config)# interface tunnel 4

Router(config-if)# ip tcp adjust-mss 1360

Router(config-if)# ip mtu 1400

For IPv6-enabled interfaces we can use the same type of functions, but the IPv6 header is 40-bytes instead of IPv4’s ~20-byte header. We must also consider the 20-byte TCP header which is the same size for IPv4 and IPv6.

Router(config)# interface tunnel 6

Router(config-if)# ipv6 tcp adjust-mss 1340

Router(config-if)# ipv6 mtu 1400

This MSS option does not work for UDP applications because there is no way to negotiate this during the handshake because UDP is a connectionless protocol. For UDP applications that do not perform PMTUD and set the DF=1 bit, one option may be to configure a policy that sets the DF bit back to zero.

Here is a good document from Cisco on this topic titled “Resolve IP Fragmentation, MTU, MSS, and PMTUD Issues with GRE and IPSEC”.

Compensate by Increasing the MTU Size

The primary issue with MTU size is encapsulation is taking place while the links between sites only support 1500 byte MTU. Frequently, links between enterprise routers and the upstream ISP routers only support 1500-byte MTU. This is also true on the links between CE routers and PE routers.

It would be highly desirable to be able to increase the MTU size over the WAN. If the MTU size was able to be increased throughout the path across the WAN, then the added encapsulation overhead could be compensated for by the WAN interface of the routers. This would eliminate the need to reduce the MTU size on the tunnel interfaces, adjust MSS, and alleviate the routers from performing any fragmentation.

Recommendations

It is important to be aware of issues related to the reduction in the end-to-end effective MTU size related to encapsulation. This can occur with tunnels, overlay technologies, IPsec links, and new Layer-2 data center interconnect protocols. Detecting these issues, troubleshooting them, and correcting the problem can be difficult. If you are using encapsulation technologies then you should consider increasing the MTU size if that is possible. You could ask your service provider if they support larger frame sizes within their network and on the link between their PE and your CE router. At the very least, you should document where in your network topology that these MTU size problems may occur so you are ready to quickly troubleshoot any application issues that may result.

Read More ...
| 0 comments ]

Before diving into configuration let me first describe what AAA is all about.

AAA stands for authentication, authorization and accounting, a system in IP-based networking to control what computer resources (routers,switches, firewalls, wireless access points, WLC, WCS) users have access to and to keep track of the activity of users over a network.

Authentication is the process of identifying an individual, usually based on a username and password. Authentication is based on the idea that each individual user will have unique information that sets him or her apart from other users.
Authorization is the process of granting or denying a user access to network resources once the user has been authenticated through the username and password. The amount of information and the amount of services the user has access to depend on the user’s authorization level.
Accounting is the process of keeping track of a user’s activity while accessing the network resources, including the amount of time spent in the network, the services accessed while there and the amount of data transferred during the session. Accounting data is used for trend analysis, capacity planning, billing, auditing and cost allocation.

AAA services often require a server that is dedicated to providing the three services. RADIUS, TACACs are an example of an AAA service. In my post i am using 2 ACS box running in high availability in Global Data Center for AAA and using Microsoft Active Directory as a database for end user authentication.

Now lets dig into configuration.

AAA for Telnet users by an HWTACACS server on HP A Series Switches
======================================================================
Local-user unetadmin –>This sets the local user, in case ACS server fails.
password simple icewater
service-type ssh telnet terminal
authorization-attribute level 3 –>Level 3 is the highest level in HP A series, like privilege 15 in cisco devices.
!
super password level 3 cipher rainwater –>This is like Enable password in cisco.

!
User-interface vty 0 15
Authentication-mode scheme –>It means we are using AAA scheme.
user privilege level 3 –>If authentication by AAA user will be directed to privilege 3.
quit
!
hwtacacs scheme acs –>We need to define a scheme first.
primary authentication x.x.x.x –>Where x.x.x.x is primary ACS server.
secondary authentication y.y.y.y –>Where y.y.y.y is secondary ACS server.
primary authorization x.x.x.x
secondary authorization y.y.y.y
primary accounting x.x.x.x
secondary accounting y.y.y.y
!
key authentication HP_ASeries –>Key should match with the key configured in ACS box. Note:- This is case -sensitive.
key authorization HP_ASeries
key accounting HP_ASeries
user-name-format without-domain
nas-ip z.z.z.z –> This is the source of the AAA conversation from the device to the ACS box, either it should be management interface or the ip that is configured on the ACS box for this particular device.

quit
!
domain upm_acs –>Configured “scheme” should be embedded into a “Domain” to define the hierarchy for AAA.
authentication default hwtacacs-scheme acs local –>This means the AAA will first try ACS primary then secondary and if both fails then local.
authorization default hwtacacs-scheme acs local
accounting default hwtacacs-scheme acs local
authentication login hwtacacs-scheme acs local
authorization login hwtacacs-scheme acs local
accounting login hwtacacs-scheme acs local
access-limit disable
state active
idle-cut disable
self-service-url disable
user-group upm_acs –>We need to define user-group as same as Domain name.
domain default enable upm_acs –>This is the main command to enable the domain for AAA, in case if we have multiple domain configured, like one for TACACS, other for Radius.

AAA for HP E Series Switches:
================================

# Configure the switch to use AAA for Telnet users.

password manager user-name –>Manager is highest level of access in HP E series.

password manager user-name unetadmin

password: icewater

confirm : icewater

aaa authentication login privilege-mode –>Login straight into Manager mode, no need to type “Enable” after successful login.
aaa authentication telnet login radius local –>This means for telnet AAA will first try ACS primary then secondary and if both fails then local.
aaa authentication telnet login radius local
aaa authentication telnet enable radius local
aaa authentication ssh login radius local –>This is for SSH.
aaa authentication ssh enable radius local
aaa accounting exec start-stop radius

!
radius-server host x.x.x.x key HP_ESeries –>Define primary Radius server host and the key.
radius-server host y.y.y.y key HP_ESeries –>Define secondary Radius server host and the key.

ip source-interface radius z.z.z.z –>This is the source of the AAA conversation from the device to the ACS box, either it should be management interface or the ip that is configured on the ACS box for this particular device.

Refer to http://afrozahmad.com/blog/hp/aaa-configuration-for-hp-a-and-e-series-switches/

Read More ...
| 0 comments ]

Information

Excessive spanning-tree topology changes in a network can lead to latency, performance, and unnecessary traffic flooding problems. Ensuring a stable spanning-tree topology is a key foundation to a well running network. This document outlines the main causes of spanning-tree topology changes and covers the applicable switch show commands to diagnose the problem.

Spanning-tree topology changes can be triggered by any of the following:
  1. Non edge ports in a spanning-tree domain transitioning from online to offline and vice versa. Non edge ports are ports that connect to other networking devices that typically participate in spanning-tree while edge ports connect to PCs and other devices that should not participate in spanning-tree. All current E Series switches (Excluding switches running Comware) have an auto-edge detection feature which will automatically detect if a port is edge or non edge based on if a BPDU is received on the interface. In a stable network, non edge ports (switch-to-switch) should rarely, if ever transition. If a non edge port is transitioning repeatedly (flapping) however, each transition will end up triggering a spanning-tree topology change. 
  2. Spanning-tree BPDUs from other network segments or spanning-tree regions with the appropriate flags set to instigate a topology change. 
  3. Switch software. Older versions of software do not have the auto-edge feature and non edge ports have to be manually configured.

Details

It’s best to start troubleshooting spanning tree topology changes on the root bridge of the spanning-tree domain.
  • Keep in mind that most of the counter statistics is since switch boot. This will contain historical data. It is strongly advised that the counters should be compared over successive data collections. This gives a timeframe to compare the changes to.
  • To check for excessive port transitions (port toggling) the easiest output to gather and review is "show tech statistics" which is near the end of a "show tech all" output. Look for interfaces that show a high number of port transitions and then determine if switch believes the interface is edge or non edge which can be seen in a "show spanning-tree" output:
  • If the switch is not properly auto detecting edge or non edge status, a port can administratively be forced to edge or non edge.
  • A switch port can be configured as admin-edge. If it receives a BPDU it will change state away from edge. The command "show spanning-tree detail" will help verify if the port is in fact behaving as an edge port. Look for the value of "OperEdgePort". It should be Yes.
  • If edge and non edge ports are properly detected by the root bridge and none of the non edge ports are excessively transitioning then a "show spanning-tree debug-counters ports all instance 0" will show on what interfaces the root bridge is receiving topology change information on. Optionally a "show spanning-tree details" output provides similar information however the debug-counters provide a date and time stamp for the different counters. Also note that the "show spanning-tree debug-counters"... command can be ran for specific interfaces and specific instances in the case of MSTP. In a single spanning tree region (STP, RSTP, or MSTP with no other instanced defined) the instance ID will be "0": 
  • Once a particular interface has been identified as receiving excessive topology changes, the above steps can then be repeated on the attached neighboring device. 
  • In certain cases the neighboring unit may be part of a different network segment or not locally manageable. In this case BPDU (or PVST if the neighbor is a Cisco) filtering can be applied to the interface to prevent the spanning-tree information being received on the interface from affecting the topology of the local spanning tree region. Be advised that applying BPDU filtering to an interface removes it from spanning tree and the port will always transition to a forwarding state, since it discard BPDUs bi-directionally.
  • Always check the software release notes for the switches in question as there have been fixes implemented for spanning tree on all platforms.

Read More ...
| 0 comments ]

Configuring an MST region

To configure an MST region:
  1. Enter system view and use the command
    system-view
  2. Enter MST region view and use the command
    stp region-configuration
  3. Configure the MST region name and use the command
    region-name name
    NOTE: Optional. The MST region name is the MAC address by default.
  4. Configure the VLAN-toinstance mapping table and use the command:
    • instance instance-id vlan vlan-list
    • vlan-mapping modulo modulo
      NOTE: Optional. Use either command. All VLANs in an MST region are mapped to the CIST (or MSTI 0) by default.
  5. Configure the MSTP revision level of the MST region and use the command
    revision-level level
  6. Display the MST region configurations that are not activated yet and use the command
    check region-configuration
  7. Activate MST region configuration manually and use the command
    active region-configuration
  8. Display the activated configuration information of the MST region and use the command
    display stp region-configuration [ | { begin | exclude | include } regular-expression ]
Two or more MSTP-enabled devices belong to the same MST region only if they are configured to have the same format selector (0 by default, not configurable), MST region name, the same VLAN-to-instance mapping entries in the MST region and the same MST region revision level, and they are interconnected via a physical link.

The configuration of MST region–related parameters, especially the VLAN-to-instance mapping table, will cause MSTP to launch a new spanning tree calculation process, which may result in network topology instability. To reduce the possibility of topology instability caused by configuration, MSTP does not immediately launch a new spanning tree calculation process when processing MST region–related configurations; instead, such configurations takes effect only after activating the MST region–related parameters by using the active region-configuration command, or enable MSTP by using the stp enable command in the case that MSTP is disabled.

Configuring the root bridge or a secondary root bridge

MSTP can determine the root bridge of a spanning tree through MSTP calculation. Also, there is an option of specifying the current device as the root bridge or a secondary root bridge using the commands provided by the system.
NOTE:
  • A device has independent roles in different MSTIs. It can act as the root bridge or a secondary root bridge of one MSTI and being the root bridge or a secondary root bridge of another MSTI. However, the same device cannot be the root bridge and a secondary root bridge in the same MSTI at the same time.
  • There is only one root bridge in effect in a spanning tree instance. If two or more devices have been designated to be root bridges of the same spanning tree instance, MSTP selects the device with the lowest MAC address as the root bridge.
  • When the root bridge of an instance fails or is shut down, the secondary root bridge (if specified one) can take over the role of the primary root bridge. However, if specified a new primary root bridge for the instance then, the secondary root bridge will not become the root bridge. If the user has specified multiple secondary root bridges for an instance, when the root bridge fails, MSTP will select the secondary root bridge with the lowest MAC address as the new root bridge.
Configuring the current device as the root bridge of a specific spanning tree
To configure the current device as the root bridge of a specific spanning tree follow the steps given below:
  1. Enter system view and use the command
    system-view
  2. Configure the current device as the root bridge of a specific spanning tree and use the command
    stp [ instance instance-id ] root primary
Configuring the current device as a secondary root bridge of a specific spanning tree
To configure the current device as a secondary root bridge of a specific spanning tree follow the steps given below:
  1. Enter system view and use the command
    system-view
  2. Configure the current device as a secondary root bridge of a specific spanning tree
    stp [ instance instance-id ] root secondary
After specifying the current device as the root bridge or a secondary root bridge, the user cannot change the priority of the device. The user can also configure the current device as the root bridge by setting the priority of the device to 0.

Configuring the work mode of an MSTP device

MSTP and RSTP are mutually compatible, and can recognize each other’s protocol packets. However, STP is unable to recognize MSTP packets. For hybrid networking with legacy STP devices and for full interoperability with RSTP-enabled devices, MSTP supports the following work modes: STP-compatible mode, RSTP mode, and MSTP mode.
  • In STP-compatible mode, all ports of the device send out STP BPDUs,
  • In RSTP mode, all ports of the device send out RSTP BPDUs. If the device detects that it is connected to a legacy STP device, the port connecting to th e legacy STP device will migrate automatically to STP-compatible mode.
  • In MSTP mode, all ports of the device send out MSTP BPDUs. If the device detects that it is connected to a legacy STP device, the port connecting to the legacy STP device will migrate automatically to STP-compatible mode.
Make this configuration on the root bridge and on the leaf nodes separately.
To configure the MSTP work mode:
  1. Enter system view and use the command
    system-view
  2. Configure the work mode of MSTP
    stp mode { stp | rstp | mstp }

Configuring the device priority

CAUTION:
  • After configuring a device as the root bridge or a secondary root bridge, you cannot change the priority of the device.
  • During root bridge selection, if all devices in a spanning tree have the same priority, the one with the lowest MAC address will be selected as the root bridge of the spanning tree.
Device priority is a factor in spanning tree calculation. The priority of a device determines whether the device can be elected as the root bridge of a spanning tree. A lower numeric value indicates a higher priority. We can set the priority of a device to a low value to specify the device as the root bridge of the spanning tree. A spanning tree device can have different priorities in different MSTIs.
To configure the priority of a device in a specified MSTI follow the steps given below:
  1. Enter system view and use the command
    system-view
  2. Configure the priority of the current device in a specified MSTI, use the command
    stp [ instance instance-id ] priority priority

Configuring the maximum hops of an MST region

By setting the maximum hops of an MST region, the user can restrict the region size. The maximum hops configured on the regional root bridge will be used as the maximum hops of the MST region.
The regional root bridge always sends a configuration BPDUs with a hop count set to the maximum value. When a switch receives this configuration BP DU, it decrements the hop count by 1 and uses the new hop count in the BPDUs it propagates. When the ho p count of a BPDUS reaches 0, it is discarded by the device that received it. Devices beyond the reach of the maximum hop can no longer take part in spanning tree calculation, and the size of the MST region is confined.
To configure the maximum number of hops of an MST region follow the steps given below:
  1. Enter system view and use the command
    system-view
  2. Configure the maximum hops of the MST region and use the command
  3. stp max-hops hops

Configuring the network diameter of a switched network

Any two terminal devices in a switched network are interconnected through a specific path composed of a series of devices. The network diameter is the number of devices on the path composed of the most devices. The network diameter is a parameter th at indicates the network size. A bigger network diameter indicates a larger network size.
Make this configuration on the root bridge only.
To configure the network diameter of a switched network follow the steps given below:
  1. Enter system view and use the command
    system-view
  2. Configure the network diameter of the switched network, use the command
    stp bridge-diameter diameter

Configuring timers of MSTP

STP calculation involves the following timing parameters:
  • Forward delay - Determines the time interval of state transition. To prevent temporary loops, a port must go through an intermediate state, the learning state, before it transitions from the discarding state to the forwarding state, and must wait a certain period of time (for ward delay) before it transitions from one state to another to keep synchronized with the remote device during state transition.
  • Hello time - Used to detect link failures. STP sends configuration BPDUs at the interval of hello time. If a device fails to receive configuration BPDUs within the hello time, a new spanning tree calculation process will be triggered because of configuration BPDU timeout.
  • Max age - Used to detect configuration BPDU timeout. In the CIST, the device determines whether a configuration BPDU received on a port has expired based on the max age timer. If a port receives a configuration BPDU that has expired, that MSTI must be re-calculated. The max age is meaningless for MSTIs.
To avoid frequent network changes, the settings of the hello time, forward delay and max age timers must meet the following formulas:
  • 2 × (forward delay – 1 second) ƒ max age
  • Max age ƒ 2 × (hello time + 1 second)
HP does not recommend us to manually set the spanning tree timers. Instead, we can specify the network diameter and let spanning tree protocols automatically calculate the timers based on the network diameter. If the network diameter uses the default value, the timers also use their default values. Configure the timers on the root bridge only, and the timer settings on the root bridge apply to all devices on the entire switched network.
To configure the spanning tree timers follow the steps given below:
  1. Enter system view and use the command
    system-view
  2. Configure the forward delay timer (in STP/RSTP/MSTP mode) and use the command
    stp timer forward-delay time
  3. Configure the hello timer
    stp timer hello time
  4. Configure the max age timer (in STP/RSTP/MSTP mode) and use the command
    stp timer max-age time
The length of the forward delay is related to the network diameter of the switched network. The larger the network diameter is, the longer the forward delay should be. If the forward delay is too short, temporary redundant paths can be introduced. If the forward delay is too long, it may take a long time for the network to converge. HP recommends to use the default setting.
An appropriate hello time enables the device to timely detect link failures on the network without using excessive network resources. If the hello time is set too long, the device will take packet loss as a link failure and trigger a new spanning tree calculation process. If the hello time is set too short, the device will send repeated configuration BPDUs frequently, which adds to the device burden and causes waste of network resources. HP recommends to use the default setting. If the max age time is too short, the network devices will frequently launch spanning tree calculations and may take network congestion as a link failure.
If the max age is too long, the network may fail to timely detect link failures and fail to timely launch spanning tree calculations , reducing the auto-sensing capability of the network. HP recommends to use the default setting.

Configuring the timeout factor

The timeout factor is a parameter used to decide the timeout time in the following formula:
Timeout time = timeout factor × 3 × hello time.
After the network topology is stabilized, each non-root-bridge device forwards configuration BPDUs to the downstream devices at the interval of hello time to check whether any link is faulty. If a device does not receive a BPDU from the upstream device within nine times the hello time, it assumes that the upstream device has failed and starts a new spanning tree calculation process.
Sometimes a device may fail to receive a BPDU from the upstream device because the upstream device is busy. If a spanning tree calculation occurs, the calculation can fail and also waste the network resources. In a very stable network, avoid such unwanted spanning tree calculations by setting the timeout factor to 5, 6, or 7.
To configure the timeout factor follow the steps given below:
  1. Enter system view and use the command
    system-view
  2. Configure the timeout factor of the device and use the command
    stp timer-factor factor

Configuring the maximum port rate

The maximum rate of a port refers to the maximum number of BPDUs the port can send within each hello time. The maximum rate of a port is related to the physical status of the port and the network structure.
Make this configuration on the root bridge and on the leaf nodes separately.
To configure the maximum rate of a port or a group of ports follow the steps given below:
  1. Enter system view and use the command
    system-view
  2. Enter interface view or port group view
    • Enter Layer 2 Ethernet interface view or Layer 2 aggregate interface view and use the command
      interface interface-type interface-number
    • Enter port group view and use the command
      port-group manual port-group-name
  3. Configure the maximum rate of the ports and use the command
    stp transmit-limit limit
The higher the maximum port rate is, the more BPDUs will be sent within each hello time, and the more system resources will be used. By setting an appropriate maximum port rate, the user can limit the rate at which the port sends BPDUs and prevent MSTP from using excessive network resources when the network becomes instable. HP recommends to use the default setting.

Configuring ports as edge ports

If a port directly connects to a user terminal rather than another device or a shared LAN segment, this port is regarded as an edge port. When a network topology change occurs, an edge port will not cause a temporary loop. Because a device does not know whether a port is directly connected to a terminal, the user needs to manually configure the port to be an edge port. After that, this po rt can transition rapidly from the blocked state to the forwarding state without delay.
Make this configuration on the root bridge and on the leaf nodes separately.
To specify a port or a group of ports as edge port or ports follow the steps given below:
  1. Enter system view and use the command
    system-view
  2. Enter interface view or port group view
    • Enter Layer 2 Ethernet interface view or Layer 2 aggregate interface view and use the command
      interface interface-type interface-number
    • Enter port group view and use the command
      port-group manual port-group-name
  3. Configure the current ports as edge ports and use the command
    stp edged-port enable
With BPDU guard disabled, when a port set as an edge port receives a BPDU from another port, it will become a non-edge port again. To restore the edge port, re-enable it.
If a port directly connects to a user terminal, configure it as an edge port and enable BPDU guard for it. This enables the port to transition to the forwarding state fast while ensuring network security. Otherwise, the port can be blocked and changes to the forwarding state after a period twice the forward delay. In the waiting period, service traffic is interrupted.
Among loop guard, root guard and edge port settings, only one function (whichever is configured the earliest) can take effect on a port at the same time.

Configuring path costs of ports

CAUTION: If you change the standard that the device uses to calculate the default path costs, you restore the path costs to the default.
Path cost is a parameter related to the rate of a port. On an MSTP-enabled device, a port can have different path costs in different MSTIs. Setting appropriate path costs allows VLAN traffic flows to be forwarded along different physical links, achieving VLAN-based load balancing.
The device can automatically calculate the default path cost; alternatively, the user can also configure the path cost for ports.
Make the following configurations on the leaf nodes only.
Specifying a standard that the device uses when calculating the default path cost:
Specify a standard for the device to use in automatic calculation for the default path cost. The device supports the following standards:
  • dot1d-1998 - Device calculates the default path cost for ports based on IEEE 802.1d-1998.
  • dot1t - Device calculates the default path cost for ports based on IEEE 802.1t.
  • legacy - Device calculates the default path cost for ports based on a private standard.
To specify a standard for the device to use when it calculates the default path cost follow the steps given below:
  1. Enter system view and use the command
    system-view
  2. Specify a standard for the device to use when it calculates the default path costs of its ports and use the command
    stp pathcost-standard { dot1d- 1998 | dot1t | legacy }
Table 1 - Mappings between the link speed and the path cost, shows the mappings between the link speed and the path cost.
Link Speed
Link Speed
Path Cost
IEEE 802.1d-1998
IEEE 802.1t
Private Standard
0
-
65,535
200,000,000
65,535
10 Mb/s
Single Port
100
2,000,000
2000
Aggregate interface containing 2 selected ports
1,000,000
1800
Aggregate interface containing 3 selected ports
666,666
1600
Aggregate interface containing 4 selected ports
500,000
1400
100 Mb/s
Single Port
19
200,000
200
Aggregate interface containing 2 selected ports
100,000
180
Aggregate interface containing 3 selected ports
66,666
160
Aggregate interface containing 4 selected ports
50,000
140
1000 Mb/s
Single Port
4
20,000
20
Aggregate interface containing 2 selected ports
10,000
18
Aggregate interface containing 3 selected ports
6666
16
Aggregate interface containing 4 selected ports
5000
14
10 Gb/s
Single Port
2
2000
2
Aggregate interface containing 2 selected ports
1000
1
Aggregate interface containing 3 selected ports
666
1
Aggregate interface containing 4 selected ports
500
1
When calculating path cost for an aggregate interface, IEEE 802.1d-1998 does not take into account the number of selected ports in its aggregation group as IEEE 802.1t does. The calculation formula of IEEE 802.1t is: Path Cost = 200,000,000/link speed (in 100 kb/s), where link speed is the sum of the link speed values of the selected ports in the aggregation group.
To configure the path cost of ports follow the steps given below:
  1. Enter system view and use the command
    system-view
  2. Enter interface view or port group view
    • Enter Layer 2 Ethernet interface view or Layer 2 aggregate interface view and use the command
      interface interface-type interfacenumber
    • Enter port group view and use the command
      port-group manual port-groupname
  3. Configure the path cost of the ports
    stp [ instance instance-id ] cost cost
When the path cost of a port changes, the system re-calculates the role of the port and initiates a state transition.
Configuration example
# Specify that the device use IEEE 802.1d-1998 to calculate the default path costs of its ports.
<Sysname> system-view  
[Sysname] stp pathcost-standard dot1d-1998 
# Set the path cost of GigabitEthernet 1/0/3 on MSTI 2 to 200.
<Sysname> system-view  
[Sysname] interface gigabitethernet 1/0/3  
[Sysname-GigabitEthernet1/0/3] stp instance 2 cost 200 

Configuring the port priority

The priority of a port is an important factor in determining whether the port can be elected as the root port of a device. If all other conditions are the same, the port with the highest priority will be elected as the root port. On an MSTP-enabled device, a port can have different priorities in different MSTIs, and the same port can play different roles in different MSTIs, so that data of different VLANs can be propagated along different physical paths, implementing per-VLAN load balancing. The user can set port priority values based on the actual networking requirements.
Make this configuration on the leaf nodes only.
To configure the priority of a port or a group of ports follow the steps given below:
  1. Enter system view and use the command
    system-view
  2. Enter interface view or port group view
    • Enter Layer 2 Ethernet interface view or Layer 2 aggregate interface view and use the command
      interface interface-type interfacenumber
    • Enter port group view and use the command
      port-group manual port-group-name
  3. Configure the port priority
    stp [ instance instance-id ] port priority priority
When the priority of a port changes, MSTP re-calculates the role of the port and initiates a state transition.
A lower priority value indicates a higher priority. If the user configures the same priority value for all ports on a device, the specific priority of a port depends on the index number of the port. A lower index number means a higher priority. Changing the priority of a port triggers a new spanning tree calculation process.

Configuring the port link type

A point-to-point link is a link directly connecting two devices. If the two ports across a point-to-point link are root ports or designated ports, the ports can rapidly transition to the forwarding state after a proposal-agreement handshake process.
Make this configuration on the root bridge and on the leaf nodes separately.
To configure the link type of a port or a group of ports follow the steps given below:
  1. Enter system view and use the command
    system-view
  2. Enter interface view or port group view
    • Enter Layer 2 Ethernet interface view or Layer 2 aggregate interface view and use the command
      interface interface-type interface-number
    • Enter port group view and use the command
      port-group manual portgroup- name
  3. Configure the port link type and use the command
    stp point-to-point { auto | force-false | forcetrue }
If the current port is a Layer 2 aggregate interface or if it works in full duplex mode, the user can configure the link to which the current port connects as a point-to-point link. HP recommends to use the default setting, and let MSTP detect the link status automatically.
If a port is configured as connecting to a point-to-point link or a non- point-to-point link, the setting takes effect for the port in all MSTIs.
If the physical link to which the port connects is not a point-to-point link and manually set it to be one, the configuration may cause temporary loops.

Configuring the mode a port uses to recognize/send MSTP packets

A port can receive/send MSTP packets in the following formats:
  • dot1s - 802.1s-compliant standard format
  • legacy - Compatible format
By default, the packet format recognition mode of a port is auto. The port automatically distinguishes the two MSTP packet formats, and determines the format of packets it will send based on the recognized format. Configure the MSTP packet format on a port. When working in MSTP mode after the configuration, the port sends and receives only MSTP packets of the format the user has configured to communicate with devices that send packets of the same format. Make this configuration on the root bridge and on the leaf nodes separately.
To configure the MSTP packet format to be supported on a port or a group of ports follow the steps given below:
  1. Enter system view and use the command
    system-view
  2. Enter interface view or port group view
    • Enter Layer 2 Ethernet interface view or Layer 2 aggregate interface view and use the command
      interface interface-type interfacenumber
    • Enter port group view and use the command
      port-group manual port-group-name
  3. Configure the mode that the port uses to recognize/send MSTP packets and use the command
    stp compliance { auto | dot1s | legacy }
MSTP provides the MSTP packet format incompatibility guard function. In MSTP mode, if a port is configured to recognize/send MSTP packets in a mode other than auto, and receives a packet in a format different from the specified type, the port will become a designated port and remain in the discarding state to prevent the occurrence of a loop.
MSTP provides the MSTP packet format frequent change guard function. If a port receives MSTP packets of different formats frequently, the MSTP packet format configuration can contain errors. If the port is working in MSTP mode, it will be disabled for protection. The closed ports can be restored only by the network administrators.

Enabling the output of port state transition information

A large-scale, MSTP-enabled network can have many MSTIs, and ports may frequently transition from one state to another. In this situation, the user can enable devices to output the port state transition information of all MSTIs or the specified MSTI so as to monitor the port states in real time.
Make this configuration on the root bridge and on the leaf nodes separately.
To enable output of port state transition information follow the steps given below:
  1. Enter system view and use the command
    system-view
  2. Enable output of port state transition information
    stp port-log { all | instance instance-id }

Enabling MSTP feature

The user must enable MSTP for the device before any other MSTP-related configurations can take effect.
Make this configuration on the root bridge and on the leaf nodes separately.
Enabling the spanning tree feature (in STP/RSTP/MSPT mode)
To enable the spanning tree feature in STP/RSTP/MSTP mode follow the steps given below:
  1. Enter system view and use the command
    system-view
  2. Enable the spanning tree feature globally
    stp enable
  3. Enter interface view or port group view
    • Enter Layer 2 Ethernet interface view or Layer 2 aggregate interface view and use the command
      interface interface-type interface-number
    • Enter port group view and use the command
      port-group manual portgroup- name
  4. Enable the spanning tree feature for the port or group of ports and use the command
    stp enable
In system view, the user can use the stp enable or undo stp enable command to enable or disable STP globally. Use the undo stp enable command to disable the MSTP feature for certain ports so that they will not take part in spanning tree calculation to save the CPU resources of the device.

Performing mCheck

If a port on a device that is running MSTP, RSTP, or PVST connects to an STP device, this port automatically transitions to the STP-compatible mode. However, it cannot automatically transition back to the original mode under the following circumstances:
  • The STP device is shut down or removed.
  • The STP device transitions to the MSTP, RSTP, or PVST mode.
Performing mCheck globally
MSTP has three working modes: STP compatible mode, RSTP mode, and MSTP mode.
If a port on a device running MSTP (or RSTP) connects to a device running STP, this port will migrate to the STP-compatible mode automatically. However, it will not be able to migrate automatically back to the MSTP (or RSTP) mode, but will remain working in the STP-compatible mode under the following circumstances:
  • The device running STP is shut down or removed.
  • The device running STP migrates to the MSTP (or RSTP) mode.
To perform global mCheck:
  1. Enter system view and use the command
    system-view
  2. Perform mCheck and use the command
    stp mcheck
Performing mCheck in interface view:
To perform mCheck in interface view:
  1. Enter system view and use the command
    system-view
  2. Enter Layer 2 Ethernet interface view or Layer 2 aggregate interface view and use the command
    interface interface-type interface-number
  3. Perform mCheck and use the command
    stp mcheck

Configuring digest snooping

As defined in IEEE 802.1s, interconnected devices are in the same region only when the MST region-related configurations (region name, revision level, VLAN-to-instance mappings) on them are identical. An MSTP-enabled device identifies devices in the same MST region by checking the configuration ID in BPDU packets. The configuration ID includes the region name, revision level, configuration digest that is in 16-byte length and is the result calculated via the HMAC-MD5 algorithm based on VLAN-to-instance mappings.
Since MSTP implementations vary with vendors, the configuration digests calculated using private keys is different. The different vendors’ devices in the same MST region cannot communicate with each other.
Enabling the digest snooping feature on the port connecting the local device to a third-party device in the same MST region can make the two devices communicate with each other.
Before enabling digest snooping, ensure that associated devices of different vendors are connected and run MSTP.
Configuring the digest snooping feature:
The user can enable digest snooping only on a device that is connected to a third-party device that uses its private key to calculate the configuration digest.
To configure digest snooping perform the following:
  1. Enter system view and use the command
    system-view
  2. Enter interface or port group view
    • Enter Layer 2 Ethernet interface view or Layer 2 aggregate interface view and use the command
      interface interface-type interface-number
    • Enter port group view and use the command
      port-group manual portgroup- name
  3. Enable digest snooping on the interface or port group
    Enable digest snooping on the interface or port group
  4. Return to system view
    quit
  5. Enable global digest snooping
    stp config-digest-snooping
With the digest snooping feature enabled, comparison of configuration digest is not needed for in-the-same-region check, so the VLAN-to-instance mappings must be the same on associated ports.
With global digest snooping enabled, modification of VLAN-to-instance mappings and removing of the current region configuration using the undo stp region-configuration command are not allowed. The user can only modify the region name and revision level.
The user must enable digest snooping both globally and on associated ports to make it take effect. HP recommends to enable digest snooping on all associated ports first and then globally, making the configuration take effect on all configured ports and reducing impact on the network.
To avoid loops, do not enable digest snooping on MST region edge ports. HP recommends to enable digest snooping first and then MSTP. To avoid traffic interruption, do not configure digest snooping when the network works well.
Digest snooping configuration example:
Network requirements:
As shown in Figure - Digest snooping configuration:
  • Device A and Device B connect to Device C, which is a third-party device. All these devices are in the same region.
  • Enable digest snooping on Device A’s and Device B’s ports that connect Device C, so that the three devices can communicate with one another.
Figure 1: Digest snooping configuration
Configuration procedure:
# Enable digest snooping on GigabitEthernet 1/0/1 of Device A and enable global digest snooping on Device A.
<DeviceA> system-view  
[DeviceA] interface gigabitethernet 1/0/1  
[DeviceA-GigabitEthernet1/0/1] stp config-digest-snooping  
[DeviceA-GigabitEthernet1/0/1] quit  
[DeviceA] stp config-digest-snooping 
# Enable digest snooping on GigabitEthernet 1/0/1 of Device B and en able global digest snooping on Device B.
<DeviceB> system-view  
[DeviceB] interface gigabitethernet 1/0/1  
[DeviceB-GigabitEthernet1/0/1] stp config-digest-snooping  
[DeviceB-GigabitEthernet1/0/1] quit  
[DeviceB] stp config-digest-snooping 

Configuring no agreement check

In RSTP and MSTP, the following types of messages are used for rapid state transition on designated ports:
  • Proposal: sent by designated ports to request rapid transition
  • Agreement: used to acknowledge rapid transition requests
Both RSTP and MSTP devices can perform rapid transition on a designated port only when the port receives an agreement packet from the downstream device. RSTP and MSTP devices have the following differences:
  • For MSTP, the downstream device’s root port sends an agreement packet only after it receives an agreement packet from the upstream device.
  • For RSTP, the downstream device sends an agreement packet regardless of whether an agreement packet from the upstream device is received.
Figure 2 - Rapid state transition of an MSTP designated port, shows the rapid state transition mechanism on MSTP designated ports:
Figure 2: Rapid state transition of an MSTP designated port
Figure 3 - Rapid state transition of an RSTP designated port, below shows rapid state transition of an RSTP designated port:
Figure 3: Rapid state transition of an RSTP designated port
If the upstream device is a third- party device, the rapid state transition implementation may be limited. For example, when the upstream device uses a rapid transition mechanism similar to that of RSTP, and the downstream device adopts MSTP and does not work in RSTP mode, the root port on the downstream device receives no agreement packet from the upstream device and sends no agreement packets to the upstream device. As a result, the de signated port of the upstream device fails to transit rapidly and can only change to the forwarding state after a period twice the forward delay.
The no agreement check feature can be enabled on the downstream device’s port to enable the designated port of the upstream device to transit its state rapidly.
Configuration prerequisites:
Before configuring the no agreement check function, complete the following tasks:
  • Connect a device is to a third- party upstream device supporting MSTP via a point-to-point link.
  • Configure the same region name, revision level and VLANs-to-instance mappings on the two devices, assigning them to the same region.
Configuring the no agreement check function:
To make the no agreement check feature take effect, enable it on the root port.
To configure no agreement check:
  1. Enter system view and use the command
    system-view
  2. Enter interface or port group view
    • Enter Layer 2 Ethernet interface view or Layer 2 aggregate interface view and use the command
      interface interface-type interface-number
    • Enter port group view and use the command
      port-group manual portgroup- name
  3. Enable no agreement check and use the command
    stp no-agreement-check
No agreement check configuration example:
As shown in Figure 4:
  • Device A connects to Device B, a third-party device that has different MSTP implementation. Both devices are in the same region.
  • Device B is the regional root bridge, and Device A is the downstream device.
Figure 4: No agreement check configuration
Configuration procedure:
# Enable no agreement check on GigabitEthernet 1/0/1 of Device A.
<DeviceA> system-view  
[DeviceA] interface gigabitethernet 1/0/1  
[DeviceA-GigabitEthernet1/0/1] stp no-agreement-check 

Configuring TC snooping

Figure 5 - TC snooping application scenario, shows a TC snooping application scenario. Device A and Device B are both IRF-enabled switches and form an IRF virtual device; they operate at the distribution layer and do not have STP enabled. The IRF virtual device formed by Device A and Device B connect to multiple access-layer customer networks, such as Customer 1 and Customer 2. Device C, Device D, and Device E in customer network Customer 1 are all enabled with STP. Customer 1 is dual-uplinked to the IRF virtual device for high availability. The IRF virtual device transparently transmits STP BPDUs from Customer 1 at Layer 2. Other customer networks (such as Custom er 2) act the same as Customer 1.
Figure 5: TC snooping application scenario
In the network, the IRF virtual device transparently transmits the received STP BPDUs and does not participate in STP calculations. When a topology change occurs to the IRF virtual device or attached access-layer networks, the IRF virtual device may need a long time to learn the correct MAC address table entries and ARP entries, resulting in long network disruption. To avoid the network disruption, TC snooping can be enabled on the IRF virtual device.
TC snooping enables a device to actively clear the MAC address table entries and ARP entries upon receiving TC-BPDUs and to re-learn the MAC address table entries and ARP entries, so that the device can normally forward the user traffic.
Configuration prerequisites:
Disable STP globally.
Configuring TC snooping:
Perform the TC snooping configuration on the IRF virtual device shown in Figure 5 - TC snooping application scenario:
To configure TC snooping:
  1. Enter system view
    system-view
  2. Enable TC snooping
    stp tc-snooping
TC snooping and STP are mutually exclusive.
TC snooping does not take effect on the ports on which BPDU tunneling is enabled for STP.

Configuring protection functions

A spanning tree device supports the following protection functions:
  • BPDU guard
  • Root guard
  • Loop guard
  • TC-BPDU guard
Configuration prerequisites:
MSTP has been correctly configured on the device.
Enabling BPDU guard
For access layer devices, the access ports can directly connect to the user terminals (such as PCs) or file servers. The access ports are configured as edge ports to allow rapid transition. When these ports receive configuration BPDUs, the system will set these ports automatically as non-edge ports and start a new spanning tree calculation proc ess. This will cause a change of network topology. Under normal conditions, these ports should not receive configuration BPDUs. However, if someone forges configuration BPDUs maliciously to attack the devices, the network will become instable.
MSTP provides the BPDU guard function to protect the system against such attacks. With the BPDU guard function enabled on the devices, when edge ports receive configuration BPDUs, MSTP will close these ports and notify the NMS that these ports have been closed by MSTP. The closed ports will be re-activated by the device after a detection interval.
Make this configuration on a device with edge ports configured.
To enable BPDU guard:
  1. Enter system view and use the command
    system-view
  2. Enable the BPDU guard function for the device
    stp bpdu-protection
BPDU guard does not take effect on loopback test-enabled ports.
Enabling root guard
The root bridge and secondary root bridge of a spanning tree should be located in the same MST region. Especially for the CIST, the root bridge and secondary root bridge are put in a high-bandwidth core region during network design. However, because of possible configuration errors or malicious attacks in the network, the legal root bridge may receive a configuration BPDU with a higher priority. The current legal root bridge will be superseded by another device, causing an undesired change of the network topology. As a result, the traffic that should go over high-speed links is switched to low-speed links, resulting in network congestion.
To prevent this situation from happening, MSTP provides the root guard function. If the root guard function is enabled on a port of a root bridge, this port will keep playing the ro le of designated port on all MSTIs. Once this port receives a configuration BPDU with a higher priority from an MSTI, it immediately sets that port to the listening state in the MSTI, without forwarding the packet (this is equivalent to disconnecting the link connected to this port in the MSTI). If the port receives no BPDUs with a higher priority within twice the forwarding delay, it will revert to its original state. Make this configuration on a designated port.
To enable root guard:
  1. Enter system view and use the command
    system-view
  2. Enter interface view or port group view
    • Enter Layer 2 Ethernet interface view or Layer 2 aggregate interface view
      interface interface-type interface-number
    • Enter port group view
      port-group manual portgroup- name
  3. Enable the root guard function for the ports
    stp root-protection
Among loop guard, root guard and edge port settings, only one function (whichever is configured the earliest) can take effect on a port at the same time.
Enabling loop guard
By keeping receiving BPDUs from the upstream device, a device can maintain the state of the root port and blocked ports. However, because of link congestion or unidirectional link failures, these ports may fail to receive BPDUs from the upstream devices. The device will reselect the port roles: Those ports in forwarding state that failed to receive upstream BPDUs will become designated ports, and the blocked ports will transition to the forwarding state, resulting in loops in the switched network. The loop guard function can suppress the occurrence of such loops.
The initial state of a loop guard-enabled port is discarding in every MSTI. When the port receives BPDUs, its state transitions normally; otherwise, it stays in the discarding state to prevent temporary loops.
Make this configuration on the root port and alternate ports of a device.
To enable loop guard:
  1. Enter system view and use the command
    system-view
  2. Enter interface view or port group view
    • Enter Layer 2 Ethernet interface view or Layer 2 aggregate interface view
      interface interface-type interface-number
    • Enter port group view
      port-group manual portgroup- name
  3. Enable the loop guard function for the ports
    stp loop-protection
Do not enable loop guard on a port connecting user terminals. Otherwise, the port will stay in the discarding state in all MSTIs because it cannot receive BPDUs. Among loop guard, root guard and edge port settings, only one function (whichever is configured the earliest) can take effect on a port at the same time.
Enabling TC-BPDU guard
When receiving TC BPDUs (the BPDUs used to notify topology changes), a switch flushes its forwarding address entries. If someone forges TC-BPDUs to attack the switch, the switch will receive a large number of TC-BPDUs within a short time and be busy with forwarding address entry flushing. This affects network stability.
With the TC-BPDU guard function, the user can set the maximum number of immediate forwarding address entry flushes that the switch can perform within a certain period of time after receiving the first TC-BPDU. For TC-BPDUs received in excess of the limit, the switch performs forwarding address entry flush only when the time period expires. This prevents frequent flushing of forwarding address entries.
To enable TC-BPDU guard:
  1. Enter system view and use the command
    system-view
  2. Enable the TC-BPDU guard function
    stp tc-protection enable
  3. Configure the maximum number of forwarding address entry flushes that the device can perform every 10 seconds
    stp tc-protection threshold number

Read More ...