53-1003036-02 09 December, 2013 Multi-Service IronWare Switching Configuration Guide Supporting Multi-Service IronWare R05.6.
Copyright © 2013 Brocade Communications Systems, Inc. All Rights Reserved. ADX, AnyIO, Brocade, Brocade Assurance, the B-wing symbol, DCX, Fabric OS, ICX, MLX, MyBrocade, OpenScript, VCS, VDX, and Vyatta are registered trademarks, and HyperEdge, The Effortless Network, and The On-Demand Data Center are trademarks of Brocade Communications Systems, Inc., in the United States and/or in other countries. Other brands, products, or service names mentioned may be trademarks of their respective owners.
Contents About This Document Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xxv Supported hardware and software . . . . . . . . . . . . . . . . . . . . . . . . . xxvi Supported software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxvi Document conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xxvii Text formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Port loop detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Strict mode and Loose mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Recovering disabled ports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Disable duration and loop detection interval. . . . . . . . . . . . . . . 10 Enabling loop detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Configuring a global loop detection interval . . . . . . . . . . . . .
Chapter 3 Using a Redundant Management Module How management module redundancy works . . . . . . . . . . . . . . . . . 50 Management module redundancy overview . . . . . . . . . . . . . . . 50 Management module switchover . . . . . . . . . . . . . . . . . . . . . . . . 51 Switchover implications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Management module redundancy configuration . . . . . . . . . . . . . . . 53 Changing the default active chassis slot . . . . . . . . . . . . . . . .
General operating principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Operating modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 LLDP packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 TLV support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Configuration considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Using LLDP. . . . . . . . . . . . . .
Deploying a LAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .125 Commands available under LAG once it is deployed . . . . . . .126 Configuring ACL-based mirroring. . . . . . . . . . . . . . . . . . . . . . . .126 Disabling ports within a LAG . . . . . . . . . . . . . . . . . . . . . . . . . . .126 Enabling ports within a LAG . . . . . . . . . . . . . . . . . . . . . . . . . . .127 Adding a Port to Currently Deployed LAG . . . . . . . . . . . . . . . . .
VLAN configuration rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .167 VLAN ID range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .167 Tagged VLANs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .167 VLAN hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .167 Multiple VLAN membership rules . . . . . . . . . . . . . . . . . . . . . . .168 Dual-mode default VLAN . . . . . . . . . . . . . . . . . .
Clearing extended VLAN counters . . . . . . . . . . . . . . . . . . . . . . . . . .199 Clearing counters for all VLANs. . . . . . . . . . . . . . . . . . . . . . . . .200 Clearing counters for a specific VLAN. . . . . . . . . . . . . . . . . . . .200 Clearing VLAN and port counters . . . . . . . . . . . . . . . . . . . . . . .200 Clearing VLAN counters on a port with a specific priority . . . .200 Clearing extended counters statistics on a port . . . . . . . . . . .
Application of a standalone ESI . . . . . . . . . . . . . . . . . . . . . . . . . . . .229 Flood domain and VLAN translation . . . . . . . . . . . . . . . . . . . . .229 Configuring a flood domain with VLAN translation . . . . . . . . .230 Chapter 9 IEEE 802.1ad - Provider Bridges for the Brocade NetIron CES and Brocade NetIron CER About IEEE 802.1ad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .233 IEEE 802.1ad Provider Bridging limitations . . . . . . . . . . . . . . .
Adding and removing VLANs and ESIs. . . . . . . . . . . . . . . . . . . . . . .269 Valid ESI configuration and interconnection modes . . . . . . . .272 Uniqueness requirements for VLANs . . . . . . . . . . . . . . . . . . . .273 Chapter 11 Provider Backbone Bridging (PBB) Networks for the Brocade NetIron XMR and the Brocade MLX series Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .277 Provider Backbone Bridges . . . . . . . . . . . . . . . . . . . . . .
SuperSpan™ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .336 Customer ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .336 BPDU forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .337 Preforwarding state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .337 Combining single STP and multiple spanning trees . . . . . . . .338 Configuring SuperSpan . . . . . . . . . . . . . . . . . . . . . . .
Convergence in a simple topology . . . . . . . . . . . . . . . . . . . . . . . . . .423 Convergence at start up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .423 Convergence after a link failure . . . . . . . . . . . . . . . . . . . . . . . .426 Convergence at link restoration . . . . . . . . . . . . . . . . . . . . . . . .427 Convergence in a complex RSTP topology. . . . . . . . . . . . . . . . . . . .428 Propagation of topology change . . . . . . . . . . . . . . . . . . . . . . . .
MRP Phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .489 Ring interface ownership. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .491 Ring interface IDs and types . . . . . . . . . . . . . . . . . . . . . . . . . . .492 Selection of the master node for a ring . . . . . . . . . . . . . . . . . .493 RHP processing in rings with shared interfaces . . . . . . . . . . .495 How ring breaks are detected and healed between shared interfaces. . . . . . . . . . .
ERP commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .531 Assigning ERP IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .531 Naming an Ethernet Ring Node . . . . . . . . . . . . . . . . . . . . . . . .531 Configuring the default MAC ID. . . . . . . . . . . . . . . . . . . . . . . . .532 Configuring R-APS MEL value . . . . . . . . . . . . . . . . . . . . . . . . . .532 Configuring R-APS topology change propagation . . . . . . . . . .
Displaying VSRP information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .572 Displaying VRID information . . . . . . . . . . . . . . . . . . . . . . . . . . .572 Displaying the active interfaces for a VRID . . . . . . . . . . . . . . .575 VSRP fast start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .575 VSRP slow start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .577 VSRP and Foundry MRP signaling . . . . . . . . . . . . .
L2VPN support for L2 MCT clusters. . . . . . . . . . . . . . . . . . . . . . . . .666 Support for non-direct ICL . . . . . . . . . . . . . . . . . . . . . . . . . . . . .666 L2VPN timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .667 Cluster CCP session rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . .667 Handling L2VPN spoke down . . . . . . . . . . . . . . . . . . . . . . . . . .668 CCP down handling when both L2 and L2VPN exist . . . . . . . .
Chapter 19 Configuring IP The IP packet flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .702 ARP cache table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .703 Static ARP table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .703 IP route table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .704 IP forwarding cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring ARP parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 748 How ARP works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749 Rate limiting ARP packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . .750 Changing the ARP aging period. . . . . . . . . . . . . . . . . . . . . . . . .751 Enabling proxy ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .751 Enabling local proxy ARP . . . . . . . . . . . . . . . . . . . . . .
Configuring static routes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .783 Static route types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .784 Static IP route parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . .784 Multiple static routes to the same destination provide load sharing and redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .785 Static route states follow port states . . . . . . . . . . . . . . . . . . .
Displaying IP information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .833 Displaying IP interface information. . . . . . . . . . . . . . . . . . . . . .834 Displaying interface name in Syslog. . . . . . . . . . . . . . . . . . . . .837 Displaying ARP entries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .837 Displaying the forwarding cache . . . . . . . . . . . . . . . . . . . . . . . .839 Dual Active Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 22 Reverse Path Forwarding RPF configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .878 Configuration considerations for RPF. . . . . . . . . . . . . . . . . . . .878 Special considerations for configuring RPF on Brocade NetIron CES and Brocade NetIron CER devices. .878 Special considerations for configuring RPF with ECMP routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .879 RPF support for IP over MPLS routes . . . . . . . . . . . .
Chapter 24 Configuring Uni-Directional Link Detection (UDLD) Configuration considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .908 Configuring UDLD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .908 Changing the keepalive interval . . . . . . . . . . . . . . . . . . . . . . . .908 Changing the keepalive retries . . . . . . . . . . . . . . . . . . . . . . . . .908 UDLD for tagged ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xxiv Multi-Service IronWare Switching Configuration Guide 53-1003036-02
About This Document In this chapter • Audience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxv • Supported hardware and software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxvi • Document conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxvii • Notice to the reader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxviii • Related publications . . .
Supported hardware and software The following hardware platforms are supported by this release of this guide: TABLE 1 Supported devices Brocade NetIron XMR Series Brocade MLX Series NetIron CES 2000 and NetIron CER 2000 Series Brocade NetIron XMR 4000 Brocade MLX-4 Brocade NetIron CES 2024C Brocade NetIron XMR 8000 Brocade MLX-8 Brocade NetIron CES 2024F Brocade NetIron XMR 16000 Brocade MLX-16 Brocade NetIron CES 2048C Brocade NetIron XMR 32000 Brocade MLX-32 Brocade NetIron CES 2048CX Br
Document conventions This section describes text formatting conventions and important notice formats used in this document.
Notice to the reader This document may contain references to the trademarks of the following corporations. These trademarks are the properties of their respective companies and corporations. These references are made for informational purposes only.
Getting technical help or reporting errors To contact Technical Support, go to http://www.brocade.com/services-support/index.page for the latest e-mail and telephone contact information.
xxx Multi-Service IronWare Switching Configuration Guide 53-1003036-02
Chapter 1 Configuring Interface Parameters Table 2 displays the individual Brocade devices and the IP features they support.
1 Assigning a port name TABLE 2 Supported Brocade IP features (Continued) Features supported Brocade NetIron XMR Series Brocade MLX Series Brocade NetIron CES 2000 Series BASE package Brocade NetIron CES 2000 Series ME_PREM package Brocade NetIron CES 2000 Series L3_PREM package Brocade NetIron CER 2000 Series Base package Brocade NetIron CER 2000 Series Advanced Services package Link Fault Signaling Yes Yes Yes Yes Yes Yes Yes 10G Port Local Fault Yes Yes No No No No No LFS or R
Assigning an IP address to a port 1 The text parameter is an alphanumeric string. The name can have up to 255 characters on a Brocade device and can include blanks. You do not need to use quotation marks around the string, even when it contains blanks. Assigning an IP address to a port To assign an IP address to an interface, enter the following commands. Brocade(config)# interface e 1/8 Brocade(config)# ip address 10.45.6.110 255.255.255.
1 Modifying port mode NOTE An auto negotiation port must be connected to another auto negotiation port. If you connect an auto negotiation port to a fixed speed or duplex port, the behavior is undefined. Also, ports must be disabled before changing speed. Modifying port mode You can configure a port to accept either full-duplex (bi-directional) or half-duplex (uni-directional) traffic. Port duplex mode and port speed are modified by the same command.
Disabling or re-enabling a port 1 Brocade(config)# interface e 1/8 Brocade(config-if-e10000-1/8)# auto Brocade(config-if-e10000-1/8)# link-config gig copper autoneg-control down-shift Syntax: [no] link-config gig copper autoneg-control [down-shift|100m|10m] The 10m option will limit the port to negotiation to speeds and duplex of 10mb. The 100m option will limit the port to negotiation of speeds and duplex below 100mb.
1 Changing the default Gigabit negotiation mode Changing the default Gigabit negotiation mode You can configure the default Gigabit negotiation mode to be one of the following: • neg-full-auto – The port is only for copper-SFP and to support 10/100/1000M tri-speed auto negotiation. • auto-full -- The port tries to perform a negotiation with its peer port to exchange capability information. If it is unable to reach an agreed upon speed, the port goes into a fixed speed and keeps the link up.
Modifying port priority (QoS) 1 Modifying port priority (QoS) You can give preference to the inbound traffic on specific ports by changing the Quality of Service (QoS) level on those ports. For information and procedures, refer to the Configuring Quality of Service for the Brocade NetIron XMR and Brocade MLX series Chapter in the Multi-Service IronWare Traffic Management Configuration Guide. Setting IP VPN packets with a TTL value of 1 to be dropped This command is for IP VPN packets only.
1 Port flap dampening The time parameter is the number of 50-ms units. The default is 0. The valid range is from 0 to 200. The up parameter means only “up” events are delayed. The down parameter means that only the down events are delayed. If neither the up or down parameter is specified, both up and down events are delayed. This is the default. Port flap dampening The port flap dampening feature allows you to configure a wait period before a port, whose link goes down then up, becomes enabled.
Port flap dampening 1 Re-enabling a port disabled by port link dampening A port disabled by the port link dampening is automatically re-enabled once the wait period expires; however, if the wait period is set to zero (0) seconds or you want to re-enable the port before the configured wait period expires, you must re-enable the port by entering the link-error-disable command on the disabled port as shown in the following.
1 Port loop detection Port loop detection This feature allows the Brocade device to disable a port that is on the receiving end of a loop by sending test packets. You can configure the time period during which test packets are sent. Strict mode and Loose mode There are two types of loop detection; Strict Mode and Loose Mode. In Strict Mode, a port is disabled only if a packet is looped back to that same port. Strict Mode overcomes specific hardware issues where packets are echoed back to the input port.
Port loop detection 1 The following information applies to Strict Mode loop detection: • A port is disabled only if a packet is looped back to that same port. • Loop detection must be configured on the physical port. • Strict Mode overcomes specific hardware issues where packets are echoed back to the input port. NOTE Brocade recommends that you limit the use of Loose Mode.
1 Port loop detection Configuring a global loop detection interval The loop detection interval specifies how often a test packet is sent on a port. When loop detection is enabled, the loop detection time unit is 0.1 second, with a default of 10 (one second). The range is from 1 (one tenth of a second) to 100 (10 seconds). You can use the show loop-detection status command to view the loop detection interval. To configure the global loop detection interval, enter a command such as the following.
Port loop detection 1 Displaying loop-detection information Use the show loop-detection command to display the loop detection status.
1 Mirroring and Monitoring Mirroring and Monitoring You can monitor traffic on Brocade device ports by configuring another port to “mirror” the traffic on the ports you want to monitor. By attaching a protocol analyzer to the mirror port, you can observe the traffic on the monitored ports. Monitoring traffic on a port is a two-step process: • Enable a port to act as the mirror port. This is the port to which you connect your protocol analyzer. • Enable monitoring on the ports you want to monitor.
Mirroring and Monitoring 1 Brocade(config)# mirror-port ethernet 3/1 Syntax: [no] mirror-port ethernet slot/portnum NOTE If a port is configured as a mirror port, all traffic sent from that port will retain the encapsulation of the port being monitored and not add the encapsulation of the Egress port. Enter the slot and port number of the port that will be the mirrored.
1 ACL-based inbound mirroring This output displays the output traffic mirrored to mirror port 1/1 from port 3/1 and input traffic mirrored to mirror port 1/2 from port 4/1, which are explicitly configured. ACL-based inbound mirroring The Multi-Service IronWare software supports using an ACL to select traffic for mirroring from one port to another. Using this feature, you can monitor traffic in the mirrored port by attaching a protocol analyzer to it.
ACL-based inbound mirroring 1 Brocade(config)# enable-acl-cam-sharing Brocade(config)# interface ethernet 4/1 Brocade(config-if-e10000-4/1)# ip access-group 101 in Brocade(config-if-e10000-4/1)# acl-mirror-port ethernet 6/1 Brocade(config-if-e10000-4/1)# interface ethernet 4/2 Brocade(config-if-e10000-4/2)# ip access-group 101 in Configuring ACL-based inbound mirroring The following sections describe how to configure ACL-based Inbound Mirroring on a Brocade device: • • • • • • • Creating an ACL with a
1 ACL-based inbound mirroring Applying the ACL to an interface You must apply the ACL to an interface using the ip access-group command as shown in the following. Brocade(config)# interface ethernet 1/1 Brocade(config-if-e10000-1/1)# ip access-group 101 in Specifying the destination mirror port You can specify physical ports or a LAG to mirror traffic from. The following sections describe how to perform each of these configurations.
1 ACL-based inbound mirroring The following considerations apply when configuring ACL-based mirroring with LAGs: • You must configure ACL-mirroring for an individual member port from the LAG configuration level. Attempting to configure ACL-mirroring at the interface level for an individual member port will fail and display the following message. Error: please use config level to configure ACL based mirroring on port.
1 10G WAN PHY fault and performance management Brocade(config)# lag mylag Brocade(config-lag-mylag)# Brocade(config-lag-mylag)# Brocade(config-lag-mylag)# Brocade(config-lag-mylag)# static ports ethernet 10/1 to 10/4 primary-port 10/1 deploy acl-mirror-port ethe-port-monitored 10/2 ethe 11/3 Brocade(config)# vlan 10 Brocade(config-vlan-10)# tagged ethe 10/1 to 10/4 Brocade(config-vlan-10)# router-interface ve 10 The ACL-based mirroring will apply to VLAN 10 traffic incoming on ports 10/1 and 10/2 since
10G WAN PHY fault and performance management 1 Turning alarm interfaces on and off When a 10 GbE port is to WAN PHY mode, alarm monitoring is set on by default. You can turn alarm monitoring off for an individual port as shown in the following.
1 10G WAN PHY fault and performance management The curr15min parameter specifies that you want to display WAN PHY alarm and performance information for the current 15 minute interval for either the port number port no or slot number slot no specified. The day parameter specifies that you want to display WAN PHY alarm and performance information for the current day for either the port number port no or slot number slot no specified.
10G WAN PHY fault and performance management TABLE 5 1 WAN PHY display parameters (Continued) Parameter Description. Alarm indication signal (AIS) The AIS is an all-ones characteristic or adapted information signal. It is generated to replace the normal traffic signal when it contains a defect condition in order to prevent consequential downstream failures being declared or alarms being raised.
1 10G WAN PHY fault and performance management TABLE 5 24 WAN PHY display parameters (Continued) Parameter Description. Severely Errored seconds (SES) At each layer, an Severely Errored Second (SES) is a second with x or more CVs at that layer, or a second during which at least one or more incoming defects at that layer has occurred. Values of x vary depending on the line rate and the Bit Error Rate.
Wait for all cards feature 1 Wait for all cards feature During a system reload, an Interface module comes up after it completes its initialization process. After an Interface module is up, its ports can come up. Since 10G modules have more packet processors to initialize, 1G ports are up earlier than 10G ports. NOTE Rebooting interface modules manually is not supported. The wait for all cards feature will only take effect when the entire router or switch is rebooted.
1 Link fault signaling There are two independent link-fault signaling commands link-fault-signaling and link-fault-signaling ignore-rx. These commands are applicable at both the global (system-level) and per-port level. Both global and per-port configurations are considered jointly to determine the resulting per-port configuration. When a global configuration is applied, it will override the corresponding per-port configuration already present.
Link fault signaling 1 Brocade(config)# interface e 3/1 Brocade(config-if-e100000-3/1)#link-fault-signaling ignore-rx Brocade(config-if-e100000-3/1)#show run Current configuration: ! ver V5.4.0iT163 module 1 ni-mlx-8-port-10g-m module 3 ni-mlx-8-port-10g-m ! link-fault-signaling ! interface ethernet 3/1 link-fault-signaling ignore-rx ! TX LFS is enabled on all ports.
1 Link fault signaling PORT 2/1: PORT 2/2: RX ON RX ON TX ON TX ON TX LFS is enabled on all ports and RX LFS is enabled on all ports. Brocade(config)#int e 2/1 Brocade(config-if-e10000-2/1)#no link-fault-signaling Brocade(config-if-e10000-2/1)#show run Current configuration: ! ver V5.3.
Link fault signaling 1 Example Configuring RX LFS on all ports and enabling TX LFS on one port Brocade(config)#show run Current configuration: ! ver V5.3.0pT183 ! no spanning-tree ! vlan 1 name DEFAULT-VLAN ! hostname Brocade ! end Brocade(config)#show link-fault-signaling Global Link Fault : RX ON TX OFF PORT #: LINK FAULT: PORT 2/1: PORT 2/2: RX ON RX ON TX OFF TX OFF TX LFS is disabled on all ports and RX LFS is enabled on all ports.
1 Link fault signaling ! no spanning-tree ! vlan 1 name DEFAULT-VLAN ! hostname Brocade link-fault-signaling ! interface ethernet 2/1 link-fault-signaling ignore-rx ! end Brocade(config)#show link-fault-signaling Global Link Fault : RX ON TX ON PORT #: LINK FAULT: PORT 2/1: PORT 2/2: RX OFF RX ON TX ON TX ON TX LFS is enabled on all ports and RX LFS is enabled on all ports except 2/1.
Displaying and clearing remote fault counters 1 Displaying and clearing remote fault counters To display Remote Fault Notification (RFN) counters on 10GbE LAN physical interface, enter the following command.
1 Local fault event detection and counters Limits and restrictions Current implementation with this feature has the following limitations: • Works only on a 10GbE LAN interface. Information for ports in a WAN interface at the time of inquiry is not displayed. Information for a port that does not belong to 10 GbE module is not displayed. • In a Management Module switchover state, the remote fault notification counts and detection time are maintained.
Displaying Network Processor statistics 1 Or use the to option for a range of ports. Use the slot option to limit the display to a single slot. The following table describes the output of the show local-fault command. TABLE 7 Display of show local-fault output This field... Displays... Port The variable specifies the port number for the interface module. Local Fault Detected The local-fault is detected on a given interface.
1 Displaying Network Processor statistics NP NP NP NP NP NP Rx Rx Rx Rx Rx Rx IPv6 Packet Route-only Drop IPv6 Suppress RPF Drop IPv6 RPF Drop Count IPv4 Byte IPv6 Byte = = = = = = (0) (0) (0) (0) (0) (0) NP Rx Routed Packet Drop = (0) Port 10/4 TX NP Tx Sent to MAC Packet NP Tx Raw Good Packet NP Tx Source Port Supress Drop NP Tx Bad Packet Count NP Tx Unicast Packet NP Tx Broadcast Packet NP Tx Multicast Packet NP Tx IPX HW Forwarded Packet NP Tx Receive from TM NP Tx ACL Drop NP Tx IPv4 Packet N
Displaying Network Processor statistics 1 You can use the slot option and specify a variable to display NP statistics for an individual interface module. For Brocade NetIron CES and Brocade NetIron CER, you can either use show np statistics command or show np statistics [slot ] command to display the NP statistics for an interface in a specified slot. The Tx and Rx counters displayed are described in the following tables.
1 Displaying Network Processor statistics TABLE 9 Tx counters TX counter (per port) Explanation Tx Sent to MAC Packet Total number of packets sent to MAC for transmit Tx Raw Good Packet Total number of packets sent to egress processing logic that pass the initial length checks (min, max, offsets, bad packet etc.
Displaying Network Processor statistics TABLE 11 1 Relationships between TX counters Tx Raw Good Packets = = Tx Receive From TM Packets - Tx Bad Packets Tx Unicast Packets + Tx Broadcast Packets + Tx Multicast Packets + Tx Source Port Suppression Drop Tx Sent to MAC = = Tx IPv4 Packets + Tx IPv6 Packets + Tx Others Tx Raw Good Packets – Tx Source Port Suppression Drop – Tx ACL drop - Tx RL Drop – Tx Multicast TTL drop Clearing the NP statistics counters You can clear the NP statistics counters for
1 38 Displaying Network Processor statistics Multi-Service IronWare Switching Configuration Guide 53-1003036-02
Chapter 2 Enabling the Foundry Discovery Protocol (FDP) and Reading Cisco Discovery Protocol (CDP) Packets Table 12 displays the individual devices and the Foundry Discovery Protocol (FDP) and Reading Cisco Discovery Protocol (CDP) Packets features they support.
2 Using FDP • • • • Hostname (device ID) Product platform and capability Software version VLAN and Layer 3 protocol address information for the port sending the update. A device running FDP sends FDP updates on Layer 2 to MAC address 01-E0-52-CC-CC-CC. Other devices listening on that address receive the updates and can display the information in the updates. NOTE FDP is disabled by default on Brocade devices.
Using FDP 2 NOTE FDP is not supported on VPLS/VLL endpoints. By removing FDP from the configuration, the no fdp enable will stay in the configuration. Changing the FDP update timer By default, a device enabled for FDP sends an FDP update every 60 seconds. You can change the update timer to a value from 5 – 900 seconds. To change the FDP update timer, enter a command such as the following at the global CONFIG level of the CLI.
2 Using FDP Displaying neighbor information To display a summary of all the neighbors that have sent FDP updates to this device, enter the following command.
Using FDP TABLE 14 2 Detailed FDP and CDP neighbor information This line... Displays... Device ID The hostname of the neighbor. In addition, this line lists the VLAN memberships and other VLAN information for the neighbor port that sent the update to this device. Entry address(es) The Layer 3 protocol addresses configured on the neighbor port that sent the update to this device. If the neighbor is a Layer 2 Switch, this field lists the management IP address.
2 Reading CDP packets The ethernet slot/portnum parameter lists the FDP information. Displaying FDP and CDP statistics To display FDP and CDP packet statistics, enter the following command.
Reading CDP packets 2 NOTE The device can interpret only the information fields that are common to both CDP version 1 and CDP version 2. NOTE When you enable interception of CDP packets, the device drops the packets. As a result, Cisco devices will no longer receive the dropped packets. Enabling interception of CDP packets globally To enable the device to intercept and display CDP packets, enter the following command at the global CONFIG level of the CLI.
2 Reading CDP packets • CDP entries for all Cisco neighbors or a specific neighbor • CDP packet statistics Displaying neighbors To display the Cisco neighbors the device has learned from CDP packets, enter the following command.
Reading CDP packets 2 Brocade# show fdp entry * Device ID: Router Entry address(es): IP address: 10.95.6.143 Platform: cisco RSP4, Capabilities: Router Interface: Eth 1/1, Port ID (outgoing port): FastEthernet5/0/0 Holdtime : 124 seconds Version : Cisco Internetwork Operating System Software IOS (tm) RSP Software (RSP-JSV-M), Version 12.0(5)T1, RELEASE SOFTWARE (fc1) Copyright (c) 1986-1999 by cisco Systems, Inc.
2 Reading CDP packets Brocade# clear fdp table Syntax: clear fdp table To clear CDP statistics, enter the following command.
Chapter 3 Using a Redundant Management Module Table 15 displays the individual Brocade devices and the Redundant Management Module features they support.
3 How management module redundancy works You can install a redundant management module in slot M1 or M2 of a Brocade chassis. (By default, the system considers the module in slot M1 to be the active management module and the module in slot M2 to be the redundant, or standby module. If the active module becomes unavailable, the standby module automatically takes over management of the system.
How management module redundancy works 3 failover. Brocade devices support Layer 3 hitless failover with restart for high-availability routing in protocols such as BGP and OSPF. With these high-availability features enabled, when a device experiences a failover or restart, forwarding disruptions are minimized, and route flapping diminished to provide continuous service.
3 How management module redundancy works • An Auxiliary flash card installed in the active management module When the replacement module boots, the system compares the flash code and system-config files on the standby module to the files on the active module. If differences exist, the files on the standby module are synchronized to match those on the active module. Removal and replacement of a standby management module You can remove a standby management module without causing a switchover to occur.
Management module redundancy configuration 3 Management module redundancy configuration Configuring management module redundancy consists of performing one optional task (changing the default active chassis slot) as described in the following section. Changing the default active chassis slot By default, the Brocade system considers the module installed in slot M1 to be the active management module. However, you can change the default active chassis slot to M2 using the active-management command.
3 Managing management module redundancy • secondary, which contains the secondary Multi-Service IronWare image for the management module A Brocade Multi-Service IronWare image contains layer 1 – 3 software used by the management module. During startup or switchover, the flash code on the active module is compared to the flash code on the standby module. If the files differ, the files on the standby module are synchronized to the files on the active module.
Managing management module redundancy FIGURE 1 3 Active and standby management module file synchronization The Brocade system allows you to perform the following file synchronization tasks: • Compare files on the active module with files on the standby module and immediately synchronize any files that are different. • Immediately synchronize all files between the active and standby modules. The following sections explain how to perform these tasks.
3 Managing management module redundancy Brocade# sync-standby Synchronizing files without comparison You can synchronize the flash code, system-config file, and running-config file immediately without comparison. When you synchronize the files, active module files are copied to the standby module, replacing the files on the standby module. To immediately synchronize the files between the active and standby modules, enter the following command at the Privileged EXEC level.
Monitoring management module redundancy 3 Brocade# boot system flash primary Brocade# Are you sure? (enter 'y' or 'n'): y Syntax: [no] boot system bootp | [flash primary | flash secondary] | slot number filename | tftp ip-address filename The flash primary keyword specifies the primary Brocade Multi-Service IronWare image in the management module flash memory. The flash secondary keyword specifies the secondary Brocade Multi-Service IronWare image in the flash memory.
3 Monitoring management module redundancy Status LED You can determine which management module is currently active and which is standby by observing the Active LED on each module. If this LED is on (green), the module is the active module. If this LED is off, the module is the standby module. You can also observe the Pwr LED on each module. If this LED is on (green), the module is receiving power. If the LED is off, the module is not receiving power.
Displaying switchover information 3 Displaying temperature information All management, interface and switch fabric modules contain temperature sensors. By default, the Brocade system polls module temperature every 60 seconds. You can display the current temperature of the modules by entering either of the following commands: • show chassis • show temperature For information about these commands, refer to the appropriate hardware installation guide.
3 Flash memory and Auxiliary Flash card file management commands However, in three previous sessions, switchovers occurred. In sessions #1 and #3, the switchovers occurred because the software was upgraded to “Ver3.7.0T163”. In session #2 the switchover occurred because the active module was rebooted. In sessions #1 and #3, the modules installed in M1 were the active modules, while the modules installed in M2 were the standby modules.
Verifying available flash space on the management module before an image is copied • • • • • • • • • • • • • • • • 3 Format a flash card Determine the current management focus Switch the management focus Display a directory of files Display the contents of a file Display the hexadecimal output of a file Create a subdirectory Remove a subdirectory Rename a file Change the read-write attribute of a file Delete a file Recover (undelete) a file Append one file to another (join two files) Perform copy operati
3 Verifying available flash space on the management module before an image is copied The 32 MB flash space is capable of holding two Brocade NetIron CES or Brocade NetIron CER images (image size is about 11 MB). However, during the TFTP copy operation, it needs more buffer space. It is not possible to copy or update an existing image to a 32 MB flash, if there are two images in the flash already. If you try to copy or update an image, the following error message is displayed.
Verifying available flash space on the management module before an image is copied 3 Most file management commands provide the option of specifying the file system to which the command applies. If you want the command to apply to the file system that has the current management focus, you do not need to specify the file system.
3 Verifying available flash space on the management module before an image is copied • # • & Auxiliary flash card file system The Auxiliary flash card file system is hierarchical, which means that it supports subdirectories. Therefore, you can create or delete subdirectories in this file system using the md/mkdir and rd/rmdir commands, respectively.
Verifying available flash space on the management module before an image is copied • • • • 3 } ^ # & You can use spaces in a file or subdirectory name if you enclose the name in double quotes. For example, to specify a subdirectory name that contains spaces, enter a string such as the following: “a long subdirectory name”. A subdirectory or file name can be a maximum of 256 characters long. A complete subdirectory path name cannot contain more than 256 characters. There is no maximum file size.
3 Verifying available flash space on the management module before an image is copied To reformat a flash card in slot 2 on the management module, for example, enter the following command. Brocade# format slot2 ....................................................... ....................................................... ....................................................... ...................................... 80809984 bytes total card space. 80809984 bytes available on card.
Verifying available flash space on the management module before an image is copied 3 Brocade# cd /slot2 Device not present Syntax: cd directory-pathname Syntax: chdir directory-pathname For the directory-pathname parameter for both cd and chdir commands, specify /slot1 or /slot2 to switch the focus to slot 1 or slot 2, respectively. Specify /flash to switch the focus to flash memory.
3 Verifying available flash space on the management module before an image is copied For example, to display a directory of the files in flash memory, if flash memory has the management focus, enter the following command.
Verifying available flash space on the management module before an image is copied 3 For example, to display a directory of the files on the flash card in slot 2, if flash memory has the management focus, enter the following command.
3 Verifying available flash space on the management module before an image is copied For example, to display the contents of a file in flash memory, if flash memory has the current management focus, enter a command such as the following. Brocade# more cfg.cfg Syntax: more [/directory/]file-name Use the directory parameter to specify a directory in a file system that does not have current management focus. Use the path-name parameter to specify the file you want to display.
Verifying available flash space on the management module before an image is copied 3 For example, to create a subdirectory on the flash card inserted in slot 2, if the flash memory has current management focus, enter a command such as the following. Brocade# mkdir slot2 TEST Syntax: [no] md | mkdir [slot1 | slot2] dir-name You can enter either md or mkdir for the command name. Specify the slot1 or slot2 keyword to create a subdirectory on the flash card in slot 1 or slot 2, respectively.
3 Verifying available flash space on the management module before an image is copied Brocade# chdir /slot2/TEST Current directory of slot2 is: /TEST For information about changing the directory using the cd and chdir commands, refer to “Switching the management focus”. Removing a subdirectory You can remove a subdirectory from the flash card file system using the rd and rmdir commands, which have the same syntax and function exactly the same.
Verifying available flash space on the management module before an image is copied 3 The software renames the file in the file system that has the current management focus flash memory by default. However, you do not need to change the focus to rename the file in a file system that does not currently have management focus. In this case, you can specify the /directory/old-file-name /directory/new-file-name parameter with the rename or mv command to rename the file in the desired file system.
3 Verifying available flash space on the management module before an image is copied The software will change the read-write attribute of the file in the file system that has the current management focus (flash memory by default). However, you do not need to change the focus to change this file attribute in a file system that does not currently have management focus.
Verifying available flash space on the management module before an image is copied 3 The directory parameter specifies the directory in a file system that does not have the current management focus. The file-name parameter specifies the file that you want to delete. For example, to delete all files with names that start with “test” from flash memory, if flash memory has the current management focus, enter a command similar to the following. Brocade# delete test*.
3 Verifying available flash space on the management module before an image is copied To end the undelete process, enter CTRL + C. Appending a file to another file You can append a file in flash memory or on a flash card to the end of another file in one of these file systems. The software will append one file to another in the file system that has the current management focus (flash memory by default).
Verifying available flash space on the management module before an image is copied 3 • Copy a startup-config file between flash memory on the management module and a TFTP server • Copy the running-config to a flash card or a TFTP server • Load a running-config from a flash card or TFTP server into the running-config on the device NOTE Since the copy options require you to explicitly specify the flash card, you can perform a copy regardless of which flash card is on the currently active management module
3 Verifying available flash space on the management module before an image is copied Specify the optional standby keyword to copy the Brocade Multi-Service IronWare image from the secondary location in flash memory on the active management module to the primary location in flash memory on the standby module.
Verifying available flash space on the management module before an image is copied 3 Copying the startup-config file between a flash card and flash memory Use the following methods to copy a startup-config file between flash memory and a flash card. By default, the Brocade device uses the startup-config in the primary area of flash memory when you boot or reload the device. NOTE The Brocade device cannot configure from a startup-config file on a flash card. You cannot boot or reload from a flash card.
3 Verifying available flash space on the management module before an image is copied To copy the running configuration for the device into a file on a flash card, enter a command similar to the following. Brocade# copy running-config slot1 runip.1 Syntax: copy running-config slot1 | slot2 [/to-dir-path/]to-name To copy the running configuration for the device into a file on a TFTP server, enter a command such as the following. Brocade# copy running-config tftp 10.10.10.1 runip.
Verifying available flash space on the management module before an image is copied 3 • Copy files from flash memory to a flash card or vice versa • Copy files from one flash card to another flash card The software will copy a file in a file system to another location in the file system that has the current management focus (flash memory by default). However, you do not need to change the focus to copy a file from one location to another in a file system that does not currently have management focus.
3 Verifying available flash space on the management module before an image is copied Rebooting from the system To use a source besides the Multi-Service IronWare image in the primary location in flash memory for a single reboot, enter a command similar to the following at the Privileged EXEC level of the CLI. Brocade# boot system slot1 /slot1/xmr03000.bin The command in this example reboots the system using the image xmr03000.bin located on the flash card in slot 1.
Verifying available flash space on the management module before an image is copied 3 Syntax: boot system slot1 file-name | slot2 file-name | flash secondary | tftp ip-address file-name | bootp NOTE The command syntax is the same for immediately reloading and for changing the primary source, except the file-name must be the full path name. You cannot specify a relative path name.
3 Verifying available flash space on the management module before an image is copied Specify the dir-path-name parameter if you want to save the configuration changes to a directory other than the root directory of a flash card file system. The file-name parameter indicates the name of the saved configuration file. To change the save location back to flash memory, enter a command similar to the following. Brocade# locate startup-config flash-memory router1.
Chapter 4 Configuring LLDP Table 19 displays the individual devices that support the Link Layer Discovery Protocol, the Foundry Discovery Protocol (FDP), Reading Cisco Discovery Protocol (CDP) Packets, and related feature support.
4 General operating principles Figure 2 illustrates LLDP connectivity. FIGURE 2 LLDP connectivity General operating principles LLDP use the services of the Data Link sub layers, Logical Link Control and Media Access Control, to transmit and receive information to and from other LLDP Agents (protocol entities that implement LLDP). LLDP is a one-way protocol.
General operating principles 4 Transmit mode An LLDP agent sends LLDP packets to adjacent LLDP-enabled devices. The LLDP packets contain information about the transmitting device and port. An LLDP agent initiates the transmission of LLDP packets whenever the transmit countdown timing counter expires, or whenever LLDP information has changed. When a transmit cycle is initiated, the LLDP manager extracts the MIB objects and formats this information into TLVs.
4 General operating principles General system information TLVs are optional in LLDP implementations and are defined by the Network Administrator.
General operating principles TABLE 20 4 Chassis ID subtypes (Continued) ID Subtype Description 3 Port component 4 MAC address 5 Network address 6 Interface name 7 Locally assigned 8 – 255 Reserved Brocade devices use Chassis ID subtype 4, the base MAC address of the device. Other third party devices may use a Chassis ID subtype other than 4. The Chassis ID will appear similar to the following on the remote device, and in the CLI display output on the Brocade device (show lldp local-info).
4 Configuration considerations The TTL value is automatically computed based on the LLDP configuration settings. The TTL value will appear similar to the following on the remote device, and in the CLI display output on the Brocade device (show lldp local-info): Time to live: 40 seconds • If the TTL field has a value other than zero, the receiving LLDP agent is notified to completely replace all information associated with the LLDP agent or port with the information in the received LLDPDU.
Using LLDP 4 Configuring transmit and receive mode To enable receipt and transmission of LLDP packets on individual ports, enter the lldp enable ports ethernet command at the Global CONFIG level of the CLI. The enabled ports are placed into transmit and receive mode by default. Brocade(config)# lldp enable ports ethernet 2/1 Syntax: [no] lldp enable ports ethernet port list | all For port list, specify the ports in the format [slotnum/]portnum, where slotnum is required on chassis devices only.
4 Using LLDP Specifying the maximum number of LLDP neighbors You can change the limit of the number of LLDP neighbors for which LLDP data will be retained, per device as well as per port. Per device To change the maximum number of neighbors for which LLDP data is retained for the entire system, use the lldp max-total-neighbors command. The default number of LLDP neighbors per device is 392.
Using LLDP 4 Enabling LLDP SNMP notifications and Syslog messages SNMP notifications and Syslog messages for LLDP provide data updates and general status. When LLDP SNMP notifications are enabled, corresponding Syslog messages are enabled as well. When LLDP SNMP notifications are enabled, the device sends traps and corresponding Syslog messages whenever there are changes to the LLDP data received from neighboring devices. LLDP SNMP notifications and corresponding Syslog messages are disabled by default.
4 Using LLDP NOTE The LLDP transmit delay timer must not be greater than one quarter of the LLDP transmission interval (CLI command lldp transmit-interval). Changing the interval between regular LLDP transmissions The LLDP transmit interval specifies the number of seconds between regular LLDP packet transmissions. When LLDP is enabled, by default, the device waits 30 seconds between regular LLDP packet transmissions. To change the LLDP transmission interval, enter the lldp transmit-interval command.
Using LLDP 4 Syntax: lldp reinit-delay seconds The seconds variable specifies the LLDP re-initialization delay timer with a range of 1 to 10 seconds. LLDP TLVs advertised by the Brocade device When LLDP is enabled on a global basis, the Brocade device automatically advertises the following information, except as specified.
4 Using LLDP Port description The port description TLV identifies the port from which the LLDP agent transmitted the advertisement. The port description is taken from the ifDescr MIB object from MIB-II. By default, the port description is automatically advertised when LLDP is enabled on a global basis. To disable advertisement of the port description, enter the lldp advertise port-description ports ethernet command.
Using LLDP 4 For port list, specify the ports in the format [slotnum/]portnum, where slotnum is required on chassis devices only. You can list all of the ports individually, use the keyword to to specify a range of ports, or a combination of both. To apply the configuration to all ports on the device, use the keyword all instead of listing the ports individually. Note that using the keyword all may cause undesirable effects on some ports.
4 Using LLDP System name The system name is taken from the sysName MIB object. The sysName MIB object corresponds to the name defined with the CLI command hostname. By default, the system name is automatically advertised when LLDP is enabled on a global basis. To disable this advertisement, enter the lldp advertise system-name ports ethernet command.
Using LLDP 4 Port and Protocol VLAN ID The port and protocol VLAN TLV indicates if a port is capable of supporting port and protocol VLANs and whether it is enabled on the port. If port and protocol VLANs are enabled on the port, the advertisement also contains the port and protocol VLAN ID (PPVID). If the port is not capable of supporting port and protocol VLANs, or if the port is not enabled with any port and protocol VLAN, the PPVID number will be zero.
4 Using LLDP Link aggregation Brocade devices advertise link aggregation information about standard link aggregation (LACP) as well as static trunk configuration. By default, link-aggregation information is automatically advertised when LLDP is enabled on a global basis. To disable this advertisement, enter the lldp advertise link-aggregation ports ethernet command.
Using LLDP 4 Note that using the keyword all may cause undesirable effects on some ports. The configuration will be applied to all ports, however, the ports that are not members of any VLAN will not send VLAN name advertisements.Maximum frame size Maximum frame size TLV The maximum frame size TLV provides the maximum 802.3 frame size capability of the port. This value is expressed in octets and includes the four-octet Frame Check Sequence (FCS). The default maximum frame size is 1522.
4 Using LLDP Brocade#show lldp LLDP transmit interval LLDP transmit hold multiplier LLDP transmit delay LLDP SNMP notification interval LLDP reinitialize delay LLDP maximum neighbors LLDP maximum neighbors per port : : : : : : : 10 seconds 4 (transmit TTL: 40 seconds) 1 seconds 5 seconds 1 seconds 392 4 Syntax: show lldp Table 22 describes the information displayed by the show lldp statistics command. TABLE 22 102 Show lldp statistics This field... Displays...
Using LLDP 4 LLDP statistics The show lldp statistics command displays an overview of LLDP neighbor detection on the device, as well as packet counters and protocol statistics. The statistics are displayed on a global and per-port basis. The following shows an example report.
4 Using LLDP This field... Displays... Neighbor entries deleted The number of LLDP neighbors deleted since the last reboot or since the last time the clear lldp statistics all command was issued. This number includes the number of entries deleted after timing out or aging out. Neighbor entries aged out The number of LLDP neighbors dropped on all ports after the time-to-live expired. Note that LLDP entries age out naturally when a port’s cable or module is disconnected or when a port becomes disabled.
Using LLDP 4 This field... Displays... Port ID The identifier for the port. Brocade devices use the permanent MAC address associated with the port as the port ID. Port Description The description for the port. Brocade devices use the ifDescr MIB object from MIB-II as the port description. System Name The administratively-assigned name for the system. Brocade devices use the sysName MIB object from MIB-II, which corresponds to the CLI hostname command setting.
4 Using LLDP Brocade#show lldp neighbors detail ports e 8/13 Local port: 8/13 + Chassis ID (MAC address): 0024.3891.1100 + Port ID (MAC address): 0024.3891.125c + Time to live: 40 seconds + System name : "IxANVL-1" + Port description : "GigabitEthernet8/13" + System description : "Brocade MLXe (System Mode: MLX), IronWare Version V\ 5.3.0T163 Compiled on Jan 3 2012 at 18:01:00 label\ ed as V5.3.00b460" + System capabilities : bridge, router Enabled capabilities: bridge, router + 802.
Resetting LLDP statistics 4 LLDP configuration details The show lldp local-info command displays the local information advertisements (TLVs) that will be transmitted by the LLDP agent. NOTE The show lldp local-info output will vary based on LLDP configuration settings. The following shows an example report. Brocade#show lldp local-info ports ethernet 1/40 Local port: 1/40 + Chassis ID (MAC address): 001b.edb3.f180 + Port ID (MAC address): 001b.edb3.
4 Resetting LLDP statistics If you do not specify any ports or use the keyword all, by default, the system will clear lldp statistics on all ports. You can list all of the ports individually, use the keyword to to specify ranges of ports, or a combination of both. To apply the configuration to all ports on the device, use the keyword all instead of listing the ports individually.
Chapter Brocade NetIron XMR and Brocade MLX Series Link Aggregation 5 NOTE This chapter is applicable only to the Brocade NetIron XMR and Brocade MLX series devices. This chapter describes how to configure Link Aggregation Groups (LAG) for the Brocade NetIron XMR and Brocade MLX series. Beginning with release 03.7.
5 LAG formation rules LAG formation rules The LAG formation rules are mentioned below: • The 10Gx24-DM module ports can only be part of LAGs exclusively consisting of 24x10G ports. A LAG cannot have a mix of 24x10G module ports and any other 10G module ports. • A port can only be a member of one LAG, and that LAG must be static, dynamic or a keep-alive LAG.
LAG formation rules 5 • The router can support up to 256 LAGs, and each LAG can contain up to 64 member ports. • If the router is configured to support 32 LAGs by using the system-max trunk-num command, the maximum number of LAG ports is 64. • If the router is configured to support 64 LAGs by using the system-max trunk-num command, the maximum number of LAG ports is 32. • If the system-max trunk-num is set to 256, the maximum number of LAG ports supported is 8.
5 LAG formation rules • Make sure the device on the other end of the LAG link can support the same number of ports in the link.
LAG load sharing FIGURE 5 5 Examples of multi-slot, multi-port LAG LAG load sharing Brocade devices can be configured for load sharing over a LAG by either of the following methods: • Hash Based Load Sharing • Per Packet Load Sharing Each of these methods, that are described in the following sections, are configured per LAG using the trunk-type command as described in “Configuring load sharing type”.
5 LAG load sharing NOTE TCP or UDP Destination and Source port is used under the following conditions: – Packet is non-fragmented and without option, and packet is a TCP or UDP packet – or the load-balance force-l4-hashing command is configured. • Layer-2 packets with an MPLS payload: source MAC address and destination MAC address, VLAN ID, Inner VLAN ID (for double-tagged packets), Ethertype, and up to 3 MPLS Labels.
LAG load sharing 5 NOTE TCP or UDP Destination and Source port is used under the following conditions: – Packet is non-fragmented and without option, and packet is a TCP or UDP packet – or, the load-balance force-l4-hashing command is configured. • IPv6 tunnel encapsulated IPv6 traffic: source MAC address and destination MAC address, IPv6 source and destination address, TCP or UDP source port and TCP or UDP destination port, and IPv6 next header. and VLAN-ID.
5 LAG load sharing Load sharing for MPLS LAGs Load sharing on MPLS LAG involves traffic flows that include the MPLS Inner and Outer Labels. These can be used exclusively or in combination with the IP and MAC source and destination addresses to determine the LAG index for a traffic flow. In version 03.5.
Migrating from a pre-03.7.00 LAG or LACP configuration 5 Per packet server LAG load sharing Per packet LAG load balancing is a type of LAG that load balances traffic on a per-packet basis, as compared to traditional server LAG load-balancing which balances traffic based on packet content such as source or destination addresses. In per packet server LAG load balancing, the packet processor (PPCR) on each module selects a port in the per packet server LAG to forward traffic in a round-robin fashion.
5 Configuring a LAG d. The timeout configuration set by the command link-aggregate configure timeout will be converted to the lacp-timeout command. e. Individual port priority set by the command link-aggregate configure port-priority will be converted to the lacp-port-priority command. f.
Configuring a LAG 5 You can either assign a LAG ID explicitly or it will be automatically generated by the system. The LAG ID stays the same across system reload and hitless upgrade. The command to configure LAGs allows explicit configuration of the LAG ID for static and dynamic LAGs. To create a LAG with the LAG ID option, enter a command such as the following. Brocade(config)# lag blue static Brocade(config-lag-blue)# Syntax: [no] lag name [static | dynamic] [id number] The ID parameter is optional.
5 Configuring a LAG Example : show lag command and the output. Brocade(config)# show lag Total number of LAGs: 1 Total number of deployed LAGs: 1 Total number of s created:1 (127 available) LACP System Priority / ID: 1 / 0000.0001.
Configuring a LAG 5 When the LACP forwarding is enabled on the primary port of the static LAG, the LACP BPDU forwarding is enabled on all ports of the LAG when the LAG is deployed. When the static LAG is undeployed the BPDU forwarding state is retained. NOTE LACP BPDU forwarding is not supported for any port of dynamic or keep alive LAGs.
5 Configuring a LAG Ports can be added to an undeployed LAG or to currently deployed LAG using the commands described.
Configuring a LAG 5 Specifying the LAG threshold Trunk threshold brings the LAG down if the trunk threshold condition is not met by the LAG. Syntax: [no] trunk-threshold number You can specify a threshold from 1 (the default) up to the number of ports in the LAG. NOTE This configuration is only applicable for configuration of a static or dynamic LAG. Below are the different behavioral patterns for static and dynamic LAG.
5 Configuring a LAG NOTE Configuring the LACP trunk threshold on a third-party device may occasionally cause performance or incorrect traffic flow issues. To avoid this issue, configure the trunk threshold on either the Brocade MLX series device only or on both the Brocade MLX series device and the third-party device. Configuring an LACP port priority In a dynamic or keep-alive LAG, a port priority can be configured at the global level.
Deploying a LAG 5 The short keyword configures the port for the short timeout mode—3 seconds. In the short timeout configuration, an LACPDU is sent every second. If no response comes from its partner after 3 LACPDUs are sent, a timeout event occurs, and the LACP state machine transitions to the appropriate state based on its current state. If you specify neither long nor short, the state machine operates based on the standard IEEE specification as its default behavior.
5 Deploying a LAG Commands available under LAG once it is deployed Once a LAG has been deployed, the following configurations can be performed on the deployed LAG: • • • • • • • • Configuring ACL-based Mirroring Disabling Ports within a LAG Enabling Ports within a LAG Monitoring and Individual LAG Port Assigning a name to a port within a LAG Enabling sFlow Forwarding on a port within a LAG Setting the sFlow Sampling Rate for a port within a LAG Configuring LACP BPDU Forwarding Configuring ACL-based mir
Deploying a LAG 5 Brocade(config)# lag blue static Brocade(config-lag-blue)# deploy Brocade(config-lag-blue)# disable ethernet 3/1 Syntax: [no] disable ethernet [slot/port] | named [name] Use the ethernet option with the appropriate [slot/port] variable to specify a Ethernet port within the LAG that you want to disable. Use the named option with the appropriate [slot/port] variable to specify a named port within the LAG that you want to disable.
5 Deploying a LAG • When a port is deleted from a deployed static LAG, the LACP BDPU forwarding state of the LAG will be retained on the deleted port.
Deploying a LAG 5 Assigning a name to a port within a LAG You can assign a name to an individual port within a LAG using the port-name command within the LAG configuration as shown in the following. Brocade(config)# lag blue static Brocade(config-lag-blue)# deploy Brocade(config-lag-blue)# port-name orange ethernet 3/1 Syntax: [no] port-name text ethernet [slot/port] The text variable specifies the port name. The name can be up to 50 characters long.
5 Deploying a LAG Use the port-name option with the appropriate [text] variable to specify the named port within the LAG that you want to configure the sampling rate for. The num variable specifies the average number of packets from which each sample will be taken. The software rounds the value you enter up to the next odd power of 2. This can be a value between 512 - 1048576. Configuring a dynamic LAG within a VRF In release 3.8.00, support was added for dynamic LAGs within a VRF.
Deploying a LAG 5 • When dynamic rebalancing is taking place, there will be dropped packets. This is because as the forwarding port for a LAG OIF changes, the FID and the MVID of the forwarding entry change as well, thus requiring a reprogramming of the PRAM before the changes take effect. This results in a brief disruption in traffic. • As of Multi-Service IronWare version 05.3.00, dynamic rebalancing will done only for Layer 3 multicast traffic and not for Layer 2 Snooping traffic.
5 Deploying a LAG Brocade# show lag Total number of LAGs: 4 Total number of deployed LAGs: 3 Total number of s created:3 (125 available) LACP System Priority / ID: 0001 / 0004.80a0.
Deploying a LAG 5 The keep-alive option limits the display to keep alive LAGs. The deployed option limits the display to static LAGs. Optional commands include: Syntax: show lag id Syntax: show lag id num_id Syntax: show lag ethernet slot/port To display long port names, set-lag-port-mode-wid command. This command is useful if the ports names are long. In wide mode, the complete port name will be displayed and port type will not be displayed.
5 Deploying a LAG Ports: Port Count: Primary Port: Trunk Type: LACP Key: e 31/11 to 31/14 e 31/21 to 31/24 8 31/11 hash-based 100 Port Individual Configuration: Port Name 31/11test Deployment: Port 31/11 31/12 31/13 31/14 31/21 31/22 31/23 31/24 Link Up Up Up Up Up Up Up Up Trunk ID 6, Active Primary 31/12, base fid: 0x0800 Port-State Forward Forward Forward Forward Forward Forward Forward Forward Speed 1G 1G 1G 1G 1G 1G 1G 1G Tag No No No No No No No No MAC Name 00da.1111.27aa test 00da.1111.
Deploying a LAG TABLE 25 5 Show LAG information (Continued) This field... Displays... Primary The primary port of the LAG. Port List The list of ports that are configured in the LAG. The following information is displayed per-LAG the show lag command for each LAG configured. LAG Configuration Ports: List of ports configured with the LAG. Primary Port: The primary port configured on the LAG. LAG Type: The load sharing method configured for the LAG: either hash-based or per-packet.
5 Deploying a LAG TABLE 25 136 Show LAG information (Continued) This field... Displays... Tio Indicates the timeout value of the port. The timeout value can be one of the following: • L – Long. The LAG group has already been formed and the port is therefore using a longer message timeout for the LACPDU messages exchanged with the remote port. Typically, these messages are used as confirmation of the health of the aggregate link. • S – Short.
Deploying a LAG TABLE 25 5 Show LAG information (Continued) This field... Displays... Exp Indicates whether the negotiated link aggregation settings have expired. The settings expire if the port does not receive an LACPDU message from the port at the other end of the link before the message timer expires. This field can have one of the following values: • Exp – The link aggregation settings this port negotiated with the port at the other end of the link have expired.
5 Deploying a LAG Syntax: show statistics lag Syntax: show statistics lag lag_name Displaying multicast LAG member port usage Use the show ip pim count lag command to display the multicast LAG member port usage. The Forwarding entries correlate to the multicast (S, G) entries. Brocade# show ip pim count lag lag-member-port PORT ID FORWARDING ENTRIES e2/43 0 e2/44 0 e2/45 0 e2/46 0 Syntax: show ip pim count lag lag-member-port For IPv6, use the show ipv6 pim count lag lag-member-port command.
Deploying a LAG 5 Sample Output Cont…. Alignment 0 FCS 0 GiantPkts 0 ShortPkts 0 InBitsPerSec 782177316 OutBitsPerSec 466226351 InPktsPerSec 90896 OutPktsPerSec 99992 InUtilization 7.96% OutUtilization 4.82% Syntax: show interface lag lag-name The lag-name or lag ID parameter can be used to display the detailed information of a specified the LAG. If no LAG name or LAG ID is specified, the detailed information of all the LAGs configured in the system will be displayed.
5 Displaying LACP information for a specified LAG name or LAG ID Displaying LACP information for a specified LAG name or LAG ID Use the show lacp command to display LACP information for a specified LAG name or LAG ID. For each LAG port configured, the show lacp command displays the system identifier, system priority, port priority, and various state machine variables for both the actor and the partner of the system.
Displaying LACP information for a specified LAG name or LAG ID TABLE 26 5 Output from the show lacp command This Field... Displays... Port Lists the port number of the LAG member. Displayed in slot/port format. Role Indicates if the LACP information displayed for a LAG port is for the actor or the partner. System Priority (Sys Pri) Lists the system priority configured for this port.
5 142 Displaying LACP information for a specified LAG name or LAG ID This Field... Displays... Defaulted (Def) Defaulted partner information is the set of LACP partner information (the system priority, key, port priority, and state of the partner) that is used when the information is not obtained from the partner through LACPDUs. This occurs when LACPDUs are not properly received on time.
Displaying LACP information for a specified LAG name or LAG ID 5 Error messages displayed for LACP information when specifying a LAG name or LAG ID If you do not configure a specified LAG name or LAG ID, an error message displays on the console, as shown in the following example. Brocade#show lacp lag_id 5 Error: LAG ID 5 is not configured If you do not deploy a specified LAG name or LAG ID, an error message displays on the console, as shown in the following example.
5 144 Displaying LACP information for a specified LAG name or LAG ID Multi-Service IronWare Switching Configuration Guide 53-1003036-02
Chapter Brocade NetIron CES and Brocade NetIron CER Link Aggregation 6 This chapter describes how to configure Link Aggregation Groups (LAG) for Brocade NetIron CES and Brocade NetIron CER devices. NOTE The terms LAG and LAG groups are used interchangeably in this guide. LAG formation rules Multi-Service IronWare software supports the use a single interface to configure any of the following LAG types: • Static LAGs– Manually-configured aggregate link containing multiple ports.
6 LAG formation rules • Are configured as MRP primary and secondary interfaces. • LAG deployment will fail if the LACP BPDU forwarding is disabled on the primary port and enabled on one or more of the secondary ports. Layer 3 requirements The LAG is rejected if any secondary LAG ports have any Layer 3 configuration, such as IPv4s, OSPF, RIP, RIPng, IS-IS, etc. Layer 4 (ACL) requirements All LAG ports must have the same ACL configurations; otherwise, the LAG is rejected.
LAG load sharing FIGURE 6 6 Example of a 1-port keepalive LAG Figure 7 shows an example of a valid 2-port LAG between devices where the ports on each end are on the same interface module. Ports in a valid 2-port LAG on one device are connected to two ports in a valid 2-port LAG on another device. FIGURE 7 Example of 2-port LAG LAG load sharing Brocade devices can be configured for load sharing over a LAG using hash-based load sharing.
6 Deploying a LAG If the packet is not IP: • If the packet is MPLS, the hash is further calculated as the following: • hash[5:0] = hash[5:0]^MPLS_L0[5:0]^MPLS_L1[5:0]^MPLS_L2[5:0]; • The 4-bit hash value is: hash[3:0] = hash[5:0]% num_of__members; NOTE The hashing in CES/CER is based on the values present in the header of the incoming traffic (L2, L3, and L4).
Deploying a LAG 6 Commands available under LAG once it is deployed Once a LAG has been deployed, the following configurations can be performed: • • • • • • • Configuring ACL-based Mirroring Disabling Ports within a LAG Enabling Ports within a LAG Monitoring and Individual LAG Port Assigning a name to a port within a LAG Enabling sFlow Forwarding on a port within a LAG Setting the sFlow Sampling Rate for a port within a LAG Configuring ACL-based mirroring To configure ACL-based mirroring for all ports i
6 Deploying a LAG Use the named option with the appropriate slot/port variable to specify a named port within the LAG that you want to disable. When a port is deleted from a deployed static LAG, the LACP BDPU forwarding state of the LAG will be retained for the deleted port. Enabling ports within a LAG You can enable an individual port within a LAG using the enable command.
Deploying a LAG 6 Brocade(config)# lag blue static Brocade(config-lag-blue)# deploy Brocade(config-lag-blue)# port-name orange ethernet 3/1 Syntax: [no] port-name text ethernet [slot/port] The text variable specifies the port name. The name can be up to 50 characters long. Use the ethernet option with the appropriate [slot/port] variable to apply the specified name to an Ethernet port within the LAG.
6 Deploying a LAG Static LAG Considerations Enabling and Disabling LACP BPDU Forwarding on a Port NOTE The forward-lacp command must be issued on the physical port configuration, not in LAG configuration. For scenarios in which dynamic LAG ports require LACP BPDU packet forwarding, you can issue the forward-lacp command in the interface mode. Once LACP Forwarding has been enabled on a dynamic LAG, all the LACP BPDUs will follow regular packet forwarding actions.
Deploying a LAG 6 Displaying LAG information You can display LAG information for by entering the show lag command. Brocade# show lag Total number of LAGs: 4 Total number of deployed LAGs: 3 Total number of s created:3 (125 available) LACP System Priority / ID: 0001 / 0004.80a0.
6 Deploying a LAG The brief option displays summary information for any or all configured LAGs. The deployed option limits the display to LAGs that are currently deployed. The dynamic option limits the display to dynamic LAGs. The Ethernet option displays the output for the specified Ethernet port. The keep-alive option limits the display to keep alive LAGs. The deployed option limits the display to static LAGs. Table 27 describes the information displayed by the show lag command.
Deploying a LAG TABLE 27 6 Show LAG information (Continued) This field... Displays... Link The status of the link, which can be up or down. L2 State The Layer 2 state for the port. Dupl The duplex state of the port, which can be one of the following: • Full • Half • None Speed The bandwidth of the interface. LAG The LAG ID of the port. Tag Indicates whether the ports have 802.1q VLAN tagging. The value can be Yes or No. Priori Indicates the Quality of Service (QoS) priority of the ports.
6 Deploying a LAG TABLE 27 156 Show LAG information (Continued) This field... Displays... Syn Indicates the synchronization state of the port. The state can be one of the following: • No – The port is out of sync with the remote port. The port does not understand the status of the LACPDU process and is not prepared to enter a LAG link. • Syn – The port is in sync with the remote port.
Deploying a LAG 6 To display long port names, set-lag-port-mode-wid command. This command is useful if the ports names are long. In wide mode, the complete port name will be displayed and port type will not be displayed. In standard (non-wide) mode, only a portion of the port name is displayed if the port name is long and the port type is displayed. The following example shows the wide-mode display of a show lag command.
6 Deploying a LAG Deployment: Port 31/11 31/12 31/13 31/14 31/21 31/22 31/23 31/24 Link Up Up Up Up Up Up Up Up Trunk ID 6, Active Primary 31/12, base fid: 0x0800 Port-State Forward Forward Forward Forward Forward Forward Forward Forward Speed 1G 1G 1G 1G 1G 1G 1G 1G Tag No No No No No No No No MAC Name 00da.1111.27aa test 00da.1111.27aa 00da.1111.27aa 00da.1111.27aa 00da.1111.27aa 00da.1111.27aa 00da.1111.27aa 00da.1111.
Deploying a LAG 6 Displaying LAG information for a specified LAG name or LAG ID The show interfaces lag command displays LAG information for a LAG specified by LAG name or LAG ID. If no LAG name or LAG ID is specified, it shows detailed information of all the LAGs configured in the system. For each port of a LAG, detailed information about the LAG interface, including counters is displayed.
6 Deploying a LAG LAG Configuration: Ports: e 1/1 to 1/2 e 1/13 to 1/14 e 1/25 to 1/26 e 1/37 to 1/38 Port Count: 8 Primary Port: 1/1 Trunk Type: hash-based LACP Key: 100 Deployment: Trunk ID 1, Active Primary 1/1, base fid: 0x0000 Port Link Port-State Type 1/1 Up Forward default-port 1/2 Up Forward default-port 1/13 Up Forward default-port 1/14 Up Forward default-port 1/25 Up Forward default-port 1/26 Up Forward default-port 1/37 Up Forward default-port 1/38 Up Forward default-port Dupl Speed Trunk Ta
Deploying a LAG 6 Displaying the running configuration for a LAG The show running-config lag command displays the running configuration for a specified LAG or all LAGs as specified in the parameters.
6 162 Deploying a LAG Multi-Service IronWare Switching Configuration Guide 53-1003036-02
Chapter 7 VLANs Table 28 displays the individual Brocade devices and the VLAN features they support.
7 VLANs TABLE 28 Supported Brocade VLAN features (Continued) Features supported Brocade NetIron XMR Series Brocade MLX Series Brocade NetIron CES 2000 Series BASE package Brocade NetIron CES 2000 Series ME_PREM package Brocade NetIron CES 2000 Series L3_PREM package Brocade NetIron CER 2000 Series Base package Brocade NetIron CER 2000 Series Advanced Services package Hardware Flooding for Layer 2 Multicast and Broadcast Packets Yes Yes Yes Yes Yes Yes Yes Unknown Unicast Flooding on VLAN
VLANs 7 network constitute a single Layer 2 broadcast domain. Once you create a port-based VLAN and assign an interface to that VLAN, that interface is automatically removed from the default VLAN if the interface is assigned to the VLAN as an untagged interface. If the interface is assigned as a tagged interface, then the interface is a member of both the default VLAN, and the VLAN to which it is assigned.
7 VLANs If you configure a VLAN that spans multiple devices, you need to use tagging only if a port connecting one of the devices to the other is a member of more than one port-based VLAN. If a port connecting one device to the other is a member of only a single port-based VLAN, tagging is not required. Figure 9 shows an example of two devices that have the same Layer 2 port-based VLANs configured across them. Notice that only one of the VLANs requires tagging.
VLAN configuration rules 7 Protocol-based VLANs can be configured to have static or excluded port memberships. Static ports are permanent members of a protocol-based VLAN. They remain active members of the protocol-based VLAN regardless of whether they receive traffic for the VLAN’s protocol. NOTE The dynamic port membership is not supported on Brocade devices.
7 VLAN configuration rules • If it is a Layer 3 packet and the port is a member of a Layer 3 protocol-based VLAN for the packet’s protocol, the device forwards the packet on all the Layer 3 protocol-based VLAN ports that have been configured or drops the packet if the port is explicitly excluded from the protocol VLAN.
VLAN configuration rules 7 When the no untagged ethernet / command is applied under the default VLAN against a port in dual mode, the port will go into pure tagged mode in contrast to the default operating conditions where the port is automatically placed in the dual mode state with regard to the default VLAN. To change the default condition of a Brocade device regarding the dual-mode, default VLAN behavior, enter the no dual-mode-default-vlan command as shown in the following.
7 VLAN configuration rules If you leave a tagged port in dual-mode as an untagged member of the default VLAN, then any untagged broadcast, multicast, and unknown unicast frames received on that port will be flooded out on all other ports in the default VLAN. This is expected behavior. The no dual-mode-default-vlan command has been provided to change this behavior, but this command can only be added if no ports are in dual-mode.
Configuring port-based VLANs 7 • When virtual-interfaces are configured on a VLAN, the CPU-protection is done only on unknown-unicast packets from the VLAN. Multicast and broadcast packets from the VLAN will be sent to the CPU. This allows the CPU to process packets such as ARP and OSPF “hello” packets that may be relevant to the device. • When virtual-interface is not configured on the VLAN, the CPU-protection is performed for all packets (unknown-unicast, multicast and broadcast) from the CPU.
7 Configuring port-based VLANs Ports are removed from the default VLAN only when the port is added as an untagged member of a different VLAN. The untag command also allows the ports to process packets that do not contain 802.1q tagging. A port is removed from a default-VLAN when the port is added as an untagged member of a different VLAN. The tagged parameter allows the Brocade device to add a four-byte tag 802.1q tag to the packets that go through the tagged ports.
Configuring protocol-based VLANs 7 You must specify a VLAN ID that is not already in use. For example, if VLAN 10 exists, do not use “10” as the new VLAN ID for the default VLAN. VLAN IDs are from 1 – 4090. The VLAN ID range above 4090 has been reserved for current and future features for internal control purposes. Configuring protocol-based VLANs Once port-based VLANs are created, you can further segment the broadcast domains by creating protocol-based VLANs, based on Layer 3 protocols.
7 Configuring virtual routing interfaces NOTE Dynamically adding ports to the protocol-based VLANs are not supported. Ports within the port-based VLAN can only be added as static ports to the protocol-based VLAN. The running-configuration will show “no dynamic” under ip-proto name name to indicate that the ports are added as static ports to the protocol-based VLAN. Configuring virtual routing interfaces The Brocade device sends Layer 3 traffic at Layer 2 within a protocol-based VLAN.
Configuring virtual routing interfaces 7 Integrated Switch Routing (ISR) Integrated Switch Routing (ISR) feature enables VLANs configured on the Brocade device to route Layer 3 traffic from one protocol-based VLAN to another instead of forwarding the traffic to an external router. The VLANs provide Layer 3 broadcast domains for the protocols, but do not in themselves provide routing services. This is true even if the source and destination protocols are on the same device.
7 VLAN groups There is a separate STP domain for each port-based VLAN. Routing occurs independently across port-based VLANs or STP domains. You can define each end of each backbone link as a separate tagged port-based VLAN. Routing will occur independently across the port-based VLANs. Because each port-based VLAN’s STP domain is a single point-to-point backbone connection, you are guaranteed to never have an STP loop.
VLAN groups 7 The VLAN group feature allows you to create multiple port-based VLANs with identical port members. Since the member ports are shared by all the VLANs within the group, you must add the ports as tagged ports. This feature not only simplifies VLAN configuration but also allows you to have a large number of identically configured VLANs in a startup configuration file on the device’s flash memory module.
7 VLAN groups This message is normal and indicates that the configuration has take effect. It does not indicate that an error condition has occurred. 3. If required, you can add and remove individual VLANs or VLAN ranges from the VLAN group configuration level. For example, to add VLANs 1001 and 1002 to VLAN group 1 and remove VLANs 900 through 1000, enter the following commands.
Configuring super aggregated VLANs 7 Configuring super aggregated VLANs A super aggregated VLAN allows multiple VLANs to be placed within another VLAN. This feature allows you to construct Layer 2 paths and channels. A path contains multiple channels, each of which is a dedicated circuit between two end points. The two devices at the end points of the channel appear to each other to be directly attached. The network that connects them is transparent to the two devices.
7 Configuring super aggregated VLANs Each client connected to the edge device is in its own port-based VLAN. All the clients’ VLANs are aggregated by the edge device into a single VLAN for connection to the core. The device that aggregates the VLANs forwards the aggregated VLAN traffic through the core. The core can consist of multiple devices that forward the aggregated VLAN traffic.
Configuring super aggregated VLANs 7 Since each VLAN configured on the core devices is an aggregate of multiple client VLANs, the aggregated VLANs greatly increase the number of clients a core device can accommodate. This example shows a single link between the core devices. However, you can use a LAG group to add link-level redundancy. Configuring aggregated VLANs A maximum of 1526 bytes are supported on ports where super-aggregated VLANs are configured.
7 Configuring super aggregated VLANs • Configure a VLAN tag type (tag ID) that is different than the tag type used on the edge devices. If you use the default tag type (8100) on the edge devices, set the tag type on the core devices to another value, such as 9100. The tag type must be the same on all the core devices. The edge devices also must have the same tag type but the type must be different from the tag type on the core devices.
Configuring super aggregated VLANs 7 Brocade-A(config-vlan-103)# untagged ethernet 1/3 Brocade-A(config-vlan-103)# exit Brocade-A(config)# vlan 104 Brocade-A(config-vlan-104)# tagged ethernet 2/1 Brocade-A(config-vlan-104)# untagged ethernet 1/4 Brocade-A(config-vlan-104)# exit Brocade-A(config)# vlan 105 Brocade-A(config-vlan-105)# tagged ethernet 2/1 Brocade-A(config-vlan-105)# untagged ethernet 1/5 Brocade-A(config-vlan-105)# exit Brocade-A(config)# write memory Commands for device B The commands for
7 Configuring super aggregated VLANs Commands for device D Device D is at the other end of path and separates the channels back into individual VLANs. The tag type must be the same as tag type configured on the other core device (Device C). In addition, VLAN aggregation also must be enabled.
Configuring 802.
7 Configuring 802.1q-in-q tagging In Figure 16, the untagged ports (to customer interfaces) accept frames that have any 802.1Q tag other than the configured tag-type 9100. These packets are considered untagged on this incoming port and are re-tagged when they are sent out of the uplink towards the provider. The 802.
Configuring 802.1q tag-type translation 7 Example configuration Figure 15 shows an example 802.1Q-in-Q configuration. FIGURE 15 Example 802.1Q-in-Q configuration Configuring 802.1q tag-type translation The introduction of 802.1q tag-type translation provides finer granularity for configuring multiple 802.1q tag-types on a single device, by enabling you to configure 802.1q tag-type per port. This enhancement allows for tag-type translation from one port to the next on tagged interfaces. 802.
7 Configuring 802.1q tag-type translation FIGURE 16 802.1q Tag-type translation configuration example 1 As illustrated in Figure 16, the devices process the packet as follows: • Customer Edge Switch 1 sends a packet with an 802.1q tag-type of 8100 to Provider Core Switch 1. • Since the customer-facing interface on Provider Core Switch 1 has the same 802.
Configuring 802.1q tag-type translation FIGURE 17 7 802.1q Tag-type translation configuration example 2 As illustrated in Figure 17, the devices process the packets as follows: • Path A: When Core Switch 1 receives the tagged packet from Edge Switch 1, it keeps the 8500 tag-type in the frame header (because the incoming port on Core Switch 1 is untagged) and adds the 9100 tag-type as it sends the packet to the uplink (Core Switch 2).
7 Miscellaneous VLAN features Enabling 802.1q Tag-type Translation To enable 802.1q tag-type translation, configure an 802.1q tag-type on the provider core link, between the provider core switches (refer to Figure 17). Enter commands such as the following.
Hardware flooding for layer 2 multicast and broadcast packets 7 Configuring uplink ports within a port-based VLAN You can configure a subset of the ports in a port-based VLAN as uplink ports. When you configure uplink ports in a port-based VLAN, the device sends all broadcast and unknown-unicast traffic from a port in the VLAN to the uplink ports, but not to other ports within the VLAN. Thus, the uplink ports provide tighter broadcast control within the VLAN.
7 Unknown unicast flooding on VLAN ports Example Brocade(config)# Brocade(config)# vlan 2 Brocade(config-vlan-2)# multicast-flooding Brocade(config-vlan-2)# exit Syntax: [no] multicast-flooding NOTES: • This feature cannot be enabled on an empty VLAN; the VLAN must already have ports assigned to it prior to enabling this feature. • This feature is not supported on Layer 3 protocol-based VLANs.
Command changes to support Gen-2 modules 7 Configuring VLAN CPU protection VLAN CPU protection is recommended for the VLANs which are intended for pure Layer 2 use. This feature will protect the CPU from the flooding of unknown-unicast or multicast or broadcast Layer 2 packets on that VLAN. When using routing protocols (like OSPF etc.) on a specific VLAN, you need to disable VLAN CPU protection for it to work. This feature is intended for Layer 2 applications and not for Layer 3 routing applications.
7 Command changes to support Gen-2 modules Deprecated commands vlan-counter exclude-overhead The vlan-counter exclude-overhead command has been deprecated in the NetIron XMR/MLX only. The new command is the exclude-ethernet-overhead command. NOTE The statistics - exclude-ethernet-overhead command will replace the vlan-counter exclude-overhead command when upgrading to the new image. By default, the VLAN byte counters include the 20-byte Ethernet overhead.
Command changes to support Gen-2 modules 7 The vlan-accounting on command enables counters for a specific VLAN. The vlan-accounting off command disables counters for a specific VLAN. clear vlan all-vlans statistics The clear vlan byte-accounting all-vlans command has been deprecated. The new command is the clear vlan all-vlans statistics command. To clear VLAN counters for all VLANs, enter the following command.
7 Extended VLAN counters for 8x10G modules Name Name of the port-based VLAN. [None] appears if a name has not been assigned. Priority Level Priority level assigned to the port-based VLAN. L2 protocols Layer 2 control protocol configured on the VLAN. Untagged or Tagged Ports ID of the untagged or tagged ports that are members of the VLAN. (protocol-based VLANs) If protocol based VLANs are configured, their type and name appear after the list of ports.
Displaying VLAN counters 7 Enabling accounting on per-slot basis You can enable or disable per-VLAN priority accounting mode on all or a per-slot basis on the ingress and egress counters. To enable accounting on per-slot basis, enter the following command. Layer 2 VLAN accounting is enabled by default. Counters are polled once every 50 seconds.
7 Displaying VLAN counters p7 0 0 0 0 eth 12/3 -- Extended-counter resource allocation failed – encountering Stats ID allocation failure eth 12/4 0 0 0 0 p0 0 0 0 0 p1 0 0 0 0 p6 0 0 0 0 p7 0 0 0 0 < -- On Slot 14: < -- module with per-VLAN/port based accounting Syntax: show vlan vlan-id statistics [detail |routed |switched] The vlan-id parameter specifies the VLAN ID of the port. The slot/port parameter specifies the interface module location of a 8x10g module.
Clearing extended VLAN counters 7 To display VLAN counters information for switched packets on a specific port on a VLAN, enter the following command. Brocade# show vlan 10 statistics ethernet 14/1 switched VLAN 10: Extended Switched Counters (only applicable for G2 modules): Interface RxPkts TxPkts RxBytes TxBytes eth 14/1 0 0 0 0 To display detailed VLAN counters information on a specific port on a VLAN, enter the following command.
7 Clearing extended VLAN counters Clearing counters for all VLANs To clear the ingress and egress packet and byte counters for routed packets and switched packets on all VLANs, enter the following command. Brocade# clear vlan all-vlans statistics Syntax: clear vlan all-vlans statistics [switched] Enter the switched keyword to clear only the counters of switched packets. If you do not specify the switched keyword, the counters for both routed packets and switched packets are cleared.
7 IP interface commands Specify the switched keyword to clear counters for the switched packets. If the switched keyword is not specified the counters for both the routed packets and switched packets will be cleared. The switched keyword is accepted only if the routed packets and switched packets are counted separately. Clearing extended counters statistics on a port To clear all extended counters statistics simultaneously for a single port, enter the following command.
7 IP interface commands TABLE 33 show ip interface command output details Field Description Interface The interface the counter statistics are displayed. RxPkts The number of packets received at the specified port. TxPkts The number of packets transmitted from the specified port. RxBytes The number of bytes received at the specified port. TxBytes The number of bytes transmitted from the specified port.
IP interface commands eth 12/2 p0 0 0 0 0 0 0 0 0 0 0 0 0 7 p7 To display the detailed aggregate count of the routed packets and switched packets of a virtual IP interface are configured combined mode, use the following command.
7 IP interface commands accounting mode configuration. If you have configured accounting mode to count routed and switched packets separately, only the routed counters will be cleared. If you have configured accounting mode to count routed and switched packets together, the combined counter will be cleared.
Transparent VLAN flooding 7 Transparent VLAN flooding You can configure your Brocade device for transparent VLAN flooding. This feature allows packets to be forwarded without any form of CPU intervention including MAC learning and MAC destination lookups. NOTE Because this feature floods all VLAN packets in hardware, it is not expected to work in conjunction with routing functions such as establishing routing protocol neighborship and Layer 3 forwarding even when the VLAN has a VE configured.
7 Transparent VLAN flooding • Layer 2 or Layer 3 outbound ACLs may be applied to any port in a VLAN that has TVF enabled. • Input Layer 3 ACLs need to be applied to a virtual routing interface on the VLAN and should not be attached to a port directly. Note that the ACL would apply to all ports in the VLAN by default. If this is not desired, a subset of ports in the VLAN may be specified, as in the following configuration.
Transparent firewall mode 7 Transparent firewall mode The transparent firewall mode allows the device to switch control packets destined to itself. By default, Brocade devices will drop control packets received with the device's MAC address as the packet's destination MAC address (that is, packets destined to the switch or router). Under the transparent firewall mode, switching packets destined to itself is allowed.
7 Displaying VLAN information PORT-VLAN 200, Name [None], Priority Level -, Priority Force 0 Topo HW idx : 0 Topo SW idx: 257 Topo next vlan: 0 L2 protocols : NONE Tagged Ports : ethe 1/1 ethe 1/10 ethe 1/29 Associated Virtual Interface Id: 120 PORT-VLAN 4095, Name CONTROL-VLAN, Priority Level -, Priority Force 0 Topo HW idx : 1 Topo SW idx: 257 Topo next vlan: 0 L2 protocols : NONE Associated Virtual Interface Id: NONE Syntax: show vlan [vlan-id] [brief| detail] [Ethernet slot/port] [ begin expression |
Displaying VLAN information 7 To display information for a specific VLAN, enter a VLAN id as shown in the example below.
7 Displaying VLAN information Displaying VLAN status and port types To display detailed information about the state, port types, port modes, of a VLAN, as well as control protocols configured on the VLAN, enter the following command.
Displaying VLAN information TABLE 38 7 Output of show vlan detail (Continued) This field... Displays... Protocol Protocol configured on the VLAN. State Current state of the port such as disabled, blocking, forwarding, etc. Displaying VLAN group information To display information about VLAN groups, enter the following command.
7 Multi-port static MAC address Multi-port static MAC address The multi-port static MAC address feature enables you to send traffic destined for a particular MAC address on a set of ports of a VLAN instead of flooding the traffic on all ports of the VLAN. This feature enables you to configure a Layer 2 static multicast MAC address. This feature is supported on both the Brocade NetIron XMR, Brocade MLX series and Brocade NetIron CER, Brocade NetIron CES series platforms.
Configuring multi-port static MAC address 7 Syntax: [no] static-mac-address multi-ports ethernet [|[ to ] ..
7 Displaying multi-port static MAC address information Error: port 4/11 is part of multiport-mac and cannot be added as secondary port of a trunk • When a LAG primary port is part of a multi-port static MAC address, the LAG cannot be undeployed or deleted. Also, when a non-LAG port is part of a multi-port static MAC address, you cannot deploy a LAG with that port. These configurations will be rejected. The following are the sample error messages for each of these cases: - Veto check for deploying LAG.
SA and DA learning and aging 7 ethe 2/1 to 2/5 prority 5 Displaying changes in the MAC table You can display the complete MAC table, a specific entry in the MAC table, or a specific MAC entry with M-port details. To display the complete MAC table, enter the following command. Brocade# show mac MAC Address Port Age VLAN 0100.5e42.7f40 1/1... Static 10 Ports : e 1/1 to 1/3 e 2/1 to 2/5 0000.999d.9996 2/20 Static 10 Type To display a specific MAC address from the MAC table, enter the following command.
7 Command Command • • • • 216 transparent-hw-flooding lag-load-balancing system-max tvf-lag-lb-fid-pool system-max tvf-lag-lb-fid-group show vlan tvf-lag-lb Multi-Service IronWare Switching Configuration Guide 53-1003036-02
transparent-hw-flooding lag-load-balancing 7 transparent-hw-flooding lag-load-balancing Configures transparent VLAN flooding LAG load balancing on a specific VLAN when there is PBR to TVF VLAN flooding.
7 system-max tvf-lag-lb-fid-pool system-max tvf-lag-lb-fid-pool Configures maximum FID pool size for transparent VLAN flooding LAG load balancing globally. Syntax Command Default Parameters [no] system-max tvf-lag-lb-fid-pool number None number Specifies the decimal value of FID pool size defined. Valid from 0 through 2048 (Default is 0, setting the value as 0 will disable transparent VLAN flooding LAG load balancing globally).
system-max tvf-lag-lb-fid-group 7 system-max tvf-lag-lb-fid-group Configures maximum FID group size for transparent VLAN flooding LAG load balancing globally. Syntax Command Default Parameters [no] system-max tvf-lag-lb-fid-group number None number Specifies the decimal value of the FID number defined per group. Valid values are 2, 4, 8.
7 show vlan tvf-lag-lb show vlan tvf-lag-lb Displays transparent VLAN flooding LAG load balancing information. Syntax Parameters show vlan tvf-lag-lb None Command Modes Privileged EXEC mode Usage Guidelines The show vlan tvf-lag-lb command displays transparent VLAN flooding LAG load balancing information. Command Output The show vlan tvf-lag-lb command displays the following information: Examples Output field Description TVF FID pool size Specifies the maximum TVF FID pool size.
show vlan tvf-lag-lb Multi-Service IronWare Switching Configuration Guide 53-1003036-02 7 221
7 222 show vlan tvf-lag-lb Multi-Service IronWare Switching Configuration Guide 53-1003036-02
Chapter Ethernet Service Instance (ESI) for Brocade NetIron CES and Brocade NetIron CER Devices 8 Ethernet Service Instance (ESI) overview An Ethernet Service Instance (ESI) is a provisioning environment for defining VLAN and other layer 2 parameters for creating services, typically across a carrier network. In a local area network a total of 4K VLANs can be configured across the entire network domain.
8 Ethernet Service Instance (ESI) overview Once an ESI is defined, Brocade NetIron CES and Brocade NetIron CER devices operate on rules for configuring VLANs inside an ESI, and check against configuration incompatibilities (such as configuring the same VLAN value from two different ESIs on the same port).
Ethernet Service Instance (ESI) overview 8 • Client ESI - An ESI that is defined to be a client of another ESI, and that can have one or more VLANs defined inside it. Configuration considerations The following rules apply for CLI operations for Provider Bridge (PB) and related protocols: • To prevent topology changes at startup, it is recommended that you not use the same ESI-Vlan ID as the Default-Vlan ID. • An ESI is created for each service (such as a customer CVLANs, SVLANs, PBB, etc.).
8 Show VLAN commands Defining CVLANs inside the ESI To define CVLANs inside the ESI, enter a command such as the following. Brocade(config-esi-acme)# vlan 10 Configuring the CVLAN to be tagged To configure CVLAN 10 to be tagged on port 1/1, enter a command such as the following. Brocade(config-esi-acme-vlan-10)# tagged ethernet 1/1 Show VLAN commands The following show commands will display custom ESI configurations for VLANs.
8 Show VLAN commands Brocade#show vlan brief Configured PORT-VLAN entries: 1 Maximum PORT-VLAN entries: 512 Default PORT-VLAN id: 1 VLAN Name Encap ESI Pri Ports ---- ---- ----- --- --- ----- 10 [None] cvlan acme - Syntax: show vlan brief Displaying a single ESI To display details of a single ESI, enter the following command from any level of the CLI.
8 Show VLAN commands NOTE The tag1 and tag2 are independent of port-types, so the system can be configured to use tag1 for SVLAN, BVLAN and tag2 for CVLAN. Configuring tag-types You can set the ISID value using a separate command similar to the Brocade NetIron XMR and Brocade MLX series command as shown below. Syntax: [no] tag-value isid num You can configure CVLAN, SVLAN, and BVLAN tag-types as shown below.
Application of a standalone ESI Brocade(config)#show tag-type Encap Current VLAN Tags --------------------cvlan 8100 svlan 9100 isid 86B5 bvlan 9100 8 Default VLAN Tags ----------------8100 88A8 88E7 88A8 NOTE The Brocade NetIron CES and Brocade NetIron CER require that the SVLAN and BVLAN tag types be same. The default tag-type for bvlan and svlan is 0x88A8 for the Brocade NetIron CES and 0x8100 for Brocade MLX series devices.
8 Application of a standalone ESI The following CLI commands create the scenario shown in Figure 20.
Application of a standalone ESI 8 • Packets received on 1/1 are sent out on 1/2 with a CVLAN mapping of 20. • Packets received on 1/2 are sent out on 1/4 with a CVLAN mapping of 10. • Packets received on 1/4 with a CVLAN mapping of 10 are sent to 1/2 with a CVLAN mapping of 20.
8 232 Application of a standalone ESI Multi-Service IronWare Switching Configuration Guide 53-1003036-02
Chapter IEEE 802.1ad - Provider Bridges for the Brocade NetIron CES and Brocade NetIron CER 9 About IEEE 802.1ad In a Provider Bridge (PB) network, a provider VLAN is called a Service VLAN (SVLAN), and a customer VLAN is called a Customer VLAN (CVLAN). A CVLAN carries a default tag-type of 0x8100. The range of customer VLANs (CVLANs) can be mapped to an SVLAN, allowing a CVLAN to cross a provider boundary. The SVLAN can be configured to provide service, tunnels, or broadcast domains.
9 About IEEE 802.1ad • As with normal VLAN devices, every PB node must learn all customer MAC addresses, even with SVLAN encapsulation. Port type configuration for Provider Bridging (PB) FIGURE 23 Port types in a Provider Bridge (PB) The Brocade NetIron CES defines two types of ports for operation in a provider network: • Customer-edge: This port receives packets with CVLAN tagging.
About IEEE 802.1ad 9 Sample configuration FIGURE 24 IEEE 802.1ad network with ESI definitions The network architecture for IEEE 802.1ad in Figure 24 shows customer A with two tagged CVLAN ports connected to SVLAN 100, and customer B with two CVLANs connected to SVLAN 200. To define these configurations and associate them, ESIs are created for each of the configurations.
9 About IEEE 802.1ad Configuring port type values Four port-type values are specified. For our example, set 1/10 and 1/11 to provider-network port type. Brocade(config)# interface ethernet 1/10 Brocade(config-if-e10000-1/10)# port-type provider-network Brocade(config-if-e10000-1/10)# exit Use the following commands to set 1/11 to provider-network port type.
About IEEE 802.1ad TABLE 40 9 show interfaces command output This field... Displays... Module type Port# is State The module type variable specifies a type of interface module, such as 10GigabitEthernet. The port# variable specifies the port number for the interface module. The state variable if the interface module is up or down. Line protocol is status The status variable specifies if the line protocol is up or down.
9 About IEEE 802.1ad TABLE 40 show interfaces command output (Continued) This field... Displays... Trunk membership The Trunk membership variable identifies the interface module as a member of a primary or secondary port. This specifies members of an active port or not a member of an active port. Configured trunk membership The Configured trunk membership variable identifies the interface module as a member of any configured trunk or not a member of a configured trunk.
About IEEE 802.1ad TABLE 40 9 show interfaces command output (Continued) This field... Displays... value output errors, value collisions • • Network Processor transmitted value packets Received from Traffic Manager value packets The value variable specifies the number of transmitted packets with errors. The value variable specifies the number of transmitted packets with collision errors. The value variable specifies the number of packets transmitted from the Network Processor.
9 About IEEE 802.1ad Brocade(config-esi-acme)# vlan 20 Brocade(config-esi-acme-vlan-20)# tagged ethernet 1/2 Brocade(config-esi-acme-vlan-20)# exit Create an ESI on provider side 1. Configure santa as the name of the provider IEEE 802.1ad service Brocade(config)# esi santa encapsulation svlan 2. Define SVLAN 100 inside this ESI Brocade(config-esi-acme-iptv)# vlan 100 3.
About IEEE 802.1ad 9 In this display, the ESI named acme is an ESI of the encapsulation type CVLAN, which has two members (VLANs). The acme ESI now has the santa ESI as a provider with an SVLAN encapsulation type. The santa provider ESI is configured with VLAN ID 100. This means that both CVLANs in the acme ESI receive a second SVLAN encapsulation (with a tag-type value of SVLAN as globally configured) and a SVLAN ID of 100.
9 About IEEE 802.1ad Brocade(config)# esi ESI_1 Brocade(config-esi-ESI_1)# Brocade(config-esi-ESI_1)# Brocade(config-esi-ESI_1)# Brocade(config-esi-ESI_1)# Brocade(config-esi-ESI_1)# Brocade(config-esi-ESI_1)# encapsulation svlan single-flood-domain vlan 100 tagged ethernet 1/3 vlan 200 tagged ethernet 1/4 exit Untagged ports Packets from SVLAN port with only SVLAN tag (no CVLAN tag) are sent to only untagged ports in the default ESI.
About IEEE 802.1ad 9 Layer 2 Protocol Forwarding (L2PF) Layer 2 Protocol Forwarding (L2PF) is configured on CVLANs. You can configure the system to forward BPDUs on all CVLANs coming at different edge ports, drop all BPDUs, or selectively enable forwarding on a few CVLANs. L2PF can transparently extend the STP topology of the CVLAN domain through the SVLAN domain, as if the CVLAN switches were directly hooked together.
9 About IEEE 802.1ad Below, Sx is a simple bridge without STP. FIGURE 28 Physical network NOTE It is critical for L2PF to disable STP on the client CVLAN to operate in that CVLAN. STP wins over L2PF when both are enabled on a given client CVLAN. Table 41 displays the Port configuration for IEEE 802.1ah and IEEE 802.1ad.
About IEEE 802.1ad 9 Global configuration By default, the device enables Layer 2 protocol forwarding (L2PF). Customer-BPDU packets on all CVLANs are forwarded to provider network ports when they arrive at customer-edge ports. Since L2PF is globally enabled by default, all CVLANs have L2PF enabled by default. No CLI configuration is needed.
9 246 About IEEE 802.
Chapter IEEE 802.1ah Provider Backbone Bridging (PBB) Networks for the Brocade NetIron CES and the Brocade NetIron CER 10 Overview The IEEE 802.1ah Provider Backbone Bridges (PBB) standard was developed to address the limitations of Provider Bridges (PB) and to add additional capabilities sought by Service Providers.
10 Overview By adding the PBB header, PBB isolates the Service Provider and customer address spaces. This means that Ethernet switches in the core of the Service Provider network will no longer learn customer MAC addresses or use customer MAC addresses to forward customer frames to their destinations.
Overview 10 The semantics and the structure of the Backbone VLAN Tag (B-TAG) are identical to that of the PB S-TAG. The B-TAG was designed this way so that core PBB switches do not need to be aware of PBB. In fact, standard PB switches can be used in the core of a PBB network. Only the switches at the edge of the Service Provider PBB network need to be aware PBB. A PBB network uses two types of bridges (Figure 30): Backbone Edge Bridges (BEB) and Backbone Core Bridges (BCB).
10 Overview As with PB, PBB networks use a Spanning Tree Protocol (STP), e.g., RSTP or MSTP, to dynamically determine the active topology of the PBB network and MAC address learning to dynamically build a forwarding database. Since an IB-BEB forwards frames to PB and PBB networks, it has to learn customer and backbone MAC addresses. However, since an IB-BEB is at the edge of the Service Provider network, it only learns customer MAC addresses of the local traffic.
Overview 10 • ISID operation: A 24-bit ISID supports the provider bridging operation framework where an EVC setup gives the closed environment for customer packets on the two ends to be limited to the EVC. The EVC is identified by the ISID value. • Customer MAC address learning is limited to the ISID domains that are part of an EVC. A PBB device doesn't need to learn customer MAC addresses that are not part of this EVC.
10 Overview Displaying tag types To display the tag types, enter the following command. Brocade(config)# show tag-type Encap Current VLAN Tags --------------------cvlan 8100 svlan 9100 isid 86B5 bvlan 9100 Default VLAN Tags ----------------8100 88A8 88E7 88A8 NOTE On PB networks, SVLAN and BVLAN tag types must be same. Port configuration for IEEE 802.1ah and IEEE 802.1ad at each interface Table 42 displays the Port configuration for IEEE 802.1ah and IEEE 802.1ad.
Overview 10 A new ESI 'acme-iptv' is created for the incoming SVLAN (at VLAN ID = 100). This is assigned to a BVLAN (VLAN ID = 400) under ESI 'iptv_carrier' by first mapping it to ISID 10300 under ESI 'iptv_service'.
10 Overview Create an SVLAN ESI on IEEE 802.1ad side (PBB ingress) 1. Create an ESI on 801.1ad side. Acme-iptv” is name of the provider IEEE 802.1ad service. Brocade(config)# esi acme-iptv encapsulation svlan 2. Define SVLAN 100 as one of the parameters for ESI Acme-iptv. Brocade(config-esi-acme-iptv)# vlan 100 3. Associate physical ports to SVLAN 100.
Integrated IEEE 802.1ad and IEEE 802.1ah 10 ESI configuration display after mappings To display the ESI configurations, enter the show esi command.
10 Integrated IEEE 802.1ad and IEEE 802.1ah • Layer 2 switches in the IEEE 802.1ah-encapsulated network are normal Provider Bridging systems, which process BVLAN header as if it was an SVLAN-encapsulated packet. • Tag-types - BVLAN and SVLAN tag-types are the same (default 0x88a8), so the Provider Bridging system inside the PBB network can process BVLAN packets as they were SVLAN encapsulated.
Integrated IEEE 802.1ad and IEEE 802.1ah 10 IEEE 802.1ah (PBB) configurations Ingress ports receive SVLAN-encapsulated packets. In this case, the ingress port already contains SVLAN tagged frames and the PBB switch provides additional encapsulation by adding the PBB header. An SVLAN can be mapped to one unique ISID or alternatively multiple SVLANs can be mapped to the same ISID. In Figure 34, the PBB device expects tagged Ethernet packets coming in with SVLAN encapsulation.
10 Integrated IEEE 802.1ad and IEEE 802.1ah Use the customer-edge parameter to specify the Customer Edge Port for IEEE 802.1ad PB Use the provider-network parameter to specify the Provider Network Port IEEE 802.1ad PB Displaying port- types The show interfaces command displays port-type for an interface, as shown below. Brocade(config-if-e10000-5/1)# show interfaces 10GigabitEthernet5/1 is empty, line protocol is down Hardware is 10GigabitEthernet, address is 0e04.80de.ada0 (bia 0e04.80de.
Integrated IEEE 802.1ad and IEEE 802.1ah TABLE 43 10 Display of show interfaces command This field... Displays... Member of VLAN # (untagged) port# L2 VLANS (tagged) Port is in dual mode/untagged/tagged mode Port state is status The VLAN# (untagged) variable specifies a port that is a member of only 1 VLAN. The port# Layer 2 VLANS (tagged) variable specifies a port that is a member of multiple ports and untagged. A port is in dual- mode specifies member VLAN ports as untagged and tagged.
10 Integrated IEEE 802.1ad and IEEE 802.1ah TABLE 43 Display of show interfaces command This field... Displays... Received value broadcasts, value multicasts, value unicasts The value variable specifies the amount of traffic the interface module is receiving on broadcasts, multicasts, and unicast traffic. value input errors, value CRC, value frame, value ignored • • • • 260 The value variable specifies the number of received packets with errors.
Point to Point PBB 10 Point to Point PBB Point to Point PBB (P2P PBB) provides the ability to turn off MAC address learning on a per service instance basis (ISID). This provides support for point-to-point services, such as EVPL, which do not require MAC address learning. Point to Point PBB is designed to flood the traffic to a specific remote BEB in the core PBB network, instead of flooding across all the BEBs.
10 ISID mapping to VPLS ISID mapping to VPLS The ISID mapping to VPLS feature allows the service instance to be identified end-to-end across the Ethernet and VPLS networks using the same value without modifying how the MPLS network operates. When the PBB packet is sent out on the MPLS cloud, the ISID is always preserved in the packet as the payload tag. A VPLS instance can recognize PBB packets only when it is configured in tagged-mode. Figure 35 illustrates this feature.
ISID mapping to VPLS FIGURE 36 ISID endpoint configuration example FWS FWS PBB VPLS PBB NI CES NI CES NI CES FWS 10 MPLS Core NI CES PBBN PBBN XMR/ MLX FWS NI CES XMR/ MLX NI CES Configuring the ISID endpoints The existing VLAN CLI under the VPLS configuration mode has been enhanced to configure ISID endpoints.
10 ISID mapping to VPLS Syntax: [no] tag-type HEX-VALUE [port-type slot/port [to slot/port] Use the HEX-VALUE parameter to specify the etype in hex (Default: 0x8100). Syntax: [no] tag-type isid HEX-VALUE Use the isid parameter to specify the etype for I-Tagged packets. Use the HEX-VALUE parameter to specify the etype in hex (Default: 0x88e7). Topology Groups For topology groups, the member VPLS VLAN commands have been enhanced to specify the ISID level.
ISID mapping to VPLS 10 To display the ISID endpoints in a topology group, use the following command. Brocade# show topology Topology Group 1 ================== Topo HW Index : 65535 Master VLAN : 100 VPLS VLAN exist : TRUE Member VLAN : None Member Group : None Member VPLSs : vpls id 100 vlan 100 isid 450 Syntax: show topology Load balancing traffic You can enable the device to mask out different PBB header fields.
10 ISID mapping to VPLS Show commands Use the show load-balance mask-option command to view the mask sub-options individually. Brocade# show load-balance mask-options ethernet Mask Ethernet options Mask Source MAC is enabled on No Slots Mask Destination MAC is enabled on No Slots Mask Vlan is enabled on No Slots Mask Inner-Vlan is enabled on No Slots Mask ISID is enabled on - Use the show load-balance mask-option pbb command to view the pbb mask sub-options.
ISID mapping to VPLS 10 CoS with ISID to ISID endpoints Figure 37 illustrates the behavior when using CoS with ISID to ISID endpoints. FIGURE 37 CoS Treatment Local Switching - Incoming Packet Outgoing Packet B-VLANPCP ISIDCOS B-VLANPCP ISIDCOS X Y X’ or X Y IncomingPacket B-VLAN PCP ISIDCOS X Y MPLSCloud OutgoingPacket Tunnel / VC PayloadTag Label EXP(Z) COS Vor internal priority Y B-VLAN PCP ISIDCOS Wor Y Y LEGEND: X – original B-VLAN PCP. Y – original ISID COS.
10 ISID mapping to VPLS • The outgoing outer VLAN CoS is same as the incoming packet’s outer VLAN CoS if the qos pcp encode-policy off command is configured on the outgoing interface. • The outgoing ISID CoS is the same as incoming packet’s ISID CoS. This cannot be changed by any configuration. Remote switching The following configuration guidelines should be considered for remote switching when using CoS with ISID endpoints.
Adding and removing VLANs and ESIs 10 Configuration mismatch - forwarding behavior The same ISID value must be configured on ingress and egress devices. Typically, when the MPLS egress device receives the first packet, the CAMs are programmed so that forwarding can be done in hardware. If there is a configuration mismatch, if the MPLS egress device has received a packet with an ISID that is not the same as the configured ISID, the software can detect the mismatch and not program the CAMs.
10 Adding and removing VLANs and ESIs TABLE 44 Elementn Add SVLAN Adding a VLAN to an ESI ESI encapsulation SVLAN Configuration Duplicates Decision No client ESI defined, No I-ESI provider ESI defined • I-ESI provider ESI defined Duplicates among all S-ESI belonging to the I-ESI NOT OK • OK Duplicates among all NOT OK S-ESI with no provider ESI Client ESI defined Number of SVLANs in the ESI == 0 No duplicates across all provider ESIs Number of SVLANS in the ESI >= 1 NOT OK Adding a sour
Adding and removing VLANs and ESIs 10 Deleting a VLAN TABLE 46 Deleting a VLAN VLAN type (ESI-encapsulation) Actions CVLAN Delete CVLAN from ESI SVLAN Delete SVLAN from ESI BVLAN Delete BVLAN from ESI ISID Delete ISID from ESI Deleting an ESI TABLE 47 PB PB Deleting an ESI ESI-encapsulation Actions CVLAN • SVLAN • • • • • PBB PBB SVLAN ISID • • • • • • • PBB BVLAN • • • • • Multi-Service IronWare Switching Configuration Guide 53-1003036-02 Remove ESI from any associated provid
10 Adding and removing VLANs and ESIs Valid ESI configuration and interconnection modes Figure 39 shows the allowable configurations for the ESI elements.
Adding and removing VLANs and ESIs 10 Uniqueness requirements for VLANs FIGURE 40 CVLAN uniqueness requirement Multiple CVLANs Multiple CVLANs C-ESI Multiple CVLANs Single SVLAN Default ESI Multiple CVLANs C-ESI Multiple CVLANs S-ESI C-ESI C-ESI A CVLAN in a particular C-ESI needs to be unique among all C-ESIs that are bound to the provider S-ESI CVLANs bound to no ESI (i.e.
10 Adding and removing VLANs and ESIs SVLAN uniqueness FIGURE 41 SVLAN uniqueness for IEEE 802.1ad and IEEE 802.1ah configurations Multiple SVLANs S-ESI Multiple SVLANs S-ESI Multiple CVLANs Single SVLAN I-tag S-ESI I-ESI S-ESI Multiple SVLANs C-ESI Multiple CVLANs S-ESI Multiple SVLANs Multiple SVLANs C-ESI Multiple CVLANs Multiple SVLANs S-ESI C-ESI C-ESI Multiple SVLANs I-tag I-ESI C-ESI PB 802.
Adding and removing VLANs and ESIs 10 I-tag uniqueness I-tags must be unique across all I-ESIs that are associated with a single B-ESI provider ESI, as shown in Figure 42. FIGURE 42 I-tag mappings Multiple SVLANs S-ESI Multiple SVLANs I-tag S-ESI I-ESI B-tag (B-VLAN) Multiple SVLANs I-tag S-ESI I-ESI Multiple SVLANs S-ESI 802.
10 276 Adding and removing VLANs and ESIs Multi-Service IronWare Switching Configuration Guide 53-1003036-02
Chapter Provider Backbone Bridging (PBB) Networks for the Brocade NetIron XMR and the Brocade MLX series 11 Overview The IEEE 802.1ah Provider Backbone Bridges (PBB) standard was developed to address the limitations of Provider Bridges (PB) and to add additional capabilities sought by Service Providers. When compared to a PB network, a PBB network deployment offers simplified operations, lower capital expenditures, and overall better scalability in terms of the number of supported customers.
11 Overview By adding the PBB header, PBB isolates the Service Provider and customer address spaces. This means that Ethernet switches in the core of the Service Provider network will no longer learn customer MAC addresses or use customer MAC addresses to forward customer frames to their destinations.
Backbone Edge Bridge (BEB) operation 11 A PBB network uses two types of bridges (Figure 44): Backbone Edge Bridges (BEB) and Backbone Core Bridges (BCB). As explained above, the functionality required from a BCB is the same as a standard IEEE 802.1ad PB bridge. A BEB is used at the boundary of a PBB network to add and remove the PBB header. Backbone Edge Bridge (BEB) operation A BEB containing an I-Component and a B-Component is called an IB-BEB.
11 Backbone Edge Bridge (BEB) operation Service instance A Service Instance (SI) is also known as a bridging domain. It is defined as a single flooding domain where any traffic that requires flooding is always flooded to all endpoints under the same SI. When an unknown destination packet is received at a PBB endpoint it will cause flooding of this packet to all the endpoints (source port suppressed). The following types of endpoints defined here are supported by PBB.
Backbone Edge Bridge (BEB) operation 11 Example 3: If the packet is destined to an IB-Tagged endpoint, the original tag that contains the C-VID of 100 is stripped at ingress and a PBB header (contains the B-MACs, B-Tag and I-Tag) is inserted when the packet exits through the IB-Tagged endpoint. Optionally, if S-VLAN keep mode is configured, an S-Tag will also be inserted. More details about S-VLAN keep mode is discussed in a later section.
11 Backbone Edge Bridge (BEB) operation IB-Tagged Endpoint with S-VLAN Keep mode The system can be configured with S-VLAN keep mode which indicates that packets received at the IB-Tagged endpoint from the PBB network will contain an S-Tag after the I-Tag field (see Figure 44). When such a packet is destined to a local endpoint, in addition to stripping the PBB header the S-Tag is also removed.
Backbone Edge Bridge (BEB) operation 11 Customer to ISID mapping There are two types of Customer to ISID Mapping. 1:1 Customer to ISID Mapping and N:1 Customer to ISID Mapping. Brocade NetIron XMR and Brocade MLX series only support one single flooding domain per SI regardless of which mapping is chosen. 1:1 Customer to ISID mapping is supported by default.
11 Backbone Edge Bridge (BEB) operation FIGURE 45 1:1 customer to ISID mapping N:1 Customer to ISID Mapping Interop (S-VLAN Keep Mode) The benefits of N:1 customer to ISID mapping include the following: • Multiple customers are mapped to the same SI to use the same ISID. • The S-VLAN at the ingress is carried all the way to the egress side of the PBB network. • When flooding of a packet is required, it only floods to the endpoints that have the same S-VID.
Backbone Edge Bridge (BEB) operation FIGURE 46 11 S-VLAN keep mode Port Based Untagged Frame with S-Tag Insertion With S-VLAN keep mode it is also possible to insert an S-Tag on top of whatever tag(s) the original packet may already have when it goes out into the PBB network. This is done by configuring a port-based untagged endpoint with the desired S-VID as the Port's default VID and send port based untagged packets into this port.
11 Backbone Edge Bridge (BEB) operation FIGURE 47 S-VLAN keep mode with S-Tag insertion PBB packet switching There are several scenarios on how a packet is switched within the BEB. • • • • Packet may be switched between a local endpoint and an IB endpoint of the SI. Packet may be switched between two local endpoints of the SI. Packet may be switched between two IB endpoints where the BEB is acting as a BCB. Unknown C-DA packets flooding handling.
Backbone Edge Bridge (BEB) operation FIGURE 48 11 Unknown Destination PBB Packet Handling If the PBB packet received was for an ISID that the BEB does not care about (no SI configured that matches the B-VLAN and ISID value of the PBB packet), then the packet is forwarded based on the B-Tag and the B-MACs as a regular Layer 2 packet. No attempt will be made to look into the inner MAC of the PBB packet.
11 Backbone Edge Bridge (BEB) operation MAC Learning for PBB Packets PBB packets are MAC-in-MAC packets. There are two types of MAC learning involved depending on whether the ISID involved in the received PBB packet is of any interest. If there is no such SI configured for the PBB packet's B-VLAN and ISID, only the outer MAC (B-SA) is learned via the regular Layer 2 MAC management for the corresponding B-VID.
Backbone Edge Bridge (BEB) operation 11 received that is being switched based on the outer B-MACs, will end up causing re-learning those B-MACs again and unnecessary flooding even though there may exist a constant traffic for some packet flow that is being switched based on the inner MACs that associate with these aged out B-MACs.
11 Backbone Edge Bridge (BEB) operation NOTE If a packet ingress through a C-Tagged endpoint is destined to a remote PBB node, the C-Tag PCP value will be used the same way as described above. The Internal priority setting is based on the original packet's PCP value operated by the port's PCP decode table, as explained in the Multi-Service IronWare Traffic Management Configuration Guide. The forced-PBB-PCP configuration option has no effect on the regular Layer 2 traffic using the same B-VID.
Backbone Edge Bridge (BEB) operation 11 NOTE If the packet ingress is through an untagged endpoint destined to a remote PBB node, the PCP value of “0” will be used as the I-Tag PCP value in the PBB header. I-Tag I-DEI Setting Packets ingress through an S-Tagged endpoint destined to a remote PBB node will have the DEI bit preserved from the received packet copied unto the PBB header I-Tag I-DEI field.
11 Configuring PBB S-Tag DEI Setting The packet internal drop precedence for an ingress IB endpoint is derived based on ingress PCP decode table operated on: 1. S-VLAN keep mode is set - The PBB packet's original S-VLAN's PCP value and merged with S-VLAN's DEI bit if “qos use-dei” is also configured at the ingress IB endpoint. 2. S-VLAN Keep mode is not set - The original packet's I-Tag PCP value and merged with I-Tag's I-DEI bit if “qos use-dei” is also configured at the ingress IB endpoint.
Configuring PBB 11 • VPLS-local-switching is turned on when PBB is configured. Since PBB support is internally implemented using VPLS local switching, the local switching feature cannot be turned off when PBB is configured for the given VPLS instance. • VC-mode configuration is not allowed under the PBB configuration. • ISIDs cannot be reused across VLANs under the PBB configuration.
11 Configuring PBB • The own chassis mac in disallowed. Configuring PBB policy Any global PBB specific configuration is configured using this sub-mode. Brocade(config)#router mpls Brocade(config-mpls)#vpls-policy Brocade(config-mpls-vpls-policy)#pbb Brocade(config-mpls-vpls-policy-pbb)# Syntax: [no] pbb System-wide SVLAN Tag Type The stag-type command specifies the Etype used for S-tagged packets in SVLAN-keep mode. This Etype is global.
Configuring PBB 11 Show Commands The following section discusses available show commands. Show mpls vpls detail The show mpls vpls detail command displays information about the operation state of the VPLS instance in regard to the local endpoints.
11 Configuring PBB Show mac vpls X b-mac HHHH.HHHH.HHHH The show mac vpls X b-mac command is used to display the C-MACs learned per B-MAC per VPLS instance. Brocade(XMR12)#show mac vpls 1 b-mac 0000.B000.0201 Total VPLS mac entries associated with b-mac 0000.B0000.0201: 2 MAC Address =========== 0000.0404.0000 0000.0408.0000 Port ==== 1/1 1/1 Vlan(In-Tag)/Peer ================= 300 200 ISID ==== 30000 30000 Age === 10 20 Syntax: show mac vpls X b-mac hhhh.hhhh.hhhh hhhh.hhhh.
Configuring PBB NHT IP Index 10.20.20.1 0 N.A. 1 N.A. 2 N.A. 3 MAC Address VLAN 000c.dbf5.c773 000c.dbf4.0000 000c.dbf5.0000 000c.dbf6.0000 Out I/F Out 1 1/20 50 N.A. 50 N.A. 60 N.A. 11 Port TNL CNT XC CNT LABEL EXP/PCP 1/20 0 1 N.A. 0 3 0 N.A. 0 2 0 N.A. 0 1 5 Syntax: show nht Show nht vlan vlan_id The show nht vlan command allows the nht entry to be displayed based with those that have the matching VLAN ID.
11 802.1ag over PBB OAM Show service-type-table output changes The output of show service-type-table command displays the Forced VLAN Action field programmed in the service type table entry.
802.1ag over PBB OAM 11 Configuration scenarios Within a PBBN (see Figure 49), the encapsulation performed by Provider Instance Ports (PIPs) also encapsulates CFM frames sourced by customers attached to Customer Network Ports (CNPs). The encapsulation of S-VLAN and C-VLAN CFM frames hides them from the PBBN. All eight levels of CFM frames generated in customer networks are carried over the backbone as encapsulated data and may be used by customer networks.
11 802.1ag over PBB OAM FIGURE 51 Maintenance Association (MA) Categories S-VLAN, C-VLAN, and Link MAs (Figure 52) • • • • Customers and Provider (PB) share the same MD level space. CFM processing scope within Customer/PB network is determined by the MD level selection. The PB network normally only processes provider MD level OAM frames. Customer C-VLAN OAM frames use customer MD level and are normally not processed by the PB network. • S-VLAN CFM frames are only visible where S-TAGs are processed.
802.1ag over PBB OAM 11 B-VLAN MAs (Figure 53) • B-VLAN MAs manage the B-VLANs within a single PBBN. • The scope of these 802.1ag frames is the PBB network only. These frames do not leave the PBB network. • These CFM frames are only visible within the PBBN where the B-TAG is being processed. I-SID MAs (Figure 53) • Backbone service instance CFM frames are only visible within the PBBN where the I-TAG is being processed.
11 802.1ag over PBB OAM Faults can be detected using Continuity Check messages at any of the four MA categories. Once a fault is detected, Link Trace can be used to narrow down the location of the fault. Depending on the location of the fault, a different MA category may need to be used to further isolate the location of the fault. 802.1ag for Link MA A new MA type is supported for Link MA.
802.1ag over PBB OAM Priority: MEP ==== 10 3 Direction ======== DOWN MAC ========= 0012.f2f7.3900 Brocade#show cfm connectivity Domain: D10 Index: 3 Level: 7 Maintenance association: MA MA Index: 1 CCM interval: 10000 ms LINK MA ID: 0 Priority: 3 RMEP MAC VLAN/PEER ==== ========== =========== 1 0012.f2f7.3861 0 PORT ===== ethe 1/1 AGE ===== 54020 PORT ===== 1/1 11 PORT-STATUS-TLV =============== N SLOTS ===== 1 STATE ======= OK 802.
11 802.1ag over PBB OAM Brocade# show cfm Domain: D1 Index: 1 Level: 3 Maintenance association: MA Ma Index: 1 CCM interval: 10000 ms PBB-VPLS ID: 100 Priority: 3 MEP Direction MAC ==== ======== ========= 1 UP 0012.f2f7.
802.1ag over PBB OAM 11 • Link-trace, loopback and delay-measurement for ISID is supported. • SVLAN keep-mode is supported. • When MEP is configured on a VPLS instance with sub-second CCM timer, the MIP flooding should be turned off. When there is no MEP and it is a sub-second-timer, then dot1ag flooding should be turned on.
11 802.1ag over PBB OAM Sample configuration output Syntax: show cfm domain domainName ma maName mep-id mepId Brocade # show cfm domain D2 ma 1 mep-id 5000 Domain: customer Index: 1 Level: 7 Maintenance association: admin Ma Index: 2 CCM interval: 10000 ms ESI aaa VLAN ID: 100 Priority: 7 MEP Direction MAC ==== ========= ========= 1 DOWN 0024.3863.
802.1ag over PBB OAM 11 Sample Output: CES-2#show cfm connectivity domain customer ma admin rmep-id 1 Output: Domain: customer Level: 7 Maintenance association: admin VLAN VLAN/VPLS/VLL ID: 100 Priority: 7 CCM interval: 100ms RMEP MAC PORT Oper Age CCM RDI State Val Cnt ==== ========= ====== ===== ===== ======= ========== 1 0024.3863.
11 802.1ag over PBB OAM 2. Create a maintenance domain with a specified name CUST_1 and level 7. Brocade(config-cfm)#domain-name CUST_1 level 7 3. Create a maintenance association within a specified domain of vlan-id 10 with a priority 3. Brocade(config-cfm-md-CUST_1)#ma-name ma_5 vlan-id 10 priority 3 4. Set the time interval between successive Continuity Check Messages. The default is 10-seconds. Brocade(config-cfm-md-CUST_1-ma-ma_5)#ccm-interval 10-second 5. Configure a MEP on port 1/1 and vlan 10.
11 802.1ag over PBB OAM 2. Create a maintenance domain with a specified name CUST_1 and level 7. Brocade(config-cfm)#domain-name CUST_1 level 7 3. Create a maintenance association within a specified domain for vpls-id 20 with a priority 3. Brocade(config-cfm-md-CUST_1)#ma-name ma_5 pbb-vpls 20 priority 3 4. Set the time interval between successive Continuity Check Messages (CCM). The default is 10 seconds.
11 802.1ag over PBB OAM Forwarded Egress Egress Action Nexthop ---------------------------------------------------------------Type Control-c to abort 1 000c.dbe2.8a00 10.1.1.1 IgrOK RLY_HIT Not Forwarded Destination 000c.dbe2.8a00 reached Syntax: cfm loopback domain NAME ma MA-NAME scr-mep mep-id {target-mip HH:HH:HH:HH:HH:HH | targetmep mep-id} [number number] [timeout timeout] Brocade#cfm loopback domain CUST_1 ma ma_5 src-mep 1 target-mep 2 DOT1AG: Sending 10 Loopback to 000c.dbe2.
802.1ag over PBB OAM 11 Configuration for PE Devices Configuring PEB-1 The local VPLS configuration will be the same as shown in the previous deployment scenario. If the local VPLS configuration is not done prior to configuring maintenance association, the MA configuration is not allowed. Also, the port and vlan in the MEP configuration should exist in local VPLS configuration prior to MEP configuration. Otherwise, it is not allowed.
11 802.1ag over PBB OAM Deployment Scenario-3 (MIPs on BEBs) In Figure 55 BEBs can work as MIP for the UP MEPs configured on PEs in the previous deployment scenario.
802.1ag over PBB OAM 11 3. Create a maintenance association within a specified domain of pbb-vpls 20 with priority 3. Brocade(config-cfm-md-PROVIDER_1)#ma-name ma_8 pbb-vpls 20 priority 3 4. Set the time interval between successive Continuity Check Messages. The default is 10-seconds. Brocade(config-cfm-md-PROVIDER_1-ma-ma_8)#ccm-interval 10-second The above configuration will create SVID MIPs on BEBs. You can use linktrace to BEB MIPs from PE MEPs to further isolate the fault location.
11 802.1ag over PBB OAM Deployment Scenario-5 (BVLAN MEPs on BEBs and MIP on BCBs) BVLAN CFM configuration will be similar to regular VLAN and it will support both MEP and MIP functionality. Show Commands The show cfm command provides the following output. Brocade#show cfm Domain: md2 Level: 6 Maintenance association: ma2 CCM interval: 10000 ms PBB-VPLS ID: 100 Priority: 4 MEP Direction MAC ==== ========= ========= 2 UP 000c.dbf3.
802.1ag over PBB OAM 11 CFM port (VL800000) PBB-VPLS 100 Brocade# Syntax: show cfm domain domain-name ma ma-name Configuring STP under an ESI VLAN STP can also be configured under a VLAN that is part of a user-configured ESI. For example, to enable spanning tree on a VLAN that is part of an ESI, configure the following commands.
11 316 802.
Chapter 12 Configuring Spanning Tree Protocol Table 48 displays the individual Brocade devices and the STP features they support. TABLE 48 Supported Brocade STP features Features supported Brocade NetIron XMR Series Brocade MLX Series Brocade NetIron CES 2000 Series BASE package Brocade NetIron CES 2000 Series ME_PREM package Brocade NetIron CES 2000 Series L3_PREM package Brocade NetIron CER 2000 Series Base package Brocade NetIron CER 2000 Series Advanced Services package IEEE 802.
12 IEEE 802.
IEEE 802.1D Spanning Tree Protocol (STP) 12 • Globally – Affects all VLANs on the Brocade device. • Individual VLAN – Affects all ports within the specified VLAN. When you enable or disable STP within a VLAN, the setting overrides the global setting. Thus, you can enable STP for the ports within a VLAN even when STP is globally disabled, or disable the ports within a port-based VLAN when STP is globally enabled. • Individual port – Affects only the individual port.
12 IEEE 802.1D Spanning Tree Protocol (STP) Enabling or disabling STP on a port Use the following procedure to disable or enable STP on an individual port. NOTE If you change the STP state of the primary port in a LAG group, the change affects all ports in the LAG group. To enable STP on an individual port, enter commands such as the following.
IEEE 802.1D Spanning Tree Protocol (STP) TABLE 50 12 Default STP bridge parameters (Continued) Parameter Description Default and valid values Hello Time The interval of time between each configuration BPDU sent by the root bridge. 2 seconds Possible values: 1 – 10 seconds Priority A parameter used to identify the root bridge in a spanning tree (instance of STP). The bridge with the lowest value has the highest priority and is the root.
12 IEEE 802.1D Spanning Tree Protocol (STP) NOTE The hello-time value parameter applies only when the device or VLAN is the root bridge for its spanning tree. Changing STP port parameters To change the path and priority costs for a port, enter commands such as the following.
IEEE 802.1D Spanning Tree Protocol (STP) 12 Enabling Root Guard Root Guard is configured on a per interfaces basis. To enable Root Guard, enter a command such as the following. Brocade(config)# interface ethernet 5/5 Brocade(config-if-e10000-5/5) spanning-tree root-protect Syntax: [no] spanning-tree root-protect Enter the no form of the command to disable Root Guard on the port.
12 IEEE 802.1D Spanning Tree Protocol (STP) For example, the original timeout period on a device was configured for 60 seconds. The port encounters a superior BPDU and the timer starts. Issuing a show span root-protect CLI command displays the following information. Brocade(config)#show span root-protect Port VLAN Current State 1/4 1 Inconsistent state (56 seconds left on timer) While the timer is in use, the timeout period is changed to 30 seconds through the issue of the following command.
IEEE 802.1D Spanning Tree Protocol (STP) 12 BPDU Guard STP protection provides the ability to prohibit an end station from initiating or participating in an STP topology. The Bridge Protocol Data Units (BPDU) Guard is used to keep all active network topologies predictable. NOTE The feature is also available for MSTP and RSTP. STP detects and eliminates logical loops in a redundant network by selectively blocking some data paths and allowing only some data paths to forward traffic.
12 IEEE 802.1D Spanning Tree Protocol (STP) Enabling BPDU Guard and disabling a port that receives BPDUs You can enable BPDU Guard on a port and at the same time configure a port to be disabled when it receives a BPDU. Enter the following commands.
IEEE 802.1D Spanning Tree Protocol (STP) 12 protect Show STP BPDU Guard information Brocader# show span protect Port Disable Port on BPDU Rx Current Port State 1/1 No down 1/2 Yes down 1/3 No up 1/4 Yes up Syntax: show spanning-tree protect The command shows the following information. TABLE 52 CLI display of show spanning-tree bp This field... Displays...
12 IEEE 802.1D Spanning Tree Protocol (STP) When the spanning-tree protect re-enable is issued to re-enable a port, the following Syslog messages are generated. Sep 9 18:43:21:I:STP: BPDU Guard re-enabled on ports ethe 1/4 Sep 9 18:43:23:I:System: Interface ethernet 1/4, state up Checking for traps The following SNMP traps are generated for BPDU Guard.
IEEE 802.1D Spanning Tree Protocol (STP) 12 To display only ports blocked by the STP protocol, enter the following command at any level of the CLI.
12 IEEE 802.1D Spanning Tree Protocol (STP) TABLE 53 CLI display of STP information (Continued) This field... Displays... Bridge MaxAge sec The number of seconds this bridge waits for a hello message from the root bridge before deciding the root has become unavailable and performing a reconvergence. Bridge Hello sec The interval between each configuration BPDU sent by the bridge. Bridge FwdDly sec The number of seconds this bridge waits following a topology change and consequent reconvergence.
IEEE 802.1D Spanning Tree Protocol (STP) TABLE 53 12 CLI display of STP information (Continued) This field... State Displays... The port’s STP state. The state can be one of the following: BLOCKING – STP has blocked Layer 2 traffic on this port to prevent a loop. The device or VLAN can reach the root bridge using another port, whose state is FORWARDING. When a port is in this state, the port does not transmit or receive user frames, but the port does continue to receive STP BPDUs.
12 IEEE 802.1D Spanning Tree Protocol (STP) Displaying detailed STP information for each interface To display the detailed STP information, enter the following command at any level of the CLI.
IEEE 802.1D Spanning Tree Protocol (STP) TABLE 54 12 CLI display of detailed STP information for ports This field... Displays... VLAN ID The VLAN that contains the listed ports and the number of STP instances on this VLAN. The STP type can be one of the following: • Proprietary multiple Spanning Tree • IEEE 802.1Q Single Spanning Tree (SSTP) NOTE: If STP is disabled on a VLAN, the command displays the following message instead: “Spanning-tree of port-vlan vlan-id is disabled.
12 IEEE Single Spanning Tree (SSTP) IEEE Single Spanning Tree (SSTP) By default, each port-based VLAN on the Brocade device runs a separate spanning tree, which you can enable or disable on an individual VLAN basis. Alternatively, you can configure the Brocade device to run a single spanning tree across all of its ports and VLANs. The SSTP feature is especially useful for connecting a Brocade device to third-party devices that run a single spanning tree in accordance with the 802.1q specification.
IEEE Single Spanning Tree (SSTP) 12 To change an STP parameter for a specific port, enter commands such as the following. Brocade(config) spanning-tree single ethernet 1/1 priority 10 The commands shown above override the global setting for STP priority and set the priority to 10 for port 1/1.
12 SuperSpan™ SuperSpan™ SuperSpan is a Brocade STP enhancement that allows Service Providers (SPs) to use STP in both SP networks and customer networks. The SP devices are Brocade devices and are configured to tunnel each customer’s STP BPDUs through the SP. From the customer's perspective, the SP network is a loop-free non-blocking device or network. The SP network behaves like a hub in the sense that the necessary blocking occurs in the customer network, not in the SP.
SuperSpan™ 12 BPDU forwarding When the Brocade device receives a customer’s BPDU on a boundary interface, the Brocade device changes the destination MAC address of the BPDU from the bridge group address (00-00-00-00-00-00) as follows: • The first byte (locally administered bit) is changed from 01 to 03, to indicate that the BPDU needs to be tunneled. • The fourth and fifth bytes are changed to the customer STP ID specified on the boundary interface.
12 SuperSpan™ In this example, a customer has two links to the SP. Since the SP is running SuperSpan, the SP ports enter the Preforwarding state briefly to allow the customer ports connected to the SP to detect the Layer 2 loop and block one of the ports. NOTE If you add a new Brocade device to a network that is already running SuperSpan, you must enable SuperSpan on the Brocade device, at least on the VLANs that will be tunneling the customer traffic.
SuperSpan™ FIGURE 59 12 Customer and SP using multiple spanning trees Both the customer and SP regions are running multiple spanning trees (one per port-based VLAN) in the Layer 2 switched network. The customer network contains VLANs 10 and 20 while the SP network contains VLANs 100 and 200. Customer traffic from VLAN 10 and VLAN 20 is aggregated by VLAN 100 in the SP since the boundary ports, 2/1 on R100 and R200, are untagged members of VLAN 100.
12 SuperSpan™ Customer uses multiple spanning trees but SP uses single STP Figure 60 shows an example of SuperSpan where the customer network uses multiple spanning trees while the SP network uses Single STP. FIGURE 60 Customer using multiple spanning trees and SP using Single STP Customer traffic from different VLANs is maintained by different spanning trees, while the SP network is maintained by a single spanning tree.
SuperSpan™ 12 Customer uses single STP but SP uses multiple spanning trees Figure 61 shows an example of SuperSpan where the customer network uses Single STP while the SP uses multiple spanning trees. FIGURE 61 Customer using Single STP and SP using multiple spanning trees In this setup, the customer network is running a single spanning tree for VLANs 10 and 20. The traffic from VLAN 10 and 20 will be carried, or aggregated by VLAN 100 at the SP’s network.
12 SuperSpan™ Customer and SP use single STP Figure 62 shows an example of SuperSpan where the customer network and SP both use Single STP. FIGURE 62 Customer and SP using Single STP In this setup, both the customer and SP networks are running a single spanning tree at Layer 2. The traffic from VLAN 10 and 20 will be carried, or aggregated by VLAN 100 at the SP network as in the previous scenario.
SuperSpan™ 12 These commands configure two interfaces on the Brocade device as SuperSpan boundary interfaces. Interface 1/1 is a boundary interface with customer 1. Interface 1/2 is a boundary interface with customer 2. Each boundary interface is associated with a number, which is the SuperSpan ID. The SuperSpan ID identifies the instance of SuperSpan you are associating with the interface. Use the same SuperSpan ID for each boundary interface with the same customer.
12 SuperSpan™ Displaying SuperSpan information To display the boundary interface configuration and BPDU statistics, enter the following command. Brocade(config)# show super-span CID 1 Boundary Ports: Port Customer Tunnel BPDU Rx BPDU Rx 1/1 1 1 1/2 0 0 Total 1 1 CID 2 Boundary Ports: Port Customer BPDU Rx 2/1 0 2/2 0 Total 0 Tunnel BPDU Rx 3 0 3 In this example, the Brocade device has two SuperSpan customer IDs. Syntax: show superspan [cid num] The cid num parameter specifies a SuperSpan customer ID.
STP feature configuration 12 STP feature configuration Spanning Tree Protocol (STP) features extend the operation of standard STP, enabling you to finetune standard STP and avoid some of its limitations. This section describes how to configure these parameters using the CLI. Fast port span When STP is running on a device, message forwarding is delayed during the spanning tree recalculation period following a topology change.
12 STP feature configuration • An STP Configuration BPDU has been received on the port, thus indicating the presence of another bridge on the port. You also can explicitly exclude individual ports from Fast Port Span if needed. For example, if the only uplink ports for a wiring closet switch are Gbps ports, you can exclude the ports from Fast Port Span. Disabling and re-enabling fast port span Fast Port Span is a system-wide parameter and is enabled by default.
STP feature configuration 12 To re-enable Fast Port Span on a port, enter a command such as the following. Brocade(config)#no fast port-span exclude ethernet 1 Brocade(config)#write memory This command re-enables Fast Port Span on port 1 only and does not re-enable Fast Port Span on other excluded ports. You also can re-enable Fast Port Span on a list or range of ports using the syntax shown above this example.
12 STP feature configuration Active uplink port failure The active uplink port is the port elected as the root port using the standard STP rules. All other ports in the group are redundant uplink ports. If an active uplink port becomes unavailable, Fast Uplink Span transitions the forwarding of traffic to one of the redundant ports in the Fast Uplink Span group in one second bypassing listening and learning port states.
STP feature configuration 12 • FSX 800 and FSX 1600 chassis devices – slotnum/portnum • ICX devices – slotnum/portnum • FESX compact switches – portnum This example configures four ports, 4/1 – 4/4, as a Fast Uplink Span group. In this example, all four ports are connected to a wiring closet switch. Only one of the links is expected to be active at any time. The other links are redundant.
12 PVST or PVST+ compatibility Brocade(config-vlan-10)#fast uplink-span ethernet 8/1 to 8/2 Syntax: [no] fast uplink-span ethernet To check the status of Fast Uplink Span for a specified VLAN. Brocade(config-vlan-2)#show span vlan 2 fast-uplink-span STP instance owned by VLAN 2 Global STP (IEEE 802.
PVST or PVST+ compatibility FIGURE 63 12 Interaction of IEEE 802.1Q, PVST, and PVST+ regions VLAN Tags and dual mode The dual-mode feature enables the port to send and receive both tagged and untagged frames on a port. When the dual-mode feature is enabled, the port is an untagged member of one of its VLANs and is at the same time a tagged member of all its other VLANs. The untagged frames are supported on the port’s Port Native VLAN.
12 PVST or PVST+ compatibility Enabling PVST+ support PVST+ support is automatically enabled when the port receives a PVST BPDU. You can manually enable the support at any time or disable the support if desired. If you want a tagged port to also support IEEE 802.1Q BPDUs, you need to enable the dual-mode feature on the port. The dual-mode feature is disabled by default and must be enabled manually.
PVST or PVST+ compatibility TABLE 56 12 CLI display of PVST+ information This field... Displays... Port The port number. NOTE: The command lists information only for the ports on which PVST+ support is enabled. Method The method by which PVST+ support was enabled on the port. The method can be one of the following: • Set by configuration – You enabled the support. • Set by auto-detect – The support was enabled automatically when the port received a PVST+ BPDU.
12 PVST or PVST+ compatibility • Process tagged PVST BPDUs for VLANs 2, 3, and 4. • Drop untagged PVST BPDUs for VLAN 1. Untagged port using VLAN 2 as port native VLAN In Figure 65, a port’s Port Native VLAN is not VLAN 1. In this case, VLAN 1 uses tagged frames and VLAN 2 uses untagged frames. FIGURE 65 Port Native VLAN 2 for untagged BPDUs To implement this configuration, enter the following commands on the Brocade device.
802.1s Multiple Spanning Tree Protocol 12 In the configuration above, all PVST BPDUs associated with VLAN 1 would be discarded. Since IEEE BPDUs associated with VLAN 1 are untagged, they are discarded because the ports in VLAN 1 are tagged. Effectively, the BPDUs are never processed by the Spanning Tree Protocol. STP assumes that there is no better bridge on the network and sets the ports to FORWARDING. This could cause a Layer 2 loop. The following configuration is correct.
12 802.1s Multiple Spanning Tree Protocol FIGURE 66 MSTP configured network The following definitions describe the STP instances that define an MSTP configuration: Common Spanning (CST) – MSTP runs a single instance of spanning tree, called the Common Spanning Tree (CST), across all the bridges in a network. This instance treats each region as a single bridge. It all other ways, it operates exactly like Rapid Spanning Tree (RSTP).
802.1s Multiple Spanning Tree Protocol 12 MSTP can be configured on a device with MRP. However, they are mutually exclusive on a specific VLAN. Also, MSTP can be configured on a port that is part of a LAG following the same rules as used for STP and RSTP.
12 802.1s Multiple Spanning Tree Protocol Configuring an MSTP instance An MSTP instance is configured with an MSTP ID for each region. Each region can contain one or more VLANs. To configure an MSTP instance and assign a range of VLANs, use a command such as the following at the Global Configuration level.
802.1s Multiple Spanning Tree Protocol 12 Setting the MSTP global parameters MSTP has many of the options available in RSTP as well as some unique options. To configure MSTP Global parameters for all instances on a device. Brocade(config)# mstp force-version 0 forward-delay 10 hello-time 4 max-age 12 max-hops 9 Syntax: [no] mstp force-version mode-number forward-delay value hello-time value max-age value max-hops value The force-version parameter forces the bridge to send BPDUs in a specific format.
12 802.1s Multiple Spanning Tree Protocol The slot/port parameter specifies a port or range of ports to be configured for point-to-point links to increase the speed of convergence. Disabling MSTP on a port To disable MSTP on a specific port, use a command such as the following at the Global Configuration level. Brocade(config)# mstp disable 2/1 Syntax: [no] mstp disable slot/port The slot/port variable specifies the location of the port that you want to disable MSTP for.
802.
12 802.
802.1s Multiple Spanning Tree Protocol 12 Displaying MSTP statistics MSTP statistics can be displayed using the commands shown below. To display all general MSTP information, enter the following command.
12 802.
802.1s Multiple Spanning Tree Protocol 12 The following example displays MSTP information for a specified MSTP instance.
12 802.1s Multiple Spanning Tree Protocol TABLE 57 Output from show MSTP (Continued) This field... Displays... Root Hop Cnt Current hop count from the root bridge. Root Bridge Bridge identifier of the root bridge. ExtPath Cost The configured path cost on a link connected to this port to an external MSTP region. Regional Root Bridge The Regional Root Bridge is the MAC address of the Root Bridge for the local region.
802.1s Multiple Spanning Tree Protocol 12 Displaying MSTP information for CIST instance 0 Instance 0 is the Common and Internal Spanning Tree Instance (CIST). When you display information for this instance there are some differences with displaying other instances. The following example displays MSTP information for CIST Instance 0.
12 802.1s Multiple Spanning Tree Protocol To display details about the MSTP that is configured on the device, enter the following command.
MSTP support for PBB 12 Interoperability between MSTP and Single STP or Single RSTP • MSTP can interoperate with SSTP or a RSTP. However it is recommended to assign all VLANs to CIST (MSTP instance 0) while operating in a SSTP or a RSTP domain since only CIST participates in the convergence with SSTP or a RSTP.
12 MSTP support for PBB • MSTP should not be configured for (1) topology groups having layer 2 (L2) member VLANs (2) member VLANs configured in a topology group. If a topology group is configured with a master vlan running MSTP, layer 2 (L2) VLANs should not be configured as members until MSTP is disabled on the master VLAN of this topology group. Such configurations via CLI are blocked. Use case scenario Figure 68 displays the use case.
MSTP support for PBB Multi-Service IronWare Switching Configuration Guide 53-1003036-02 12 371
12 MSTP support for PBB FIGURE 69 AS, CS, and ES Physical Connections 10 GbE LA G CS CS 10 G bE or AS 1 GbE LAG or ES ES ES ES Edge MSTP in a PB network The following deployment scenario is a case where MSTP is deployed for a single S-VLAN in a PB network. PBB traffic uses S-VLAN 200. The procedure to configure the nodes in the topology are discussed below.
MSTP support for PBB 12 High availability MSTP supports MP switchover and hitless software upgrade. When an MSTP root bridge undergoes MP switchover and hitless upgrade, there will be no break in transmission of the MSTP BPDU from it during reboot of the line cards. Due to this, there will be no re-convergence of the topology and no disruption in traffic. MSTP PBB with multi region feature also supports MP switchover and hitless software upgrade. There will be no traffic disruption during an upgrade.
12 MSTP support for PBB Each variable has the following range. • • • • • • Instance ID: 0-4094 (0 for CIST and 1-4094 for MSTI) Path Cost: 1-200000000 Port Priority: 0-240 in the increments of 16 Instance Priority Value: 0-61440 in the increments of 4096 VLAN ID: 1-4090 VPLS ID: 1-4294967294 Executing the above command with a [no] will delete the configured MST instance to VLAN mapping.
MSTP support for PBB 12 Brocade_AS-2(config)#router mpls Brocade_AS-2(config-mpls)#vpls pb-svlan 1 Brocade_AS-2(config-mpls-vpls-pb-svlan)#pbb Brocade_AS-2(config-mpls-vpls-pb-svlan-pbb)#vlan 200 Brocade_AS-2(config-mpls-vpls-pb-svlan-vlan-200)#tag ethernet 1/1 ethernet 1/3 MSTP Configuration Brocade_AS-2(config)#mstp-region 2 Brocade_AS-2(config-mstp-region-2)#mstp-region Brocade_AS-2(config-mstp-region-2)#mstp-region Brocade_AS-2(config-mstp-region-2)#mstp-region Brocade_AS-2(config-mstp-region-2)#mstp
12 MSTP support for PBB Configuring CE-1 and CE-2 C-VLAN Configuration Configure a regular Layer 2 VLAN with 300 (C-VLAN) and add port 1/1(CE-1) and 1/4 (CE-2) to it.
MSTP support for PBB 12 Brocade_AS2(config-mstp-region-2)#mstp-region admin-pt2pt-mac ethernet 1/1 ethernet 1/3 Brocade_AS2(config-mstp-region-2)#mstp-region start Configuring ES1 Brocade_ES1(config)#int e 1/1 Brocade_ES1(config-if-e1000-1/1)#port-type customer-edge Brocade_ES1(config-if-e1000-1/1)#int e 1/4 Brocade_ES1(config-if-e1000-1/4)#port-type customer-edge Brocade_ES1(config-if-e1000-1/4)#esi cvlan1 encap cvlan Brocade_ES1(config-esi-cvlan1)#vlan 300 Brocade_ES1(config-esi-cvlan1-vlan-300)#tag e
12 MSTP support for PBB Brocade_CE-2(config)#mstp admin-pt2pt-mac ethernet 1/4 Brocade_CE2(config)#mstp start 378 Multi-Service IronWare Switching Configuration Guide 53-1003036-02
12 MSTP support for PBB Configuring MSTP in a PBB network The following deployment scenario is a case where MSTP is deployed for a single B-VLAN in a PBB network. PBB traffic uses B-VLAN 100. The procedure to configure the nodes in the topology are discussed below.
12 MSTP support for PBB Brocade_AS-1(config-mpls-vpls-pbb-bvlan-vlan-100-isid-101010)#tagged ethernet 1/1 ethernet 1/2 Brocade_AS-1(config)#router mpls Brocade_AS-1(config-mpls)#vpls pbb-bvlan1 2 Brocade_AS-1(config-mpls-vpls-pbb-bvlan)#pbb Brocade_AS-1(config-mpls-vpls-pbb-bvlan-pbb) #vlan 100 isid 10101 Brocade_AS-1(config-mpls-vpls-pbb-bvlan-vlan-100-isid-101010)#tagged ethernet 1/1 ethernet 1/2 Brocade_AS-1(config)#router mpls Brocade_AS-1(config-mpls)#vpls pbb-bvlan2 3 Brocade_AS-1(config-mpls-vpls-p
MSTP support for PBB Brocade_CS-1(config-mstp-region-1)#mstp-region Brocade_CS-1(config-mstp-region-1)#mstp-region Brocade_CS-1(config-mstp-region-1)#mstp-region 1/2 Brocade_CS-1(config-mstp-region-1)#mstp-region 12 rev 1 instance 1 vlan 100 admin-pt2pt-mac ethernet 1/1 to start Configuring the Brocade NetIron CER and Brocade NetIron CES Configuring AS1 NOTE The AS-2 configuration is similar to the AS-1 configuration.
12 MSTP support for PBB Show commands The output of the following commands include the information about the configured Layer 2 VLANs, VPLS VLANs (Brocade MLX series and Brocade NetIron XMR) or ESI VLANs (Brocade NetIron CER and Brocade NetIron CES) within MSTP. Show MSTP config The show mstp config command displays the MSTP configuration as it appears in the running config.
MSTP support for PBB 12 Show MSTP the show mstp command displays information about all the MSTP regions for all configured instances. For Brocade MLX series and Brocade NetIron XMR The following example displays information about all the MSTP regions for all configured instances.
12 MSTP support for PBB MSTP Instance 1 - VPLS VLANs: VPLS 1 VLAN 200 ---------------------------------------------------------------------------Bridge Max RegionalRoot IntPath Designated Root Root Identifier Hop Bridge Cost Bridge Port Hop hex cnt hex hex cnt 8001001bedaf7800 20 8001001bedaf7800 0 8001001bedaf7800 Root 20 Port Num 2/5 3/5 Pri PortPath Cost 128 20000 128 20000 P2P Mac F F Edge Role State Port F DESIGNATED FORWARDING F DESIGNATED FORWARDING Designated cost 0 0 Designated bridge 800100
MSTP support for PBB 12 For Brocade NetIron CER and Brocade NetIron CES Brocade# show mstp Region 1: ----------MSTP Instance 0 (CIST) - ESI VLAN Scope: None ---------------------------------------------------------------------------Bridge Bridge Bridge Bridge Bridge Root Root Root Root Identifier MaxAge Hello FwdDly Hop MaxAge Hello FwdDly Hop hex sec sec sec cnt sec sec sec cnt 8000001bedaf7800 20 2 15 20 20 2 15 20 Root ExtPath RegionalRoot IntPath Designated Root Bridge Cost Bridge Cost Bridge Port hex
12 MSTP support for PBB 3/5 128 20000 F F DESIGNATED FORWARDING 0 8001001bedaf7800 The following example displays MSTP information for blocked ports only, in an ESI VLAN configuration.
MSTP support for PBB 8000001bedaf7800 0 Port Num 2/5 3/5 Pri PortPath Cost 128 20000 128 20000 8000001bedaf7800 0 P2P Mac F F Edge Role State Port F DESIGNATED FORWARDING F DESIGNATED FORWARDING 12 8000001bedaf7800 Root Designated cost 0 0 Designated bridge 8000001bedaf7800 8000001bedaf7800 MSTP Instance 1 - VPLS VLANs: VPLS 1 VLAN 100 ---------------------------------------------------------------------------Bridge Max RegionalRoot IntPath Designated Root Root Identifier Hop Bridge Cost Bridge Port
12 MSTP support for PBB The following example displays MSTP information for blocked ports only, in region “1” in a VPLS VLAN configuration.
MSTP support for PBB hex sec 8000001bedaf7800 20 sec 2 Root ExtPath Bridge Cost hex 8000001bedaf7800 0 Port Num 2/5 3/5 Pri PortPath Cost 128 20000 128 20000 P2P Mac F F sec 15 cnt 20 sec 20 RegionalRoot IntPath Bridge Cost hex 8000001bedaf7800 0 Edge Role State Port F DESIGNATED FORWARDING F DESIGNATED FORWARDING sec 2 sec 15 12 cnt 20 Designated Root Bridge Port hex 8000001bedaf7800 Root Designated cost 0 0 Designated bridge 8000001bedaf7800 8000001bedaf7800 MSTP Instance 1 - ESI VLANs: es
12 MSTP support for PBB The following example shows MSTP information for blocked ports only, filtered for region “1” in an ESI VLAN configuration.
MSTP support for PBB 12 Show MSTP detail The show mstp detail command displays information about all of the MSTP regions for all configured instances in detail.
12 MSTP support for PBB Port 2/5 - Role: DESIGNATED - State: FORWARDING PathCost 20000, Priority 128, OperEdge F, OperPt2PtMac F, Boundary F Designated - Root 8000001bedaf7800, RegionalRoot 8000001bedaf7800, Bridge 8000001bedaf7800, ExtCost 0, IntCost 0 ActiveTimers - helloWhen 2 MachineState - PRX-RECEIVE, PTX-IDLE, PPM-SENDING_RSTP, PIM-CURRENT PRT-ACTIVE_PORT, PST-FORWARDING, TCM-ACTIVE BPDUs - Rcvd MST 811, RST 0, Config 0, TCN 0 Sent MST 811, RST 0, Config 0, TCN 0 Port 3/5 - Role: DESIGNATED - State
MSTP support for PBB 12 Port 3/5 - Role: DESIGNATED - State: FORWARDING PathCost 20000, Priority 128, OperEdge F, OperPt2PtMac F, Boundary F Designated - Root 8000001bedaf7800, RegionalRoot 8000001bedaf7800, Bridge 8000001bedaf7800, ExtCost 0, IntCost 0 ActiveTimers - helloWhen 2 MachineState - PRX-RECEIVE, PTX-IDLE, PPM-SENDING_RSTP, PIM-CURRENT PRT-ACTIVE_PORT, PST-FORWARDING, TCM-ACTIVE BPDUs - Rcvd MST 811, RST 0, Config 0, TCN 0 Sent MST 811, RST 0, Config 0, TCN 0 MSTP Instance 1 - ESI VLANs: esi pb
12 MSTP support for PBB Designated - RegionalRoot 8001001bedaf7800, IntCost 0 Bridge 8001001bedaf7800 ActiveTimers MachineState - PIM-CURRENT, PRT-ACTIVE_PORT, PST-FORWARDING, TCM-ACTIVE Port 3/5 - Role: DESIGNATED - State: FORWARDING PathCost 20000, Priority 128 Designated - RegionalRoot 8001001bedaf7800, IntCost 0 Bridge 8001001bedaf7800 ActiveTimers MachineState - PIM-CURRENT, PRT-ACTIVE_PORT, PST-FORWARDING, TCM-ACTIVE Syntax: show mstp detail Show MSTP detail region The show mst detail region comm
MSTP support for PBB 12 ActiveTimers MachineState - PIM-CURRENT, PRT-ACTIVE_PORT, PST-FORWARDING, TCM-ACTIVE Port 3/5 - Role: DESIGNATED - State: FORWARDING PathCost 20000, Priority 128 Designated - RegionalRoot 8001001bedaf7800, IntCost 0 Bridge 8001001bedaf7800 ActiveTimers MachineState - PIM-CURRENT, PRT-ACTIVE_PORT, PST-FORWARDING, TCM-ACTIVE Syntax: show mstp detail region region-id For Brocade NetIron CER and Brocade NetIron CES Brocade_DUT# show mstp detail region 1 Region 1: ----------MSTP Instan
12 Commands Syntax: show mstp detail region region-id Commands The following commands support the features described in this chapter: • show mstp • show spanning-tree 396 Multi-Service IronWare Switching Configuration Guide 53-1003036-02
show mstp 12 show mstp Displays Multiple Spanning Tree Protocol (MSTP) information. Syntax Parameters show mstp [blocked] [mstp-id | region region_id | mstp-id region region_id] [begin string | exclude string | include string] blocked (Optional) Specifies the display information in respect of ports blocked by the MSTP only. mstp-id (Optional) Specifies the display of information for a specific MSTP instance. region region-id (Optional) Specifies the display of information for a specific MSTP region.
12 show mstp Output field Description Root Bridge Bridge identifier of the root bridge. ExtPath Cost The configured path cost on a link connected to this port to an external MSTP region. Regional Root Bridge The Regional Root Bridge is the MAC address of the Root Bridge for the local region. IntPath Cost The configured path cost on a link connected to this port within the internal MSTP region.
show mstp 12 The following example shows MSTP information for blocked ports only, filtered for region “1” in an ESI VLAN configuration: Brocade# show mstp blocked region 1 Region 1 -------MSTP Instance 0 (CIST) - ESI VLAN Scope: None ---------------------------------------------------------------------------Bridge Bridge Bridge Bridge Bridge Root Root Root Root Identifier MaxAge Hello FwdDly Hop MaxAge Hello FwdDly Hop hex sec sec sec cnt sec sec sec cnt 8000001bedb59a40 20 2 15 20 20 2 15 19 Root ExtPath
12 show spanning-tree show spanning-tree Displays Spanning Tree Protocol (STP) information. Syntax Parameters Command Modes show spanning-tree [blocked] [vlan vlan-id] blocked (Optional) Displays information in respect of ports blocked by the STP only. vlan vlan-id (Optional) Specifies the display of information for a specific port-based VLAN.
show spanning-tree Output field Description Hello sec The interval between each configuration BPDU sent by the root bridge. FwdDly sec The number of seconds this root bridge waits following a topology change and consequent reconvergence. 12 Port STP Parameters Port Num The port number. Priority The port’s STP priority. NOTE: If you configure this value, specify it in decimal format. Path Cost State The port’s STP path cost. The port’s STP state.
12 show spanning-tree Examples The following example displays STP information for VLAN “10”: .
show spanning-tree 12 Related Commands Multi-Service IronWare Switching Configuration Guide 53-1003036-02 403
12 404 show spanning-tree Multi-Service IronWare Switching Configuration Guide 53-1003036-02
Chapter 13 Configuring Rapid Spanning Tree Protocol Table 58 displays the individual Brocade devices and the Rapid Spanning Tree Protocol features they support.
13 Bridges and bridge port roles IEEE 802.1W-2001 RSTP provides rapid traffic reconvergence for point-to-point links within a few milliseconds (< 500 milliseconds), following the failure of a bridge or bridge port. This reconvergence occurs more rapidly than the reconvergence provided by the IEEE 802.1D Spanning Tree Protocol or by RSTP Draft 3 because: • STP requires a newly selected Root port to go through listening and learning stages before traffic convergence can be achieved.
Bridges and bridge port roles 13 Assignment of port roles At system start-up, all RSTP-enabled bridge ports assume a Designated role. Once start-up is complete, RSTP algorithm calculates the superiority or inferiority of the RST BPDU that is received and transmitted on a port. On a root bridge, each port is assigned a Designated port role, except for ports on the same bridge that are physically connected together.
13 Edge ports and Edge port roles Ports on Switch 1 All ports on Switch 1, the root bridge, are assigned Designated port roles. Ports on Switch 2 Port2 on Switch 2 directly connects to the root bridge; therefore, Port2 is the Root port. Switch 2’s bridge priority value is superior to that of Switch 3 and Switch 4; therefore, the ports on Switch 2 that connect to Switch 3 and Switch 4 are given the Designated port role. Furthermore, Port7 and Port8 on Switch 2 are physically connected.
Point-to-point ports FIGURE 73 13 Topology with edge ports However, if any incoming RST BPDU is received from a previously configured Edge port, RSTP automatically makes the port as a non-edge port. This is extremely important to ensure a loop free Layer 2 operation since a non-edge port is part of the active RSTP topology. The bridge detection state module can auto-detect an Edge port and a non-edge port. An administrator can also configure a port to be an Edge port.
13 Bridge port states FIGURE 74 Example of shared media Bridge port states Ports roles can have one of the following states: • Forwarding – RSTP is allowing the port to send and receive all packets. • Discarding – RSTP has blocked data traffic on this port to prevent a loop. The device or VLAN can reach the root bridge using another port, whose state is forwarding. When a port is in this state, the port does not transmit or receive data frames, but the port does continue to receive RST BPDUs.
Changes to port roles and states 13 If RSTP detects that port as a non-edge port, the port goes into a forwarding state within four seconds of link up or after two hello timer expires on the port. Changes to port roles and states To achieve convergence in a topology, a port’s role and state changes as it receives and transmits new RST BPDUs. Changes in a port’s role and state constitute a topology change.
13 State machines • It receives an RST BPDU with a proposal flag from a Designated port. The proposal flag is sent by ports with a Designated role when they are ready to move into a forwarding state. When a the role of Root port is given to another port, the old Root port is instructed to reroot. The old Root port goes into a discarding state and negotiates with its peer port for a new role and a new state. A peer port is the port on the other bridge to which the port is connected.
State machines FIGURE 75 13 Proposing and proposed stage Multi-Service IronWare Switching Configuration Guide 53-1003036-02 413
13 State machines • Sync – Once the Root port is elected, it sets a sync signal on all the ports on the bridge. The signal tells the ports to synchronize their roles and states (Figure 76). Ports that are non-edge ports with a role of Designated port change into a discarding state. These ports have to negotiate with their peer ports to establish their new roles and states.
State machines 13 • Synced – Once the Designated port changes into a discarding state, it asserts a synced signal. Immediately, Alternate ports and Backup ports are synced. The Root port monitors the synced signals from all the bridge ports. Once all bridge ports asserts a synced signal, the Root port asserts its own synced signal (Figure 77).
13 State machines • Agreed – The Root port sends back an RST BPDU containing an agreed flag to its peer Designated port and moves into the forwarding state. When the peer Designated port receives the RST BPDU, it rapidly transitions into a forwarding state. FIGURE 78 Agree stage At this point, the handshake mechanism is complete between Switch 100, the root bridge, and Switch 200.
State machines 13 Handshake when a root port has been elected If a non-root bridge already has a Root port, RSTP uses a different type of handshake. For example, in Figure 79, a new root bridge is added to the topology. FIGURE 79 Addition of a new root bridge The handshake that occurs between Switch 60 and Switch 100 follows the one described in the previous section (“Handshake when no root port is elected”). The former root bridge becomes a non-root bridge and establishes a Root port (Figure 80).
13 State machines • Proposing and Proposed – The Designated port on the new root bridge (Port4/Switch 60) sends an RST BPDU that contains a proposing signal to Port4/Switch 200 to inform the port that it is ready to put itself in a forwarding state (Figure 80). RSTP algorithm determines that the RST BPDU that Port4/Switch 200 received is superior to what it can generate, so Port4/Switch 200 assumes a Root port role.
State machines 13 • Sync and Reroot – The Root port then asserts a sync and a reroot signal on all the ports on the bridge. The signal tells the ports that a new Root port has been assigned and they are to renegotiate their new roles and states. The other ports on the bridge assert their sync and reroot signals. Information about the old Root port is discarded from all ports. Designated ports change into discarding states (Figure 81).
13 State machines • Sync and Rerooted – When the ports on Switch 200 have completed the reroot phase, they assert their rerooted signals and continue to assert their sync signals as they continue in their discarding states. They also continue to negotiate their roles and states with their peer ports (Figure 82).
State machines 13 • Synced and Agree – When all the ports on the bridge assert their synced signals, the new Root port asserts its own synced signal and sends an RST BPDU to Port4/Switch 60 that contains an agreed flag (Figure 82). The Root port also moves into a forwarding state.
13 State machines The old Root port on Switch 200 becomes an Alternate Port (Figure 84). Other ports on that bridge are elected to appropriate roles. The Designated port on Switch 60 goes into a forwarding state once it receives the RST BPDU with the agreed flag. FIGURE 84 Handshake completed after election of new root port Recall that Switch 200 sent the agreed flag to Port4/Switch 60 and not to Port1/Switch 100 (the port that connects Switch 100 to Switch 200).
Convergence in a simple topology 13 Convergence in a simple topology The examples in this section illustrate how RSTP convergence occurs in a simple Layer 2 topology at start-up. NOTE The remaining examples assume that the appropriate handshake mechanisms occur as port roles and states change. Convergence at start up In Figure 85, two bridges Switch 2 and Switch 3 are powered up. There are point-to-point connections between Port3/Switch 2 and Port3/Switch 3.
13 Convergence in a simple topology FIGURE 86 Simple Layer 2 topology The point-to-point connections between the three bridges are as follows: • Port2/Switch 1 and Port2/Switch 2 • Port4/Switch 1 and Port4/Switch 3 • Port3/Switch 2 and Port3/Switch 3 Ports 3 and 5 on Switch 1 are physically connected together. At start up, the ports on Switch 1 assume Designated port roles, which are in discarding state. They begin sending RST BPDUs with proposal flags to move into a forwarding state.
Convergence in a simple topology 13 Now, Port3/Switch 3 is currently in a discarding state and is negotiating a port role. It received RST BPDUs from Port3/Switch 2. The RSTP algorithm determines that the RST BPDUs Port3/Switch 3 received are superior to those it can transmit; however, they are not superior to those that are currently being received by the current Root port (Port4). Therefore, Port3 retains the role of Alternate port. Ports 3/Switch 1 and Port5/Switch 1 are physically connected.
13 Convergence in a simple topology Convergence after a link failure What happens if a link in the RSTP topology fails? For example, Port2/Switch, which is the port that connects Switch 2 to the root bridge (Switch 1), fails. Both Switch 2 and Switch 1 notice the topology change (Figure 88). FIGURE 88 Link failure in the topology Switch 1 sets its Port2 into a discarding state.
Convergence in a simple topology 13 Convergence at link restoration When Port2/Switch 2 is restored, both Switch 2 and Switch 1 recognize the change. Port2/Switch 1 starts assuming the role of a Designated port and sends an RST BPDU containing a proposal flag to Port2/Switch 2. When Port2/Switch 2 receives the RST BPDUs, RSTP algorithm determines that the RST BPDUs the port received are better than those received on Port3/Switch 3; therefore, Port2/Switch 2 is given the role of a Root port.
13 Convergence in a complex RSTP topology Convergence in a complex RSTP topology The following is an example of a complex RSTP topology. FIGURE 89 Complex RSTP topology In Figure 89, Switch 5 is selected as the root bridge since it is the bridge with the highest priority. Lines in the figure show the point-to-point connection to the bridges in the topology. Switch 5 sends an RST BPDU that contains a proposal flag to Port5/Switch 2.
Convergence in a complex RSTP topology 13 Next Switch 2 sends RST BPDUs with a proposal flag to Port3/Switch 4. Port3 becomes the Root port for the bridge; all other ports are given a Designated port role with discarding states. Port3/Switch 4 sends an RST BPDU with an agreed flag to Switch 2 to confirm that it is the new Root port. The port then goes into a forwarding state. Now Port4/Switch 4 receives an RST BPDU that is superior to what it can transmit.
13 Convergence in a complex RSTP topology FIGURE 90 Active Layer 2 path in complex topology Propagation of topology change The Topology Change state machine generates and propagates the topology change notification messages on each port. When a Root port or a Designated port goes into a forwarding state, the Topology Change state machine on those ports send a topology change notice (TCN) to all the bridges in the topology to propagate the topology change.
Convergence in a complex RSTP topology FIGURE 91 13 Beginning of topology change notice Switch 2 then starts the TCN timer on the Designated ports and sends RST BPDUs that contain the TCN as follows: • Port5/Switch 2 sends the TCN to Port2/Switch 5 • Port4/Switch 2 sends the TCN to Port4/Switch 6 • Port2/Switch 2 sends the TCN to Port2/Switch 1 Multi-Service IronWare Switching Configuration Guide 53-1003036-02 431
13 Convergence in a complex RSTP topology FIGURE 92 432 Sending TCN to bridges connected to Switch 2 Multi-Service IronWare Switching Configuration Guide 53-1003036-02
Compatibility of RSTP with 802.1D 13 Then FRY1, Switch 5, and Switch 6 send RST BPDUs that contain the TCN to Switch 3 and Switch 4 to complete the TCN propagation. FIGURE 93 Completing the TCN propagation Compatibility of RSTP with 802.1D RSTP-enabled bridges are backward compatible with IEEE 802.1D bridges. This compatibility is managed on a per-port basis by the Port Migration state machine.
13 Configuring RSTP parameters For example, in Figure 94, Switch 10 and Switch 30 receive legacy BPDUs from Switch 20. Ports on Switch 10 and Switch 30 begin sending BPDUs in STP format to allow them to operate transparently with Switch 20. FIGURE 94 RSTP bridges with an 802.1D bridge Once Switch 20 is removed from the LAN, Switch 10 and Switch 30 receive and transmit BPDUs in the STP format to and from each other.
Configuring RSTP parameters 13 Therefore, during RSTP deployment you may find that though a LAG has greater bandwidth, its in blocking/discarding state as its pathCost is same as any 1G link and the portIndex of 1G port is lower, making the LAG go into a blocking/discarding state. This behavior is not restricted to 1G or 10G link speed but span across different link speeds. The same behavior also holds TRUE for STP deployments.
13 Configuring RSTP parameters To designate a priority for a bridge, enter a command such as the following at the VLAN level. Brocade(config)# vlan 20 Brocade(config-vlan-20)# rstp priority 0 To make this change in the default VLAN, enter the following commands.
Configuring RSTP parameters 13 Syntax: rstp [admin-edge-port] | [admin-pt2pt-mac] The ethernet slot/portnum parameter specifies the interface used. The path-cost value parameter specifies the cost of the port’s path to the root bridge. RSTP prefers the path with the lowest cost. You can specify a value from 1 – 20,000,000. Table 59 shows the recommended path cost values from the IEEE standards.
13 Displaying RSTP information Displaying RSTP information You can display a summary or details of the RSTP information. To display a summary of RSTP, use the following command. Brocade(config)#show rstp vlan 10 VLAN 10 - RSTP instance 0 -------------------------------------------------------------------RSTP (IEEE 802.
Displaying RSTP information 13 The blocked parameter displays blocked ports only, for VLANs enabled with RSTP. When the blocked parameter is not specified, all RSTP port states are displayed. The vlan vlan-id parameter displays RSTP information for the specified port-based VLAN. The show RSTP display command shows the information listed in Table 60. TABLE 60 CLI display of RSTP summary This field... Displays...
13 Displaying RSTP information TABLE 60 CLI display of RSTP summary (Continued) This field... Displays... Fwd Dly The number of seconds a non-edge Designated port waits until it can apply any of the following transitions, if the RST BPDU it receives does not have an agreed flag: • Discarding state to learning state • Learning state to forwarding state When a non-edge port receives the RST BPDU it goes into forwarding state within 4 seconds or after two hello timers expire on the port.
Displaying RSTP information 13 To display detailed information about RSTP, using the following command. Brocade(config)#show rstp detail VLAN 10 - RSTP instance 0 -------------------------------------------------------------------RSTP (IEEE 802.1w) Bridge Parameters: BridgeId 0001000480a04000, RootBridgeId 0001000480a04000 Control ports - ethernet 1/3 ethernet 1/13 ForceVersion 2, MigrateTime 3, TxHoldCount 3 RSTP (IEEE 802.
13 Configuring RSTP under an ESI VLAN Configuring RSTP under an ESI VLAN RSTP can also be configured under a VLAN that is part of a user-configured ESI. For example, to enable RSTP on a VLAN that is part of an ESI, configure the following commands.
RSTP support for PB and PBB 13 RSTP support for PB and PBB A PBB network is comprised of a set of Backbone Core Bridges (BCBs) and Backbone Edge Bridges (BEBs). BEBs are interconnected by some or all of the S-VLANs supported by a PB network. Each BEB provides interfaces that encapsulate customer frames, thus allowing customer MAC addresses (C-MAC) and VLANs (S-VLAN) to be independent of backbone MAC addresses (B-MAC) and VLANs (B-VLAN) used to relay those frames across the backbone.
13 RSTP support for PB and PBB Core RSTP RSTP will run in the PBB core for loop detection and avoidance. All ASs and CSs will participate in the RSTP and one CS will be selected as the root for the core RSTP instance. The assumption is there will be only one RSTP instance running in the PBB core and traffic flow will be through one CS which is the root bridge. A backbone service provider can either use RSTP or MSTP.
RSTP support for PB and PBB 13 Figure 97 shows that BEB-1 and BEB-2 are connected via an IB tagged endpoint. The topology convergence is the same as in Figure 96. The difference comes in the BPDU transmitted out of the IB tagged endpoint that will be a tunneled packet which will have a PBB header. In this topology the IB- tagged end point should be always in the forwarding state by configuring either BEB-1 or BEB-2 as a ROOT bridge.
13 RSTP support for PB and PBB • RSTP interoperability between Brocade MLX series and Brocade NetIron CER devices is not supported if both are acting as a BEB. • Running RSTP on a VPLS Instance will not avoid the pure Layer 2 forwarding loop created by the regular B-VLAN in the BEBs. Run RSTP on regular B-VLAN in BEBs. • Switchover and hitless upgrade are not supported on PBB RSTP. • When changing the RSTP parameters on a regular B-VLAN, the parameters also need to be changed on the VPLS instance.
RSTP support for PB and PBB 13 Set the admin-pt2pt-mac to enabled or disabled. If set to enabled, then a port is connected to another port through a point-to-point link. The point-to-point link increases the speed of convergence. This parameter, however, does not auto-detect whether or not the link is a physical point-to-point link. The force-migration-check parameter forces the specified port to sent one RST BPDU.
13 RSTP support for PB and PBB Syntax: show mpls vpls detail NetIron #show mpls vpls id 1 VPLS as, Id 1, Max mac entries: 2048 PBB Bridge Destination MAC Address: None (NHT Index: 0) Total vlans: 2, Tagged ports: 1 (1 Up), Untagged ports 0 (0 Up) IFL-ID: n/a Enabled L2 Protocol:RSTP Vlan 100: Topo ID 1 Tagged: ethe 1/1 Port 1/1 1/2 Protocol RSTP RSTP State DISABLED FORWARDING Vlan 200 Tagged: ethe 1/1 CPU-Protection: OFF Local Switching: Enabled Extended Counter: ON 448 Multi-Service IronWare Switchi
RSTP support for PB and PBB 13 Use case scenarios Use case 1: Edge RSTP - AS-1 is connected to AS-2 and ES-1 via S-tagged endpoints of same S-VLAN The following deployment scenario is a case where RSTP is deployed for a single S-VLAN in a PB network. VPLS VLAN 200 (S-VLAN) is responsible for carrying traffic to the PB network. In this case, AS-1 is configured as ROOT Bridge, VPLS VLAN 200 is configured on AS-1, AS-2, and ES-1 which connects the three bridges together.
13 RSTP support for PB and PBB RSTP Configuration on vpls instance 1 Brocade_AS-1(config-mpls-vpls-pb-svlan)#rstp Brocade_AS-1(config-mpls-vpls-pb-svlan)#rstp priority 100 Configuring AS-2 Tag type configuration Configure the port tag type for S-VLAN to 0x9100. Brocade_AS-2(config)#tag-type 9100 eth 1/1 Brocade_AS-2(config)#tag-type 9100 eth 1/3 S-VLAN Configuration Configure VPLS VLANs which will carry the PB traffic, the S-VLAN here is 200.
RSTP support for PB and PBB 13 Configuring CE-2 C-VLAN Configuration Configure a regular Layer 2 VLAN with 300 and add port 1/4 to it. Brocade_CE-2(config)#vlan 300 Brocade_CE-2(config-vlan-300)#tagged ethernet 1/4 If RSTP needs to be enabled in CE bridges, the following configuration should be applied.
13 RSTP support for PB and PBB Use case 2: Edge RSTP - AS-1 is connected to AS-2 and ES-1 via S-tagged endpoints of different S-VLAN The following deployment scenario is a case where RSTP is deployed on two different S-VLANs of the same VPLS instance in a PB network. Here AS-1 is configured as a ROOT Bridge and RSTP is running on the VPLS Instance on AS-1, AS-2, and ES-1. VPLS VLAN 200 configured on AS-1 and AS-2 acts as an S-VLAN which connects AS-1 and AS-2.
RSTP support for PB and PBB 13 RSTP Configuration Brocade_AS-1(config-mpls-vpls-pb-svlan)#rstp Brocade_AS-1(config-mpls-vpls-pb-svlan)#rstp priority 100 Configuring AS-2 Tag type configuration Configure the port tag type for S-VLAN to 0x9100.
13 RSTP support for PB and PBB Configuring CE-2 C-VLAN Configuration Configure a regular Layer 2 VLAN with 400 (C-VLAN) and add port 1/4 to it.
RSTP support for PB and PBB 13 Configuring AS-1 Tag type configuration Configure port tag type for B-VLAN to 0x88a8. Brocade_AS-1(config)#tag-type 88e8 eth 1/1 Configure port tag type for S-VLAN to 0x9100.
13 RSTP support for PB and PBB RSTP Configuration Brocade_AS-2(config-mpls-vpls-pb-vlan)#rstp Configuring ES-1 Tag type configuration Configure the port tag type for S-VLAN to 0x9100.
RSTP support for PB and PBB 13 Use case 4: Edge RSTP - AS-1 is connected to AS-2 via IB-tagged endpoint and both the AS on ES facing side with different S-VLAN The following deployment scenario is a case where RSTP is deployed on a VPLS instance which has a S-VLAN configured to the ES facing side and B-VLAN configured which connects 2 ASs. AS-1 is configured as a ROOT Bridge. VPLS VLAN 200 is configured in AS-1 and AS-2 acts as B-VLAN which connects AS-1 and AS-2.
13 RSTP support for PB and PBB Brocade_AS-1(config-mpls-vpls-pbb-vlan)#pbb B-VLAN Configuration Brocade_AS-1(config-mpls-vpls-pbb-vlan-pbb)#vlan 200 isid 101010 Brocade_AS-1(config-mpls-vpls-pbb-vlan-vlan-200-isid-101010)#tagged ethernet 1/1 S-VLAN Configuration Brocade_AS-1(config-mpls-vpls-pb-vlan-pbb)#vlan 300 Brocade_AS-1(config-mpls-vpls-pb-vlan-vlan-300)#tag ethernet 1/2 RSTP Configuration Brocade_AS-1(config-mpls-vpls-pb-vlan)#rstp Brocade_AS-1(config-mpls-vpls-pb-vlan)#rstp priority 100 Config
RSTP support for PB and PBB 13 S-VLAN Configuration Configure VPLS VLANs which will carry the PB traffic, the S-VLAN here is 300.
13 RSTP support for PB and PBB The following discussion describes how to configure the nodes in the topology. FIGURE 102 Edge RSTP topology 5 Edge RSTP 1/1 S‐ VLAN 200 1/1 AS‐2 AS‐1 1/2 1/3 S‐VLAN 300 S‐VLAN 300 1/3 1/2 ES‐1 1/1 1/1 CE‐1 1/4 1/4 CE‐2 Configuring AS-1 Tag type configuration Configure a port tag type for S-VLAN to 0x9100.
RSTP support for PB and PBB 13 S-VLAN Configuration Brocade_AS-2(config)#router mpls Brocade_AS-2(config-mpls)#vpls pb-svlan 1 Brocade_AS-2(config-mpls-vpls-pb-svlan)#pbb Brocade_AS-2(config-mpls-vpls-pb-svlan-pbb)#vlan 200 Brocade_AS-2(config-mpls-vpls-pb-svlan-vlan-200)#tag ethernet 1/1 Brocade_AS-2(config-mpls-vpls-pb-svlan-pbb)#vlan 300 Brocade_AS-2(config-mpls-vpls-pb-svlan-vlan-300)#tag ethernet 1/2 RSTP Configuration Brocade_AS-2(config-mpls-vpls-pb-svlan)#rstp Configuring ES-1 Port-type configur
13 RSTP support for PB and PBB Configuring CE-1 C-VLAN Configuration Configure a regular Layer 2 VLAN with 400 (C-VLAN) and add port 1/1 to it. Brocade_CE-1(config)#vlan 400 Brocade_CE-1(config-vlan-400)#tagged ethernet 1/1 Configuring CE-2 C-VLAN Configuration Configure a regular Layer 2 VLAN with 400 (C-VLAN) and add port 1/4 to it.
RSTP support for PB and PBB 13 AS-1 Configuration NOTE The AS-2 configuration is similar to the AS-1 configuration. To carry PBB traffic, configure a VPLS instance. The B-VLAN used here is 100. For PB traffic, the S-VLAN used is 200 and C-VLAN 300.
13 RSTP support for PB and PBB Port type configuration Brocade_ES-1(config)#tag-type 9100 eth 1/10 Brocade_ES-1(config)#router mpls Brocade_ES-1(config-mpls)#vpls pb-svlan 1 Brocade_ES-1(config-mpls-vpls-pb-svlan)#vlan 200 Brocade_ES-1(config-mpls-vpls-pb-svlan-vlan-200)#tag ethernet 1/10 RSTP Configuration Brocade_ES-1(config-mpls-vpls-pb-svlan#rstp Use case 7: Core and Edge RSTP RSTP will run in the PBB core for loop detection and avoidance in the B-VLAN.
RSTP support for PB and PBB 13 S-VLAN Configuration Configure VPLS VLANs which will carry the PB traffic, the S-VLAN here is 200.
13 RSTP support for PB and PBB Configuring ES-1 NOTE The configuration of ES-2 is similar to the configuration of ES-1. Tag type configuration Configure port tag type for S-VLAN to 0x9100. Brocade_ES-1(config)#tag-type 9100 eth 1/2 Brocade_ES-1(config)#tag-type 9100 eth 1/3 S-VLAN Configuration Configure VPLS VLANs which will carry the PB traffic, the S-VLAN here is 200.
Commands 13 Commands The following commands support the features described in this chapter: • show rstp Multi-Service IronWare Switching Configuration Guide 53-1003036-02 467
13 show rstp show rstp Displays Rapid Spanning Tree Protocol (RSTP) information. Syntax Parameters Command Modes show rstp [blocked] [vlan vlan-id] blocked (Optional) Displays information in respect of ports blocked by the RSTP only. vlan vlan-id (Optional) Specifies the display of information for a specific VLAN.
show rstp 13 Output field Description Max Age The max age is derived from the Root port. An RSTP-enabled bridge uses this value, along with the hello and message age parameters to compute the effective age of an RST BPDU. The message age parameter is generated by the Designated port and transmitted in the RST BPDU. RST BPDUs transmitted by a Designated port of the root bridge contains a message value of zero.
13 show rstp Examples Output field Description State The port’s current RSTP state. A port can have one of the following states: • Forwarding • Discarding • Learning • Disabled Designated Cost The best root path cost that this port received, including the best root path cost that it can transmit. Designated Bridge The ID of the bridge that sent the best RST BPDU that was received on this port.
show rstp 13 The following example displays a summary of ports blocked by RSTP on VLAN “20” Brocade#show rstp blocked vlan 20 VLAN 20 - RSTP instance 0 -------------------------------------------------------------------RSTP (IEEE 802.
13 472 show rstp Multi-Service IronWare Switching Configuration Guide 53-1003036-02
Chapter 14 Metro Ring Protocol Table 62 displays the individual Brocade devices and the Metro Ring Protocol features they support.
14 Metro Ring Protocol (MRP) Metro Ring Protocol (MRP) Brocade MRP is a proprietary protocol that prevents layer 2 loops and provides fast reconvergence in ring topologies. It is an alternative to Spanning Tree Protocol (STP) and is especially useful in Metropolitan Area Networks (MANs) where using 802.1D STP has the following drawbacks: • 802.1D recommends a maximum bridge diameter of seven nodes with standard timers. MRP is capable of many more nodes than this. • 802.
14 Metro Ring Protocol (MRP) For each discrete ring one node is configured in the master role for the MRP ring. One of the two ring interfaces on the master node is configured as the primary interface, the other is the secondary interface. The primary interface originates Ring Health Packets (RHPs) which are used to monitor the health of the ring. An RHP is forwarded on the ring to the next interface until it reaches the secondary interface of the master node.
14 MRP rings without shared interfaces (MRP Phase 1) MRP rings without shared interfaces (MRP Phase 1) MRP Phase 1 allows you to configure multiple MRP rings, as shown in Figure 106, but the rings cannot share the same interfaces. For example, you cannot configure ring 1 and ring 2 to share interfaces ethernet 1/1 and 1/2 on Switch 5. Each ring must remain an independent ring and RHP packets are processed within each ring.
Ring initialization 14 Ring initialization Figure 107 shows the initial state of the ring, when MRP is first enabled on the ring’s switches. On the master the primary interface starts in forwarding mode and the secondary interface starts in blocking mode. All ring interfaces on member nodes begin in the preforwarding state (PF). FIGURE 107 MRP ring – initial state An RHP is an MRP protocol packet used to monitor the health of the ring.
14 Ring initialization A ring interface can have one of the following MRP states: • Preforwarding (PF) – The interface will forward RHPs and learn MAC addresses but won’t forward data for the ring. All ring interfaces start in this state when you enable MRP except the master node. A blocking interface transitions to preforwarding when the preforwarding timer expires and no RHP’s have been received. • Forwarding (F) – The interface will forward RHP’s and data for the ring.
Ring initialization 14 FIGURE 108 MRP ring – from preforwarding to forwarding Each RHP also has a sequence number. MRP can use the sequence number to determine the round-trip time for RHPs in the ring. Refer to “Using MRP diagnostics”.
14 How ring breaks are detected and healed How ring breaks are detected and healed Figure 109 shows ring interface states following a link break. MRP quickly heals the ring and preserves connectivity among the customer networks.
How ring breaks are detected and healed 14 • If the interface does not receive an RHP for its ring before the preforwarding time expires, the interface changes to the forwarding state, as shown in Figure 109. • Forwarding interfaces – All member interfaces remain in the forwarding state unless the physical interface is in an error condition.
14 How ring breaks are detected and healed NOTE In the event of a shared interface failing the alarm RHP packet is only sent by the owner ring of the failed interface. If all rings configured on a shared interface were to generate alarms then the respective master switches for each ring would start forwarding on both interfaces creating a loop condition. By restricting alarm generation to the owner ring we ensure that only one master switch is notified to ensure that the ring heals.
How ring breaks are detected and healed 14 Topology change notification for multicast traffic Figure 111 shows a Layer 2 aggregation network which runs on Brocade MRP. In this scenario, switch A acts as the MRP master and also the Internet Group Management Protocol (IGMP) querier. When a link failure is detected on the port 1/1 of switch A, the port 1/2 of switch A will transition from blocking state to forwarding state allowing the ring to re-converge in sub-second time.
14 How ring breaks are detected and healed FIGURE 112 MRP ring with switch B as the querier In the scenarios shown in Figure 111 and Figure 112, a topology change notification is sent to the MRP ring master, which forces an advertisement of the IGMP query to the entire network upon receiving the notification. This reduces the failover time for the multicast streams over a ring topology without the need of lowering the IGMP query interval or IGMP group membership time.
Master VLANs and member VLANs in a topology group 14 Master VLANs and member VLANs in a topology group The reader is referred to Topology Groups chapter for further information on topology group concepts and operation. All the ring interfaces must be placed into the master vlan for the topology group. Customers configured with member vlans inherit the configuration of the topology group master vlan and have equivalent layer 2 connectivity across the ring. Figure 113 shows an example.
14 Configuring MRP Customer A host attached to Switch D on an interface in vlan 30 can reach the customer A host attached to Switch B on an interface in vlan 30 through the ring at layer 2. The same mechanism is used to connect customer B hosts on vlan 40. Customer A and customer B traffic is separated by using different vlans. You can configure MRP separately on each customer vlan. However, this is impractical if you have many customers.
Configuring MRP 14 Adding an MRP ring to a vlan NOTE If you plan to use a topology group make sure you configure MRP on the topology group’s master vlan. To add a MRP ring to a vlan, enter commands such as the following.
14 Configuring MRP Changing the hello and preforwarding times You can also change the RHP hello time and preforwarding time. To do so, enter commands such as the following. Brocade(config-vlan-2-mrp-1)# hello-time 200 Brocade(config-vlan-2-mrp-1)# preforwarding-time 400 These commands change the hello time to 200 ms and change the preforwarding time to 400 ms. Syntax: [no] hello-time ms Syntax: [no] preforwarding-time ms The ms specifies the number of milliseconds.
MRP Phase 2 14 MRP Phase 2 MRP phase 2 expands functionality by allowing a physical interface to be shared by multiple rings configured within the same vlan. Recall that in MRP Phase 1, a node can have multiple MRP rings, but the rings cannot share the same interface. Any node can be designated as the master node for the ring. Each ring is an independent ring and RHP packets are processed within each ring exclusively.
14 MRP Phase 2 FIGURE 115 Example 1 multiple rings sharing interfaces - phase 2 On each node that will participate in ring 1, you configure the ring ID and the ring interfaces that will be used. You repeat the configuration steps for all nodes in ring 2. In a multiple ring configuration, a ring’s ID determines its priority. The lower the ring ID, the higher the priority of a ring with ring ID 1 being the highest possible priority.
MRP Phase 2 14 It is very easy to focus on the ring topology rather than the underlying layer 2 topology described by multiple rings. Design decisions are driven by the same factors as a standard spanning tree network replacing root bridges with ring masters. Traffic patterns at layer 2 are determined by which ring interfaces are forwarding and which are blocking and this in turn should drive design decisions for ring master placement as well as the direction of RHP flow from the ring masters.
14 MRP Phase 2 FIGURE 117 Example 2 multiple rings sharing interfaces - phase 2 Ring interface IDs and types For example, in Figure 118, all interfaces configured for ring 1 have a priority of 1. Interface e 1/1 on S1 and e 2/2 on S2 have a priority of 1 since 1 is the highest priority ring that shares the interface. All interfaces on ring 2, except for e 1/1 on S1 and e 2/2 on S2 have a priority of 2.
MRP Phase 2 14 FIGURE 118 Interface IDs and types In Figure 118, nodes S1 and S2 have interfaces that belong to rings 1 and 2. Interface e 1/1 on S1 and e 2/2 on S2 are regular interfaces for ring 1, but they are tunnel interfaces for ring 2. Selection of the master node for a ring Configuring MRP rings with shared interfaces limits the nodes that can be designated as the master node for any particular ring.
14 MRP Phase 2 FIGURE 119 Unexpected switching path with shared interface In Figure 119 ring 2 was configured with shared ring interfaces on S1 and S3 as depicted. S1 was configured as the master for ring 1 and the shared interface was defined as the secondary interface and subsequently blocks data.
MRP Phase 2 14 FIGURE 120 Expected switching path with shared interface RHP processing in rings with shared interfaces Interfaces on an MRP ring have one of the following states: • Blocking (B) – The interface can process RHPs, but cannot forward data for the ring. Only the secondary interface on the Master node can be blocking. If the interface receives RHP’s for lower priority rings these RHPs will be discarded by this interface.
14 MRP Phase 2 The primary interface of the master node initiates RHP packets and sends them onto the ring. When the packet reaches a forwarding interface, MRP checks to see if the receiving interface is a regular interface or a tunnel interface: • If the interface is a regular interface, the RHP packet is forwarded to the next interface. Forwarding of the packet continues on the ring until the secondary interface of the master node receives the packet and processes it.
MRP Phase 2 14 Normal flow Figure 121 and Figure 122 show how RHP packets are forwarded in rings with shared interfaces. Figure 121 shows the flow of ring 1 RHPs while Figure 122 shows how ring 2 RHPs flow. Interface e 2/1 is the primary interface of the ring 1 master node. The primary interface forwards an RHP packet on the ring. Since all the interfaces on ring 1 are regular interfaces, the RHP packet is forwarded until it reaches interface e 2/2, the secondary interface of the ring 1 master.
14 MRP Phase 2 FIGURE 122 RHP flow on rings with shared interfaces showing ring 2 RHP flow Referring to Figure 122 interface 3/1, is the primary interface of the ring 2 master node. It sends an RHP packet on the ring. Since all interfaces on S4 are regular interfaces, the RHP packet is forwarded on those interfaces. When the RHP reaches S2: • A copy of the RHP is sent out of regular interface e 2/1 onto ring 1.
MRP Phase 2 14 Flow when a link breaks Referring to Figure 123 if the link between S1 and S2 fails, the secondary interface on the ring 1 master node changes to a forwarding state. The RHPs from the master for ring 2 reach S2 and a copy of the RHP is forwarded out of e 2/1. This RHP traverses the ring 1 master and continues around ring 1 until it reaches S1. After S1 the RHP is back on ring 2 and is finally received by the master for ring 2 which keeps its secondary interface in blocking mode.
14 Tuning MRP timers Configuring MRP with shared interfaces MRP Phase 2 allows you to enter commands such as the following when configuring MRP.
Tuning MRP timers 14 Hello time This timer specifies the interval at which RHP’s are generated by the ring master. It should be noted that this interval is applied not only to standard RHP’s but also to topology change notification RHP’s.
14 Tuning MRP timers Example 3: Preforwarding time = 10000ms Hello time = 5000ms Time to forwarding = 2 x preforwarding time = 20000ms Post recovery mac table flush time = 3 x hello time = 15000ms Full connectivity = Time to forwarding + Post recovery mac table flush time = 35000ms = 35secs It can therefore be seen that the hello time should not be changed on the network unless there is evidence of regular misses on the ring. Time to traverse the ring can be determined by running MRP diagnostics.
Using MRP diagnostics 14 Example 3: Preforwarding time = 10000ms Hello time = 5000ms Time to forwarding = preforwarding time – hello time = 5000ms Post recovery mac table flush time = 3 x hello time = 15000ms Full connectivity = Time to forwarding + Post recovery mac table flush time = 20000ms = 20sec Using MRP diagnostics The MRP diagnostics feature calculates how long it takes for RHP packets to travel through the ring.
14 Displaying MRP information Displaying MRP diagnostics To display MRP diagnostics results, enter the following command on the Master node. Brocade(config)# show metro 2 diag Metro Ring 2 - CustomerA ============= diagnostics results Ring id 2 Diag state enabled Diag frame sent 1230 RHP average time(microsec) 125 Recommended hello time(ms) 100 Recommended Prefwing time(ms) 300 Diag frame lost 0 Syntax: show metro ring-id diag This display shows the following information.
Displaying MRP information 14 Displaying ring information To display ring information, enter the following command.
14 Displaying MRP information TABLE 64 This field... Interface role 506 CLI display of MRP ring information (Continued) Displays... The interface role can be one of the following: primary • Master node – The interface generates RHPs. • Member node – The interface forwards RHPs received on the other interface (the secondary interface). • secondary – The interface does not generate RHPs. • Master node – The interface listens for RHPs. • Member node – The interface receives RHPs.
MRP CLI example 14 MRP CLI example The following examples show the CLI commands required to implement the MRP configuration shown in Figure 124. FIGURE 124 NOTE For simplicity, the figure shows the vlans on only two switches. The CLI examples implement the ring on all four switches. Commands on Switch A (master node) The following commands configure a vlan for the ring. The ring vlan must contain both of the node’s interfaces with the ring.
14 MRP CLI example Brocade(config)# vlan 2 Brocade(config-vlan-2)# tag ethernet 1/1 to 1/2 Brocade(config-vlan-2)# metro-ring 1 Brocade(config-vlan-2-mrp-1)# name “Metro A” Brocade(config-vlan-2-mrp-1)# master Brocade(config-vlan-2-mrp-1)# ring-interface ethernet 1/1 ethernet 1/2 Brocade(config-vlan-2-mrp-1)# enable Brocade(config-vlan-2-mrp-1)# exit Brocade(config-vlan-2)# exit The following commands configure the customer vlans.
Configuring MRP under an ESI VLAN 14 Commands on Switch C Brocade(config)# vlan 2 Brocade(config-vlan-2)# tag ethernet 1/1 to 1/2 Brocade(config-vlan-2)# metro-ring 1 Brocade(config-vlan-2-mrp-1)# name “Metro A” Brocade(config-vlan-2-mrp-1)# ring-interface ethernet 1/1 ethernet 1/2 Brocade(config-vlan-2-mrp-1)# enable Brocade(config-vlan-2)# exit Brocade(config)# vlan 30 Brocade(config-vlan-30)# tag ethernet 1/1 to 1/2 Brocade(config-vlan-30)# tag ethernet 2/1 Brocade(config-vlan-30)# exit Brocade(config)
14 Configuring MRP under an ESI VLAN ethernet 1/2 Brocade(config-esi-customer1-vlan-100-mrp-1)# enable Brocade(config-esi-customer1-vlan-100-mrp-1)# exit Brocade(config-esi-customer1-vlan-100)# exit Configuration considerations The configuration considerations are as follows: • MRP can be configured for vlans with encapsulation type B-VLAN, S-VLAN or C-VLAN. • When MRP is configured for vlans under an ESI, the MRP members must be part of the same ESI.
Chapter 15 Ethernet Ring Protection Protocol Table 65 displays the Brocade devices and the Ethernet Ring Protection (ERP) features they support.
15 Ethernet Ring Protection NOTE Before configuring ERP, you must configure a VLAN and the ports you require for your deployment. This chapter describes ERP components, features, and how to configure, and manage ERP. Ethernet Ring Protection components An ERP deployment consists of the following components: • • • • • • Roles assigned to devices, called Ethernet Ring Nodes (ERN) Interfaces Protocols — ERP alone or with IEEE 802.
Ethernet Ring Protection 15 Using standalone ERP When using standalone ERP, all devices have a role, and all devices participate at least as ERP members. Ring-APS (R-APS) messages are sent at initial start-up of a configuration and periodically when link or node failures or recoveries occur. Each ERN applies the information received in the R-APS messages and forwards the received RAPS messages if both ports are in the forwarding state.
15 Ethernet Ring Protection As a result, ERN 2, the RPL owner, unblocked the RPL, and the topology became stable and loop free. ERP messaging In ERP, ERNs send R-APS messages. Figure 126 shows the general R-APS packet structure. For details about the packet structures, see ITU-T G.8032. FIGURE 126 R-APS packet structure The destination MAC address (Dst Mac) is the first element in the packet and is of the form 00-00-00-00-00-. The default value is 01.
Ethernet Ring Protection 15 When an ERP topology starts up, each ERN (in Init state) transmits a R-APS (NR). After start-up, the behavior varies by assigned role. Figure 127 shows the initialization process for an ERN. FIGURE 127 Message exchange and actions during ERN initialization version 2 RPL owner Non-RPL node RPL node Init state Init state Init state 1 2 3 1 2 3 1 2 3 Blocks the RPL Sends a R-APS (NR) Enters the Pending state. 4. Starts the WTR timer 5.
15 Initializing a new ERN • Hold-off timer — Each ERN uses a hold-off timer to delay reporting a port failure. When the timer expires, the ERN checks the port status. If the issue still exists, the failure is reported. If the issue does not exist, nothing is reported. • Message interval — This is an operator configurable feature for sending out R-APS messages continuously when events happen.
Initializing a new ERN 15 • ERN 4 stays in the Pending state, transmits R-APS (NR) messages, and continues to block the left interface. FIGURE 129 Initializing an ERP topology - II Figure 130 shows the next sequence of events. The actions of each ERN are: • ERN 1 terminates R-APS received on the blocked port, unblocks the non-failed port, stops transmitting R-APS (NR) messages, and enters the Pending state. • ERN 2 takes no action. • ERN 3 takes no action.
15 Initializing a new ERN Figure 131 shows the next sequence of events. The actions of each ERN are: • ERN 1, from the Pending state, unblocks the left interface, stops sending R-APS (NR) and stays in the Pending state. Now both interfaces are in the forwarding state. • ERN 2 takes no action. • ERN 3 takes no action. • ERN 4 stays in the Pending state and transmits R-APS (NR) messages. The left interface is blocked, and the right interface is in the forwarding state.
Initializing a new ERN 15 Figure 133 shows the next sequence of events. The actions of each ERN are: • After the WTB timer expires, ERN 2 (RPL owner in the Pending state) transmits R-APS (NR, RB), and then ERN 2 enters the Idle state. • ERN 1, still in the Pending state, forwards R-APS (NR, RB) and enters the Idle state. • ERN 3 takes no action. • ERN 4 from the Pending state and stops transmitting R-APS (NR).
15 Signal fail Lastly, ERNs 1, 2, and 3 are in the Idle state, and ERN 4 changes the blocking port to the forwarding state. All ERNs remain in the Idle state. See Figure 134. FIGURE 134 Initializing an ERP topology - VII Signal fail Signal fail and signal fail recovery provide the mechanism to repair the ring to preserve connectivity among customer networks. ERP guarantees that although physically the topology is a ring, logically it is loop-free.
Manual switch 15 Figure 135 shows a simple Ethernet ring topology before a failure. This diagram shows dual-end blocking enabled (thick line) between ERNs one (RPL node) and 6 (RPL owner). ERNs 3, 2, 4, and 5 are non-RPL nodes. FIGURE 135 ERP topology Figure 136 shows the same Ethernet ring topology after a failure at the forwarding port of ERN 4 when a signal fail triggered, and ring protection was needed. ERN 6 unblocked the RPL port and the RPL node changed the blocking port to the forwarding state.
15 Manual switch The node, which receives the R-APS (MS), forwards it to the adjacent nodes. If the receiving node is already in the Idle or Pending state, it unblocks the non-failed port and stops transmitting R-APS messages. Only one MS can exist in the topology at any time. An MS condition has to be manually cleared with the no command. NOTE If any ERN is in an FS state or in a protected state through an SF event and an operator tries to configure an MS, the ERN will reject the request.
Manual switch 15 Figure 137 shows a manual switch on ERN 3, which is a non-RPL node. In order to clear the MS condition, the operator must enter the manual switch command from ERN 3. The sequence of messages and actions is as shown in Figure 138.
15 Forced switch Forced switch Forced switch (FS) is an operator-initiated mechanism that moves the blocking role of the RPL to a different ring link followed by unblocking the RPL, even if one or more failed links exist in the ring. The node configured to initiate an FS blocks the port and sends out a R-APS (FS) to inform other nodes to unblock any blocked ports (including failed ones) as long as no other local request with higher priority exists. The RPL owner unblocks the RPL and flushes the FDB.
Forced switch 15 Figure 141 shows the sequential order of events triggered as a result of an operator-initiated forced switch command entered from ERN 4.
15 Forced switch Next, the operator enters the no command to clear the forced switch. For this example, the operator initiated the forced switch from ERN 4 and must clear it from ERN 4. Figure 142 shows the forced switch recovery process in sequential order.
Dual-end blocking 15 Double Forced Switch A local FS is of a higher priority than a received R-APS (FS); therefore, the local FS request blocks the port even when the node receives a R-APS(FS) from another FS request of another node. After the first FS clears, the node starts the guard timer and sends out a R-APS (NR). The adjacent nodes of the first cleared FS node will not process or forward the R-APS (NR) because they are still receiving R-APS (FS) from the second FS node.
15 Interconnected rings When a sub-ring initializes, each ERN in the non-closed ERP sends out a R-APS (NR). After the RPL owner receives a R-APS (NR), it blocks the RPL; and the RPL owner sends out a R-APS (NR, RB). The shared link remains blocked even if the shared link has a SF error. The blocking state in ERP means the R-APS channel is blocked at the same port where the traffic channel is blocked, except on sub-rings without use of R-APS virtual channel.
FBD flush optimization 15 FBD flush optimization The FDB stores the node ID and BPR sent in the R-APS messages. When an ERN receives a new R-APS message, it compares the received node ID and BPR to the node ID and BPR in its memory. If the pair vary from the previously stored pair, the ERN deletes the previous pair and stores the new pair. The device then triggers a FDB flush unless the DNF (No Not Flush) is set in the message.
15 Configuring ERP with IEEE 802.1ag Device 1 RPL owner NOTE Optionally, you can configure the non-revertive mode feature. This setting can only be set on the RPL owner.
ERP commands 15 • Enable the configuration You must perform the following minimum configuration tasks for each non-RPL node: • Configure an ERP instance • Set the left and right interfaces • Configure the maintenance entity group end points (MEP) from each ERN, which can have a role of RPL owner or non-RPL node, adjacent to switches not participating in the ERP configuration • Enable the configuration ERP commands This section lists ERP configuration commands.
15 ERP commands Configuring the default MAC ID You can configure the MAC ID. The device appends this ID number to the end of the permanent portion of the ERP MAC address (00-00-00-00-00- <01 or ERP ID>) in R-APS messages. By default 00-00-00-00-00-01 is used as the dst MAC, which is always used by Version 1 of ITU-T 8032. If Version 2 is configured, then the raps-default-mac command can be negated by entering the no raps-default-mac command.
ERP commands 15 For proper operation you must configure the interfaces following the same manner on each ERN, such as left/right, left/right, and so on. In NetIron R05.3.00 the interface configuration commands have been enhanced to allow configuration of ERP with ESI VLANs.
15 ERP commands Achieving sub-50ms ring protection switch time The G.8032v2 ERP implementation has been enhanced to achieve sub-50ms ring protection switch time. This enhancement involves optimizations to reduce the number of MAC flushes, temporary flooding of traffic while MAC flush is in progress, and faster link failure detection using Connectivity Fault Management (CFM). You will need to configure the following to achieve sub-50ms ring protection switch time.
ERP commands 15 Configuration example NOTE The VLAN CPU protection needs to be enabled on the VLANs.
15 ERP commands Device 2 Configuration steps CFM Configuration: Brocade#configure terminal Brocade(config)#cfm-enable Brocade(config-cfm)#domain-name erp id 1 level 1 Brocade(config-cfm-md-erp)#ma-name ma-erp link-ma priority 7 Brocade(config-cfm-md-erp-ma-ma-erp)#individual-link-monitoring Brocade(config-cfm-md-erp-ma-ma-erp)#mep 201 down port eth 1/1 Brocade(config-cfm-md-erp-ma-ma-erp)#mep 202 down port eth 1/2 VLAN Configuration: Brocade(config)#vlan 100 Brocade(config-vlan-100)#tag eth 1/1 eth 1/2 B
ERP commands 15 Configuring dual-end blocking You can configure dual-end blocking to optimize your ERP configuration. The RPL node must be adjacent to the RPL owner. When you configure the RPL on an ERN that is adjacent to the RPL owner, you are enabling the dual-end blocking feature and changing the ERN’s role to that of RPL node. You configure the RPL node with the rpl command.
15 ERP commands This WTR timer is activated on the RPL Owner Node. When the relevant delay timer expires, the RPL owner initiates the reversion process by transmitting an R-APS (NR, RB) message. The WTR timer is deactivated when any higher priority request preempts this timer. The WTR timers may be started and stopped. A request to start running the WTR timer does not restart the WTR timer. A request to stop the WTR timer stops the WTR timer and resets its value.
ERP commands 15 You can configure the hold-off timer in 100ms increments from 0 to 10,000 ms (10 seconds); the default value is 0 ms. The hold-off timer value cannot be stopped through the CLI. Syntax: holdoff-time time-value> Configuring the message interval time The message interval time of R-APS messages continuously sent within an ERP ring can be configured. You can configure the interval in 100ms increments from 100ms to 5000ms (5 seconds); the default value is 5000ms.
15 ERP over ESI VLAN (Brocade NetIron CES and Brocade NetIron CER) ERP over ESI VLAN (Brocade NetIron CES and Brocade NetIron CER) ERP PBB is supported for Brocade NetIron CES and Brocade NetIron CER starting with the release of NetIron R0.5.3.00. Figure 146 shows a diagram of one of the sample topologies that shall be used for deploying ERP over PBB using the ESI model. In the diagram, Ring 3 is the major ring while all others are sub-rings. Each ESI VLAN will be running a separate instance of ERP.
ERP over ESI VLAN (Brocade NetIron CES and Brocade NetIron CER) 15 The interconnection nodes play a vital role in traffic forwarding and should be aware of ERP instances associated with each other within the node. In Figure 146, the DUT17 interconnection node needs to be aware of Ring 1 being a sub-ring of the Ring 2 ERP instance. This association is important as it is required to perform a FDB flush in Ring-2 on receiving R-APS (SF) messages from Ring-1 .
15 ERP over ESI VLAN (Brocade NetIron CES and Brocade NetIron CER) enable ! interface ethernet 1/1 port-type provider-network enable ! interface ethernet 1/2 port-type provider-network enable PBB interconection node (BEB) FIGURE 149 PBB interconection node (BEB) sample configuration BEB-1 Configuration for Major ring B-VLAN 100 ! esi bvlan encapsulation bvlan vlan 100 tagged ethe 1/1 ethe 1/2 ! erp 100 left-interface esi bvlan vlan 100 ethe 1/1 right-interface esi bvlan vlan 100 ethe 1/2 rpl-owner raps-
ERP support for PBB (Brocade MLX series and Brocade NetIron XMR) 15 port-type backbone-edge enable ! PBB interconection node (BCB) FIGURE 150 PBB interconnection node (BCB) BCB-1 Configuration for Major ring B-VLAN 100 ! esi bvlan encapsulation bvlan vlan 100 tagged ethe 1/1 ethe 1/2 ! erp 100 left-interface esi bvlan vlan 100 ethe 1/1 right-interface esi bvlan vlan 100 ethe 1/2 raps-default-mac rpl esi bvlan vlan 100 ethe 1/2 enable ! interface ethernet 1/1 port-type backbone-network enable ! interface
15 ERP support for PBB (Brocade MLX series and Brocade NetIron XMR) • Configure PBB VPLS VLANs for carrying PB/PBB traffic • Configure the topology group - ERP protocol over the master VLAN - PB/PBB traffic over the member VPLS VLANs Blocking of L2 protocols for PBB The configurations discussed will be blocked • ERP is the only protocol that will be supported for PBB in NetIron R05.3.00, any other protocol configuration with PBB is blocked.
ERP support for PBB (Brocade MLX series and Brocade NetIron XMR) 15 PE-2 PBB Configuration with S-VLAN 200 ! tag-type 88a8 eth 1/1 tag-type 88a8 eth 1/2 ! router mpls vpls pb-pbb 1 pbb vlan 200 tagged ethe 1/1 ethe 1/2 PBB Interconnection node (BEB) FIGURE 152 PBB Interconnection node (BEB) BEB-1 ERP PB sub-ring with regular VLAN 201 ! vlan 201 tagged ethe 1/3 ! erp 201 right-interface vlan 201 ethe 1/3 raps-default-mac sub-ring parent-ring-id 100 enable ! BEB-1 topology group for PB sub-ring ! topolog
15 ERP support for PBB (Brocade MLX series and Brocade NetIron XMR) PBB Interconnection node (BCB) FIGURE 153 PBB Interconnection node (BCB) BCB-1 Configuration for Major ring B-VLAN 100 ! vlan 100 tagged ethe 1/1 ethe 1/2 ! tag-type 88a8 eth 1/1 tag-type 88a8 eth 1/2 ! erp 100 left-interface vlan 100 ethe 1/1 right-interface vlan 100 ethe 1/2 raps-default-mac rpl vlan 100 ethe 1/2 enable ! BCB-1 Configuration for Sub ring B-VLAN 100 ! vlan 100 tagged ethe 1/3 ! tag-type 88a8 eth 1/3 ! erp 101 left-inte
ERP support for PBB (Brocade MLX series and Brocade NetIron XMR) 15 • Each sub-ring will be connected to either a major ring or a sub-ring which is referred to as a parent ring. • In Figure 154 ERP instance 1 is the parent ring for sub-ring ERP instance 2 and ERP instance 2 is the parent ring for sub-ring ERP instance 3.
15 ERP support for PBB (Brocade MLX series and Brocade NetIron XMR) raps-default-mac enable ! Node-3 Configuration for Sub ring VLAN 100 ! vlan 100 tagged ethe 1/2 ! erp 200 right-interface vlan 100 ethe 1/2 raps-default-mac sub-ring parent-ring-id 100 raps-propagate-tc rpl vlan 100 ethe 1/2 enable ! FIGURE 156 RAPS-propagate-tc configuration A and B are end-points exchanging traffic, active path is as indicated by green line.
Viewing ERP operational status and clearing ERP statistics 15 The sequence of events for restoring the traffic When the link connecting Node-1 and Node-2 goes down, it results in topology change on sub-ring resulting in following events: • The topology change on the sub-ring results in the generation of R-APS(SF) PDUs by Node-1 and Node-2 in addition to flushing their own FDBs. • Node-3 and Node-5 on the reception of R-APS(SF) perform an FDB flush on the sub-ring ERP interface 1/2.
15 Viewing ERP operational status and clearing ERP statistics I/F Port ERP port state Interface status Interface type L 1/12 blocking normal rpl R 1/11 forwarding normal non-rpl RAPS sent RAPS rcvd RAPS dropped RAPS ignored Oper state changes 3 3 0 0 0 Table 67 summarizes the table fields and their meanings. TABLE 67 550 Summary of CLI output for show erp command This field... Displays... ERP id The ERP ID is the number that was configured at setup.
Viewing ERP operational status and clearing ERP statistics 15 Clearing ERP statistics You can clear ERP statistics by entering the clear erp erp_id> statistics command to clear the statistics of one erp instance. You can clear all ERP statistics by entering the clear erp statistics command to clear the statistics of all erp instances.
15 552 Viewing ERP operational status and clearing ERP statistics Multi-Service IronWare Switching Configuration Guide 53-1003036-02
Chapter 16 Virtual Switch Redundancy Protocol (VSRP) Table 68 displays the individual Brocade devices and the Virtual Switch Redundancy Protocol (VSRP) features they support.
16 Virtual Switch Redundancy Protocol (VSRP) Figure 158 shows a VSRP configuration. FIGURE 158 VSRP mesh – redundant paths for Layer 2 traffic VSRP Master F F VSRP Aware VSRP Backup optional link F B VSRP Aware B B VSRP Aware Hello packets In this example, two Brocade devices are configured as redundant paths for VRID 1. On each Brocade device, a Virtual Router ID (VRID) is configured on a port-based VLAN.
Layer 2 redundancy 16 NOTE If the Brocade device is configured as the VSRP Master and it is connected to a FastIron switch (FESX, FSX, SuperX, FGS, and FLS) that is operating as a VSRP-Aware device, the FastIron switch must have the vsrp-aware tc-vlan-flush command configured at the VLAN level. When the vsrp-aware tc-vlan-flush command is enabled on the FastIron switch, MAC addresses will be flushed at the VLAN level, instead of at the port level.
16 Layer 2 redundancy When a Backup sends a Hello message announcing its intent to become the Master, the Backup also starts a hold-down timer. During the hold-down time, the Backup listens for a Hello message with a higher priority than its own: • If the Backup receives a Hello message with a higher priority than its own, the Backup resets its Dead Interval and returns to normal Backup status.
Layer 2 redundancy 16 You can reduce the sensitivity of a VSRP device to failover by increasing its configured VSRP priority. For example, you can increase the configured priority of the VSRP device on the left in Figure 160 to 150. In this case, failure of a single link does not cause failover. The link failure caused the priority to be reduced to 100, which is still equal to the priority of the other device. This is shown in Figure 161.
16 Layer 2 redundancy Track ports Optionally, you can configure track ports to be included during VSRP priority calculation. In VSRP, a track port is a port that is not a member of the VRID’s VLAN, but whose state is nonetheless considered when the priority is calculated. Typically, a track port represents the exit side of traffic received on the VRID ports. By default, no track ports are configured. When you configure a track port, you assign a priority value to the port.
Layer 2 redundancy 16 MAC address failover on VSRP-aware devices VSRP-aware devices maintain a record of each VRID and its VLAN. When the device has received a Hello message for a VRID in a given VLAN, the device creates a record for that VRID and VLAN and includes the port number in the record.
16 Configuring basic VSRP parameters Configuring basic VSRP parameters To configure VSRP, perform the following required tasks: • Configure a port-based VLAN containing the ports for which you want to provide VSRP service. NOTE If you already have a port-based VLAN but only want to use VSRP on a sub-set of the VLANs ports, you can selectively remove ports from VSRP service in the VLAN. Refer to “Removing a port from the VRID’s VLAN”. • Configure a VRID: • Specify that the device is a backup.
Configuring basic VSRP parameters 16 Brocade(config)# router vsrp Syntax: [no] router vsrp If you want to provide Layer 3 redundancy only, you could use VRRP or VRRP-Extended. You may use router vrrp or router vrrp-extended as long as router vsrp is not enabled. Disabling or re-enabling VSRP To disable Layer 3 VSRP, enter the following command at the global CONFIG level. Brocade(config)# no router vsrp router vsrp is disabled.
16 VSRP 2 VSRP 2 In VSRP setup, there are always at least two VSRP switches for each VSRP instance. A passive device should always have either one access link or one trunk link connected with each VSRP switch for each VSRP instance. This can create a black hole scenario. A black hole is when VSRP failover causes data traffic from the switches/hosts which connect to VSRP passive switch to go nowhere. VSRP 2 can detect the health of each pair/set of links for each VSRP instance.
VSRP 2 16 FIGURE 166 Black hole scenario 3 VSRP failover: • VSRP backup set all include links in blocking state. Blocking ports drop data traffic. • VSRP failover changes master state by current priority change. • Current priority changes by link failure and track port failure.
16 VSRP 2 VSRP is switch redundancy, VSRP 2 is link redundancy. When VSRP backup changes an include port from blocking state to forwarding state, to make the aware session changes, VSRP backup will send advertisements on the forwarding include ports every 3*hello time. VSRP aware switches are able to change the src port of aware session and flush MACs. For VSRP non-aware switches (other vendors), the non-aware switch will flush MACs because the link connecting VSRP master is failed.
Displaying VSRP 2 16 • Link-pair has to be enabled or disabled on all VSRP switches for the same VSRP instance. • Currently, VSRP 2 only supports two VSRP switches in the topology. Multiple VSRP switches may cause a loop when the link redundancy set the VSRP ports in the forwarding state in the link failed cases. • For VSRP 2 supporting Layer 3 VSRP, it is necessary to have a non-include link in between two VSRP switches. VSRP virtual router is still in VSRP master.
16 Displaying VSRP 2 This display shows the following information when you use the vrid num or vlan vlan-id parameter. For information about the display when you use the aware parameter, refer to “Displaying the active interfaces for a VRID”. TABLE 69 CLI display of VSRP VRID or VLAN information This field... Displays... Total number of VSRP routers defined The total number of VRIDs configured on this device. VLAN The VLAN on which VSRP is configured.
Displaying VSRP 2 TABLE 69 16 CLI display of VSRP VRID or VLAN information (Continued) This field... Displays... dead-interval The configured value for the dead interval. The dead interval is the number of seconds a Backup waits for a Hello message from the Master for the VRID before determining that the Master is no longer active. If the Master does not send a Hello message before the dead interval expires, the Backups negotiate (compare priorities) to select a new Master for the VRID.
16 Displaying VSRP 2 Removing a port from the VRID’s VLAN By default, all the ports in the VLAN on which you configure a VRID are interfaces for the VRID. You can remove a port from the VRID while allowing it to remain in the VLAN. Removing a port is useful in the following cases: • There is no risk of a loop occurring, such as when the port is attached directly to an end host. • You plan to use a port in a Foundry MRP ring.
Displaying VSRP 2 16 You can configure a Backup to instead save the current timer values received from the Master when you save the configuration. Saving the current timer values instead of the configured ones helps ensure consistent timer usage for all the VRID’s devices.
16 Displaying VSRP 2 Changing the Dead interval The Dead interval is the number of seconds a Backup waits for a Hello message from the Master before determining that the Master is dead. To change the Dead interval, enter a command such as the following at the configuration level for the VRID. Brocade(config-vlan-200-vrid-1)# dead-interval 3 Syntax: [no] dead-interval num The num parameter specifies the interval and can be from 3 – 84 units of 100 milliseconds.
Displaying VSRP 2 16 The num parameter specifies the hold-down interval and can be from 2 – 84 units of 100 milliseconds. The default is 2 units of 100 ms (200 milliseconds). NOTE If you change the timer scale, the change affects the actual number of seconds. Changing the default track priority When you configure a VRID to track the link state of other interfaces, if one of the tracked interface goes down, the software changes the VSRP priority of the VRID interface.
16 Displaying VSRP information Preemption applies only to Backups and takes effect only when the Master has failed and a Backup has assumed ownership of the VRID. The feature prevents a Backup with a higher priority from taking over as Master from another Backup that has a lower priority but has already become the Master of the VRID.
Displaying VSRP information 16 On a devices where the VSRP Fast Start feature is enabled. Brocade(config-vlan-100-vrid-100)#show vsrp vrid 100 VLAN 100 auth-type no authentication VRID 100 ======== State Administrative-status Advertise-backup Preempt-mode master enabled disabled true Parameter Configured Current Unit/Formula priority 100 50 (100-0)*(2.0/4.0) hello-interval 1 1 sec/1 dead-interval 3 3 sec/1 hold-interval 3 3 sec/1 initial-ttl 2 2 hops next hello sent in 00:00:00.
16 Displaying VSRP information TABLE 70 CLI display of VSRP VRID or VLAN information (Continued) This field... Displays... Preempt-mode Whether the device can be pre-empted by a device with a higher VSRP priority after this device becomes the Master. This field can have one of the following values: • disabled – The device cannot be pre-empted. • enabled – The device can be pre-empted. NOTE: For the following fields: • Configured – indicates the parameter value configured on this device.
VSRP fast start 16 Displaying the active interfaces for a VRID On a VSRP-aware device, you can display VLAN and port information for the connections to the VSRP devices (Master and Backups). To display the active VRID interfaces, enter the following command on the VSRP-aware device. Brocade(config-vlan-200-vrid-1)# show vsrp aware Aware port listing VLAN ID VRID Last Port 100 1 3/2 200 2 4/1 Syntax: show vsrp aware This display shows the following information when you use the aware parameter.
16 VSRP fast start • Once a VSRP restart port is brought up by a VSRP instance, other VSRP instances (in Master state) that have this port as a member do not go to forwarding immediately. This is a safety measure that is required to prevent transitory loops. This could happen if a peer VSRP node gets completely cut off from this node and assumed Master state. In this case, where there are 2 VSRP instances that are in Master state and forwarding, the port comes up and starts forwarding immediately.
VSRP slow start 16 Displaying ports that have VSRP fast start feature enabled The show vsrp vrid command shows the ports on which the VSRP fast start feature is enabled. Brocade(config-vlan-100-vrid-100)#show vsrp vrid 100 VLAN 100 auth-type no authentication VRID 100 ======== State Administrative-status Advertise-backup Preempt-mode save-current master enabled disabled true false Parameter Configured Current Unit/Formula priority 100 50 (100-0)*(2.0/4.
16 VSRP and Foundry MRP signaling VSRP and Foundry MRP signaling A device may connect to a Foundry MRP ring through VSRP to provide a redundant path between the device and the Foundry MRP ring. VSRP and Foundry MRP signaling, ensures rapid failover by flushing MAC addresses appropriately. The host on the Foundry MRP ring learns the MAC addresses of all devices on the Foundry MRP ring and VSRP link.
VSRP and Foundry MRP signaling 16 To ensure that Foundry MRP is informed of the topology change and to achieve convergence rapidly, a signaling process for the interaction between VSRP and Foundry MRP. When a VSRP node fails, a new VSRP master is selected. The new VSRP master finds all Foundry MRP instances impacted by the failover. Then each Foundry MRP instance does the following: • The Foundry MRP node sends out a Foundry MRP PDU with the mac-flush flag set three times on the Foundry MRP ring.
16 VSRP and Foundry MRP signaling FIGURE 170 New path established There are no CLI commands used to configure this process.
Chapter 17 Topology Groups Table 72 displays the individual Brocade devices and the Topology Group features they support.
17 Master VLAN and member VLANs You can use topology groups with the following Layer 2 protocols: • • • • • STP Foundry MRP VSRP RSTP Ethernet RIng Protection (ERP) Master VLAN and member VLANs Each topology group contains a master VLAN and can contain one or more member VLANs and VLAN groups. A definition for each of these VLAN types follows: • Master VLAN – The master VLAN contains the configuration information for the Layer 2 protocol.
Configuration considerations 17 NOTE Because free ports are not controlled by the master port’s Layer 2 protocol, they are assumed always to be in the forwarding state, when enabled. Configuration considerations The configuration considerations are as follows: • You can configure up to 256 topology groups. Each group can control up to 4000 VLANs. A VLAN cannot be controlled by more than one topology group.
17 Configuring a topology group The commands configure topology group 2 and add the following to it: • VLAN 2 as master VLAN • VLANs 3, 4, and 5 as member VLANs • Member VLAN group 2 Syntax: [no] topology-group group-id The topology-group command creates a topology group. The group-id parameter assigns an ID 1 to 255 to the topology group. Syntax: [no] master-vlan vlan-id This command adds the master VLAN to the topology group. The VLAN must already be configured.
Configuring a topology group 17 The name option allows you to specify the VPLS instance that you are configuring into the topology group by using the name of the instance. The vlan-id variable is used with the vlan keyword to specify the VPLS VLAN being configured into topology group. You can specify multiple vlan-id values or specify a range of VLANs using the to option. The inner-vlan option allows you to specify a VPLS dual-tagged (double-tagged) VLAN configuration.
17 Displaying topology group information This command adds the master VLAN in ESI identified by the VLAN ID to the topology group. The VLAN must already be configured in the ESI “esi-name”. Make sure all the Layer 2 protocol settings in the VLAN are correct for your configuration before you add the VLAN to the topology group. A topology group can have only one master VLAN. Syntax: [no] member-vlan esi-name vlan-id This command adds a member VLAN in ESI identified by the VLAN ID to the topology group.
Displaying topology group information 17 This display shows the following information: TABLE 73 CLI display of topology group information This field... Displays... Topology Group The ID of the topology group. The range for group-id is 1 – 256. Topo HW Index A topology hardware index is a unique hardware ID that is assigned to a VLAN when a Layer 2 protocol is configured on the VLAN. The VLAN that runs the Layer 2 protocol could be a standalone Layer 2 VLAN or a master VLAN under a topology group.
17 Displaying topology group information TABLE 74 Topology group information with hardware index table (Continued) This field... Displays... Topology HW Index A topology hardware index is assigned to a VLAN when a Layer 2 protocol is configured on the VLAN. The VLAN that runs the Layer 2 protocol could be a standalone Layer 2 VLAN or a master VLAN under a topology group. The show topology-group hw-index-table output shows the mapping of a topology hardware index to a VLAN. The range for is 0 – 511.
Displaying topology group information TABLE 75 17 CLI display of topology group information (Continued) This field... Displays... L2 protocol The Layer 2 protocol configured on the control ports. The Layer 2 protocol can be one of the following: • Foundry MRP • STP • RSTP • VSRP • ERP Per vlan free ports The ports that are not controlled by the Layer 2 protocol information in the master VLAN.
17 590 Displaying topology group information Multi-Service IronWare Switching Configuration Guide 53-1003036-02
Chapter 18 Multi-Chassis Trunking (MCT) Table 76 displays the individual devices and the Multi-Chassis Trunking (MCT) features they support.
18 About Multi-Chassis Trunk (MCT) In an MCT scenario, all links are active and can be load shared to increase bandwidth. In addition, traffic restoration can be achieved in milliseconds after an MCT link failure or MCT switch failure. MCT is designed to increase network resilience and performance. FIGURE 171 Chassis trunk example MCT Benefits MCT provides the following benefits: • Provides link-level and switch-level redundancy.
About Multi-Chassis Trunk (MCT) • • • • 18 Interaction with MRP to build larger resilient Layer 2 domains Enhancement to Link Aggregation Groups Provides nodal redundancy in addition to link and modular redundancy Operates at the physical level to provide sub-second failover FIGURE 172 How MCT works MCT components To properly understand MCT, consider Figure 173, which shows an example of MCT deployment, functions and features.
18 About Multi-Chassis Trunk (MCT) MCT terminology • MCT peer switches: A pair of switches connected as peers through the ICL. The LAG interface is spread across two MCT peer switches and it acts as the single logical endpoint to the MCT client. • MCT client: The MCT client is the device that connects with MCT peer switches through an IEEE 802.3ad link. It can be a switch or an endpoint server host in the single-level MCT topology or another pair of MCT switches in a multi-tier MCT topology.
About Multi-Chassis Trunk (MCT) 18 • MCT VLANs: VLANs on which MCT clients are operating. These VLANs are explicitly configured in the MCT configuration by the user. NOTE: For MCT VLANs, MAC learning is disabled on ICL ports, while MAC learning is enabled on ICL port for non-MCT VLANs. • MCT Session VLANs: The VLAN used by the cluster for control operations. CCP protocol runs over this VLAN. The interface can be a single link or LAG port. If it is LAG port, it should be the primary port of the LAG.
18 About Multi-Chassis Trunk (MCT) MCT peers Each MCT physical node, A and B, will act as an MCT peer and they are connected using an ICL. The pair of MCT peers will act as one logical switch for the access switch or server so that the MCT pair can connect using standard LAG to them. This is illustrated in Figure 174. FIGURE 174 MCT peers ICL traffic handling An ICL link on the Brocade device can be a single port or a static or LACP LAG.
About Multi-Chassis Trunk (MCT) 18 FIGURE 175 MCT Active-Passive topology Figure 175 is an example of an MCT Active-Passive topology. PE1 and PE2 are nodes of cluster, MCT1. PE3 and PE4 are nodes of another MCT cluster, MCT2. • CE1 and CE2 are clients of MCT1 and MCT2 respectively. • Data traffic will be forwarded on the Active-Active links between the PEs. • Data traffic will be forwarded on the Active links from the CE to PE.
18 About Multi-Chassis Trunk (MCT) IGMP and MLD Control Packet Processing on MCT cluster switches For IGMP reports and leaves, • Native Packets coming to CPU from CCEP endpoints will be encapsulated in MDUP header and sent across ICL link thru the TCP connection to the remote cluster peer, along with required control information in the header indicating the packet was received from a CCEP link, VLAN and client RBridgeID.
About Multi-Chassis Trunk (MCT) 18 L2 protocol packet handling The default behavior is to forward or flood STP and RSTP BPDU packets. If the no cluster-l2protocol-forward command is configured on global basis or cluster-l2protocol-forward disable is configured on a port, the STP protocol packets coming on the MCT VLANs are dropped. All other L2 protocol packets will be flooded on the MCT VLANs or dropped. The cluster-l2protocol-forward command is not applicable to these protocol packets.
18 About Multi-Chassis Trunk (MCT) STP • The STP algorithm has been modified such that ICL never goes to blocking. ICL guard mechanism ensures that if ICL is going in blocking state then the port on which the superior BPDUs are being received is moved to BLOCKING state and ICL guard timer starts running on it. This timer runs as long as Superior BPDUs are received on this interface. As long as this timer runs on an interface the Superior BPDUs are dropped.
About Multi-Chassis Trunk (MCT) TABLE 79 18 MCT feature interaction matrix Supported Not Supported Flooding features (VLAN CPU protection, multicast flooding etc.) on cluster VLANs. 802.1ah on CCEP or ICL ports. Multi-VRF MSTP UDLD as independent boxes. VPLS on CCEP or ICL ports. Link OAM as independent boxes. VLL on CCEP or ICL ports. 802.1ag as independent boxes. MPLS on CCE or ICL ports. ARP as independent boxes.
18 About Multi-Chassis Trunk (MCT) • MAC Database Update Protocol (MUDP) will synchronize all MAC entries for VLANs served by ICL link • • • • Cluster ID should be same on both cluster switches • • • • MCT clients may support 16 members per LAG.
About Multi-Chassis Trunk (MCT) 18 c. Configure the session VLAN for the cluster. d. Configure one or more client/member VLANs for the cluster. e. Configure the ICL port or LAG being used for the cluster. f. Configure the MCT peer for this cluster. g. Deploy the cluster. All attributes except for client or member VLANs cannot be changed after the cluster is deployed. h. Configure the MCT cluster client instances.
18 About Multi-Chassis Trunk (MCT) 8. Configure the client role revertible mode 9. Configure the client role revertible timer 10. Configure the MCT peer for this cluster. 11. Configure the ICL port or LAG being used for the cluster. 12. Configure the MCT peer for this cluster. 13. Deploy the cluster. All attributes except for client or member VLANs cannot be changed after the cluster is deployed. 14. Configure the MCT cluster client instances.
About Multi-Chassis Trunk (MCT) 18 Single level MCT example FIGURE 176 Single level MCT The following steps are task for configuring a MCT scenario as shown in Figure 176. NOTE Save the current configuration files for both chassis operating in standalone mode before you begin creating a MCT. TOR-A (Top of rack MCT capable switch) See Figure 176. Creating LAG-1 1. You can either assign a LAG ID explicitly or it will be automatically generated by the system.
18 About Multi-Chassis Trunk (MCT) The ID parameter is optional. The value of the ID parameter that you can enter is from 1 to 256. If you do not enter a LAG ID, the system will generate one automatically. Once the LAG ID is generated the system will save it in the configuration file along with the LAG name, therefore the value will stay the same across system reload. NOTE The LAG id parameter is for static and dynamic LAGs only. No explicit configuration of a LAG id is allowed on keepalive LAGs.
About Multi-Chassis Trunk (MCT) 18 • For dynamic LAGs, LACP is activated on all LAG ports. When activating LACP, use active mode if passive is not specified; otherwise, use passive mode. • For a keep-alive LAGs, a LAG is formed, and LACP is started on the LAG port. Once the deploy command is issued, all LAG ports will behave like a single port. If the no deploy command is executed, then the LAG is removed. For dynamic LAGs, LACP is de-activated on all of the LAG ports.
18 About Multi-Chassis Trunk (MCT) 3. The primary port must be explicitly assigned using the primary-port command. Brocade(config-lag-3)# primary-port 1/5 4. Deploy the LAG 3 as shown below. Brocade(config-lag-3)# deploy 5. Assign a name to an individual port within a LAG. Brocade(config-lag-2)# port-name lag-client-2:1/1 ethernet 1/5 Brocade(config-lag-2)# port-name lag-client-1:1/2 ethernet 1/4 Enable layer 2 switching 1. By default, Brocade devices support routing over layer 2 switching.
About Multi-Chassis Trunk (MCT) 18 Brocade(config-vlan-2)# untag eth 1/3 to 1/5 3. Add the ICL port or LAG to the VLAN as tagged. ICL ports cannot be untagged in any VLAN and will automatically be removed from the default VLAN upon MCT cluster configuration. Brocade(config-vlan-2)#tag eth 1/1 to 1/2 Create the session VLAN See Figure 176 and “Creating LAG-1” for additional information on creating VLANs. 1. At the global CONFIG level assign an ID to the VLAN .
18 About Multi-Chassis Trunk (MCT) The parameter is an alphanumeric string. The name can have up to 255 characters on a device and can include blanks. You do not need to use quotation marks around the string, even when it contains blanks. Adding a virtual interface Add a virtual interface and configure an IP address on the interface by entering commands such as the following. Brocade(config)# interface ve 100 Brocade(config-vif-100)# ip address 1.1.1.
About Multi-Chassis Trunk (MCT) 18 NOTE The VLAN range is allowed to change even if cluster is deployed. 5. Specify the ICL for the cluster.The ICL interface can be a single link or trunk port. If it is a trunk port, it should be the primary port of the trunk . Only one ICL is supported. Enter a command such as the following to create the ICL for the cluster.
18 About Multi-Chassis Trunk (MCT) Creating cluster client 1 See Figure 176. 1. Create a cluster client instance and change the mode to the client instance. If an instance is already present, then directly change the mode to the client instance mode. Brocade(config-cluster-TOR)# client client-1 Syntax: [no] client The parameter can be 64 characters (maximum).
About Multi-Chassis Trunk (MCT) 18 3. Create a cluster client interface. Brocade(config-cluster-TOR-client-2)#client-interface ether 1/5 4. Deploy the cluster client. Brocade(config-cluster-TOR-client-2)deploy TOR-B Creating LAG-1 See Figure 176 and “Creating LAG-1” for additional information on creating a LAG. 1. Create a LAG with the LAG ID option. Brocade(config)# lag 1 dynamic id 1 Brocade(config-lag-1)# 2. Define the port the LAG will be using: Brocade(config-lag-1)# ports ethernet 1/6 3.
18 About Multi-Chassis Trunk (MCT) Creating LAG 3 See Figure 176 and “Creating LAG-1” for additional information on creating a LAG. 1. Create a LAG as shown below. Brocade(config)# lag 3 dynamic id 3 Brocade(config-lag-3)# 2. Define the port the LAG will be using. Brocade(config-lag-3)# ports ethernet 1/3 to 1/4 3. The primary port must be explicitly assigned using the primary-port command. Brocade(config-lag-3)# primary-port 1/3 4. Deploy a LAG as shown below. Brocade(config-lag-3)# deploy 5.
About Multi-Chassis Trunk (MCT) 18 Enable layer 2 switching 1. By default, Brocade devices support routing over layer 2 switching. You can enable layer 2 switching globally or on individual port using the no route-only command. The no route-only and route-only commands prompts you for whether or not you want to change the “route-only” behavior. You must enter y if you want to proceed or n if you do not.
18 About Multi-Chassis Trunk (MCT) 1. At the global CONFIG level assign an ID to the VLAN 4090. Brocade(config)# vlan 4090 name Session-VLAN Syntax: [no] vlan name VLAN IDs can be in the range of 1 – 4090. Use the no form of the command to delete the VLAN from the configuration. The VLAN ID range above 4090 has been reserved for current and future features for internal control purposes. In addition to a VLAN number, you can assign a name to a VLAN by entering name .
About Multi-Chassis Trunk (MCT) 18 Brocade(config)# interface ve 100 Brocade(config-vif-100)# ip address 1.1.1.2/24 Syntax: [no] interface [ve ] Syntax: [no] ip address The variable allows you to specify a VE interface ID. Configuring the cluster operation mode The cluster can be deployed separately without any client configured. When the cluster is deployed, it will check all the deployed clients and start the state machine for the clients. See Figure 176. 1.
18 About Multi-Chassis Trunk (MCT) Syntax: [no] icl ethernet x/y The parameter can be 64 characters (maximum). The ethernet x/y parameter is the ICL interface. 6. Specify the rbridge and ICL for the peers by entering a command such as the following. Brocade(config-cluster-TOR)# peer 1.1.1.1 rbridge-id 1 icl TOR Syntax: [no] peer rbridge-id icl The< peer-ip >parameter should be in same subnet as that of cluster management interface.
About Multi-Chassis Trunk (MCT) 18 Brocade(config-cluster-TOR-client-1)#client-interface ether 1/5 Syntax: [no] client-interface interface : ethernet x/y The ethernet x/y parameter is the ethernet interface. 4. Deploy the cluster client. If cluster is not deployed, the configuration will be taken but the client FSM will not be started. The consistency checks for client will be done at the time of client deploy.
18 About Multi-Chassis Trunk (MCT) 1. Create LAG 1 as shown below. Brocade(config)# lag 1 dynamic id 1 Brocade(config-lag-1)# 2. Define the ports the LAG will be using. Brocade(config-lag-1)# enable ethernet 1/1 to 1/3 3. The primary port must be explicitly assigned using the primary-port command. Brocade(config-lag-1)# primary-port 1/1 4. Deploy the LAG as shown below. Brocade(config-lag-1)# deploy 5. Assign a name to an individual port within a LAG.
About Multi-Chassis Trunk (MCT) 18 Optional cluster operation features A cluster can operate in two modes: Cluster Failover Mode Fast-failover (default) - As soon as the ICL interface goes down the CCP goes down. All the remote MACs are flushed. Slow-failover - Even if the ICL interface goes down the CCP waits for the hold-time before making the CCP down. Remote MACs are flushed only when the CCP is down. To disable the fast-failover mode, enter a command such as the following.
18 About Multi-Chassis Trunk (MCT) Active/Passive mode To configure MCT to operate in the Active/Passive mode, set the mode for the cluster. The cluster mode should be configured on both the node. If both nodes are not configured Active-Passive, then the CCP will not be brought up. This configuration is not allowed after the cluster is deployed.
About Multi-Chassis Trunk (MCT) 18 Brocade(config-cluster-TOR)#keep-alive-vlan 10 Syntax: [no] keep-alive-vlan The parameters specify the VLAN range. Possible values are 1 - 4090. When the CCP is down: • If keep-alive-vlan is configured, then CCRR messages are sent periodically for every 1 second over that VLAN. • When CCP is down and keep-alive vlan is configured, Master/Slave selection is based on following criteria: 1.
18 About Multi-Chassis Trunk (MCT) By default , MCT acts as a hub for STP, or RSTP. Switches connected to MCT can run STP normally. When STP, RSTP, or MSTP is enabled, the L2 protocol forwarding configuration is ignored and has no effect. To configure L2 protocol forwarding globally, enter a command such as the following. Brocade(config)#cluster-l2protocol-forward To disable L2 protocol forwarding on an interface, enter a command such as the following.
About Multi-Chassis Trunk (MCT) TABLE 81 18 L2 protocol forwarding action –MCT switch and non - MCT switch Protocol Destination MAC Non- MCT switch forwarding action MCT switch forwarding action SuperSpan 03-80-c2-xx-xx-00 Flood to the VLAN Same as non-MCT switch VSRP Control 03-04-80-00-01-00 Flood to the VLAN Same as non-MCT switch VSRP Source 03-04-80-00-01-01 Flood to the VLAN Same as non-MCT switch Loop detection MAC Base MAC address | 0x03000000 Flood to the VLAN Same as non-MCT
18 About Multi-Chassis Trunk (MCT) Syntax: [no] loop-detection shutdown-sending-port Loop-detection-syslog-duration If any of the ports has shutdown disabled, any loop detection will be logged into the syslog. Since the port is not shutdown, loop detect PDUs will come at a very fast rate and entries into the syslog are throttled. By default, syslog-duration is 10 minutes. The configurable range is from 10 minutes to 1440 minutes.This is a global command and any changes will be applied to all interfaces.
About Multi-Chassis Trunk (MCT) 18 When hitless failover happens on a Brocade MLXe, NetIron MLX, or NetIron XMR node, that node flushes all the MACs and will reestablish cluster CCP session. In this case, the user may notice some traffic impact. 6. Double failures – The ICL goes down and client interface goes down on one MCT node. Multiple failures could drop traffic in this scenario even if there is actual physical path is available.
18 About Multi-Chassis Trunk (MCT) Show commands Use the show cluster command to display the peer and client states.
About Multi-Chassis Trunk (MCT) TABLE 82 18 Reason for Local CCEP down Reason for Local CCEP down means.... Slave state Client is in Slave State when CCP is down cluster and client undeployed Neither the Cluster or Client is deployed. cluster undeployed Cluster is not deployed client undeployed Client is not deployed Syslogs and debugging Syslogs are displayed when remote CCEP is state is changed or remote client is deployed or undeployed.
18 About Multi-Chassis Trunk (MCT) interface ethernet 3/20 loop-detection shutdown-disable loop-detection vlan 20 ! interface ethernet 4/17 enable ! loop-detection shutdown-sending-port loop-detection vlan 20 loop-detection vlan 11 ! interface ve 10 ip address 10.10.10.1/24 ! ! ! cluster abc 1 rbridge-id 100 session-vlan 10 keep-alive-vlan 30 member-vlan 11 to 20 member-vlan 40 to 50 icl icl1 ethernet 3/20 peer 10.10.10.
About Multi-Chassis Trunk (MCT) 18 The following failure modes can occur for Layer 2 multicast over MCT. Local CCEP down event: • Outgoing traffic on local CCEP will now go through ICL and go out of remote CCEP. • Incoming traffic on local CCEP will now ingress through remote CCEP, and then ingress through ICL locally. Local CCEP up event: • Outgoing traffic on remote CCEP (after egressing through local ICL) will now start going out of local CCEP.
18 About Multi-Chassis Trunk (MCT) Multicast show commands Use the show ip pim mcache command to display if a CCEP port is being blocked or being forwarded to.
About Multi-Chassis Trunk (MCT) 18 Intf/Port|Groups| Version |Querier | Timer |V1Rtr|Tracking | |Oper Cfg| |OQrr GenQ| | ---------+------+----+----+---------------------------------------+----+----+----+--------v62 0 2 2 Disabled e2/1 2 - Self (MCT-Blk) 0 79 No e1/37 2 - Self 0 108 No e1/33 2 - Self 0 108 No Brocade# MAC operations This section describes MAC related configuration operations MAC Database Update (MDUP) The MACs that are learned locally are given the highest priority or the cost of 0 so th
18 About Multi-Chassis Trunk (MCT) Configuring the health check timer To configure the periodic timer value of the cluster MAC’s synchronization, enter the client-health-check [timer] [value] command. Time values range from 30 through 120 seconds and 60 seconds is the default.
About Multi-Chassis Trunk (MCT) 18 • Single MAC entry Manually synchronizing all interface MAC entries The cluster sync-cluster-intf-mac command synchronizes all interface MAC entries between the MCT peers of a cluster. Brocade#Cluster sync-cluster-intf-mac Cluster - All Interface MAC's Requested from peer Brocade# Manually synchronizing VLAN interface MAC entries The cluster sync-cluster-intf-mac vlan-id xxxx command synchronizes the interface MAC entries for the specified VLAN ID between MCT peers.
18 About Multi-Chassis Trunk (MCT) Manually synchronizing all client MAC entries The cluster sync-cluster-mac client-all command synchronizes all configured client MAC entries between MCT peers. Brocade#Cluster sync-cluster-mac client-all Cluster - Macs Requested from Peer for all Clients Manually synchronizing a single MAC entries The cluster sync-cluster-mac mac HHHH.HHHH.HHHH.vlan-id xxxx command synchronizes the specified MAC entry specific to a VLAN from the MCT peer.
About Multi-Chassis Trunk (MCT) 18 Configuring the Cluster MAC synchronization timer To configure the timer value of the cluster MAC’s synchronization, enter the cluster-mac-sync [timer] [value] command. Time values range from 5 through 60 minutes and 15 minutes is the default.
18 About Multi-Chassis Trunk (MCT) MAC aging Only the local MAC entries are aged on a node. The remote MAC entries will be aged based on explict MDUP messages only. The remote MACs learned through MDUP messages are dynamic MACs with the exception that they never age from FDB. MAC flush If the CEP port is down, the MACs are flushed and individual MAC deletion messages are sent to the Peer. If the CCEP local port is down, the MACs are flushed locally and individual MAC deletion messages are sent to peer.
About Multi-Chassis Trunk (MCT) 18 To display all the Cluster Local MAC entries for a cluster, use the show mac cluster command as shown below: Brocade#show mac cluster abc Total Cluster Enabled(CL+CR+CCL+CCR) MACs: 451 Total Cluster Local(CL) MACs: 100 Total Cluster Remote(CR) MACs: 151 Total Cluster Client Macs(CCL+CCR) for all clients: 200 Total Cluster Client Local(CCL) MACs for all clients: 200 CCL: Cluster Client Local CCR:Cluster Client Remote CL:Local CR:Remote MAC Address Port Age VLAN Type FDID
18 About Multi-Chassis Trunk (MCT) Clear MAC commands To clear all MACs in the system, enter a command such as the following. Brocade#clear mac Syntax: clear mac Clear cluster specific MACs To clear cluster specific MACs in the system, enter a command such as the following. Brocade#clear mac cluster TOR 1 local Syntax: clear mac cluster | { local | remote } Clear client specific MACs To clear client specific MACs in the system, enter a command such as the following.
About Multi-Chassis Trunk (MCT) 18 MDUP Flush Messages sent: 1 MDUP Synch Messages sent: 0 MDUP Update Messages received: 3 Add Mac received: 40 Del Mac received: 0 Move Mac received: 0 MDUP Mac Info Messages received: 0 MDUP Flush Messages received: 0 MDUP Synch Messages received: 0 Syntax: show mac mdup-stats Clearing the statistics of MDUP packets To clear the statistics of MDUP packets, enter a command such as the following.
18 About Multi-Chassis Trunk (MCT) Single level MCT example FIGURE 178 Single level MCT TOR-A: lag "1" dynamic id 1 ports ethernet 1/1 to 1/2 primary-port 1/1 deploy port-name "ICL-to-TOR-B:1/1" port-name "ICL-to-TOR-B:1/2" ! lag "2" dynamic id 2 ports ethernet 1/3 to 1/4 primary-port 1/3 deploy port-name "lag-client-1:1/1" port-name "lag-client-1:1/2" ! lag "3" dynamic id 3 ports ethernet 1/5 primary-port 1/5 deploy port-name "lag-client-2:1/1" ! no route-only 642 ethernet 1/1 ethernet 1/2 ethernet 1
About Multi-Chassis Trunk (MCT) 18 ! vlan 1 name DEFAULT-VLAN no untagged ethe 1/1 to 1/2 ! vlan 2 name client-VLAN untagged ethe 1/3 to 1/7 tagged ethe 1/1 to 1/2 ! vlan 4090 name Session-VLAN tagged ethe 1/1 to 1/2 router-interface ve 100 ! hostname TOR-A ! interface ethernet 1/1 enable ! interface ethernet 1/3 enable ! interface ethernet 1/5 enable ! interface ethernet 1/6 port-name CEP-PC enable ! interface ethernet 1/7 port-name to-L3-ECMP enable ! interface ve 100 ip address 1.1.1.
18 About Multi-Chassis Trunk (MCT) deploy port-name "ICL-to-TOR-A:1/1" ethernet 1/1 port-name "ICL-to-TOR-A:1/2" ethernet 1/2 ! lag "2" dynamic id 2 ports ethernet 1/3 primary-port 1/3 deploy port-name "lag-client-1:1/3" ethernet 1/3 ! lag "3" dynamic id 3 ports ethernet 1/4 primary-port 1/4 deploy port-name "lag-client-2:1/2" ethernet 1/4 ! no route-only ! vlan 1 name DEFAULT-VLAN no untagged ethe 1/1 to 1/2 ! vlan 2 name client-VLAN untagged ethe 1/3 to 1/5 tagged ethe 1/1 to 1/2 ! vlan 4090 name Sessio
About Multi-Chassis Trunk (MCT) 18 rbridge-id 200 client-interface ethernet 1/4 deploy ! end ---------------------------------------- Client-1: ! lag "1" dynamic id 1 ports ethernet 1/1 to 1/3 primary-port 1/1 deploy port-name "lag-to TOR-A" ethernet 1/1 port-name "lag-to TOR-A" ethernet 1/2 port-name "lag-to TOR-B" ethernet 1/3 ! interface ethernet 1/1 enable ! end ---------------------------------------- Client-2: ! lag "1" dynamic id 1 ports ethernet 1/1 to 1/2 primary-port 1/1 deploy port-name "lag-
18 About Multi-Chassis Trunk (MCT) Single level MCT- extension example FIGURE 179 Single level MCT- extension TOR-A: lag "1" dynamic id 1 ports ethernet 1/1 primary-port 1/1 deploy port-name "lag-client-2:1/1" ! lag "2" dynamic id 2 ports ethernet 1/2 primary-port 1/2 deploy port-name "lag-client-3:1/1" ! lag "3" dynamic id 3 ports ethernet 1/3 to 1/4 primary-port 1/3 deploy port-name "ICL-to-TOR-B:1/3" port-name "ICL-to-TOR-B:1/4" ! lag "4" dynamic id 4 ports ethernet 1/5 646 ethernet 1/1 ethernet 1/
About Multi-Chassis Trunk (MCT) 18 primary-port 1/5 deploy port-name "lag-client-1:1/1" ethernet 1/5 ! no route-only ! vlan 1 name DEFAULT-VLAN no untagged ethe 1/3 to 1/4 ! vlan 2 name client-VLAN untagged ethe 1/1 to 1/2 ethe 1/5 to 1/6 tagged ethe 1/3 to 1/4 ! vlan 4090 name Session-VLAN tagged ethe 1/3 to 1/4 router-interface ve 100 ! hostname TOR-A ! interface ethernet 1/1 enable ! interface ethernet 1/2 enable ! interface ethernet 1/3 enable ! interface ethernet 1/5 enable ! interface ethernet 1/6 p
18 About Multi-Chassis Trunk (MCT) ---------------------------------------- TOR-B: lag "1" dynamic id 1 ports ethernet 1/6 primary-port 1/6 deploy port-name "lag-client-2:1/2" ! lag "2" dynamic id 2 ports ethernet 1/7 primary-port 1/7 deploy port-name "lag-client-3:1/2" ! lag "3" dynamic id 3 ports ethernet 1/3 to 1/4 primary-port 1/3 deploy port-name "ICL-to-TOR-A:1/3" port-name "ICL-to-TOR-A:1/4" ! lag "4" dynamic id 4 ports ethernet 1/5 primary-port 1/5 deploy port-name "lag-client-1:1/2" ! no route-o
About Multi-Chassis Trunk (MCT) 18 cluster TOR 1 rbridge-id 2 session-vlan 4090 member-vlan 2 icl TOR ethernet 1/3 peer 1.1.1.
18 About Multi-Chassis Trunk (MCT) ! interface ve 2 ip address 10.10.10.1/24 ip ospf area 0 ! end ---------------------------------------- Client-3: ! lag "1" dynamic id 1 ports ethernet 1/1 to 1/2 primary-port 1/1 deploy port-name "lag-to TOR-A" ethernet 1/1 port-name "lag-to TOR-B" ethernet 1/2 ! vlan 2 untagged ethe 1/1 to 1/3 router-interface ve 2 ! router ospf area 0 ! interface ethernet 1/1 enable ! interface ethernet 1/3 port-name L3-ECMP-Cloud ! interface ve 2 ip address 10.10.10.
About Multi-Chassis Trunk (MCT) 18 Two level MCT example TABLE 83 Two level MCT TOR-A: lag "1" dynamic id 1 ports ethernet 1/1 to 1/2 primary-port 1/1 deploy port-name "ICL-to-TOR-B:1/1" ethernet 1/1 port-name "ICL-to-TOR-B:1/2" ethernet 1/2 ! lag "2" dynamic id 2 ports ethernet 1/3 primary-port 1/3 deploy port-name "lag-client-Server:1" ethernet 1/3 ! lag "3" dynamic id 3 ports ethernet 1/4 to 1/5 primary-port 1/4 deploy port-name "lag-Router-C:1/3" ethernet 1/4 port-name "lag-Router-D:1/3" ethernet 1/
18 About Multi-Chassis Trunk (MCT) ! no route-only ! vlan 1 name DEFAULT-VLAN no untagged ethe 1/1 to 1/2 ! vlan 2 name client-VLAN untagged ethe 1/3 to 1/5 tagged ethe 1/1 to 1/2 ! vlan 4090 name Session-VLAN tagged ethe 1/1 to 1/2 router-interface ve 100 ! hostname TOR-A ! interface ethernet 1/1 enable ! interface ethernet 1/3 enable ! interface ethernet 1/4 enable ! interface ve 100 ip address 1.1.1.1/24 ! ! cluster TOR 1 rbridge-id 1 session-vlan 4090 member-vlan 2 icl TOR ethernet 1/1 peer 1.1.1.
About Multi-Chassis Trunk (MCT) 18 deploy port-name "lag-client-Server:2" ethernet 1/3 ! lag "3" dynamic id 3 ports ethernet 1/4 to 1/5 primary-port 1/4 deploy port-name "lag-Router-C:1/4" ethernet 1/4 port-name "lag-Router-D:1/4" ethernet 1/5 ! no route-only ! vlan 1 name DEFAULT-VLAN no untagged ethe 1/1 to 1/2 ! vlan 2 name client-VLAN untagged ethe 1/3 to 1/5 tagged ethe 1/1 to 1/2 ! vlan 4090 name Session-VLAN tagged ethe 1/1 to 1/2 router-interface ve 100 ! hostname TOR-B ! interface ethernet 1/1 en
18 About Multi-Chassis Trunk (MCT) ports ethernet 1/1 to 1/2 primary-port 1/1 deploy port-name "ICL-to-Router-D:1/1" ethernet 1/1 port-name "ICL-to-Router-D:1/2" ethernet 1/2 ! lag "2" dynamic id 2 ports ethernet 1/3 to 1/4 primary-port 1/3 deploy port-name "lag-TOR-A:1/4" ethernet 1/3 port-name "lag-TOR-B:1/4" ethernet 1/4 ! no route-only ! vlan 1 name DEFAULT-VLAN no untagged ethe 1/1 to 1/2 ! vlan 2 name client-VLAN untagged ethe 1/3 to 1/5 tagged ethe 1/1 to 1/2 ! vlan 4090 name Session-VLAN tagged et
About Multi-Chassis Trunk (MCT) 18 ports ethernet 1/1 to 1/2 primary-port 1/1 deploy port-name "ICL-to-Router-C:1/1" ethernet 1/1 port-name "ICL-to-Router-C:1/2" ethernet 1/2 ! lag "2" dynamic id 2 ports ethernet 1/3 to 1/4 primary-port 1/3 deploy port-name "lag-TOR-A:1/5" ethernet 1/3 port-name "lag-TOR-B:1/5" ethernet 1/4 ! no route-only ! vlan 1 name DEFAULT-VLAN no untagged ethe 1/1 to 1/2 ! vlan 2 name client-VLAN untagged ethe 1/3 to 1/5 tagged ethe 1/1 to 1/2 ! vlan 4090 name Session-VLAN tagged et
18 About Multi-Chassis Trunk (MCT) MRP integration with MCT example FIGURE 180 MRP integration with MCT MCT-capable-switch-A lag "1" dynamic id 1 ports ethernet 1/1 to 1/2 primary-port 1/1 deploy port-name "ICL-to-Switch-2:1/1" ethernet 1/1 port-name "ICL-to-Switch-2:1/2" ethernet 1/2 ! lag "2" dynamic id 2 ports ethernet 1/3 to 1/4 primary-port 1/3 deploy port-name "lag-client-1:1/1" ethernet 1/3 port-name "lag-client-1:1/2" ethernet 1/4 ! no route-only ! vlan 1 name DEFAULT-VLAN no untagged ethe 1/1 to
About Multi-Chassis Trunk (MCT) 18 vlan 4090 name Session-VLAN tagged ethe 1/1 to 1/2 router-interface ve 100 ! hostname Switch-1 ! interface ethernet 1/1 enable ! interface ethernet 1/3 enable ! interface ethernet 1/5 port-name MRP-from-Master enable ! interface ve 100 ip address 1.1.1.1/24 ! ! cluster MRPRing 1 rbridge-id 1 session-vlan 4090 member-vlan 2 icl MRPRing ethernet 1/1 peer 1.1.1.
18 About Multi-Chassis Trunk (MCT) ring-interfaces ethe 1/1 ethe 1/5 enable ! vlan 4090 name Session-VLAN tagged ethe 1/1 to 1/2 router-interface ve 100 ! hostname Switch-2 ! interface ethernet 1/1 enable ! interface ethernet 1/3 enable ! interface ethernet 1/5 port-name MRP-to-Master enable ! interface ve 100 ip address 1.1.1.2/24 ! ! cluster MRPRing 1 rbridge-id 2 session-vlan 4090 member-vlan 2 icl MRPRing ethernet 1/1 peer 1.1.1.
MCT for VRRP or VRRP-E 18 MCT for VRRP or VRRP-E One MCT switch is the VRRP or VRRP-E master router and the other MCT switch is VRRP or VRRP-E backup router The MCT switch that acts as backup router needs to ensure that packets sent to a VRRP-E virtual IP address can be L2 switched to the VRRP-E master router for forwarding. The MCT switch that acts as master router will sync the VRRP-E MAC to the other MCT switch that acts as backup router.
18 MCT for VRRP or VRRP-E FIGURE 181 Example of MCTS that are Layer 2 switched In Figure 182, MCTs are deployed on two sites that are connected through two WAN links. • Two WAN links are completely independent. Switch A and B form MCT 1 and switch C and D form MCT 2. There are L2 protocols running on the VRRP-E routers. L2 protocols will block one of the WAN links to ensure loop-free topology.
MCT for VRRP or VRRP-E 18 FIGURE 182 Example of MCTs that are deployed on two sites that are connected through two WAN links. Configuration considerations • VRRE-E virtual MAC will be synced and learned on ICL ports on backup routers through the ICL. • VRRP or VRRP-E master router will be broadcast hello packets to all VLAN member ports including ICL ports. Normal VLAN FID will be used for broadcasting.
18 MCT for VRRP or VRRP-E • The VRRP-E MAC will be learned by the other MCT switch that acts as backup router. • Both data traffic and VRRP-E control traffic will need to travel through ICL unless the short-path forwarding feature is enabled. When both MCT devices act as the VRRP or VRRP-E backup routers, the following behavior will be seen: • Packets sent to VRRP-E virtual IP address will be L2 switched to the VRRP-E master router for forwarding.
MCT for VRRP or VRRP-E 18 • VRRP or VRRP-E backup routers will not flood back hello packets received from ICL ports to ICL ports, but will be flooded to other non- ICL ports. • MCT switches must have complete routing information using static routes for L3 forwarding. • For MCT switches configured with VRRP or VRRP-E, track-port features can be enabled to track the link status to the core switches so the VRRP or VRRP-E failover can be triggered.
18 MCT for VRRP or VRRP-E IPv6 VRRP-E short-path forwarding delay Use IPv6 VRRP-e short-path forwarding delay to configure the time delay required to enable short path forwarding after reloading the backup router. When configured, short path forwarding will be enabled only after the configured delay time after the MP initialization is completed (from the time all modules in the system are UP). Default value is set to 0 seconds.
MCT for VRRP or VRRP-E 18 ! cluster ABC rbridge-id 100 session-vlan 4090 member-vlan 100 to 300 icl icl_a_b ethernet 2/1 peer 10.10.20.
18 L2VPN support for L2 MCT clusters interface ve 10 ipv6 address 10::2/64 ipv6 vrrp vrid 10 backup priority 50 ipv6-address 10::100 activate ! NOTE Cluster client-rbridge-id on both switch A and B have to be same value for a given MCT.
L2VPN support for L2 MCT clusters 18 • This configuration is not mandated by configuration but is required for MCT operation to support L2VPN services. • A cluster L2 peer address configuration is not required to support L2VPN over MCT. NOTE For MCT L2VPN services to function, you must configure an operational MPLS tunnel (RSVP or LDP) between the MCT peers. L2VPN timers Following optional timers are needed when using MCT L2VPN. Keep-alive timer: This is used to detect a CCP that is down.
18 L2VPN support for L2 MCT clusters • This timer is to quickly detect CCP communication between the MCT peers and to failover quickly. This failure can happen due to route flaps or congestion in the network or in the MCT peer nodes. (Compared to L2 or MCT peer, this is similar to ICL link down).
L2VPN support for L2 MCT clusters 18 • For L2VPN, for both VLL and VPLS, Both MCT nodes will take the Active role for signaling towards the remote PE’s. When L2 Keep-alive vlan is configured, initial state will be same as if there is no keep-alive. Then once Keep-alive probes are exchanged, only one of the client links will stay up. Graceful restart support Graceful switchover is handled for MCT/L2VPN by the following: • Using the client-interfaces shutdown (cluster configuration) command.
18 L2VPN support for L2 MCT clusters Client Info: -----------Name Rbridge-id Config Port Trunk FSMState c1 101 Deployed 1/4 2 Admin Up c2 102 Deployed 1/2 1 Up Syntax: show cluster See “Show commands” for additional information regarding the show cluster output. Sample Configurations To support L2VPN services, the cluster with the newly added L2VPN parameters for this feature must be configured. Below, the configuration highlighted is the new L2VPN configuration. Assume: Local MCT node loopback 1.1.1.
MCT for VPLS vpls MCT_VPLS1 101 vpls-peer 3.3.3.3 4.4.4.4 5.5.5.5 [vpls-pw-redundancy-active] vlan 101 tagged eth 3/1 18 6.6.6.6 MCT for VPLS MCT helps organizations build scalable and resilient network infrastructures. MCT is an enhancement over the link aggregation standard, which allows multiple switches to appear as single logical switch connecting to another switch using a standard LAG.
18 MCT for VPLS Configuration Considerations Certain configurations must be correctly configured on both MCT nodes for MCT to work. If the following are not configured correctly, then MCT functionality will not come up for that VPLS instance and both MCT nodes will independently come up as Active nodes. • VPLS instance configuration should be with the same vc-id on both MCT nodes. • Both MCT nodes should have "MCT" configured for the VPLS Instance.
MCT for VPLS 18 • Local-switching enable or disable • VPLS MAC table size For each VPLS instance which has a MCT end-point, the MCT peer node is configured as a special VPLS peer. This is done on both MCT nodes. This is referred to as the cluster-peer and the PW between them is called the MCT Spoke PW. One of the nodes from MCT pair is picked as active. This can be done either globally or controlled per VPLS instance.
18 MCT for VPLS On Standby MCT PE Node • Traffic received from CE’s is forwarded to all locally connected CE’s and to MCT Spoke PW which is the only PE session which is active. • Traffic received from the MCT Spoke PW is forwarded to all locally connected CE’s which are single homed to this standby MCT PE node. MAC Learning & Synching CCEP endpoints can send traffic to either of the MCT switches. This causes MAC addresses to move from CCEP port and the MCT Spoke PW continuously.
MCT for VPLS 18 Local switching with MCT With MCT-VPLS support, local-switching refers to traffic switched between end-points of both the MCT nodes of the cluster. Identical vpls-local-switching configurations are required on the two MCT nodes for either supporting local-switching or disabling local-switching. When local-switching is disabled, packets from the Active MCT node end-points are not sent to MCT-Spoke PW. Packets from standby MCT node are always sent to MCT-Spoke PW.
18 MCT for VPLS PE to PE Forwarding With the support of MCT end-point for VPLS, packets received from a remote PE are sent to cluster-peer (received from a PW and sent to another PW). Similarly packets received from standby MCT node (using the cluster-cluster peer PW) are sent to Remote PE. The received MPLS packet are de-capsulated and the L2 Payload is again encapsulated into MPLS packet with the right labels.
MCT for VPLS 18 Error: End-point should not be configured while removing Cluster-Peer configuration. If any remote peer is configured while resetting the cluster-peer mode for the VPLS instance, the following error message will be displayed. Error: Remote-peer should not be configured while removing Cluster-Peer configuration. If auto-discover is configured while resetting the cluster-peer mode for the VPLS instance, the following error message will be displayed.
18 MCT for VPLS IFL-ID: n/a VC-Mode: Raw Total VPLS peers: 2 (2 Operational) Cluster-Peer address: 12.12.12.12, State: Operational, Uptime: 2 hr 55 min Tnnl in use: tnl2(3)[RSVP] Peer Index:0 Local VC lbl: 983040, Remote VC lbl: 983040 Local VC MTU: 1500, Remote VC MTU: 1500 Local VC-Type: Ethernet(0x05), Remote VC-Type: Ethernet(0x05) Peer address: 15.15.15.
MCT for VLL 18 router mpls vpls test 10 cluster-peer 12.12.12.12 vpls-peer 21.21.21.21 22.22.22.22 3.3.3.3 vlan 10 tag eth 1/1 eth 1/2 …….. cluster abc 1 rbridge-id 100 l2vpn-peer 12.12.12.12 rbridge-id 101 deploy client c1 rbridge-id 300 client-interface ethernet 1/1 deploy Switch PE12: MLX-PE12#show run router mpls vpls test 10 cluster-peer 11.11.11.11 vpls-peer 21.21.21.21 22.22.22.22 3.3.3.3 vlan 10 tag eth 1/1 eth 1/2 …….. cluster abc 1 rbridge-id 101 l2vpn-peer 11.11.11.
18 MCT for VLL • There is a VLL instance mct-spoke-pw established between MCT pair for sending data traffic from standby to active node from the customer edge nodes(CE1, CE2). • MCT cluster pair nodes communicate to each other using CCP communication provided by MCT infrastructure to identify as cluster pairs based on per instance and negotiate active/standby roles. • For cluster pair PE1 and PE2, traffic from CE1 to CE2 flows as follows.
MCT for VLL 18 Peer information sync If VLL information is already sent to the MCT peer and VLL peer is updated, then the VLL peer information will sync to the MCT peer. VLL Peer information includes PW status and redundancy status. End point status handling Whenever there are any end point status changes, they are synchronized by MCT infrastructure and the events will be handled whenever logical status of endpoint changes from UP to DOWN or DOWN to UP.
18 MCT for VLL VLL global pw-redundancy (optional) Once MCT is enabled for a VLL instance, the two MCT cluster nodes synchronize the configuration with each other over the CP and decide which node will take up the Active role and Standby role. PW redundancy support provides is backup PWs ready so that traffic can be quickly failed over to the backup PWs. This command can be configured either globally for all VLL instances with MCT or for each VLL instance individually.
18 MCT for VLL Once the vll-instance is operational and if the vll level pwredundancy is changed, the pw-redundancy election is triggered, which can cause the vll-active state to change. Setting the L2VPN global revertible timer Whenever a node needs to become active for a given L2VPN instance, it sends a message to peer MCT node and starts this timer.
18 MCT for VLL Extended Counters: Disabled Counter : Disabled Vll-Peer State Remote VC type Local label Local group-id Tunnel LSP MCT Status TLV : : : : : : : 5.5.5.5 (Standby-Standby) Down - no tummel LSP to vll-peer Remote VC MTU : Remote label : 0 Remote group-id: LSP_to_1 (tnl0) Standby Vll-Peer State Remote VC type Local label Local group-id Tunnel LSP MCT Status TLV : : : : : : : 4.4.4.
MCT Snooping 18 client MCT_CLIENT1 rbridge-id 101 client-interface e 1/1 [vll-pw-redundancy-active] deploy MCT Snooping All VLAN IGMP and PIM snooping features are supported on the MCT links. Brocade supports both IPv4 and IPv6 snooping over MCT links. Events Handling CCEP down event to MCT CCEP down event to MCT peer is generated only if, • The CCEP port is replaced in the SG entry's OIF to ICL ports, if CCEP ports exists in the OIF list.
18 MCT Snooping MCT remote CCEP up event CCEP up event from the MCT PEER is generated only if, • IGMP joins may start coming thru the remote CCEP links or • IGMP joins may continue to come thru the local CCEP link as before. In both cases, upon receiving MCT CCEP up event from peer, the local CCEP ports will be removed from the OIF list of those SG entries with ICL as IIF. No other SG entries are affected. They'll continue to have the membership information from CCEP ports.
MCT Snooping 18 There are no specfic MCT commands for configuring MCT snooping. Below is a sample MCT snooping configuration .
18 MCT Snooping tagged ethe 1/1 ethe 1/7 ethe 1/12 ethe 1/23 ethe 1/25 to 1/27 ethe 1/40 ethe 1/42 ethe 1/47 ethe 2/1 router-interface ve 31 multicast6 passive ! ! vlan 4090 tagged ethe 1/1 ethe 1/25 to 1/27 router-interface ve 49 ! interface ve 21 ip address 21.1.1.1/24 ! interface ve 31 ip address 31.31.31.3/24 ipv6 address 2031:31::2/112 ! interface ve 49 ip address 49.49.49.1/30 ! ! cluster CLUSTER-1 1 rbridge-id 1 session-vlan 4090 member-vlan 20 to 50 icl ICL-1 ethernet 1/1 peer 49.49.49.
MCT Snooping 18 tagged ethe 1/1 ethe 1/25 ethe 1/45 to 1/46 router-interface ve 21 multicast active ! ! vlan 31 tagged ethe 1/1 ethe 1/9 ethe 1/12 ethe 1/14 ethe 1/25 ethe 1/39 ethe 1/41 to 1/42 ethe 1/45 to 1/46 ethe 2/1 router-interface ve 31 multicast6 passive ! ! vlan 4090 tagged ethe 1/1 ethe 1/25 ethe 1/45 to 1/46 router-interface ve 49 ! interface ve 21 ip address 21.1.1.2/24 ! interface ve 31 ip address 31.31.31.2/24 ipv6 address 2031:31::1/112 ! ! interface ve 49 ip address 49.49.49.
18 MCT Snooping Brocade# show ip multicast vlan 20 ----+-----+---------+---------------+-----+-----+-----VLAN State Mode Active Time (*, G)(S, G) Querier Query Count Count ----+-----+---------+---------------+-----+-----+-----20 I-Ena Active Self 40 1 1 ----+-----+---------+---------------+-----+-----+-----Router ports: Flags: R-Router Port, V2|V3: IGMP Receiver, P_G|P_SG: PIM Join 1 (*, 224.1.1.
MCT Snooping 18 Router ports: 4/3 (97s) Flags: R-Router Port, V2|V3: IGMP Receiver, P_G|P_SG: PIM Join 1 (*, 224.1.1.1 ) 00:07:09 NumOIF: 2 profile: none Outgoing Interfaces: e4/3 vlan 20 ( R) 00:02:42/97s e3/2 vlan 20 ( V2) 00:07:09/91s 1 (1.1.1.1, 224.1.1.
18 PIM Over MCT PIM Over MCT NOTE PIM-DM over MCT is not supported in this release. Figure 186 is an example of the IGMP synchronizing. FIGURE 186 Synchronizing IGMP State on the CCEPs Synchronizing IGMP State on the CCEPs The MDUP channel sends an IGMP report of messages received on the local CCEP to the remote MCT peer. This ensures that regardless of which MCT peer the client forwards the messages, both will recieve it and process it, ensuring identical state in both MCT Peers.
PIM Over MCT 18 P1 sends this to P2 via MDUP. P2 adds (*, G1) to CCEP2 upon processing it. R sends IGMP report for (*, G2). Client forwards it to P2 on CCEP2. P2 sends this to P1 via MDUP. P1 adds (*, G2) to CCEP1 upon processing it. Final result, both P1 and P2 has both (*, G1) and (*, G2) on their local CCEPs.
18 PIM Over MCT Show commands Use the show ip pim mcache command to display if a CCEP port is being blocked or being forwarded to.
PIM Over MCT 18 MJ - Membership Join, MI - Membership Include, ME - Membership Exclude BR - Blocked RPT, BA - Blocked Assert, BF - Blocked Filter, BI Blocked IIF, BM - Blocked MCT Total entries in mcache: 1 1 (2062:62:62:62::11, ff1a::2) in v62 (tag e1/1), Uptime 00:00:58 (SM) upstream neighbor is L2 fe80::21b:edff:fea4:a441.
18 PIM Over MCT Received Received Received Received Brocade# messages dropped because messages dropped because messages dropped because bytes skipped because of MCT VLAN unrecognized of bad message type of bad checksum sync or checksum errors : : : : 0 0 0 0 Syntax: show ipv6 pim count mct Displaying IGMP Interfaces Use the show ip igmp interface command to show the IGMP Query suppression state on CCEP ports.
PIM Over MCT 18 vlan 4090 tagged ethe 2/1 to 2/2 router-interface ve 100 router pim rp-address 2.2.2.1 interface management 1 ip address 10.25.109.6/21 enable interface ve 100 ip address 1.1.1.1/24 interface ve 200 ip address 2.2.2.1/24 ip pim-sparse cluster AMERICAS 1 rbridge-id 100 session-vlan 4090 member-vlan 200 icl AMERICAS-ICL ethernet 2/1 peer 1.1.1.
18 PIM Over MCT rbridge-id 300 client-interface ethernet 3/5 deploy 698 Multi-Service IronWare Switching Configuration Guide 53-1003036-02
Chapter 19 Configuring IP Table 85 displays the individual Brocade devices and the IP features they support.
19 Configuring IP TABLE 85 700 Supported Brocade IP features (Continued) Features supported Brocade NetIron XMR Series Brocade MLX Series Brocade NetIron CES 2000 Series BASE package Brocade NetIron CES 2000 Series ME_PREM package Brocade NetIron CES 2000 Series L3_PREM package Brocade NetIron CER 2000 Series Base package Brocade NetIron CER 2000 Series Advanced Services package Disabling Gratuitous ARP Requests for Local Proxy ARP Yes Yes Yes Yes Yes Yes Yes Dynamic ARP Inspection (DAI
19 Configuring IP TABLE 85 Supported Brocade IP features (Continued) Features supported Brocade NetIron XMR Series Brocade MLX Series Brocade NetIron CES 2000 Series BASE package Brocade NetIron CES 2000 Series ME_PREM package Brocade NetIron CES 2000 Series L3_PREM package Brocade NetIron CER 2000 Series Base package Brocade NetIron CER 2000 Series Advanced Services package Statistics for GRE and Manual IPv6 Tunnels Yes Yes No No No No No Multi-port static ARP for the CES/CER No No Y
19 The IP packet flow The IP packet flow Figure 187 shows how an IP packet moves through a Brocade device. FIGURE 187 IP Packet flow through a Brocade device Figure 187 shows the following packet flow. 1. When the Brocade device receives an IP packet, the Brocade device checks for IP ACL filters on the receiving interface. If a deny filter on the interface denies the packet, the Brocade device discards the packet and performs no further processing.
The IP packet flow 19 The software enables you to display the ARP cache and static ARP table, the IP route table, the IP forwarding cache. You also can change the capacity of the following tables by changing the memory allocation for the table: • • • • “ARP cache table” “Static ARP table” “IP route table” “IP forwarding cache” ARP cache table The Address Resolution Protocol (ARP) is supported on the Brocade device. Refer to “Configuring ARP parameters”.
19 The IP packet flow • “Displaying the static ARP table” To configure other ARP parameters, refer to “Configuring ARP parameters”. To increase the size of the ARP cache and static ARP table, refer to the following: • For dynamic entries, refer to the “Displaying and modifying default settings for system parameters”. The ip-arp parameter controls the ARP cache size. IP route table The IP route table contains paths to IP destinations.
The IP packet flow 19 IP forwarding cache The Brocade device maintains a software cache table for fast processing of IP packets that are forwarded or generated by the CPU. The cache also contains forwarding information that is normally contained in the IP routing table. For example, the cache contains information on the physical outgoing port, priority, VLAN, and the type of cache entry. Also, cache entries have hardware information, which is useful for debugging and aging.
19 Basic IP parameters and defaults Basic IP parameters and defaults IP is enabled by default. The following protocols are disabled by default: • Route exchange protocols (RIP, OSPF, IS-IS, BGP4) • Multicast protocols (IGMP, PIM-DM, PIM-SM, DVMRP) • Router redundancy protocols (VRRP-E, VRRP, FSRP) When parameter changes take effect Most IP parameters described in this chapter are dynamic. They take effect immediately, as soon as you enter the CLI command.
Basic IP parameters and defaults TABLE 86 19 IP global parameters (Continued) Parameter Description Default Router ID The value that routers use to identify themselves to other routers when exchanging route information. OSPF and BGP4 use router IDs to identify routers. RIP does not use the router ID. The IP address configured on the lowest-numbered loopback interface. If no loopback interface is configured, then the lowest-numbered IP address configured on the device.
19 Basic IP parameters and defaults TABLE 86 IP global parameters (Continued) Parameter Description Default Directed broadcast mode The packet format the router treats as a directed broadcast. The following formats can be directed broadcast: • All ones in the host portion of the packet’s destination address. • All zeroes in the host portion of the packet’s destination address.
Basic IP parameters and defaults TABLE 86 19 IP global parameters (Continued) Parameter Description Default IP load sharing A feature that enables the device to balance traffic to a specific destination across multiple equal-cost paths. Load sharing is based on a combination of destination MAC address, source MAC address, destination IP address, source IP address, and IP protocol. Enabled NOTE: Load sharing is sometimes called Equal Cost Multi Path (ECMP).
19 Basic IP parameters and defaults TABLE 87 IP interface parameters (Continued) Parameter Description Default Encapsulation type The format of the packets in which the device encapsulates IP datagrams. The encapsulation format can be one of the following: • Ethernet II • SNAP Ethernet II IP Maximum Transmission Unit (MTU) The maximum length (number of bytes) of an encapsulated IP datagram the device can forward.
GRE IP tunnel 19 GRE IP tunnel Multi-Service IronWare software supports the tunneling of packets with the Generic Routing Encapsulation (GRE) mechanism over an IP network, as described in RFC 2784. With GRE, packets are encapsulated in a transport protocol packet at a tunnel source and delivered to a tunnel destination, where they are unpacked and made available for delivery.
19 GRE IP tunnel • Fragmentation of the Inner packet as described in Section 3.4 of RFC 4459 This enhancement also allows you to set a specific MTU value for packets entering a configured GRE tunnel. Packets whose size is greater than the configured value are fragmented and encapsulated with IP/GRE headers for transit through the tunnel. This feature supports Jumbo packets although they may be fragmented based on the MTU value configured.
GRE IP tunnel 19 Configuring ECMP for routes through an IP GRE tunnel If multiple routes are using IP GRE tunnels to a destination, packets are automatically load-balanced between tunnels. This feature allows for load distribution of traffic among the available IP GRE tunnels. If the routes to a destination are both normal IP routes and routes through IP GRE tunnels, ECMP is not enabled.
19 GRE IP tunnel The multi-service-2 parameter provides another alternative to multi-service to optimize the device for Multi-Service applications. The multi-service-3 parameter provides another alternative to multi-service to optimize the device for Multi-Service applications to support IPv6 VRF. The multi-service-4 parameter provides another alternative to multi-service to optimize the device for Multi-Service applications to support IPv6 VRF.
GRE IP tunnel 19 Configuring a tunnel interface To configure a tunnel interface, use a the following command. Brocade(config)# interface tunnel 1 Brocade(config-tnif-1) Syntax: [no] interface tunnel tunnel id The tunnel-id variable is numerical value that identifies the tunnel being configured. Possible range is from 1 to the maximum configured tunnels in the system.
19 GRE IP tunnel Configuring a tunnel interface for GRE encapsulation To configure a specified tunnel interface for GRE encapsulation, enter the following command. Brocade(config)# interface tunnel 1 Brocade(config-tnif-1)tunnel mode gre ip Syntax: [no] tunnel mode gre ip The gre parameter specifies that the tunnel will use GRE encapsulation The Ip parameter specifies that the tunnel protocol is IP.
GRE IP tunnel 19 Configuring a TOS value This is an optional parameter that allows you to set the TOS value for the outer IP header of the GRE tunnel packets. To configure the TOS value, enter the following command. Brocade(config)# interface tunnel 1 Brocade(config-tnif-1)tunnel tos 100 Syntax: [no] tunnel tos tos-value The tos-value variable specifies a TOS value for the outer IP header. The Brocade NetIron XMR and Brocade MLX series possible values are 0 - 255. The default value is 0.
19 GRE IP tunnel Configuring a maximum MTU value for a tunnel interface You can set an MTU value for packets entering the tunnel. Packets that exceed either the default MTU value of 1476 bytes or the value that you set using this command are fragmented for transit through the tunnel. The default MTU value is set to 1476. The following command allows you to change the MTU value for packets transiting “tunnel 1”.
GRE IP tunnel 19 Brocade(config-tnif-1)# ip address 10.10.3.1/24 Brocade(config-tnif-1)# keepalive 5 4 Brocade(config-tnif-1)# exit Brocade(config)# ip route 10.10.2.0/24 10.10.3.2 Configuration example for Brocade B Brocade(config)# interface ethernet 5/1 Brocade(config-if-e10000-5/1)# ip address 131.108.5.2/24 Brocade(config)# interface tunnel 1 Brocade(config-tnif-1)# tunnel source ethernet 5/1 Brocade(config-tnif-1)# tunnel destination 36.0.8.
19 Multicast over GRE tunnel Syntax: show interface tunnel tunnel-no Multicast over GRE tunnel NOTE MTU fragmentation for multicast traffic is not enabled over a GRE tunnel. Packets are transmitted without MTU fragmentation. This behavior is applicable on Brocade MLX series, Brocade NetIron XMR, Brocade NetIron CER, and Brocade NetIron CES devices. Multi-Service IronWare software supports Multicast over a point-to-point GRE tunnel.
Tunnel statistics for a GRE tunnel or IPv6 manual tunnel 19 NOTE The configuration is not recommended for all users, it is only needed if the user wants to override the default behavior. When the GRE encapsulated multicast packet is received, hardware processing attempts to find a match in the CAM session based on the inner (s,g) entry. If hardware processing cannot find the inner (s,g) entry in the CAM session, the packet will be dropped.
19 Tunnel statistics for a GRE tunnel or IPv6 manual tunnel system prompts you. Thereafter, when you run any of these three commands to disable or enable a feature, the system does not prompt. Removing any of the configurations can be done at anytime and does not necessitate a reload. The new configuration immediately becomes effective, but the source-ingress CAM partition is removed only upon the next reload.
Tunnel statistics for a GRE tunnel or IPv6 manual tunnel 19 Statistics polling on the MP and LP The LP module polls the statistics once every second. For every one second, the module polls the statistics either for 5000 entries or until the completion of a specific application. (The same polling mechanism is also used for other applications, such as IP, MPLS, L3VPN, VLL, VPLS and IP Tunnel.) After all the applications are polled, the system waits for 220 seconds to schedule the next polling event.
19 Tunnel statistics for a GRE tunnel or IPv6 manual tunnel Behavior after an LP failure If LP module goes down, the counters for that LP are preserved. After the LP comes back up, the preserved counters for that LP can be displayed. Feature scalability A Brocade NetIron XMR device supports 256 tunnels by default and 8000 tunnels for its maximum number of tunnels.
Restart global timers 19 To clear statistics for a specific tunnel, include the ID of that tunnel. Configuring IPv6 session enforce check You can enable the IPv6 session enforce check by using the ipv6-session-enforce-check command. When an IPv6 packet arrives and this feature is enabled, the system tries to match the IPv6 packet source and destination address pair with the tunnel configured destination and source pair. If the pairs do not match, the packet is dropped in hardware.
19 Restart global timers The process of syncing routes between a new MP and its LPs using the new timers are illustrated in Figure and described in the following steps. 1. The MP switchover from active to redundant MP begins. 2. The system max-hold- timer starts. 3. The IGP/BGP restart process begins. 4. If the IGP/BGP restart process is completed before the system max-hold-timer expires, the system max-hold-timer is cancelled and the protocols-converge-timer starts. 5.
Configuring IP parameters 19 Graceful-restart protocols-converge-timer This timer defines the time that a Brocade device waits for restarting protocols to converge at the final step in the restart process. In a heavily loaded system where BGP/OSPF/GRE/Static protocols can have a dependency on each other, their restart procedures may also depend on each other.
19 Configuring IP parameters Assigning an IP address to an Ethernet port To assign an IP address to port 1/1, enter the following commands. Brocade(config)# interface ethernet 1/1 Brocade(config-if-e1000-1/1)# ip address 10.45.6.1 255.255.255.0 NOTE You also can enter the IP address and mask in CIDR format, as follows. Brocade(config-if-e10000-1/1)# ip address 10.45.6.
Configuring IP parameters 19 For the syntax of the IP address, refer to “Assigning an IP address to an Ethernet port” on page 728. Assigning an IP address to a virtual interface A virtual interface is a logical port associated with a Layer 3 Virtual LAN (VLAN) configured on a Brocade device. NOTE Other sections in this chapter that describe how to configure interface parameters also apply to virtual interfaces.
19 Configuring IP parameters Enter the MAC address in the following format: HHHH.HHHH.HHHH NOTE You must save the configuration and reload the software to place the change into effect. Deleting an IP address To delete an IP address, enter a command such as the following. Brocade(config-if-e1000-1/1)# no ip address 10.1.2.1 This command deletes IP address 10.1.2.1. You do not need to enter the subnet mask. To delete all IP addresses from an interface, enter the following command.
Configuring IP parameters 19 The donor interface must be one of the following: • Loopback interface • VE interface • Ethernet interface (can be part of a LAG interface; must be untagged if in a VLAN) The unnumbered interfaces can be the following: • VE interface • Ethernet interface (must be untagged if in a VLAN) Configuring an unnumbered interface To enable an unnumbered interface to inherit the IP address of a donor interface, enter commands such as the following: Brocade (config)# interface ve 10 B
19 Configuring IP parameters port enabled port state: UP ip address: 1.1.1.1/24 Unnumbered interface, Using IP address of unnumbered arp-suppression is enabled Port belongs to VRF: default-vrf (output truncated) ve 9 The second highlighted line indicates whether ARP suppression is enabled or disabled. Refer to “ARP suppression on unnumbered interfaces” for information about ARP suppression.
Configuring IP parameters 19 • DHCP option 82 (refer to “Enabling DHCP snooping on a VLAN” on page 764) • Static DAI entries (refer to “Configuring DAI” on page 755) Syntax: [no] ip unnumbered-arp-suppression Use the no ip unnumbered-arp-suppression command to disable ARP suppression on the interface. This command is applicable only to donor and unnumbered interfaces. It has no effect on other interfaces.
19 Configuring IP parameters • If reachability is needed between two hosts within the same subnet, you must configure local proxy ARP on the unnumbered interfaces. Refer to “Enabling local proxy ARP” on page 752 for more information. Static route considerations for unnumbered interfaces • If you configure a static route with an unnumbered interface or donor interface as the next hop, it is recommended that you configure a standard static route instead of an interface-based static route.
Configuring IP parameters 19 Brocade (config-vlan-30)# router-interface ve 30 Brocade (config-vlan-30)# interface ve 30 Brocade (config-vif-30)# ip unnumbered loopback 1 Configure the DHCP server. In this example, the DHCP server address is 10.40.40.4. Brocade (config-vif-30)# interface ethernet 1/2 Brocade (config-if-e1000-1/2)# ip address 10.40.40.1/24 Brocade (config-if-e1000-1/2)# dhcp-snooping-trust Configure the DHCP server address in the unnumbered interfaces.
19 Configuring IP parameters You can also enter the IP address and mask in the Classless Interdomain Routing (CIDR) format, as follows. Brocade(config-if-e1000-1/5)# ip address 10.9.9.9/31 Syntax: [no] ip address ip-address ip-mask Syntax: [no] ip address ip-address/subnet mask-bits The ip-address variable specifies the host address. The ip-mask variable specifies the IP network mask. The subnet mask-bits variable specifies the network prefix mask.
Configuring IP parameters Brocade(config-if-e1000-2/5)# show ip route Total number of IP routes: 21 Destination Gateway Port 1 10.2.2.2/31 DIRECT eth 1/5 2 10.4.4.4/31 DIRECT eth 1/5 3 10.25.25.254/31 DIRECT ve 10 4 10.168.32.0/31 DIRECT ve 10 Cost 0/0 0/0 0/0 0/0 Type D D D D 19 Uptime 2h19m 2h19m 2h25m 2h25m Syntax: show ip route Enabling hardware forwarding of IP option packets based on Layer 3 destination The IP option field in an IP header is variable in length.
19 Configuring IP parameters Brocade(config)# trunk e 3/1 to 3/4 trunk transaction done. Brocade(config-trunk-3/1-3/4)# exit Brocade(config)# interface ethernet 3/1 Brocade(config-if-e1000-3/1)# ignore-options If the LAG is removed, the ignore-options command will be propagated to all ports that were previously in the LAG. If you try to create a LAG where some of the ports have the ignore-options command configured and some do not, the LAG will not be allowed as shown in the following example.
Configuring IP parameters 19 For example, if the domain “newyork.com” is defined on a Brocade device and you want to initiate a ping to host “NYC01” on that domain, you need to reference only the host name in the command instead of the host name and its domain name. For example, you could enter either of the following commands to initiate the ping. Brocade# ping nyc01 Brocade# ping nyc01.newyork.
19 Configuring IP parameters Because the newyork.com domain is already defined on the Brocade device, you need to enter only the host name, NYC02, as noted below. Brocade# traceroute nyc02 Syntax: [no] traceroute host-ip-addr [maxttl value] [minttl value] [numeric] [timeout value] [source-ip ip addr] The only required parameter is the IP address of the host at the other end of the route.
Configuring IP parameters 19 • The MAC address of the next-hop gateway toward the packet’s destination. • An Ethernet broadcast address. The entire IP packet, including the source address, destination address, other control information, and the data, is placed in the data portion of the Layer 2 packet. Typically, an Ethernet network uses one of two different formats of Layer 2 packet: • Ethernet II • Ethernet SNAP (also called IEEE 802.3) The control portions of these packets differ slightly.
19 Configuring IP parameters Changing the MTU The IP MTU is the maximum length of an IP packet that a Layer 2 packet can contain. If an IP packet is larger than the IP MTU allowed by the Layer 2 packet, the Brocade device fragments the IP packet into multiple parts that will fit into Layer 2 packets, and sends the parts of the fragmented IP packet separately, in different Layer 2 packets. The device that receives the multiple fragments of the IP packet reassembles the fragments into the original packet.
Configuring IP parameters 19 3. If neither an IPv4 Interface MTU value or an IPv4 Global MTU value are configured, the default IPv4 MTU value of 1500 will be used. Globally changing the IP MTU To globally enable jumbo support on all IP interfaces, enter commands such as the following. Brocade(config)# ip global-mtu 5000 Brocade(config)# write memory Syntax: [no] ip global-mtu bytes The bytes parameter specifies the maximum IP packet size to be forwarded on a port.
19 Configuring IP parameters Changing the router ID In most configurations, a Brocade device has multiple IP addresses, usually configured on different interfaces. As a result, a Brocade device’s identity to other devices varies depending on the interface to which the other device is attached. Some routing protocols, including OSPF and BGP4, identify a Brocade device by just one of the IP addresses configured on the Brocade device, regardless of the interfaces that connect the Brocade devices.
Configuring IP parameters 19 Syntax: [no] ip router-id ip-addr NOTE The command for setting the router ID for a specified VRF is exactly the same as for the default VRF. The only difference is that when setting it for a specific VRF, the ip router-id command is configured within the VRF as shown in the example. NOTE You can specify an IP address used for an interface, but do not specify an IP address in use by another device.
19 Configuring IP parameters Syntax: [no]ipv6 nd global-suppress-ra Configuring IPv6 ND global router advertisement globally on the default VRF When configuring the ipv6 nd global-suppress-ra command, the ND Router Advertisement messages is not sent out on any interface in the default VRF, unless the ipv6 nd send-ra is set on the interface. By default, ipv6 nd global-suppress-ra is not set for the IPv6 VRF.
Configuring IP parameters 19 MTU is 1500 bytes ICMP redirects are disabled ND DAD is enabled, number of DAD attempts: 3 ND reachable time is 30 seconds ND advertised reachable time is 0 seconds ND retransmit interval is 1000 milliseconds ND advertised retransmit interval is 0 milliseconds ND router advertisements suppressed No Inbound Access List Set No Outbound Access List Set IPv6 RPF mode: None IPv6 RPF Log: Disabled OSPF enabled RxPkts: 0 TxPkts: 0 RxBytes: 0 TxBytes: 0 IPv6 unicast RPF drop: 0 IPv6 u
19 Configuring an interface as the source for Syslog packets Identifying a single source IP address for Telnet, SSH, NTP, TFTP, TACACS/TACACS+, or RADIUS packets provides the following benefits: • If your Telnet, SSH, NTP, TFTP, TACACS/TACACS+, or RADIUS server is configured to accept packets only from specific IP addresses, you can use this feature to simplify configuration of the server by configuring the device to always send the packets from the same link or source address.
Configuring ARP parameters 19 How ARP works The Brocade device needs to know a destination’s MAC address when forwarding traffic, because the Brocade device encapsulates the IP packet in a Layer 2 packet (MAC layer packet) and sends the Layer 2 packet to a MAC interface on a device directly attached to the Brocade device. The device can be the packet’s final destination or the next-hop router toward the destination.
19 Configuring ARP parameters NOTE If the device receives an ARP request packet that it is unable to deliver to the final destination because of the ARP timeout and no ARP response is received (the Brocade device knows of no route to the destination address), the device sends an ICMP Host Unreachable message to the source. Rate limiting ARP packets For rate-limiting purposes, ARP traffic destined for the CPU is assigned a separate global QoS ID 0xFFE.
Configuring ARP parameters 19 Changing the ARP aging period When the Brocade device places an entry in the ARP cache, the Brocade device also starts an aging timer for the entry. The aging timer ensures that the ARP cache does not retain learned entries that are no longer valid. An entry can become invalid when the device with the MAC address of the entry is no longer on the network. The ARP age affects dynamic (learned) entries only, not static entries. The default ARP age is ten minutes.
19 Configuring ARP parameters Enabling local proxy ARP Under some Layer-2 configurations such as uplink-switch or private VLAN, broadcast packets are not flooded to every port in a VLAN. In these configurations, an ARP request from one host may not reach another host. Enabling the Local Proxy ARP feature on a port directs the device to reply on behalf of a target host if it exists. The ARP reply returned contains the device’s mac address instead of the mac address of the target host.
Configuring ARP parameters 19 Creating static ARP entries The Brocade device has a static ARP table, in addition to the regular ARP cache. The static ARP table contains entries that you configure. Static entries are useful in cases where you want to pre-configure an entry for a device that is not connected to the Brocade device, or you want to prevent a particular entry from aging out. The software removes a dynamic entry from the ARP cache if the ARP aging interval expires before the entry is refreshed.
19 Dynamic ARP inspection The timer-value variable is a value between 10 to 3600 seconds. The default value is 60 seconds. Dynamic ARP inspection NOTE This feature is supported on Layer 2 and Layer 3 code. Dynamic ARP Inspection (DAI) enables the device to intercept and examine all ARP request and response packets in a subnet and discard those packets with invalid IP to MAC address bindings.
Dynamic ARP inspection 19 DAI inspects ARP packets received on untrusted ports, as shown in Figure 193. DAI carries out the inspection based on IP-to-MAC address bindings stored in a trusted binding database. For the Brocade device, the binding database is the ARP table, which supports DAI, DHCP snooping, and IP Source Guard. To inspect an ARP request packet, DAI checks the source IP and source MAC address against the ARP table.
19 Dynamic ARP inspection Feature Default Dynamic ARP Inspection Disabled Trust setting for ports Untrusted Enabling dynamic ARP inspection on a VLAN ARP and Dynamic inspection ARP entries need to be configured for hosts on untrusted ports. Otherwise, when Dynamic ARP Inspection checks ARP packets from these hosts against entries in the ARP table, it will not find any entries for them, and the device will not allow and learn ARP from an untrusted host. Dynamic ARP Inspection is disabled by default.
Dynamic ARP inspection 19 Brocade(config)# interface ethernet 1/4 Brocade(config-if-e10000-1/4)# arp-inspection-trust The commands change the CLI to the interface configuration level of port 1/4 and set the trust setting of port 1/4 to trusted. Syntax: [no] arp-inspection-trust Creating ARP entries Static entries are useful in cases where you want to pre-configure an entry for a device that is not connected to the Brocade device, or you want to prevent a particular entry from aging out.
19 Dynamic ARP inspection The ethernet slot/port command specifies the port number attached to the device that has the MAC address of the entry. (The ethernet keyword is repeated before each individual port or range of ports to be included in the multi-port ARP entry.) VRF Considerations The configuration command above creates a static ARP entry associated with the default VRF.
Dynamic ARP inspection 19 Supported applications • PBR PBR supports use of a multi-port static ARP entry as an IP next hop. • Trunk ports Primary trunk ports can be configured in multi-port static ARPs. If a secondary trunk port is included in a multi-port ARP entry, however, the trunk will not be deployed. • ARP inspection ARP inspection is performed for multi-port static ARPs the same as for normal static ARP entries.
19 Dynamic ARP inspection Adding an ARP entry for a VRF IP Addresses can be uniquely determined by VRF. The VLAN number is not needed because the VLAN information is obtained through the ARP protocol. To define an ARP inspection entry for a specific VRF, enter commands such as the following. Brocade(config)# vrf vpn1 Brocade(config-vrf-vpn1))#arp 10.53.4.2 1245.7654.2348 e 3/5 This command creates an ARP entry for vrf with IP address 10.53.4.2 and MAC address of 1245.7654.2348 on ethernet 3/5.
19 Dynamic ARP inspection 1/8 0 1/9 0 1/10 0 1/11 0 1/12 0 1/13 0 1/14 0 1/15 0 1/16 0 1/17 0 1/18 0 1/19 0 1/20 0 Module 3: Port Arp Packets Captured 3/1 0 3/2 0 3/3 0 3/4 690 0 0 0 0 0 0 0 0 0 0 0 0 0 Arp Packets Failed Inspection 0 0 0 153 Specifying a port number with the show ip arp-statistics command displays the statistics for that port only, along with details of the last five ARP packets that failed inspection, as shown in the following.
19 DHCP snooping TABLE 90 Show ip arp-inspection-statistics (Continued) This field... Displays... Target IP The destination IP address of the ARP rejected packet. Target MAC The destination MAC address of the ARP rejected packet. Source IP The source IP address of the ARP rejected packet. Source MAC The source MAC address of the ARP rejected packet. VLAN The VLAN number of the ARP rejected packet.
DHCP snooping 19 NOTE DHCP Snooping will not dynamically build the ARP Inspection table. How DHCP snooping works When enabled on a VLAN, DHCP snooping stands between untrusted ports (those connected to host ports) and trusted ports (those connected to DHCP servers).
19 DHCP snooping System reboot and the binding database To allow DAI and DHCP snooping to work smoothly across a system reboot, the binding database is saved to a file in the system flash memory after the user issues the “reload” command. DHCP learned entries are written to the system flash memory before the device reboots. The flash file is written and read only if DHCP snooping is enabled. Configuring DHCP snooping Follow the steps listed below to configuring DHCP snooping. 1.
DHCP option 82 insertion 19 • Vendor-Specific (suboption 9) —Contains the Internet Assigned Numbers Authority (IANA) enterprise number (4874) and the layer 2 circuit ID and the user packet class. Suboption 1 and suboption 2 are usually determined by the client network access device and depend on the network configuration. Suboption 9 can be used to associate specific data with the DHCP messages relayed between the DHCP relay and the DHCP server. The suboption 9 can include the client’s IEEE 802.
19 DHCP option 82 insertion The Brocade device inserts DHCP option 82 when relaying DHCP request packets to DHCP servers. When DHCP server reply packets are forwarded back to DHCP clients, and sub-option 2 matches the local port MAC address, then DHCP option 82 is deleted. The vlan/port information is used to forward the DHCP reply.
DHCP option 82 insertion 19 Displaying DHCP snooping status and ports To display the DHCP snooping status for a VLAN and the trusted and untrusted ports in the VLAN, enter the following command.
19 DHCP option 82 insertion Displaying DHCP snooping statistics counters NOTE The last five dropped packets are displayed through the CLI. Notifications and traps are not sent. To display the DHCP snooping statistics counters, enter the following command.
DHCP option 82 insertion 19 To display the DHCP snooping statistics counters for Ethernet ports, enter the following command. Brocade#show ip dhcp-snooping-statistic eth 1/20 DHCP packets captured: 9 DHCP packets dropped by snooping: 7 Last 5 packets dropped by snooping: Time DHCP type Source Mac/ Server IP/ Source IP Gateway IP 2008-05-03 00:29:43 OFFER 0030.4843.37ad 10.1.1.125 10.1.1.125 10.1.1.10 2008-05-03 00:29:59 OFFER 0030.4843.37ad 10.1.1.125 10.1.1.125 10.1.1.10 2008-05-03 00:31:18 OFFER 0030.
19 Zero Touch Provisioning DHCP snooping configuration example The following example configures VLAN 2 and VLAN 20, and changes the CLI to the global configuration level to enable DHCP snooping on the two VLANs. The commands are as follows.
Zero Touch Provisioning 19 FIGURE 198 Zero Touch Provisioning Zero Touch Provisioning consists of the following steps. 1. The IP address validation and lease negotiation enables the DHCP client to automatically obtain and configure an IP address. a. As the Brocade device comes online, it checks if the DHCP client is enabled on any of the data ports. b. If no data port is enabled, the device tries to obtain an address on the management port.
19 Zero Touch Provisioning Zero Touch Provisioning limitations The following limitations apply to the Zero Touch Provisioning feature. • By default, Zero Touch Provisioning is always enabled on a management port. • Zero Touch Provisioning fails on a management port which has a static address configured on it. • Zero Touch Provisioning does not support trunked ports or Link Aggregation Control Protocol (LACP) ports.
Zero Touch Provisioning 19 Supported messages for DHCP servers Zero Touch Provisioning supports the following DHCP messages: • • • • • • • DHCPACK DHCPDECLINE DHCPDISCOVER DHCPNAK DHCPOFFER DHCPRELEASE DHCPREQUEST NOTE Zero Touch Provisioning does not support the DHCPINFORM message. Configuring Zero Touch Provisioning Zero Touch Provisioning allows a Brocade device to dynamically update its running configuration.
19 Zero Touch Provisioning Syntax: ip dhcp-client vlan vlan number ve [ve number | tagged | untagged | slot / port | auto-update disabled] Enabling autoconfiguration on a default VLAN To enable autoconfiguration on a default VLAN, use the following command when auto-update is enabled on port 1/1.
IP source guard 19 Brocade#show ip interface Interface IP-Address OK? Method Status Protocol VRF Type Lease Time eth 1/1 10.1.1.1 YES NVRAM admin/down down default-vrf Static N/A mgmt 1 10.21.96.160 YES NVRAM up up default-vrf Dynamic 672651 Table 94 describes the fields from the output of show ip interface command. TABLE 94 Output display of show ip interface command Field Description Interface The type and the slot and port number of the interface. IP-Address The IP address of the interface.
19 IP source guard When IP Source Guard is first enabled, only DHCP packets are allowed and all other IP traffic is blocked. IP Source Guard uses IP or MAC bindings inside the ARP Inspection table to detect a valid IP address. When the system learns a valid IP address on the port, the client port then allows IP traffic to enter. If the source IP address of a packet does not match any of the IP addresses inside the ARP Inspection table, the packet is dropped.
IP source guard CAM 19 The vlan_number variable specifies the ID of a configured VLAN. If the strict option is enabled, then valid IP source address is bound to a particular source port. This configuration can be learned from a DHCP reply, or manually configured. NOTE The strict mode requires DHCP relay-information insertion to be turned on.
19 Configuring forwarding parameters Configuring IP source guard CAM partition IP Source Guard creates two CAM sub-partitions. The CAM sub-partitions include IP_SOURCE_GUARD_PERMIT and IP_SOURCE_GUARD_DENY. All CAM entries that are permitted, go to the IP_SOURCE_GUARD_PERMIT sub-partition. All CAM entries that are denied, go to the IP_SOURCE_GUARD_DENY sub-partition.
Configuring forwarding parameters 19 NOTE A less common type, the all-subnets broadcast, goes to all directly-attached subnets. Forwarding for this broadcast type also is supported, but most networks use IP multicasting instead of all-subnet broadcasting. Forwarding for all types of IP directed broadcasts is disabled by default. You can enable forwarding for all types if needed. You cannot enable forwarding for specific broadcast types.
19 Configuring the maximum ICMP error message rate Enabling support for zero-based IP subnet broadcasts By default, the Brocade device treats IP packets with all ones in the host portion of the address as IP broadcast packets. For example, the Brocade device treats IP packets with 10.157.22.255/24 as the destination IP address as IP broadcast packets and forwards the packets to all IP hosts within the 10.157.22.x subnet (except the host that sent the broadcast packet to the Brocade device).
Configuring the maximum ICMP error message rate 19 Since the ICMP error metering code implementation is similar between the Management Module and Interface Module code, this change will also affect the Management Module ICMP error rate. To configure the maximum ICMP error rate, enter the following command. Brocade(config)# ip icmp max-err-msg-rate 600 Syntax: [no] ip icmp max-err-msg-rate error per second The error per second variable specifies the maximum error rate in errors per second.
19 Configuring the maximum ICMP error message rate • Port – The destination host does not have the destination TCP or UDP port specified in the packet. In this case, the host sends the ICMP Port Unreachable message to the Brocade device, which in turn sends the message to the host that sent the packet. • Protocol – The TCP or UDP protocol on the destination host is not running.
Configuring static routes 19 Disabling ICMP redirect messages ICMP redirect messages can be disabled or re-enabled. By default, the Brocade device sends an ICMP redirect message to the source of a misdirected packet in addition to forwarding the packet to the appropriate router. You can disable ICMP redirect messages on a global basis or on an individual port basis.
19 Configuring static routes • Statically configured route – You can add routes directly to the route table. When you add a route to the IP route table, you are creating a static IP route. This section describes how to add static routes to the IP route table. Static route types You can configure the following types of static IP routes: • Standard – the static route consists of the destination network address and network mask, and the IP address of the next-hop gateway.
Configuring static routes 19 Multiple static routes to the same destination provide load sharing and redundancy You can add multiple static routes for the same destination network to provide one or more of the following benefits: • IP load balancing – When you add multiple IP static routes for the same destination to different next-hop gateways, and the routes each have the same metric and administrative distance, the Brocade device can load balance traffic to the routes’ destination.
19 Configuring static routes The software automatically removes a static IP route from the IP route table if the port used by that route becomes unavailable. When the port becomes available again, the software automatically re-adds the route to the IP route table. Configuring a static IP route To configure an IP static route with a destination address of 10.0.0.0 255.0.0.0 and a next-hop router IP address of 10.1.1.1, enter the following. Brocade(config)# ip route 10.0.0.0 255.0.0.0 195.1.1.
Configuring static routes 19 The metric parameter specifies the cost of the route and can be a number from 1 – 16. The default is 1. NOTE If you specify 16, RIP considers the metric to be infinite and thus also considers the route to be unreachable. The tag num parameter specifies the tag value of the route. Possible values: 0 - 4294967295. Default: 0. The distance num parameter specifies the administrative distance of the route.
19 Configuring static routes Syntax: [no] ip route dest-ip-addr dest-mask | dest-ip-addr/mask-bits next-hop-vrf next-hop-vrf-name next-hop-ip-addr The dest-ip-addr is the route’s destination. The dest-mask is the network mask for the route’s destination IP address. Alternatively, you can specify the network mask information by entering / followed by the number of bits in the network mask. For example, you can enter 10.0.0.0 255.255.255.0 as 192.0.0.0/.24.
Configuring static routes 19 Brocade(config-vrf-red)# rd 3:1 Brocade(config-vrf-red)# address-family ipv4 Brocade(config-vrf-red)# ip route 10.128.2.69/24 next-hop-vrf default-vrf 10.1.1.1 Syntax: [no] ip route dest-ip-addr dest-mask | dest-ip-addr/mask-bits next-hop-vrf next-hop-vrf-name next-hop-ip-addr The dest-ip-addr is the route’s destination. The dest-mask is the network mask for the route’s destination IP address.
19 Configuring static routes Brocade(config)# vrf a Brocade(config-vrf-A)# rd 1:1 Brocade(config-vrf-A)# address-family ipv4 Brocade(config-vrf-A)# ip route 10.0.0.0/24 ethernet 1/2 Syntax: [no] ip route dest-ip-addr/mask-bits [ ethernet slot/port | ve num ] The dest-ip-addr is the route’s destination. The dest-mask is the network mask for the route’s destination IP address.
Configuring static routes 19 NOTE The last three parameters are optional and do not affect the null route, unless you configure the administrative distance to be 255. In this case, the route is not used and the traffic might be forwarded instead of dropped. Dropping traffic sent to the null0 interface In hardware Traffic sent to the null0 interface is done in hardware; that is, by programming the CAM to discard traffic sent to the null0 interface.
19 Configuring static routes The steps for configuring the static routes are the same as described in the previous section. The following sections provide examples. To configure multiple static IP routes, enter commands such as the following. Brocade(config)# ip route 10.128.2.69 255.255.255.0 10.157.22.1 Brocade(config)# ip route 10.128.2.69 255.255.255.0 10.111.10.1 The commands in the example above configure two static IP routes. The routes go to different next-hop gateways but have the same metrics.
Configuring static routes 19 Figure 200 shows an example of two static routes configured for the same destination network. One of the routes is a standard static route and has a metric of 1. The other static route is a null route and has a higher metric than the standard static route. The Brocade device always prefers the static route with the lower metric. In this example, the Brocade device always uses the standard static route for traffic to destination network 192.168.7.
19 Configuring static routes FIGURE 201 Standard and interface routes to the same destination network To configure a standard static IP route and a null route to the same network as shown in Figure 200 on page 793, enter commands such as the following. Brocade(config)# ip route 192.168.7.0/24 192.168.6.157/24 1 Brocade(config)# ip route 192.168.7.0/24 null0 3 The first command configures a standard static route, which includes specification of the next-hop gateway.
Static route configuration 19 Static route configuration The following enhancements to static route configuration have been added: • • • • “Static route tagging” on page 795 “Static route next hop resolution” on page 795 “Static route recursive lookup” on page 796 “Static route resolve by default route” on page 796 Static route tagging Static routes can be configured with a tag value, which can be used to color routes and filter routes during a redistribution process.
19 Static route configuration • ospf • rip NOTE Connected routes are always used to resolve static routes. Static route recursive lookup This feature of the Multi-Service IronWare software enables the Brocade device to use static routes to resolve another static route. The recursive static route next hop lookup level can be configured. By default, this feature is disabled. To configure static route next hop recursive lookup by other static routes, use the following command.
Static route configuration 19 Static route to an LSP tunnel interface This feature allows you to set the next hop for a static route to the egress router of an LSP tunnel if the destination route is contained in the MPLS routing table. In this configuration, the static route is updated with the LSP routes and reverts to its original next hop outgoing interface when this feature is disabled or when the LSP goes down. This route can be used for the default route.
19 Naming a static IP route To verify that an LSP is up and that MPLS has a route to it, you can use the show mpls lsp and show mpls route commands as shown in the following examples. Brocade# show mpls lsp Note: LSPs marked with * are taking a Secondary Path Admin Oper Tunnel Up/Dn Retry Name To State State Intf Times No. t6 10.12.12.13 UP DOWN -0 292 t5 10.12.12.12 UP UP tnl3 1 0 t2 10.12.12.12 UP UP tnl1 1 0 t7 10.12.12.12 UP UP tnl5 1 0 brocadelongl 10.12.12.
Naming a static IP route 19 Brocade(config)# ip route 10.22.22.22 255.255.255.255 eth 1/1 name abc OR Brocade(config)# ip route 10.22.22.22 255.255.255.255 10.1.1.1 name abc Syntax: [no] ip route dest-ip-addr dest-mask | dest-ip-addr/mask-bits next-hop-ip-addr| ethernet slot/port | ve num [metric] [tag num] [distance num] [name string] Enter the static route name for name string. The maximum length of the name is 128 bytes.
19 Naming a static IP route Configuring a default network route The Brocade device enables you to specify a candidate default route without the need to specify the next hop gateway. If the IP route table does not contain an explicit default route (for example, 0.0.0.0/0) or propagate an explicit default route through routing protocols, the software can use the default network route as a default route instead.
BFD for Static Routes 19 Configuring a default network route NOTE The ip default-network command is not supported on the Brocade NetIron CES and Brocade NetIron CER devices. You can configure up to four default network routes. To configure a default network route, enter commands such as the following. Brocade(config)# ip default-network 10.157.22.0 Brocade(config)# write memory Syntax: [no] ip default-network ip-addr The ip-addr parameter specifies the network address.
19 BFD for Static Routes Configuration considerations • • • • • In a multi-hop session, the protocol must be stated in the command ip route next-hop protocol. BFD multi-hop is supported for a nexthop resolved through OSPF, BGP, ISIS, RIP, and MPLS. BFD multi-hop is not supported for a nexthop resolved through Default Route. BFD for static routes is not supported for static routes with an LSP name as nexthop.
BFD for Static Routes 19 Syntax to enable BFD monitoring for IPv6: Syntax: [no] ipv6 route Destination IPv6 address Next hop Router IPv6 address … bfd The no version of the command removes BFD monitoring from the static route. Multi-hop configuration The following example shows a multi-hop configuration using the commands explained in the single hop section. Brocade(config)#ip route static-bfd 30.0.0.5 10.0.0.1 interval 90 min-rx 90 multiplier 3 Brocade(config)#ip route 20.0.0.0/24 30.0.0.
19 Configuring IP load sharing The show bfd neighbors details output indicates that BFD monitoring is enabled by the static and static6. Brocade# show bfd neighbors details 20.0.0.3 NeighborAddress State Interface Holddown Interval R/H 20.0.0.
Configuring IP load sharing 19 How multiple equal-cost paths enter the IP route table IP load sharing applies to equal-cost paths in the IP route table. Routes eligible for load sharing can enter the table from the following sources: • IP static routes • Routes learned through RIP, OSPF, and BGP4 Administrative distance The administrative distance is a unique value associated with each type (source) of IP route. Each path has an administrative distance.
19 Configuring IP load sharing Path cost The cost parameter provides a basis of comparison for selecting among paths to a given destination. Each path in the IP route table has a cost. When the IP route table contains multiple paths to a destination, the Brocade device chooses the path with the lowest cost. When the IP route table contains more than one path with the lowest cost to a destination, the Brocade device uses IP load sharing to select one of the lowest-cost paths.
Configuring IP load sharing TABLE 95 Default load sharing parameters for route sources Route source Default maximum number of paths Maximum number of paths Static IP route 4 32 NOTE: This value depends on the value for IP load sharing, and is not separately configurable. NOTE: This value depends on the value for IP load sharing, and is not separately configurable. 4 8 NOTE: This value depends on the value for IP load sharing, and is not separately configurable.
19 Configuring IP load sharing Syntax: [no] load-balance force-l4-hashing [ all | slot-number | slot-number np-id ] The all option applies the command to all ports within the device. Specifying a slot number using the slot-number variable limits the command to an individual module. Specifying a slot number and a network processor ID using the slot-number and np-id variables limits the command to the ports supported by the specified network processor on the specified interface module.
Configuring IP load sharing 19 Masking layer-2 information With the load-balance mask ethernet command set, the following Layer-2 values can be masked during ECMP and LAG index hash calculations: source and destination MAC address, VLAN, Ethertype, and Inner VLAN. To mask Layer-2 information, use the load-balance mask ethernet command, as shown in the following.
19 Configuring IP load sharing To mask the MPLS labels, enter the following command. Brocade(config)# load-balance mask mpls label0 all Syntax: [no] load-balance mask mpls [label0 | label1 | label2 | label3] [all | slot-number | slot-number np-id] Use the label0 option to mask MPLS Label 0, which is the innermost MPLS label in a packet. Use the label1 option to mask MPLS Label 1, which is the next innermost MPLS label in a packet from MPLS Label 2.
Configuring IP load sharing 19 Mask MPLS Label2 is enabled on No Slots Mask MPLS Label3 is enabled on All Slots Table 96 describes the output parameters of the show load-balance mask mpls command. TABLE 96 Output parameters of the show load-balance mask mpls command Field Description Slot Shows the slot of the interface on which the MPLS masking is enabled. Mask MPLS Label Shows whether or not the following labels are masked. Label0 - Shows if the Label 0 is masked on the interface.
19 Configuring IP load sharing Specifying a slot number using the slot-number variable limits the command to an individual module. Specifying a slot number and a network processor ID using the slot-number and np-id variables limits the command to the ports supported by the specified network processor on the specified interface module. This option can also be used in a multi-stage network to avoid the same traffic flow to always use one path of an ECMP or the same LAG member index at each stage.
Configuring IP load sharing 19 NOTE The symmetric load balancing option is applicable only for Brocade MLX series and Brocade NetIron XMR devices. The Brocade NetIron CER and Brocade NetIron CES devices load balance all traffic on the LAGs symmetrically. Therefore, the Brocade NetIron CER and Brocade NetIron CES devices do not support the symmetric load balancing commands.
19 Configuring IP load sharing Specifying a slot number and a network processor ID using the slot-number and np-id variables limits the command to the ports supported by the specified network processor on the specified interface module. The no option is used to turn off the previously enabled symmetric load balancing option. Displaying symmetric load balancing information To display the symmetric load balancing information for the interface, enter the following command.
Configuring IP load sharing 19 Slot 2 Syntax: show load-balance symmetric-options ethernet | ip | ipv6 | l4_ip | l4_ipv6 | inner_ethernet | inner_ip | inner_ipv6 | packet Table 97 describes the output parameters of the show load-balance symmetric-options command. TABLE 97 Output parameters of the show load-balance symmetric-options command Field Description Slot Shows the slot number of the interface on which the symmetric load balancing option is enabled.
19 Configuring IP load sharing NOTE If the setting for the maximum number of paths is lower than the actual number of equal-cost paths, the software does not use all the paths for load sharing. To change the maximum number of load sharing paths, enter the following command: Brocade(config)# ip load-sharing 32 Syntax: [no] ip load-sharing number The number parameter specifies the number of ECMP load sharing paths. Enter a value between 2 and 32 for number to set the maximum number of paths.
Configuring IP load sharing 19 • Packet type – The Brocade device can send Router Advertisement messages as IP broadcasts or as IP multicasts addressed to IP multicast group 224.0.0.1. The packet type is IP broadcast. • Maximum message interval and minimum message interval – When IRDP is enabled, the Brocade device sends the Router Advertisement messages every 450 – 600 seconds by default.
19 Configuring IP load sharing • multicast – The Brocade device sends Router Advertisement as multicast packets addressed to IP multicast group 224.0.0.1. The holdtime seconds parameter specifies how long a host that receives a Router Advertisement from the Brocade device should consider the advertisement to be valid. When a host receives a new Router Advertisement message from the Brocade device, the host resets the hold time for the Brocade device to the hold time specified in the new advertisement.
Configuring IP load sharing 19 • tacacs (port 65) NOTE The application names are the names for these applications that the Brocade device recognizes, and might not match the names for these applications on some third-party devices. The numbers listed in parentheses are the UDP port numbers for the applications. The numbers come from RFC 1340. NOTE As shown above, forwarding support for BootP or DHCP is enabled by default.
19 Configuring IP load sharing • • • • • • netbios-ns (port 137) ntp (port 123) tacacs (port 65) talk (port 517) time (port 37) tftp (port 69) In addition, you can specify any UDP application by using the application’s UDP port number. The udp-port-num parameter specifies the UDP application port number. If the application you want to enable is not listed above, enter the application port number. You also can list the port number for any of the applications listed above.
Configuring IP load sharing 19 You can configure the Brocade device to forward BootP or DHCP requests. To do so, configure a helper address on the interface that receives the client requests, and specify the BootP or DHCP server’s IP address as the address you are helping the BootP or DHCP requests to reach. Instead of the server’s IP address, you can specify the subnet directed broadcast address of the IP subnet the server is in.
19 Filtering Martian addresses To change the IP address used for stamping BootP or DHCP requests received on interface 1/1, enter commands such as the following. Brocade(config)# int e 1/1 Brocade(config-if-e1000-1/1)# ip bootp-gateway 10.157.22.26 These commands change the CLI to the configuration level for port 1/1, then change the BootP or DHCP stamp address for requests received on port 1/1 to 10.157.22.26.
Filtering Martian addresses 19 If no match is found, the route is accepted. This will be the case for almost all routes. If a match is found, the route is discarded (default action - deny), unless the action is set to permit. Martian address filtering is in addition to normal BGP in-bound route policies. To enable Martian address filtering, enter the following command.
19 IPv6 Over IPv4 tunnels in hardware Examples To remove a user defined Martian address or a system default Martian address, use the “no” form of the command. Brocade(config)# no ip martian 0.0.0.0/8 The following example configuration, creates a “hole” for 192.168.1.0/24 in the martian address 192.168.0.0/16. Brocade(config)# ip martian 192.168.1.0/24 permit Brocade(config)# ip martian 192.168.0.
IPv6 Over IPv4 tunnels in hardware • • • • • • • • 19 Tunnel Interface Source Address or Source Interface for the Tunnel Destination address for the Tunnel IPv6 Encapsulation IP address for the Tunnel TTL Value (optional) TOS Value (optional) MTU Value (optional) NOTE Do not forward packets from one type of tunnel to another type of tunnel in XPP. Packets may not be routed properly. Configuring a manual IPv6 tunnel You can use a manually configured tunnel to connect two isolated IPv6 domains.
19 IPv6 Over IPv4 tunnels in hardware Configuring an automatic 6to4 tunnel An automatic 6to4 tunnel establishes a transient link between IPv6 domains, which are connected by an IPv4 backbone. When needed, a device on which an automatic 6to4 tunnel is configured in one domain can establish a tunnel with another similarly configured device in another domain. When no longer needed, the devices take down the tunnel.
IPv6 Over IPv4 tunnels in hardware 19 • Static routes can be used with 6to4 tunnels. If you use a static route to configure the nexthop, you MUST enable nexthop recursion in the system (ipv6 route next-hop-recursion). • The 6to4 tunnel tries to resolve all the nexthops and programs the cam and pram entries needed. The IPv4 address in the nexthop should be reachable through the IPv4 network. Example In the below configuration: • • • • 10.10.10.1 is the tunnel source IP address 10.10.10.
19 IPv6 Over IPv4 tunnels in hardware Brocade(config-bgp)# Brocade(config-bgp)# Brocade(config-bgp)# Brocade(config-bgp)# exit-address-family address-family ipv6 unicast neighbor 2002:1616:1606::1 activate exit-address-family Configuring the maximum number of tunnels supported You can configure the device to support a specified number of tunnels using the following command.
IPv6 Over IPv4 tunnels in hardware 19 Configuring a destination address for a tunnel interface To configure a destination address for a specific tunnel interface, enter the following command. Brocade(config)# interface tunnel 1 Brocade(config-tnif-1)tunnel destination 10.108.5.2 Syntax: [no] tunnel destination ip-address The ip-address variable is destination IP address being configured for the specified tunnel.
19 IPv6 Over IPv4 tunnels in hardware The tos-value variable specifies a TOS value for the outer IP header. Possible values are 1 - 255. The default value is 0. Configuring IPv6 session enforce check You can enable the IPv6 session enforce check by using the ipv6-session-enforce-check command. When an IPv6 packet arrives and this feature is enabled, the system tries to match the IPv6 packet source and destination address pair with the tunnel configured destination and source pair.
IPv6 Over IPv4 tunnels in hardware 19 Displaying IPv6 tunneling information You can display IPv6 Tunneling Information using the show ip-tunnels, show ipv6 interface, show ipv6 route and show interface tunnel commands as shown in the following: Displaying tunnel information For example, to tunnel information for tunnel 2, enter the following command at any level of the CLI. Brocade# show ip-tunnels 2 IPv6 tnnl 2 UP : src_ip 10.211.2.1, dst_ip 10.212.2.
19 IPv6 Over IPv4 tunnels in hardware TABLE 99 IPv6 tunnel interface information This field... Tunnel interface status Line protocol status Hardware is tunnel Tunnel source Displays... The status of the tunnel interface can be one of the following: up – The tunnel interface is functioning properly. down – The tunnel interface is not functioning and is down. • • The status of the line protocol can be one of the following: up – The line protocol is functioning properly.
Displaying IP information ipv6 ipv6 ipv6 ipv6 19 address fe80::3:4:2 link-local address 1011::1/64 address 1001::1/64 ospf area 0 Displaying IP information You can display the following IP configuration information statistics: • • • • • • • Global IP parameter settings – refer to “Displaying global IP configuration information”. IP interfaces – refer to “Displaying IP interface information”. ARP entries – refer to “Displaying ARP entries”. Static ARP entries – refer to “Displaying ARP entries”.
19 Displaying IP information TABLE 100 This field... CLI display of global IP configuration information Displays... Global settings ttl The Time-To-Live (TTL) for IP packets. The TTL specifies the maximum number of router hops a packet can travel before reaching the Brocade device. If the packet’s TTL value is higher than the value specified in this field, the device drops the packet. To change the maximum TTL, refer to “Changing the TTL threshold”. arp-age The ARP aging period.
Displaying IP information TABLE 101 19 CLI display of interface IP configuration information (Continued) This field... Displays... Status The link status of the interface. If you have disabled the interface with the disable command, the entry in the Status field will be “administratively down”. Otherwise, the entry in the Status field will be either “up” or “down”. Protocol Whether the interface can provide two-way communication.
19 Displaying IP information Displaying interface counters for all ports The Brocade device supports IPv4 and IPv6 packet and byte counters. The contents of these counters can be displayed for all ports on a device or per-port. Output from the show ip interface ethernet command has been enhanced to include packet and byte counter information on a per-port basis. This is described in “Displaying interface counters for all ports”.
Displaying IP information 19 The port-number variable specifies the slot and port number that you want to clear the interface counters for. Displaying interface name in Syslog By default an interface’s slot number (if applicable) and port number are displayed when you display Syslog messages. You can display the name of the interface instead of its number by entering a command such as the following.
19 Displaying IP information The mac-address xxxx.xxxx.xxxx parameter lets you restrict the display to entries for a specific MAC address. The mask parameter lets you specify a mask for the mac-address xxxx.xxxx.xxxx parameter to display entries for multiple MAC addresses. Specify the MAC address mask as fs and 0s, where fs are significant bits. The ip-addr and ip-mask parameters let you restrict the display to entries for a specific IP address and network mask.
Displaying IP information 19 Displaying the static ARP table To display the static ARP table, enter the following command at any CLI level. Brocade# show ip static-arp Total no. Index 1 2 3 4 of entries: 4 IP Address MAC Address Port 10.1.1.1 0001.0001.0001 1/1 10.6.6.2 0002.0002.0002 1/2 10.6.6.7 1111.1111.1111 2/1... Ports : ethe 2/1 to 2/7 ethe 3/1 to 3/2 10.7.7.7 0100.5e42.7f40 3/3 VLAN ESI This example shows four static entries, one of which is multi-port.
19 Displaying IP information The show ip cache command shows the forwarding cache usage on each interface module CPU. The CPU on each interface module builds its own forwarding cache, depending on the traffic. To see the forwarding cache of a particular interface module, use the rconsole. Brocade>rconsole 15 Connecting to slave CPU 15/1...
Displaying IP information TABLE 106 19 CLI display of IP forwarding cache (Continued) This field... Displays... Port The port through which this device reaches the destination. For destinations that are located on this device, the port number is shown as “n/a”. VLAN Indicates the VLANs the listed port is in. Pri The QoS priority of the port or VLAN.
19 Displaying IP information The longer | detail | debug parameter applies only when you specify an IP address and mask. This option displays only the routes for the specified IP address and mask. The bgp option displays the BGP4 routes. The connected option displays only the IP routes that are directly attached to the Brocade device. The ospf option displays the OSPF routes. The rip option displays the RIP routes. The isis option displays the RIP routes.
Displaying IP information 19 • exclude lets you exclude matching lines from the display. • include lets you include matching lines in the display. The default routes are displayed first. Using the connected option Here is an example of how to use the connected option. To display only the IP routes that go to devices directly attached to the Brocade device.
19 Displaying IP information Brocade# show ip route summary IP Routing Table - 35 entries: 6 connected, 28 static, 0 RIP, 1 OSPF, 0 BGP, 0 ISIS, 0 MPLS Number of prefixes: /0: 1 /16: 27 /22: 1 /24: 5 /32: 1 Syntax: show ip route summary In this example, the IP route table contains 35 entries. Of these entries, 6 are directly connected devices, 28 are static routes, and 1 route was calculated through OSPF.
Displaying IP information 19 Displaying IP routes with nexthop ID By using the nexthop option with the ref-routes keyword, you can display IP routes in the forwarding table that refer to the specified nexthop entry, as the following example illustrates (using nexthop ID 65575).
19 Displaying IP information TABLE 107 CLI display of IP route table (Continued) This field... Displays... Type The route type, which can be one of the following: • B – The route was learned from BGP. • D – The destination is directly connected to this Brocade device. • R – The route was learned from RIP. • S – The route is a static route. • * – The route is a candidate default route. • O – The route is an OSPF route.
Displaying IP information 19 ARP Statistics 489279 total recv, 488154 req recv, 1125 rep recv, 1159 req sent, 3960 rep sent 0 pending drop, 0 invalid source, 0 invalid dest ICMP Statistics Received: 0 total, 0 errors, 0 unreachable, 0 time exceed 0 parameter, 0 source quench, 0 redirect, 0 echo, 0 echo reply 0 timestamp, 0 timestamp reply, 0 address mask, 0 address mask reply 0 irdp advertisement, 0 irdp solicitation Sent: 2146 total, 0 errors, 2146 unreachable, 0 time exceed (0 mpls-response) 0 parameter
19 Displaying IP information TABLE 108 CLI display of IP traffic statistics (Continued) This field... Displays... unknown proto The number of packets dropped by the device because the value in the Protocol field of the packet header is unrecognized by this device. no buffer This information is used by Brocade customer support. other errors The number of packets that this device dropped due to error types other than the types listed above.
Displaying IP information TABLE 108 19 CLI display of IP traffic statistics (Continued) This field... Displays... passive resets The number of TCP connections this device reset because the device at the other end of the connection sent a TCP RESET message. input errors This information is used by Brocade customer support. in segments The number of TCP segments received by the device. out segments The number of TCP segments sent by the device.
19 Displaying IP information TABLE 109 Show IP tunnel display information This field... Displays... IPv6 tnnl x UP | DOWN The status of the interface for manual IPv6 tunnel interface x can be one of the following: • UP – The tunnel interface is functioning properly. • DOWN – The tunnel interface is not functioning and is down. GRE tnnl x UP or DOWN The status of the interface for GRE tunnel interface x can be one of the following: • UP – The tunnel interface is functioning properly.
Displaying IP information TABLE 110 19 Show IP tunnel display information This field... Displays... Tunnel ID For each tunnel displayed, the Tunnel ID indicates the tunnel for which the statistics are displayed. Tunnel Type The tunnel type is either GRE or manual IPv6. Packets Rcv-from-tnnl The number of packets that have arrived from the tunnel. Packets Xmit-to-tnnl The number of packets that have been sent to the tunnel.
19 Displaying IP information To see the interface statistics for a particular tunnel (GRE tunnel 1 in this case), use the show interface tunnel command, as the following illustrates. Brocade#show interface tunnel 1 Tunnel 1 is up, line protocol is up Hardware is Tunnel Tunnel source 10.30.30.1 Tunnel destination is 10.20.20.1 Tunnel mode gre ip No port name Internet address is: 10.50.50.
Displaying IP information TABLE 112 19 Show IP tunnel display information (Continued) This field... Displays... Unicast Packets On a per port basis, this column shows the number of unicast packets that have arrived from the tunnel and the number of packets that have been transmitted to the tunnel. This count includes packets for both GRE tunnels and packets for manually configured IPv6 tunnels.
19 854 Displaying IP information Multi-Service IronWare Switching Configuration Guide 53-1003036-02
Chapter 20 Multiple VLAN Registration Protocol (MVRP) Table 113 displays the individual Brocade devices and the MVRP features they support.
20 Multiple VLAN Registration Protocol Syntax: [no] mvrp timer join value leave value leave-all value The timer values are set in milliseconds (ms). The default values for the timers are: • Join timer - 200ms • Leave timer - 1000ms (Recommended value: 5000ms) • Leave-all timer - 10000ms The Leave timer must be greater than or equal to twice the join timer plus 600ms. The recommended value for the Leave-all timer is at least three times the value of leave timer.
Multiple VLAN Registration Protocol 20 MVRP interface level timers Use the mvrp timer join value leave value leave-all value command to configure the join, leave and leave-all timers at interface level for MVRP. Brocade(config-if-e1000-1/1)# mvrp timer join 400 leave 1400 leave-all 10000 Syntax: [no] mvrp timer join value leave value leave-all value The timer values are set in milliseconds (ms).
20 Multiple VLAN Registration Protocol Show commands show mvrp Brocade# show mvrp ----------------------------------------------------------------------------Total configured mvrp ports: 2 Global Status: Enabled Join-timer(in ms): 200 Leave-timer(in ms): 1000 Leaveall-timer(in ms): 10000 --------------------------------------------------------------------------------MVRP Port(s): ethe 1/1 to 1/5, ethe 1/7, ethe 1/9 to 1/11 Syntax: show mvrp show mvrp [ethernet slot/port] Brocade# show mvrp ethernet 1/1 -
Multiple VLAN Registration Protocol 20 show mvrp [attributes [ethernet slot/port | vlan vlan-id]] Brocade# show mvrp attributes ethernet 1/1 Port : 1/1 State : Blocking ----------------------------------------------------------------------------VLAN Registrar Registrar Applicant State Mgmt State ----------------------------------------------------------------------------11 IN FIXED Very Anxious Observer 12 IN FIXED Very Anxious Observer Syntax: show mvrp [attributes [ethernet slot/port] show mvrp [attrib
20 Multiple VLAN Registration Protocol show mvrp [statistics [ethernet slot/port]] Brocade# show mvrp statistics ethe 1/1 Port : ethe 1/1 ---------------------------------------------------------Message type Received Transmitted ---------------------------------------------------------New 0 0 In 0 0 Join In 0 0 Join Empty 0 0 Empty 0 0 Leave 0 0 Leave-all 0 0 ---------------------------------------------------------Total PDUs 0 0 ---------------------------------------------------------- Syntax: show mvr
Multiple VLAN Registration Protocol Topo HW idx : 0 Topo SW idx: 257 L2 protocols : NONE Dynamically Tagged Ports Statically Tagged Ports : ethe 1/12 20 Topo next vlan: 0 Syntax: show vlan Error messages Deletion of dynamically learned VLAN Assume VLAN 10 is dynamically learned over port 1/1. Now when VLAN 10 is manually removed, the following error message is displayed. Error - Dynamic VLAN 10 cannot be deleted manually.
20 Multiple VLAN Registration Protocol Enabling MVRP when VLAN group is configured When MVRP is enabled while VLAN group is configured, the following error message is displayed. Error - Please remove all VLAN group configurations before running MVRP Enabling MVRP over VPLS end point port When MVRP is configured over a port which is also a VPLS end point, the following error message is displayed.
Multiple VLAN Registration Protocol 20 Changing port type to non-default when MVRP is configured over the same port When a port type of MVRP enabled port is changed to non-default, the following error message is displayed. Error: Cannot change port type to non-default when MVRP is enabled on the same port. Adding port to VPLS vlan when MVRP is configured over the same port When an MVRP enabled port is added to a VPLS VLAN, the following error message is displayed.
20 Multiple VLAN Registration Protocol Clear commands The following set of commands are available with the MVRP feature. Use the clear mvrp statistics command to clear MVRP port statistics for all ports. Brocade# clear mvrp statistics Syntax: clear mvrp statistics Use the clear mvrp statistics eth slot/port command to clear MVRP port statistics for the specific port.
Chapter 21 Multiple MAC Registration Protocol (MMRP) Table 114 displays the individual Brocade devices and the Multiple MAC Registration Protocol (MMRP) features they support.
21 MMRP networks Propagation of Group Membership MMRP uses the Registration Entries in the Filtering Database to ensure that the frames are transmitted to those ports on which group members are attached, thereby avoiding flooding of these frames on all the ports. Any node required to receive frames for this group has to declare the attribute.
MMRP networks 21 MMRP PDU Forwarding • If MMRP is not enabled globally on the system, then the MMRP PDUs will be flooded in the hardware. • If MMRP is enabled globally, then MMRP PDUs are captured to CPU for further processing. • In the LP, if MMRP is enabled on the source port of the PDU, then it is forwarded to MP for further processing. • If MMRP is not enabled on the source port of the PDU, then it is flooded to other ports from the LP.
21 MMRP networks Brocade_AS1(config-if-e10000-1/1)#port-type backbone-network Brocade_AS1(config-if-e10000-1/1)#exit Brocade_AS1(config)#esi iptv-service encapsulation isid Brocade_AS1(config-esi-iptv-service)#isid 10000 Brocade_AS1(config-esi-iptv-service-isid-10000)#exit Brocade_AS1(config)#esi iptv-carrier encapsulation bvlan Brocade_AS1(config-esi-iptv-carrier)#vlan 10 Brocade_AS1(config-esi-iptv-carrier-vlan-10)#tagged ethernet 1/1 Brocade_AS1(config-esi-iptv-carrier-vlan-10)#esi-client iptv-service
Configuring MMRP 21 This dissemination will result in the registration of this MAC on AS2, AS3, and AS4 and reachability tree is formed. Similarly AS2, AS3 also declare for the flood MAC. AS4 will not declare because the I-SID is not terminated on AS4. CS1 now has ports connecting to AS1, AS2, and AS3 registered to the flood MAC for B-VLAN10. The Figure 207 shows the reachability tree for the B-VLAN10.
21 Configuring MMRP • The registration services offered by MAD to allow Group membership, Group service requirement, and individual MAC address information to control the frame filtering behavior of participating devices. Figure 208 illustrates the architecture of MMRP in the case of a two-Port Bridge and an end station, for a given VLAN Context. Where MMRP is used in multiple VLAN Contexts, an instance of the MMRP Participant exists for each VLAN context.
Per Interface configuration 21 On Brocade NetIron CER and Brocade NetIron CES devices, the VLAN should be in the B-VLAN ESI. On Brocade MLX series and Brocade NetIron XMR devices, the B-VLAN must be a layer 2 (L2) VLAN. Global Timer Configuration Use the mmrp timer join value leave value leave-all value command to configure the join, leave, and leave-all timers at global level for MMRP.
21 Per Interface configuration MMRP interface level timers Use the mmrp timer join value leave value leave-all value command to configure the join, leave, and leave-all timers at global level for MMRP. Brocade(config)# mmrp timer join 400 leave 1400 leave-all 10000 Syntax: [no] mmrp timer join value leave value leave-all value The mmrp timer command sets the timer value in milliseconds (ms). The default value for the Join timer is 200 ms. The allowable range for the Join timer is 200 to 100000000ms.
Show commands Brocade(config-mif-1/1,1/3,1/5)# Brocade(config-mif-1/1,1/3,1/5)# Brocade(config-mif-1/1,1/3,1/5)# Brocade(config-mif-1/1,1/3,1/5)# mmrp mmrp mmrp mmrp 21 include-vlan 300 include-vlan 1000, 1100 timer join 400 leave 1400 leave-all 10000 point-to-point Syntax: [no] mmrp point-to-point By default, point-to-point is disabled. Show commands The following show commands are available for MMRP.
21 Show commands -----------------------------------------------------------------Port Vlan Mac-count ------------------------1/1 100 3 Syntax: show mmrp [ethernet slot/port [vlan vlan id]] show mmrp [attributes] Brocade(DUT1)#show mmrp attributes Port Vlan Mac-address Registrar Registrar Applicant State Mgmt State ------------------------------------------------------------------1/1 100 011e.8300.3001 IN Fixed Quiet Active 1/5 100 011e.8300.3001 LV Normal Quiet Active 1/5 100 011e.8300.
Syslog messages 21 Empty 0 156 Leave 0 0 Leave All 40 41 ---------------------------------------------------------Total PDUs 2 826 ---------------------------------------------------------- Syntax: show mmrp [statistics] show mmrp [statistics [vlan vlan id]] Brocade(DUT1)#show mmrp statistics vlan 100 Vlan 100 - Ports 1/1 to 1/6 ----------------------------------------------------------Message type Received Transmitted ----------------------------------------------------------In 0 0 Join In 0 0 Join Emp
21 CLI Error Messages 1. When MMRP is disabled globally. <14>Sep 13 15:36:48 3-1-A MMRP is disabled globally. 2. When a new MAC is registered. <14>Sep 13 15:36:48 3-1-A MMRP Mac 011e.8300.2710 registered on port 1/1 vlan 100 3. When an MMRP MAC is removed. <14>Sep 13 15:36:48 3-1-A MMRP Mac 011e.8300.2710 is removed from port 1/1 vlan 100 CLI Error Messages The following Error messages are introduced for this feature 1. Timer configuration.
Chapter 22 Reverse Path Forwarding Table 115 displays the individual Brocade devices and the Reverse Path Forwarding features they support.
22 RPF configuration RPF configuration Before you begin to configure Reverse Path Forwarding (RPF), review the following sections: • “Configuration considerations for RPF” • “Special considerations for configuring RPF on Brocade NetIron CES and Brocade NetIron CER devices” • • • • • • • “Special considerations for configuring RPF with ECMP routes” “RPF support for IP over MPLS routes” “RPF-compatible CAM profiles” “Configuring the global RPF command” “Enabling RPF on individual ports” “Configuring a ti
RPF configuration 22 • You cannot configure RPF on a physical port that belongs to a virtual LAN (VLAN). • If a combination of RPF, PBR, and ACL are configured on an interface, RPF takes precedence. • The section “Special considerations for configuring RPF with ECMP routes” does not apply to the Brocade NetIron CES and Brocade NetIron CER devices. Special considerations for configuring RPF with ECMP routes NOTE This section applies only to the Brocade NetIron XMR and Brocade MLX series devices.
22 RPF configuration TABLE 116 Software release RPF compatible and non-compatible CAM profiles (Continued) Compatible CAM profiles Non-compatible CAM profiles ipv6 l2-metro-2 mpls-l3vpn mpls-vpls mpls-l3vpn-2 mpls-vpls-2 ipv4-ipv6-2 mpls-vpn-vpls multi-service-2 multi-service multi-service-4 XMR or MLX 03.0.00 and 03.1.
RPF configuration 22 For IPv4 configurations, use the following command. Brocade(config)# reverse-path-check Syntax: reverse-path-check Brocade(config)# ipv6 reverse-path-check Enabling RPF on individual ports After RPF has been configured globally for a device, it must be configured on every interface that you want it to operate. The RPF feature can be configured on physical Ethernet interfaces.
22 RPF configuration Configuring a timer interval for IPv6 session logging You can use the ipv6 session-logging-age command to globally configure a timer interval for IPv6 session logging. The timer interval is set for 3 minutes in the following example. Brocade(config)# ipv6 session-logging-age 3 Syntax: [no] ipv6 session-logging-age minutes The minutes variable sets the timer interval for logging. Configurable values are from 1 through 10 minutes. The default value is 5 minutes.
RPF configuration 22 Syntax: suppress-rpf-drop In the following example, the IPv4 ACL 135 is applied as an inbound filter on Ethernet interface 7/5. Brocade(config)# interface ethernet 7/5 Brocade(config-if-e1000-7/5)# rpf-mode strict Brocade(config-if-e1000-3/1)# ip access-group 135 in NOTE If the physical port is a member of a virtual interface, the ACL will have to be applied to the virtual interface instead of the physical port.
22 RPF configuration Brocade#show ipv6 interface ethernet 3/1 Interface Ethernet 3/1 is down, line protocol is down IPv6 is enabled, link-local address is Global unicast address(es): Joined group address(es): ff02::2 ff02::1 MTU is 1500 bytes ICMP redirects are disabled ND DAD is enabled, number of DAD attempts: 3 ND reachable time is 30 seconds ND advertised reachable time is 0 seconds ND retransmit interval is 1 seconds ND advertised retransmit interval is 0 seconds ND router advertisements are sent eve
Displaying RPF logging 22 Syntax: clear ip interface ethernet slot/port Use the ethernet parameter to specify the Ethernet or port. The slot/port variables specify the interface for which you want to clear RPF statistics. Clearing RPF statistics for all IPv4 interfaces within a router To clear RPF statistics on all IPv4 physical interfaces within a router, use the clear ip interface counters command.
22 886 Displaying RPF logging Multi-Service IronWare Switching Configuration Guide 53-1003036-02
Chapter 23 sFlow Table 118 displays the individual Brocade devices and the sFlow features they support.
23 sFlow event workflow • • • • Non-default VRF IPv4 sampled packets Non-default VRF IPv6 sampled packets Default VRF IPv4 sampled packets Default VRF IPv6 sampled packets RFC 3176, “InMon Corporation's sFlow: A Method for Monitoring Traffic in Switched and Routed Networks” describes sFlow. Refer to this RFC to determine the contents of the sampled packet. Brocade supports sFlow v5, which replaces the version outlined in RFC 3176.
sFlow event workflow 23 • If no more IP addresses are found on that interface, then the agent IP address will use the router ID as the default behavior. sFlow agent IPv6 will be unspecified. Otherwise there is no action. Configuration considerations • Sample data is collected from inbound traffic on ports enabled for sFlow, but it does not collect the outbound traffic, even if the sFlow forwarding is enabled in the egress port.
23 sFlow event workflow Sampling rate The sampling rate is the average ratio of the number of packets incoming on an sFlow-enabled port, to the number of flow samples taken from those packets. Device ports send only the sampled traffic to the CPU. sFlow sampling requires high LP CPU usage, which can affect performance in some configurations, especially if a high sampling rate is implemented. Configured rate and actual rate When you enter a sampling rate value, this value is the configured rate.
sFlow event workflow 23 Configuring steps 4. Enable sFlow. 5. Enable null0 sampling. 6. Configure null0 routes. NOTE Above commands can be performed in any order. Feature characteristics • IPv4, IPv4-VPN, IPv6 null0 routes can be sFlow sampled. • Only explicitly configured null0 routes can be sFlow sampled. Implicit null0 drops cannot be sFlow sampled. • By default, null0 sFlow sampling feature is disabled.
23 sFlow event workflow Displaying sFlow show command This command will display the configuration for sFlow. Brocade(config)#show sflow sFlow services are enabled. sFlow management VRF is enabled. sFlow management VRF name is default-vrf. sFlow agent IP address: 55.55.55.56 sFlow agent IPV6 address: unspecified sFlow source IP address: unspecified, UDP 8888 sFlow source IPv6 address: unspecified, UDP 8888 Collector IP 77.7.7.2, UDP 6343 Polling interval is 20 seconds.
sFlow support for MPLS 23 sFlow support for MPLS In addition to the Layer 2 or Layer 3 information typically exported across devices, when sFlow sampling is configured on VPN endpoint interfaces, you can export MPLS or VPN information, such as VLL, VPLS, and VRF customer endpoint interfaces details. This functionality allows service providers to collect sFlow information from VPN customers.
23 Configuring and enabling sFlow Brocade(config)# sflow destination 10.10.10.1 This command specifies a collector with IP address 10.10.10.1, listening for sFlow data on UDP port 6343. Syntax: [no] sflow destination ip-addr [dest-udp-port] The ip-addr variable specifies the collector’s IP address. The dest-udp-port variable specifies the UDP port on which the sFlow collector will be listening for exported sFlow data. The default port number is 6343.
Configuring and enabling sFlow 23 NOTE It is recommended that you do not change the denominator to a value lower than the default. Sampling requires CPU resources. Using a low denominator for the sampling rate can cause high CPU utilization. Changing the global rate If you change the global sampling rate, the change is applied to all sFlow-enabled ports except those ports on which you have already explicitly set a sampling rate.
23 Configuring and enabling sFlow To change the sampling rate on an individual port, enter a command such as the following at the configuration level for the port. Brocade(config-if-e10000-1/1)# sflow sample 8192 Syntax: [no] sflow sample num The num variable specifies the average number of packets from which each sample will be taken. The software rounds the value you enter up to the next odd power of 2. The actual sampling rate becomes one of the values listed in “Changing the default sampling rate”.
Configuring and enabling sFlow 23 Configuring the sFlow management VRF The sflow management-vrf-disable command is used to disable the management VRF for sFlow and using the default VRF instance. By default, the management VRF is enabled on sFlow. Brocade(config)#sflow management-vrf-disable Syntax: [no] sflow [management-vrf-disable] The no sflow management-vrf-disable command disables the use of management VRF on sFlow and enables the default VRF instance.
23 ACL-based Inbound sFlow NOTE Data for POS ports is sampled using Ethernet format. The PPP or HDLC header of the sampled POS packet is replaced with an Ethernet header. PPP or HDLC control packets or IS-IS packets transmitted or received at a POS port are not sampled. Such packets are not included in the number of packets from which each sample is taken. NOTE sFlow packets cannot be forwarded from a management interface.
ACL-based Inbound sFlow 23 Configuring ACL-based Inbound sFlow The following sections describe how to configure ACL-based Inbound sFlow: • “Configuration considerations for ACL-based Inbound sFlow” • “Creating an ACL with an sFlow clause” • “Displaying sFlow information” Configuration considerations for ACL-based Inbound sFlow The following section describes configuration considerations for ACL-based Inbound sFlow: • sFlow must be enabled on the router.
23 ACL-based Inbound sFlow • IPv4 ACL-based Rate Limiting: When the copy-sflow keyword is used in an IPv4 Rate Limiting ACL, only traffic permitted by the Rate Limiting engine is copied to the CPU for forwarding to the sFlow collector. • IPv4 ACLs on VRF endpoints: You can apply ACL-based sFlow for VRF endpoints; however, such packets are treated as regular sampled sFlow packets and do not carry proprietary encapsulation. This can create a minor skew of statistics projection.
ACL-based Inbound sFlow 23 Displaying sFlow information To display sFlow configuration information and statistics, enter the following command at any level of the CLI. Brocade(config)# show sflow sFlow services are enabled. sFlow management VRF is enabled. sFlow management VRF name is blue. sFlow agent IP address: 10.25.120.1 sFlow agent IPV6 address: unspecified sFlow source IP address: unspecified, UDP 9999 sFlow source IPv6 address: 22::32, UDP 5544 2 collector destinations configured: Collector IP 10.
23 ACL-based Inbound sFlow Table 119 shows the output information provided by the show sflow command. TABLE 119 sFlow information Field sFlow services Description The feature state, which can be one of the following: disabled enabled • • sFlow management VRF Indication that sFlow is enabled to use the management VRF. Disabled means that sFlow is using the non-management VRF instance. sFlow management VRF name Management VRF name, if the management VRF is enabled on sFlow.
ACL-based Inbound sFlow 23 Displaying ACL-based sFlow statistics Use the show sflow command to display the number of sFlow samples collected for ACL-based sFlow. These statistics are shown in bold in the following display. Brocade# show sflow sFlow services are disabled. sFlow agent IP address: 10.10.10.254 Collector IP 10.10.10.1, UDP 6343 Polling interval is 30 seconds. Configured default sampling rate: 1 per 1024 packets. 0 UDP packets exported 0 sFlow samples collected.
23 Commands Commands The following commands support the features described in this chapter: • sflow null0-sampling • show sflow statistics 904 Multi-Service IronWare Switching Configuration Guide 53-1003036-02
sflow null0-sampling 23 sflow null0-sampling Enables and disables of the null0 sampling. Syntax Parameters Command Modes [no]sflow null0-sampling .slot/port Specifies the port that you want to display nullO sampling for. Global configuration mode Usage Guidelines Command Output The show sflow command displays the following information: sFlow services are enabled. sFlow management VRF is enabled. sFlow management VRF name is default-vrf. sFlow agent IP address: 55.55.55.
23 show sflow statistics show sflow statistics Displays the total count per interface for both sFlow and ACL based samples in all the slots where sFlow is configured. Syntax Parameters Command Modes show sflow statistics slot/port Specifies the port that you want to display statistics for.
Chapter 24 Configuring Uni-Directional Link Detection (UDLD) Table 120 displays the individual Brocade devices and the Uni-Directional Link Detection (UDLD) features they support.
24 Configuration considerations Configuration considerations This section describes the configuration considerations: • The feature is supported only on Ethernet ports. • To configure UDLD on a LAG group, you must configure the feature on each port of the group individually. Configuring UDLD on a LAG group’s primary port enables the feature on that port only. • Dynamic LAG is not supported.
24 Displaying UDLD information UDLD for tagged ports The default implementation of UDLD sends the packets untagged, even across tagged ports. If the untagged UDLD packet is received by a third-party switch, that switch may reject the packet. As a result, UDLD may be limited only to Brocade devices, since UDLD may not function on third-party switches. Beginning with Multi-Service IronWare release 04.1.
24 Displaying UDLD information TABLE 121 CLI display of UDLD information (Continued) This field... Displays... Keepalive Interval The number of seconds between health check packets. Port The port number. Physical Link The state of the physical link. This is the link between the Brocade port and the directly connected device. Link-keepalive Show if the keepalive link is up or down. Logical Link The state of the logical link.
Displaying UDLD information 24 TABLE 122 CLI display of detailed UDLD information This field... Displays... Current State The state of the logical link. This is the link between this device port and the device port on the other end of the link. Remote MAC Addr The MAC address of the port or device at the remote end of the logical link. Local Port The port number on this router. Remote Port The port number on the router at the remote end of the link.
24 Clearing UDLD statistics Clearing UDLD statistics To clear UDLD statistics, enter the following command. Brocade# clear link-keepalive statistics Syntax: clear link-keepalive statistics This command clears the Packets sent, Packets received, and Transitions counters in the show link keepalive ethernet slot/portnum display.
Chapter 25 BiDirectional Forwarding Detection (BFD) Table 123 displays the individual devices and the BiDirectional Forwarding Detection (BFD) features they support.
25 BiDirectional Forwarding Detection (BFD) Multi-Service IronWare software provides support for Bidirectional Forwarding Detection (BFD). BFD provides rapid detection of the failure of a forwarding path by checking that the next-hop device is alive. Without BFD enabled, it can take from 3 to 30 seconds to detect that a neighboring device is not operational causing packet loss due to incorrect routing information at a level unacceptable for real-time applications such as VOIP and video over IP.
Configuring BFD parameters 25 Unlike IS-IS and OSPF however, the Tx and Rx sessions for MPLS BFD can reside on different interface modules. This means that when counting MPLS BFD sessions against the Interface Module maximum, the Tx and Rx sessions must be counted separately.
25 Displaying BFD information Displaying BFD information You can display BFD information for the device you are logged-in to and for BFD-configured neighbors as described in the following sections.
Displaying BFD information TABLE 124 25 Display of BFD information (Continued) This field... Displays... LP The number of the interface module that the Current Session Count is displayed for. Sessions The number of Transmit (Tx) and Receive (Rx) BFD sessions currently operating on the specified interface module. BFD Enabled ports count The number of ports on the device that have been enabled for BFD. Port The port that BFD is enabled on.
25 Displaying BFD information TABLE 125 Display of BFD information (Continued) This field... Displays... Interface The logical port (physical or virtual port) on which the peer is known. Holddown The interval in microseconds after which the session will transition to the down state if no message is received. Interval The interval in microseconds at which the local device sends BFD messages to the remote peer. R/H R - Heard from Remote.
Displaying BFD information TABLE 126 25 Display of BFD neighbor detail information (Continued) This field... Displays... Diag Value of the “diagnostic” field in the BFD Control Message as used by the local device in the last message sent. Demand Value of the “demand” bit in the BFD Control Message as used by the local device in the last message sent. Poll Value of the “poll” bit in the BFD Control Message as used by the local device in the last message sent.
25 Displaying BFD information Clearing BFD neighbor sessions You can clear all BFD neighbor sessions or a specified BFD neighbor session using the following command. Brocade# clear bfd neighbor Syntax: clear bfd neighbor [ip-address | ipv6-address] The ip-address variable specifies the IPv4 address of a particular neighbor whose session you want to clear BFD. The ipv6-address variable specifies the IPv6 address of a particular neighbor whose session you want to clear BFD.
Configuring BFD for the specified protocol 25 Configuring BFD for the specified protocol BFD can be configured for use with the following protocols: • • • • • OSPFv2 OSPFv3 IS-IS BGP4 BGP4+ NOTE BFD is not supported for OSPF v2 or v3 virtual links. NOTE BFD brings IS-IS and OSPF down with it when RSTP path-cost changes are made to the switch Alt Discarding port.
25 Configuring BFD for the specified protocol If the bfd holdover-interval is set to 20 seconds, when a notification is received from BFD that the BFD session has moved to DOWN state, the system waits for 20 seconds before sending the BFD session down notification to OSPFv2 state machine. If the BFD session returns to UP state before the 20 seconds expires, the OSPFv2 state machine is not notified that the BFD session flapped.
Configuring BFD for the specified protocol 25 The holdover interval can be configured globally. If the bfd holdover-interval is set to 20 seconds, when a notification is received from BFD that the BFD session has moved to DOWN state, the system waits for 20 seconds before sending the BFD session down notification to OSPFv3 state machine. If the BFD session returns to UP state before the 20 seconds expires, the OSPFv3 state machine is not notified that the BFD session flapped.
25 Configuring BFD for the specified protocol The holdover interval can be configured globally. If the bfd holdover-interval is set to 20 seconds, when a notification is received from BFD that the BFD session has moved to DOWN state, the system waits for 20 seconds before sending the BFD session down notification to ISIS state machine. If the BFD session returns to UP state before the 20 seconds expires, the ISIS state machine is not notified that the BFD session flapped.
Configuring BFD for the specified protocol 25 Syntax: [no] bfd-enable NOTE If BFD for BGP4 is globally disabled and then enabled, the original BFD sessions for BGP4 may not be available, depending on whether or not the maximum BFD sessions limit has been reached. When a BFD session for BGP4 is disabled, the session will be removed but BGP4 peering will not go down. The remote BFD peer will be informed that BFD use is disabled.
25 Configuring BFD for the specified protocol If the bfd holdover-interval is set to 20 seconds, when a notification is received from BFD that the BFD session has moved to DOWN state, the system waits for 20 seconds before sending the BFD session down notification to BGP4 state machine. If the BFD session returns to UP state before the 20 seconds expires, the BGP4 state machine is not notified that the BFD session flapped.
Configuring BFD for the specified protocol 25 Enabling BFD for a specific BGP4 peer To enable BFD for BGP4 for a specific neighbor or peer, enter a command such as the following Brocade(config-bgp)# neighbor 10.14.1.1 fail-over bfd-enable Syntax: [no] neighbor ipv4-address l ipv6-address fail-over bfd-enable The ipv4-address | pv6-address variables specify the IPv4 or IPv6 address of a particular neighbor or peer. The no option removes the BFD for BGP4 peer from the configuration.
25 Configuring BFD for the specified protocol Displaying BFD for BGP4 You can display BFD for BGP4 information for the device you are logged in to and for BFD configured neighbors as described in the following sections.
Configuring BFD for the specified protocol TABLE 127 25 Display of BFD information (Continued) This field... Displays... Sessions The number of Transmit (Tx) and Receive (Rx) BFD sessions currently operating on the specified interface module. BFD Enabled ports count The number of ports that have been enabled for BFD. Port The port on which BFD is enabled. MinTx The interval in milliseconds during which the device sends a BFD message from this port to its peer.
25 Configuring BFD for the specified protocol Session Uptime: 0:1:37:50.600, LastSessionDownTimestamp: 0:0:0:0.0 Physical Port:TX: eth 1/1,RX: eth 1/1,Vlan Id: 3 NeighborAddress State Interface Holddown Interval R/H 10.100.100.
Configuring BFD for the specified protocol 25 TABLE 129 Display of BFD neighbor detail information This field... Displays... Total number of Neighbor entries Total number of BFD sessions. NeighborAddress IPv4 or IPv6 address of the remote peer. State The current state of the BFD session: Up Down A.DOWN – The administrative down state. INIT – The Init state. UNKNOWN – The current state is unknown. Interface The logical port on which the peer is known.
25 BFD for RSVP-TE LSP TABLE 129 Display of BFD neighbor detail information (Continued) This field... Displays... MinRxInterval The interval in milliseconds that the neighbor device waits to receive a BFD message from the peer on this remote port. Multiplier The number of times that the remote neighbor device will wait for the MinRxInterval time on this port before it determines that the peer device is non-operational. Stats: Rx Total number of BFD control messages received from the remote peer.
BFD for RSVP-TE LSP 25 • The IP TTL for transmitted MPLS BFD control packets from ingress LSR to egress LSR must be set to 1 instead of 255. • After MPLS BFD session is up, the local discriminator and the source IP address are not allowed to change without bringing down the MPLS BFD session. • The transmit and receive portion of the session can be on different LPs because the LSP is unidirectional and the returned path from egress to ingress LSR depends on IP routing.
25 BFD for RSVP-TE LSP Because the source IP address cannot be changed for MPLS BFD session after the session has comes up, the LSR-ID is used as the source IP address for all MPLS BFD packets. This guarantees that the session does not go down when the LSP path switch occurs. FRR LSP Only one BFD session is created for a FRR LSP. When a switchover from protected to detour path occurs, and when the detour is on a different LP, the BFD session is moved to the LP where the detour path resides.
Commands 25 Commands The following commands support this feature.
25 show bfd show bfd The show bfd command output is extended to include MPLS in the registered protocol list. In addition, the number of sessions on the LP are shown separately as TX and RX. Syntax Parameters show bfd [applications|mpls [detail/lsp/rsvp-session]|neighbors [A.B.C.D/X:X:X:X/bgp/details/interface/isis/ospf/ospf6]] applications The application option displays BFD users. mpls The mpls option displays MPLS BFD session information specified by the detail, lsp, or rsvp-session keyword.
show bfd Output field Examples 25 Description Maximum Exceeded Count for LPs: The number of times the request to set up a BFD session was declined because it would have exceeded the maximum number of BFD sessions allowed on an interface module. LP The number of the interface modules for which the Current Session Count is displayed. Tx/Rx Sessions The number of Transmit (Tx) and Receive (Rx) BFD sessions currently operating on the specified interface module.
25 show bfd application show bfd application The command is extended to include MPLS. Syntax Parameters Command modes Usage guidelines Command output Example show bfd application None. This command operates in all modes. Use to display MPLS in the output. The show bfd application command displays the following information. Output field Description Protocol Which protocols are registered to use BFD on the device. VRFID The VRFID of the protocol.
show bfd mpls 25 show bfd mpls A new command show bfd mpls is added to show all MPLS BFD sessions. For BFD session associated with LSP, the LSP name will be shown. For BFD session associated with egress RSVP session, the RSVP session ID issued to identify the BFD session. You can filter BFD session based on LSP name or egress RSVP session ID. Syntax Parameters show bfd mpls [detail|lsp lsp_name|rsvp-session [src_addr/dest_addr/tnnl_addr]] detail The detail option displays the MPLS BFD session in detail.
25 show mpls bfd show mpls bfd Global BFD configuration information can be shown under a new command show mpls bfd. Syntax Parameters Command modes show mpls bfd None. This command operates under all modes. History Release Command history Multi-Service NetIron Release 05.6.00 This command was introduced. Related commands 940 None.
show mpls lsp 25 show mpls lsp The existing show mpls lsp output is extended to show BFD information when the BFD administrative state is enabled. Syntax Parameters show mpls lsp [brief|detail|down [detail/extensive/wide]|extensive|name lsp_name|up [detail/extensive/wide]|wide] brief The brief option displays brief configuration information. detail The detail option displays detailed configuration information.
25 show mpls lsp • Max LP session exceeded • Peer session down • Wait for peer Command output The show mpls lsp command displays the following information. Output field Description From: The LSPs source address, configured with the from command. When a source IP address has not been specified for the LSP with the from command, and the LSP has not been enabled, then ‘(n/a)’ is displayed in the ‘From’ field. admin: The administrative state of the LSP.
show mpls lsp Output field Tunnel interface: 25 Description The status of the tunnel interface can be one of the following: UP – The tunnel interface is functioning properly. DOWN – The tunnel interface is not functioning and is down. • • outbound interface: The outbound interface taken by the active path of the LSP. When the egress interface is a VE-enabled interface, the VE interface ID specified by the vid variable is displayed here in the Outbound interface field.
25 show mpls lsp Example Output field Description Fast Reroute: The method of Fast Reroute configured for this LSP. Currently only one-to-one backup is available. Detour LSP: Indicates if the detour route is UP or DOWN. out-label: The outbound label used when sending traffic over a detour LSP. outbound interface: The physical interface on the router that is used for the detour route. Brocade# show mpls lsp lsp3 LSP lsp3, to 10.22.22.2 From: 10.11.11.
show mpls config / show mpls config lsp 25 show mpls config / show mpls config lsp The show mpls config command displays all of the user-configured MPLS parameters. The show mpls config command and the show mpls config lsp command now displays the BFD configuration if and only if it is not the default setting.
25 Configuring BFD for RSVP-TE LSPs vll-local The vll-local option displays the vll-local configuration information specified by the vll_local_name variable. vpls The vpls option displays the VPLS configuration information specified by the vpls_name variable. Command modes Usage guidelines This command operates in all modes. The show mpls config command and show mpls config lsp command displays the BFD configuration if and only if it is not the default setting.
Configuring BFD for RSVP-TE LSPs 25 BFD for RSVP-TE LSPs operates with Fast ReRoute (FRR), Redundant, and Adaptive LSPs as described: • FRR LSPs – Only one BFD session is created for an FRR LSP. A separate BFD session is not created for the detour path. When a switchover from a protected to a detour path occurs, the detour path resides on another interface module, and the BFD session is moved to that interface module.
25 Configuring BFD for RSVP-TE LSPs If the number of BFD sessions has reached the su pop rt ed maximum for the device, no MPLS Echo Reply or BFD control packet is sent. The ingress LSR will retry. Because the source IP address cannot be changed for an MPLS BFD session after the session has come up, the LSR-ID is used as the source IP address for all MPLS BFD packets. This ensures that the session will not go down when an LSP path switch occurs.
Configuring BFD for RSVP-TE LSPs 25 The transmit-time variable is the interval in milliseconds during which this device sends a BFD message to the peer informing it that it is still operational. Acceptable values are 50 - 30000. The default value is 1000 (unless changed at the global level). The receive-time variable is the interval in milliseconds the device waits to receive a BFD message from the peer.
25 Displaying MPLS BFD information Brocade(config)# router mpls Brocade(config-mpls)# lsp blue Brocade(config-mpls-lsp-blue)# secondary-path alt_sf_to_sj Brocade(config-mpls-lsp-blue-sec-path)# bfd Enabling the IP router alert option NOTE The set-router-alert-option command is supported only for NetIron XMR and NetIron MLX devices. The set-router-alert-option command sets the IP router alert option for MPLS BFD packets sent from the ingress device to the egress device.
Displaying MPLS BFD information 25 You can also obtain MPLS BFD information using the show bfd command, as described in “Displaying BFD information”, and the show mpls lsp command, as described in “Displaying signalled LSP status information”. Displaying BFD application information The following example illustrates the output from the show bfd application command.
25 Displaying MPLS BFD information TABLE 131 Display of BFD MPLS information (Continued) This field... Displays... State The current state of the BFD session: Up Down A.DOWN – The administrative down state INIT – The Init state UNKNOWN – The current state is unknown Interface The logical port (physical or virtual port) on which the BFD packet is sent out. The physical port can be either an Ethernet, or VE-enabled interface. The VE interface ID is specified by the vid variable.
Displaying MPLS BFD information 25 Displaying MPLS BFD global configuration information You can use the show mpls bfd command to display the global configuration information for a device, as shown in the following. Brocade# show mpls bfd MPLS BFD admin Minimum TX interval Minimum RX interval Detection time multiplier = = = = Enabled 1000 msec 1000 msec 3 Syntax: show mpls bfd TABLE 133 Display of BFD MPLS detail command This field... Displays...
25 954 Displaying MPLS BFD information Multi-Service IronWare Switching Configuration Guide 53-1003036-02
