HP Networking

Window's RADIUS Server - Network Policy Server with HP network devices

[3:41 AM | 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:

Enter a descriptive name for the policy.

Next you need to set the matching conditions for this policy. This example will check on:
- Windows group “net-admins”
- Service-type “login”

First add the Windows group condition:

The test group “net-admins” is selected.

Next add the service-type condition:

For the Service-Type, select “Login”

Verify the 2 conditions:

Leave the access permission to “access granted“

Admin logins are basic RADIUS login requests, so make sure to enable the clear text PAP/SPAP methods:

No other constraints need to be configured:

In the settings which will be applied, select the “Vendor Specific” category.

Select the vendor “Cisco” and the “Cisco-AV-Pair” Attribute:

For the attribute value, set shell:roles=”network-admin”

Review the Vendor Specific settings and finish the wizard.

In the Network policy list, make sure the new policy is placed in front of the block all default policies:

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:

RADIUS network trace

In the network trace, the access request shows the service-type login

And the access accept shows the assigned network role

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/

MTU Size Issues

[7:39 PM | 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.

Refer to http://www.networkworld.com/article/2224654/cisco-subnettu-size-issues/cisco-subnet/mtu-size-issues.html

[8:50 PM | 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/

[1:09 AM | 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:

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.
Spanning-tree BPDUs from other network segments or spanning-tree regions with the appropriate flags set to instigate a topology change.
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.

[7:44 PM | 0 comments ]

Configuring an MST region

To configure an MST region:

Enter system view and use the command

system-view
Enter MST region view and use the command

stp region-configuration
Configure the MST region name and use the command

region-name name

NOTE: Optional. The MST region name is the MAC address by default.
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.
Configure the MSTP revision level of the MST region and use the command

revision-level level
Display the MST region configurations that are not activated yet and use the command

check region-configuration
Activate MST region configuration manually and use the command

active region-configuration
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:

Enter system view and use the command

system-view
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:

Enter system view and use the command

system-view
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:

Enter system view and use the command

system-view
Configure the work mode of MSTP

stp mode { stp | rstp | mstp }

Link Speed	Link Speed	Path Cost
Link Speed	Link Speed	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

Information

Details

Configuring an MST region

Configuring the root bridge or a secondary root bridge

Configuring the work mode of an MSTP device

Configuring the device priority

Configuring the maximum hops of an MST region

Configuring the network diameter of a switched network

Configuring timers of MSTP

Configuring the timeout factor

Configuring the maximum port rate

Configuring ports as edge ports

Configuring path costs of ports

Configuring the port priority

Configuring the port link type

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

Enabling the output of port state transition information

Enabling MSTP feature

Performing mCheck

Configuring digest snooping

Configuring no agreement check

Configuring TC snooping

Configuring protection functions

Introduce myself

Chat Box

Google Maps

Visitor Locations

Lunar Calendar

Link URL

Followers

Tham khảo Blogroll