Force10-S25p - Reference Guide - En-Us PDF
Force10-S25p - Reference Guide - En-Us PDF
FTOS 8.4.2.7
E-Series TeraScale, C-Series,
S-Series (S50/S25)
Notes, Cautions, and Warnings
NOTE: A NOTE indicates important information that helps you make better use of your computer.
CAUTION: A CAUTION indicates potential damage to hardware or loss of data if instructions are not followed.
WARNING: A WARNING indicates a potential for property damage, personal injury, or death.
Trademarks used in this text: Dell(TM), the Dell logo, Dell Boomi(TM), Dell Precision(TM) , OptiPlex(TM), Latitude(TM), PowerEdge(TM),
PowerVault(TM), PowerConnect(TM), OpenManage(TM), EqualLogic(TM), Compellent(TM), KACE(TM), FlexAddress(TM),
Force10(TM) and Vostro(TM) are trademarks of Dell Inc. Intel(R), Pentium(R), Xeon(R), Core(R) and Celeron(R) are registered trademarks
of Intel Corporation in the U.S. and other countries. AMD(R) is a registered trademark and AMD Opteron(TM), AMD Phenom(TM) and
AMD Sempron(TM) are trademarks of Advanced Micro Devices, Inc. Microsoft(R), Windows(R), Windows Server(R), Internet Explorer(R),
MS-DOS(R), Windows Vista(R) and Active Directory(R) are either trademarks or registered trademarks of Microsoft Corporation in the
United States and/or other countries. Red Hat(R) and Red Hat(R)Enterprise Linux(R) are registered trademarks of Red Hat, Inc. in the United
States and/or other countries. Novell(R) and SUSE(R) are registered trademarks of Novell Inc. in the United States and other countries.
Oracle(R) is a registered trademark of Oracle Corporation and/or its affiliates. Citrix(R), Xen(R), XenServer(R) and XenMotion(R) are either
registered trademarks or trademarks of Citrix Systems, Inc. in the United States and/or other countries. VMware(R), Virtual SMP(R),
vMotion(R), vCenter(R) and vSphere(R) are registered trademarks or trademarks of VMware, Inc. in the United States or other countries.
IBM(R) is a registered trademark of International Business Machines Corporation.
October 2012
1 About this Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Information Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34
Related Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34
2 Configuration Fundamentals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Accessing the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35
CLI Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Navigating CLI Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37
The do Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Undoing Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40
Obtaining Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Entering and Editing Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41
Command History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Filtering show Command Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43
Multiple Users in Configuration mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44
3 Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Default Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
Configure a Host Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
Access the System Remotely . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
Access the C-Series and E-Series Remotely . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
Access the S-Series Remotely . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49
Configure the Enable Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50
Configuration File Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50
Copy Files to and from the System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51
Save the Running-configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52
View Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
File System Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55
View command history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56
Upgrading and Downgrading FTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56
4 System Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Configure Privilege Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57
Create a Custom Privilege Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57
Apply a Privilege Level to a Username . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
Apply a Privilege Level to a Terminal Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
Configure Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
Log Messages in the Logging Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62
Configuration Task List for System Log Management . . . . . . . . . . . . . . . . . . . . . . .62
Disable System Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62
Send System Messages to a Syslog Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63
Configure a Unix System as a Syslog Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63
| 3
Change System Logging Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63
www.dell.com | support.dell.com
5 802.1ag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Ethernet CFM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79
Maintenance Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80
Maintenance Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80
Maintenance End Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81
Implementation Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82
Configure CFM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Related Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82
Enable Ethernet CFM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83
Create a Maintenance Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83
Create a Maintenance Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84
Create Maintenance Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84
Create a Maintenance End Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84
Create a Maintenance Intermediate Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85
MP Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85
Continuity Check Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87
Enable CCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Enable Cross-checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88
Loopback Message and Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88
Linktrace Message and Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88
Link Trace Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89
Enable CFM SNMP Traps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90
Display Ethernet CFM Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91
4 |
6 802.3ah . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Link Layer OAM Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93
Link Layer OAMPDUs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94
Link Layer OAM Operational Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95
Link Layer OAM Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95
Link Layer OAM Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96
Remote Loopback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96
Implementation Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96
Configure Link Layer OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .97
Related Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .97
Enable Link Layer OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .97
Adjust the OAMPDU Transmission Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99
Link Performance Event Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99
Enable Error Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99
Set Threshold Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .100
Execute an Action upon Exceeding the High Threshold . . . . . . . . . . . . . . . . . . . . .102
Remote Failure Indication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102
Remote Loopback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103
Display Link Layer OAM Configuration and Statistics . . . . . . . . . . . . . . . . . . . . . . . . . .104
Manage Link Layer OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .106
Enable MIB Retrieval Support/Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .106
Adjust the Size of the Link OAM Event Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .106
7 802.1X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .107
The Port-authentication Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .109
EAP over RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .110
Configuring 802.1X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Related Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111
Important Points to Remember . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112
Enabling 802.1X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Configuring Request Identity Re-transmissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114
Configuring a Quiet Period after a Failed Authentication . . . . . . . . . . . . . . . . . . . .114
Forcibly Authorizing or Unauthorizing a Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115
Re-Authenticating a Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .116
Periodic Re-Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .116
Configuring Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117
Dynamic VLAN Assignment with Port Authentication . . . . . . . . . . . . . . . . . . . . . . . . . .119
Guest and Authentication-Fail VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121
Configuring a Guest VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121
Configuring an Authentication-Fail VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122
Multi-Host Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123
Multi-Supplicant Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .125
| 5
MAC Authentication Bypass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127
www.dell.com | support.dell.com
6 |
Configuring BFD for VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .198
Configuring BFD for Port-Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .201
Configuring Protocol Liveness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .203
Troubleshooting BFD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .203
| 7
Boot Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
www.dell.com | support.dell.com
8 |
Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .314
Configure the System to be a DHCP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .314
Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .315
Configure the Server for Automatic Address Allocation . . . . . . . . . . . . . . . . . . . . .315
Specify a Default Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .316
Enable DHCP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .317
Configure a Method of Hostname Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . .317
Allocate Addresses to BOOTP Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .318
Create Manual Binding Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .318
Check for Address Conflicts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .319
DHCP Clear Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .320
Configure the System to be a Relay Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .320
Configure Secure DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .321
Option 82 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
DHCP Snooping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .322
Drop DHCP packets on snooped VLANs only . . . . . . . . . . . . . . . . . . . . . . . . . . . .325
Dynamic ARP Inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .325
Source Address Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .327
| 9
Enable Force10 Service Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .348
www.dell.com | support.dell.com
10 |
Failure and Event Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .392
Hot-lock Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .393
Warm Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
Configure Cache Boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .394
In-Service Modular Hot-Fixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .398
Process Restartability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .399
20 Interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Interface Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
View Basic Interface Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .416
Enable a Physical Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .418
Physical Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .419
Configuration Task List for Physical Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . .419
Overview of Layer Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .420
Configure Layer 2 (Data Link) Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .420
Configure Layer 3 (Network) Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .421
Management Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .423
Configure Management Interfaces on the E-Series and C-Series . . . . . . . . . . . . .423
| 11
Configure Management Interfaces on the S-Series . . . . . . . . . . . . . . . . . . . . . . . .424
www.dell.com | support.dell.com
12 |
ARP Learning via ARP Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .474
Configurable ARP Retries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .475
ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
Configuration Task List for ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .475
UDP Helper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
Configuring UDP Helper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .477
Important Points to Remember about UDP Helper . . . . . . . . . . . . . . . . . . . . . . . . . . . .477
Enabling UDP Helper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .477
Configuring a Broadcast Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .478
Configurations Using UDP Helper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .478
UDP Helper with Broadcast-all Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .479
UDP Helper with Subnet Broadcast Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . .479
UDP Helper with Configured Broadcast Addresses . . . . . . . . . . . . . . . . . . . . . . . .480
UDP Helper with No Configured Broadcast Addresses . . . . . . . . . . . . . . . . . . . . .481
Troubleshooting UDP Helper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .481
| 13
Clear IPv6 Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .504
www.dell.com | support.dell.com
25 Layer 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559
Managing the MAC Address Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .559
Clear the MAC Address Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .560
Set the Aging Time for Dynamic Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .560
Set the Aging Time for Dynamic Entries on a VLAN . . . . . . . . . . . . . . . . . . . . .560
Configure a Static MAC Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .561
Display the MAC Address Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .561
14 |
MAC Learning Limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .562
mac learning-limit dynamic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .563
mac learning-limit station-move . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .563
mac learning-limit no-station-move . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .564
mac learning-limit sticky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .564
Displaying MAC Learning-Limited Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . .566
Learning Limit Violation Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .566
Station Move Violation Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .566
Recovering from Learning Limit and Station Move Violations . . . . . . . . . . . . . . . . .567
Per-VLAN MAC Learning Limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .567
NIC Teaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569
MAC Move Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .570
Microsoft Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .570
Default Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .570
Configuring the Switch for Microsoft Server Clustering . . . . . . . . . . . . . . . . . . . . . .571
Enable and Disable VLAN Flooding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .572
Configuring Redundant Pairs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .573
Important Points about Configuring Redundant Pairs . . . . . . . . . . . . . . . . . . . . . . .574
Restricting Layer 2 Flooding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .576
Far-end Failure Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .577
FEFD state changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .577
Important Points to Remember . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .578
Configuring FEFD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .578
Debugging FEFD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .580
| 15
Configuring Transmit and Receive Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .596
www.dell.com | support.dell.com
16 |
View the Source-active Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .623
Limit the Source-active Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .623
Clear the Source-active Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .623
Enable the Rejected Source-active Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .623
Accept Source-active Messages that fail the RFP Check . . . . . . . . . . . . . . . . . . . . . . .624
Limit the Source-active Messages from a Peer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .626
Prevent MSDP from Caching a Local Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .627
Prevent MSDP from Caching a Remote Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .628
Prevent MSDP from Advertising a Local Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .629
Log Changes in Peership States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .630
Terminate a Peership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .630
Clear Peer Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .631
Debug MSDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 632
MSDP with Anycast RP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .632
Reducing Source-active Message Flooding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .634
Specify the RP Address Used in SA Messages . . . . . . . . . . . . . . . . . . . . . . . . . . .634
MSDP Sample Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .638
| 17
Multicast Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .665
www.dell.com | support.dell.com
18 |
Enable OSPFv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .705
Enable Multi-Process OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .707
Assign an OSPFv2 area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .708
Enable OSPFv2 on interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .709
Configure stub areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .711
Configure OSPF Stub-Router Advertisement . . . . . . . . . . . . . . . . . . . . . . . . . . . . .712
Enable passive interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .713
Enable fast-convergence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .714
Change OSPFv2 parameters on interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .715
Enable OSPFv2 authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .717
Enable OSPFv2 graceful restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .717
Configure virtual links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .719
Filter routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 720
Redistribute routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .721
Troubleshooting OSPFv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .722
Sample Configurations for OSPFv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .725
Basic OSPFv2 Router Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .725
Configuration Task List for OSPFv3 (OSPF for IPv6) . . . . . . . . . . . . . . . . . . . . . . . . . .726
Enable IPv6 Unicast Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .727
Assign IPv6 addresses on an interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .727
Assign Area ID on interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .727
Assign OSPFv3 Process ID and Router ID Globally . . . . . . . . . . . . . . . . . . . . . . . .728
Configure stub areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .728
Configure Passive-Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .729
Redistribute routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .730
Configure a default route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .730
Enable OSPFv3 graceful restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .731
OSPFv3 Authentication Using IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .734
Troubleshooting OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .744
| 19
Refusing Multicast Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .756
www.dell.com | support.dell.com
20 |
Create VLANs for an Office VOIP Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . .795
Configure LLDP-MED for an Office VOIP Deployment . . . . . . . . . . . . . . . . . . . . . .796
Configure Quality of Service for an Office VOIP Deployment . . . . . . . . . . . . . . . . .797
| 21
Configure Per-VLAN Spanning Tree Plus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .836
www.dell.com | support.dell.com
22 |
Implementation Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .878
Configuration Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .878
Configuration Task List for RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .879
RIP Configuration Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .886
45 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 913
AAA Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 913
Configuration Task List for AAA Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .914
AAA Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .917
Configuration Task List for AAA Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . .917
AAA Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .920
Privilege Levels Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .920
Configuration Task List for Privilege Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .921
RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925
RADIUS Authentication and Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .926
Configuration Task List for RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .928
TACACS+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 931
Configuration Task List for TACACS+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .931
TACACS+ Remote Authentication and Authorization . . . . . . . . . . . . . . . . . . . . . . .933
Command Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .935
| 23
Protection from TCP Tiny and Overlapping Fragment Attacks . . . . . . . . . . . . . . . . . . .935
www.dell.com | support.dell.com
47 sFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 973
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 973
Implementation Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .974
Important Points to Remember . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .974
Enable and Disable sFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .975
Enable and Disable on an Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .975
sFlow Show Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .976
24 |
Show sFlow Globally . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .976
Show sFlow on an Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .976
Show sFlow on a Line Card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .977
Configure Collectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .978
Polling Intervals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .978
Sampling Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 979
Sub-sampling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .979
Back-off Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .980
sFlow on LAG ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .980
Extended sFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 980
Important Points to Remember . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .982
49 SONET/SDH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1007
Packet Over SONET (POS) Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1007
Important Points to Remember . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1007
Configuring POS Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1008
10GE WAN Physical Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1009
SONET Alarm Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1010
SONET TRAP Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1013
SONET Syslog Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1013
| 25
Events that Bring Down a SONET Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1013
www.dell.com | support.dell.com
26 |
Configuring Spanning Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1049
Related Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1050
Important Points to Remember . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1050
Configuring Interfaces for Layer 2 Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1051
Enabling Spanning Tree Protocol Globally . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1052
Adding an Interface to the Spanning Tree Group . . . . . . . . . . . . . . . . . . . . . . . . . . . .1054
Removing an Interface from the Spanning Tree Group . . . . . . . . . . . . . . . . . . . . . . . .1054
Modifying Global Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1055
Modifying Interface STP Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1056
Enabling PortFast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1056
Preventing Network Disruptions with BPDU Guard . . . . . . . . . . . . . . . . . . . . . . . . . . .1057
STP Root Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1059
STP Root Guard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1060
Root Guard Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1060
Root Guard Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1063
SNMP Traps for Root Elections and Topology Changes . . . . . . . . . . . . . . . . . . . . . .1063
Configuring Spanning Trees as Hitless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1064
STP Loop Guard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1064
Loop Guard Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1064
Loop Guard Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1067
Displaying STP Guard Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1068
| 27
Clearing a UFD-Disabled Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1090
www.dell.com | support.dell.com
56 VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1099
Virtual LAN Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1099
Port-based VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1100
VLAN Tagging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1101
Default VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1102
Implementation Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1102
Configuring VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1102
Related Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1102
Related Protocols and Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1103
Create a VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1103
Assign Interfaces to VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1104
Enable Routing between VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1105
Use a Native VLAN on Trunk Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1106
Change the Default VLAN ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1107
Set the Null VLAN as the Default VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1107
Enable VLAN Interface Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1108
28 |
VRRP Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1129
VRRP version 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1130
VRRP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1131
Create a Virtual Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1131
Assign Virtual IP addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1132
Set VRRP Group (Virtual Router) Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1135
Configure VRRP Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1136
Disable Preempt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1137
Change the Advertisement interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1138
Track an Interface or Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1139
VRRP on a VRF Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1142
Sample Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1144
VRRP for IPv4 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1144
VRRP for IPv6 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1146
VRRP in VRF Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1149
| 29
Save a hardware log to a file on the flash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1176
www.dell.com | support.dell.com
30 |
Trace logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1214
Buffer full condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1214
Manual reload condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1215
CP software exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1215
View trace buffer content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1215
Write the contents of the trace buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1216
Clear the trace buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1216
Recognize a high CPU condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1217
Configure an action upon a hardware error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1217
Buffer traffic manager hardware errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1217
Flexible packet classifier hardware errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1218
Line card MAC hardware errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1218
Core dumps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1218
RPM core dumps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1218
Line card core dumps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1219
64 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1253
| 31
www.dell.com | support.dell.com
32
|
1
About this Guide
Objectives
This guide describes the protocols and features supported by the Dell Force10 Operating System (FTOS)
and provides configuration instructions and examples for implementing them. It supports the system
platforms E-Series, C-Series, and S-Series.
The E-Series ExaScale platform is supported with FTOS version 8.1.1.0. and later.
Though this guide contains information on protocols, it is not intended to be a complete reference. This
guide is a reference for configuring protocols on Dell Force10 systems. For complete information on
protocols, refer to other documentation including IETF Requests for Comment (RFCs). The instructions in
this guide cite relevant RFCs, and Appendix 63, Standards Compliance contains a complete list of the
supported RFCs and Management Information Base files (MIBs).
Audience
This document is intended for system administrators who are responsible for configuring and maintaining
networks and assumes you are knowledgeable in Layer 2 and Layer 3 networking technologies.
Convention Description
keyword Keywords are in bold and should be entered in the CLI as listed.
parameter Parameters are in italics and require a number or word to be entered in the CLI.
{X} Keywords and parameters within braces must be entered in the CLI.
x|y Keywords and parameters separated by bar require you to choose one.
Information Symbols
Table 1-1 describes symbols contained in this guide.
Table 1-1. Information Symbols
et ex E-Series Specific
Feature/Command
If a feature or command applies to only one of the E-Series platforms, a
separate symbol calls this to attention: et for the TeraScale or e x for
the ExaScale.
*
Exception This symbol is a note associated with some other text on the page that is
marked with an asterisk.
Related Documents
For more information about the Dell Force10 E-Series, C-Series, and S-Series refer to the following
documents:
• FTOS Command Reference
• Installing and Maintaining the <Dell Force10 chassis> System
• FTOS Release Notes
In FTOS, after a command is enabled, it is entered into the running configuration file. You can view the
current configuration for the whole system or for a particular CLI mode. To save the current configuration
copy the running configuration to another location.
Note: Due to a differences in hardware architecture and the continued system development, features may
occasionally differ between the platforms. These differences are identified by the information symbols
shown on Table 1-1 on page 34.
Note: You must have a password configured on a virtual terminal line before you can Telnet into the
system. Therefore, you must use a console connection when connecting to the system for the first time.
telnet 172.31.1.53
Trying 172.31.1.53...
Connected to 172.31.1.53.
Escape character is '^]'.
Login: username EXEC mode prompt
Configuration Fundamentals | 35
CLI Modes
www.dell.com | support.dell.com
Different sets of commands are available in each mode. A command found in one mode cannot be
executed from another mode (with the exception of EXEC mode commands preceded by the command do;
see The do Command on page 40). You can set user access rights to commands and command modes using
privilege levels; for more information on privilege levels and security options, refer to Chapter 9, Security,
on page 627.
Beneath CONFIGURATION mode are sub-modes that apply to interfaces, protocols, and features.
Figure 2-2 illustrates this sub-mode command structure. Two sub-CONFIGURATION modes are
important when configuring the chassis for the first time:
• INTERFACE sub-mode is the mode in which you configure Layer 2 and Layer 3 protocols and IP
services specific to an interface. An interface can be physical (Management interface, 1-Gigabit
Ethernet, or 10-Gigabit Ethernet, or SONET) or logical (Loopback, Null, port channel, or VLAN).
• LINE sub-mode is the mode in which you to configure the console and virtual terminal lines.
Note: At any time, entering a question mark (?) will display the available command options. For example,
when you are in CONFIGURATION mode, entering the question mark first will list all available commands,
including the possible sub-modes.
36 | Configuration Fundamentals
Figure 2-2. CLI Modes in FTOS
EXEC
EXEC Privilege
CONFIGURATION
ARCHIVE
AS-PATH ACL
INTERFACE
GIGABIT ETHERNET
10 GIGABIT ETHERNET
INTERFACE RANGE
LOOPBACK
MANAGEMENT ETHERNET
NULL
PORT-CHANNEL
SONET
VLAN
VRRP
IP
IPv6
IP COMMUNITY-LIST
IP ACCESS-LIST
STANDARD ACCESS-LIST
EXTENDED ACCESS-LIST
LINE
AUXILIARY
CONSOLE
VIRTUAL TERMINAL
MAC ACCESS-LIST
MONITOR SESSION
MULTIPLE SPANNING TREE
Per-VLAN SPANNING TREE
PREFIX-LIST
RAPID SPANNING TREE
REDIRECT
ROUTE-MAP
ROUTER BGP
ROUTER ISIS
ROUTER OSPF
ROUTER RIP
SPANNING TREE
TRACE-LIST
Note: Sub-CONFIGURATION modes all have the letters “conf” in the prompt with additional modifiers to
identify the mode and slot/port information. These are shown in Table 2-1.
Configuration Fundamentals | 37
www.dell.com | support.dell.com
ip access-list standard
LIST
AUXILIARY FTOS(config-line-aux)#
LINE
38 | Configuration Fundamentals
Table 2-1. FTOS Command Modes
LIST
Figure 2-3 illustrates how to change the command mode from CONFIGURATION mode to PROTOCOL
SPANNING TREE.
Configuration Fundamentals | 39
The do Command
www.dell.com | support.dell.com
Enter an EXEC mode command from any CONFIGURATION mode (CONFIGURATION, INTERFACE,
SPANNING TREE, etc.) without returning to EXEC mode by preceding the EXEC mode command with
the command do. Figure 2-4 illustrates the do command.
Note: The following commands cannot be modified by the do command: enable, disable, exit, and
configure.
Undoing Commands
When you enter a command, the command line is added to the running configuration file. Disable a
command and remove it from the running-config by entering the original command preceded by the
command no. For example, to delete an ip address configured on an interface, use the no ip address
ip-address command, as shown in Figure 2-5.
Note: Use the help or ? command as discussed in Obtaining Help command to help you construct the
“no” form of a command.
Layer 2 protocols are disabled by default. Enable them using the no disable command. For example, in
PROTOCOL SPANNING TREE mode, enter no disable to enable Spanning Tree.
40 | Configuration Fundamentals
Obtaining Help
Obtain a list of keywords and a brief functional description of those keywords at any CLI mode using the ?
or help command:
• Enter ? at the prompt or after a keyword to list the keywords available in the current mode.
• ? after a prompt lists all of the available keywords. The output of this command is the same for the
help command.
Figure 2-6. ? Command Example
FTOS#? “?” at prompt for list of commands
calendar Manage the hardware calendar
cd Change current directory
change Change subcommands
clear Reset functions
clock Manage the system clock
configure Configuring from terminal
copy Copy from one file to another
debug Debug functions
--More--
• ? after a partial keyword lists all of the keywords that begin with the specified letters.
Figure 2-7. Keyword? Command Example
• A keyword followed by [space]? lists all of the keywords that can follow the specified keyword.
Figure 2-8. Keyword ? Command Example
Configuration Fundamentals | 41
• The UP and DOWN arrow keys display previously entered commands (see Command History).
www.dell.com | support.dell.com
Command History
FTOS maintains a history of previously-entered commands for each mode. For example:
• When you are in EXEC mode, the UP and DOWN arrow keys display the previously-entered EXEC
mode commands.
• When you are in CONFIGURATION mode, the UP or DOWN arrows keys recall the
previously-entered CONFIGURATION mode commands.
42 | Configuration Fundamentals
Filtering show Command Outputs
Filter the output of a show command to display specific information by adding | [except | find | grep |
no-more | save] specified_text after the command. The variable specified_text is the text for which you are
filtering and it IS case sensitive unless the ignore-case sub-option is implemented.
Starting with FTOS 7.8.1.0, the grep command accepts an ignore-case sub-option that forces the search to
case-insensitive. For example, the commands:
• show run | grep Ethernet returns a search result with instances containing a capitalized “Ethernet,”
such as interface GigabitEthernet 0/0.
• show run | grep ethernet would not return that search result because it only searches for instances
containing a non-capitalized “ethernet.”
Executing the command show run | grep Ethernet ignore-case would return instances containing both
“Ethernet” and “ethernet.”
• grep displays only the lines containing specified text. Figure 2-9 shows this command used in
combination with the command show linecard all.
Note: FTOS accepts a space or no space before and after the pipe. To filter on a phrase with spaces,
underscores, or ranges, enclose the phrase with double quotation marks.
• except displays text that does not match the specified text. Figure 2-10 shows this command used in
combination with the command show linecard all.
-- Line cards --
Slot Status NxtBoot ReqTyp CurTyp Version Ports
---------------------------------------------------------------------------
2 not present
3 not present
4 not present
5 not present
6 not present
Configuration Fundamentals | 43
• find displays the output of the show command beginning from the first occurrence of specified text
www.dell.com | support.dell.com
Figure 2-11 shows this command used in combination with the command show linecard all.
Figure 2-11. Filtering Command Outputs with the find Command
FTOS(conf)#do show linecard all | find 0
0 not present
1 not present
2 online online E48TB E48TB 1-1-463 48
3 not present
4 not present
5 online online E48VB E48VB 1-1-463 48
6 not present
7 not present
Note: You can filter a single command output multiple times. The save option should be the last option
entered. For example:
FTOS# command | grep regular-expression | except regular-expression
| grep other-regular-expression | find regular-expression | save
If either of these messages appears, Dell Force10 recommends that you coordinate with the users listed in
the message so that you do not unintentionally overwrite each other’s configuration changes.
44 | Configuration Fundamentals
3
Getting Started
This chapter contains the following major sections:
• Default Configuration on page 46
• Configure a Host Name on page 47
• Access the System Remotely on page 47
• Configure the Enable Password on page 50
• Configuration File Management on page 50
• File System Management on page 55
When you power up the chassis, the system performs a Power-On Self Test (POST) during which Route
Processor Module (RPM), Switch Fabric Module (SFM), and line card status LEDs blink green.The
system then loads FTOS and boot messages scroll up the terminal window during this process. No user
interaction is required if the boot process proceeds without interruption.
When the boot process is complete, the RPM and line card status LEDs remain online (green), and the
console monitor displays the Force10 banner and EXEC mode prompt, as shown in Figure 3-1.
For details on using the Command Line Interface (CLI), see the Accessing the Command Line section in
Chapter 1, Configuration Fundamentals, on page 47.
Getting Started | 45
Figure 3-1. Completed Boot Process
www.dell.com | support.dell.com
.*************.
.# #### #######.
######## ####### ######### ######## ######## .#. ###### ###########.
### ### ## ### ### #### ### .##. ## ### #### ###.
### ### ### ### ### ### ### *#. ### ### #*
### ### ## ### #### ### ######## *# -## ### #*
###### ### ## ######### ### ######## *# ### ## #*
### ### ## ### #### ### ### *# #### ### #*
### ### ### ### #### #### ### *#. #### ### ###*
### ### ### ### ### ##### ## ######## .#.##### #### #### .
### ##### ### ### ###### ######## .###### ############ .
.# ######### .
`************'
00:01:27: %RPM0-P:CP %CHMGR-5-CHECKIN: Checkin from line card 1 (type E48TB, 48 ports)
00:01:27: %RPM0-P:CP %CHMGR-5-CHECKIN: Checkin from line card 2 (type E48TB, 48 ports)
00:01:28: %RPM0-P:CP %CHMGR-5-LINECARDUP: Line card 1 is up
00:01:28: %RPM0-P:CP %CHMGR-5-LINECARDUP: Line card 2 is up
00:01:36: %RPM0-P:CP %RAM-5-RPM_STATE: RPM0 is in Active State.
00:01:36: %RPM0-P:CP %CHMGR-5-CHAS_READY: Chassis ready
Default Configuration
A version of FTOS is pre-loaded onto the chassis, however the system is not configured when you power
up for the first time (except for the default hostname, which is Force10). You must configure the system
using the CLI.
46 | Getting Started
Configure a Host Name
The host name appears in the prompt. The default host name is force10.
• Host names must start with a letter and end with a letter or digit.
• Characters within the string can be letters, digits, and hyphens.
New Hostname
• The C-Series and E-Series have a dedicated management port and a management routing table that is
separate from the IP routing table.
• The S-Series does not have a dedicated management port, but is managed from any port. It does not
have a separate management routing table.
1. Configure an IP address for the management port. See Configure the Management Port IP Address.
2. Configure a management route with a default gateway. See Configure a Management Route.
3. Configure a username and password. See Configure a Username and Password.
Getting Started | 47
Configure the Management Port IP Address
www.dell.com | support.dell.com
Assign IP addresses to the management ports in order to access the system remotely.
Define a path from the system to the network from which you are accessing the system remotely.
Management routes are separate from IP routes and are only used to manage the system through the
management port.
48 | Getting Started
To configure a username and password:
Note: The S60 system uses management ports and should be configured similar to the C-Series and
E-Series systems. Refer to Access the C-Series and E-Series Remotely
1. Configure an IP address for the port through which you will manage the system using the command ip
address from INTERFACE mode, as shown in Figure 3-3.
2. Configure a IP route with a default gateway using the command ip route from CONFIGURATION
mode, as shown in Figure 3-3.
3. Configure a username and password using the command username from CONFIGURATION mode, as
shown in Figure 3-3.
Figure 3-3. Configuring the S-Series for Remote Access
R5(conf)#int gig 0/48
R5(conf-if-gi-0/48)#ip address 10.11.131.240
R5(conf-if-gi-0/48)#show config
!
interface GigabitEthernet 0/48
ip address 10.11.131.240/24
no shutdown
R5(conf-if-gi-0/48)#exit
R5(conf)#ip route 10.11.32.0/23 10.11.131.254
R5(conf)#username admin pass force10
Getting Started | 49
Configure the Enable Password
www.dell.com | support.dell.com
The EXEC Privilege mode is accessed by the enable command. Configure a password as a basic security
measure. When using a console connection, EXEC Privilege mode is unrestricted by default; it cannot be
reached by a VTY connection if no password is configured. There are two types of enable passwords:
• enable password stores the password in the running/startup configuration using a DES encryption
method.
• enable secret is stored in the running/startup configuration in using a stronger, MD5 encryption
method.
The E-Series EtherScale platform architecture uses MMC cards for both the internal and external Flash
memory. MMC cards support a maximum of 100 files. The E-Series TeraScale and ExaScale platforms
architecture use Compact Flash for the internal and external Flash memory. It has a space limitation but
does not limit the number of files it can contain.
Note: Using flash memory cards in the system that have not been approved by Dell Force10 can cause
unexpected system behavior, including a reboot.
50 | Getting Started
Copy Files to and from the System
The command syntax for copying files is similar to UNIX. The copy command uses the format copy
source-file-url destination-file-url.
Note: See the FTOS Command Reference for a detailed description of the copy command.
• To copy a local file to a remote system, combine the file-origin syntax for a local file location with the
file-destination syntax for a remote file location shown in Table 3-1.
• To copy a remote file to Dell Force10 system, combine the file-origin syntax for a remote file location
with the file-destination syntax for a local file location shown in Table 3-1.
Getting Started | 51
• The usbflash and rpm0usbflash commands are supported on E-Series ExaScale platform only. Refer
www.dell.com | support.dell.com
Figure 3-4 shows an example of using the copy command to save a file to an FTP server.
Local Location
Remote Location
Figure 3-5 shows an example of using the copy command to import a file to the Dell Force10 system from
an FTP server.
Remote Location
Local Location
Note: The commands in this section follow the same format as those in Copy Files to and from the
System on page 51 but use the filenames startup-configuration and running-configuration. These
commands assume that current directory is the internal flash, which is the system default.
52 | Getting Started
Task Command Syntax Command Mode
Note: The internal flash memories on the RPMs are synchronized whenever there
is a change, but only if the RPMs are running the same version of FTOS.
Note: FTOS supports IPv4 and IPv6 addressing for FTP, TFTP, and SCP (in the
hostip field).
EXEC Privilege
the external flash of an RPM copy running-config rpm{0|1}slot0://filename
Note: When copying to a server, a hostname can only be used if a DNS server is configured.
FTOS Behavior: If you create a startup-configuration on an RPM and then move the RPM to another
chassis, the startup-configuration is stored as a backup file (with the extension .bak), and a new,
empty startup-configuration file is created. To restore your original startup-configuration in this
situation, overwrite the new startup-configuration with the original one using the command copy
startup-config.bak startup-config.
View Files
File information and content can only be viewed on local file systems.
Getting Started | 53
To view a list of files on the internal or external Flash:
www.dell.com | support.dell.com
The output of the command dir also shows the read/write privileges, size (in bytes), and date of
modification for each file, as shown in Figure 3-6.
Figure 3-6. Viewing a List of Files in the Internal Flash
FTOS#dir
Directory of flash:
1 View the:
Configuration files have three commented lines at the beginning of the file, as shown in Figure 3-7, to help
you track the last time any user made a change to the file, which user made the changes, and when the file
was last saved to the startup-configuration.
54 | Getting Started
In the running-configuration file, if there is a difference between the timestamp on the “Last configuration
change,” and “Startup-config last updated,” then you have made changes that have not been saved and will
not be preserved upon a system reboot.
View information about each file system. show file-systems EXEC Privilege
The output of the command show file-systems (Figure 3-8) shows the total capacity, amount of free
memory, file structure, media type, read/write privileges for each storage device in use.
You can change the default file system so that file management commands apply to a particular device or
memory.
Getting Started | 55
In Figure 3-9, the default storage location is changed to the external Flash of the primary RPM. File
www.dell.com | support.dell.com
management commands then apply to the external Flash rather than the internal Flash.
To view the command-history trace, use the show command-history command, as shown in Figure 487.
56 | Getting Started
4
System Management
System Management is supported on platforms: ces
This chapter explains the different protocols or services used to manage the Dell Force10 system
including:
• Configure Privilege Levels on page 57
• Configure Logging on page 61
• File Transfer Services on page 68
• Terminal Lines on page 69
• Lock CONFIGURATION mode on page 72
• Recovering from a Forgotten Password on page 74
• Recovering from a Forgotten Password on S-Series on page 76
• Recovering from a Failed Start on page 77
System Management | 57
A user can access all commands at his privilege level and below.
www.dell.com | support.dell.com
Remove a command from the list of available commands in EXEC mode for a specific privilege level
using the command privilege exec from CONFIGURATION mode. In the command, specify a level greater
than the level given to a user or terminal line, followed by the first keyword of each command to be
restricted.
Move a command from EXEC Privilege to EXEC mode for a privilege level using the command privilege
exec from CONFIGURATION mode. In the command, specify the privilege level of the user or terminal
line, and specify all keywords in the command to which you want to allow access.
Allow access to CONFIGURATION mode using the command privilege exec level level configure from
CONFIGURATION mode. A user that enters CONFIGURATION mode remains at his privilege level, and
has access to only two commands, end and exit. You must individually specify each CONFIGURATION
mode command to which you want to allow access using the command privilege configure level level. In the
command, specify the privilege level of the user or terminal line, and specify all keywords in the command
to which you want to allow access.
2. Then, individually identify the INTERFACE, LINE, ROUTE-MAP or ROUTER commands to which
you want to allow access using the command privilege {interface | line | route-map | router} level level.
In the command, specify the privilege level of the user or terminal line, and specify all keywords in the
command to which you want to allow access.
The following table lists the configuration tasks you can use to customize a privilege level:
Remove a command from the list of available commands privilege exec level level CONFIGURATION
in EXEC mode. {command ||...|| command}
Move a command from EXEC Privilege to EXEC mode. privilege exec level level CONFIGURATION
{command ||...|| command}
58 | System Management
Task Command Syntax Command Mode
Allow access to INTERFACE, LINE, ROUTE-MAP, privilege configure level level CONFIGURATION
and/or ROUTER mode. Specify all keywords in the {interface | line | route-map |
command. router} {command-keyword ||...||
command-keyword}
• removes the resequence command from EXEC mode by requiring a minimum of privilege level 4,
• moves the command capture bgp-pdu max-buffer-size from EXEC Privilege to EXEC mode by,
requiring a minimum privilege level 3, which is the configured level for VTY 0,
• allows access to CONFIGURATION mode with the banner command, and
• allows access to INTERFACE and LINE modes are allowed with no commands.
System Management | 59
Figure 4-1. Create a Custom Privilege Level
www.dell.com | support.dell.com
60 | System Management
Apply a Privilege Level to a Username
To set a privilege level for a user:
Configure a privilege level for a user. username username privilege level CONFIGURATION
Configure a privilege level for a terminal line. privilege level level LINE
Note: When you assign a privilege level between 2 and 15, access to the system begins at EXEC mode,
but the prompt is hostname#, rather than hostname>.
Configure Logging
FTOS tracks changes in the system using event and error messages. By default, FTOS logs these messages
on:
• the internal buffer
• console and terminal lines, and
• any configured syslog servers
Disable Logging
To disable logging:
System Management | 61
Log Messages in the Logging Buffer
www.dell.com | support.dell.com
All error messages, except those beginning with %BOOTUP (Message 1), are log in the internal buffer.
62 | System Management
Send System Messages to a Syslog Server
Send system messages to a syslog server by specifying a server:
Specify the server to which you want to send system logging {ip-address | ipv6-address CONFIGURATION
messages. You can configure up to eight syslog servers, | hostname}
which may be IPv4 and/or IPv6 addressed.
In the lines above, local7 is the logging facility level and debugging is the severity level.
Specify the minimum severity level for logging to the logging buffered level CONFIGURATION
logging buffer.
Specify the minimum severity level for logging to the logging console level CONFIGURATION
console.
Specify the minimum severity level for logging to logging monitor level CONFIGURATION
terminal lines.
Specifying the minimum severity level for logging to a logging trap level CONFIGURATION
syslog server.
Specify the minimum severity level for logging to the logging history level CONFIGURATION
syslog history table.
System Management | 63
www.dell.com | support.dell.com
Specify the size of the logging buffer. logging buffered size CONFIGURATION
Note: When you decrease the buffer size, FTOS deletes
all messages stored in the buffer. Increasing the buffer
size does not affect messages in the buffer.
Specify the number of messages that FTOS saves to its logging history size size CONFIGURATION
logging history table.
Display the logging buffer and configuration using the show logging command from EXEC Privilege
mode, as shown in Figure 4-2.
Display the logging configuration using the show running-config logging command from EXEC
Privilege mode, as shown in Figure 4-3.
64 | System Management
Figure 4-2. show logging Command Example
FTOS#show logging
syslog logging: enabled
Console logging: level Debugging
Monitor logging: level Debugging
Buffer logging: level Debugging, 40 Messages Logged, Size (40960 bytes)
Trap logging: level Informational
%IRC-6-IRC_COMMUP: Link to peer RPM is up
%RAM-6-RAM_TASK: RPM1 is transitioning to Primary RPM.
%RPM-2-MSG:CP1 %POLLMGR-2-MMC_STATE: External flash disk missing in 'slot0:'
%CHMGR-5-CARDDETECTED: Line card 0 present
%CHMGR-5-CARDDETECTED: Line card 2 present
%CHMGR-5-CARDDETECTED: Line card 4 present
%CHMGR-5-CARDDETECTED: Line card 5 present
%CHMGR-5-CARDDETECTED: Line card 8 present
%CHMGR-5-CARDDETECTED: Line card 10 present
%CHMGR-5-CARDDETECTED: Line card 12 present
%TSM-6-SFM_DISCOVERY: Found SFM 0
%TSM-6-SFM_DISCOVERY: Found SFM 1
%TSM-6-SFM_DISCOVERY: Found SFM 2
%TSM-6-SFM_DISCOVERY: Found SFM 3
%TSM-6-SFM_DISCOVERY: Found SFM 4
%TSM-6-SFM_DISCOVERY: Found SFM 5
%TSM-6-SFM_DISCOVERY: Found SFM 6
%TSM-6-SFM_DISCOVERY: Found SFM 7
%TSM-6-SFM_SWITCHFAB_STATE: Switch Fabric: UP
%TSM-6-SFM_DISCOVERY: Found SFM 8
%TSM-6-SFM_DISCOVERY: Found 9 SFMs
%CHMGR-5-CHECKIN: Checkin from line card 5 (type EX1YB, 1 ports)
%TSM-6-PORT_CONFIG: Port link status for LC 5 => portpipe 0: OK portpipe 1: N/A
%CHMGR-5-LINECARDUP: Line card 5 is up
%CHMGR-5-CHECKIN: Checkin from line card 12 (type S12YC12, 12 ports)
%TSM-6-PORT_CONFIG: Port link status for LC 12 => portpipe 0: OK portpipe 1: N/A
%CHMGR-5-LINECARDUP: Line card 12 is up
%IFMGR-5-CSTATE_UP: changed interface Physical state to up: So 12/8
%IFMGR-5-CSTATE_DN: changed interface Physical state to down: So 12/8
System Management | 65
Configure a UNIX Logging Facility Level
www.dell.com | support.dell.com
Facility is a message tag used to describe the application or process that submitted the log message. You
can save system log messages with a UNIX system logging facility:
Display non-default settings using the show running-config logging command from EXEC mode, as
shown in Figure 4-3.
66 | System Management
Synchronize Log Messages
You can configure a terminal line to hold all logs until all command inputs and outputs are complete so that
log printing does not interfere when you are performing management tasks. Log synchronization also
filters system messages for a specific line based on severity level and limits number of messages that are
printed at once.
1 Enter the LINE mode. Configure the line {console 0 | vty number CONFIGURATION
following parameters for the virtual [end-number] | aux 0}
terminal lines:
• number range: zero (0) to 8.
• end-number range: 1 to 8.
You can configure multiple virtual
terminals at one time by entering a number
followed by an end-number.
2 Set a level and the maximum number of logging synchronous [level LINE
messages to be printed. The following severity-level | all] [limit]
parameters are optional:
• level severity-level range: 0 to 7.
Default is 2. Use the all keyword to
include all messages.
• limit range: 20 to 300. Default is 20.
Display the logging synchronous configuration using the show config command from LINE mode.
Add timestamp to syslog messages. Specify service timestamps [log | debug] [datetime CONFIGURATION
the following optional parameters: [localtime] [msec] [show-timezone] |
• datetime: You can add the keyword uptime]
localtime to include the localtime, msec, Default: uptime
and show-timezone. If you do not add
the keyword localtime, the time is UTC.
• uptime. To view time since the last boot.
Display your configuration using the command show running-config logging from EXEC Privilege
mode, as shown in Figure 4-3.
System Management | 67
File Transfer Services
www.dell.com | support.dell.com
You can configure the system to transfer files over the network using File Transfer Protocol (FTP).
Display your FTP configuration using the command show running-config ftp from EXEC Privilege mode,
as shown in Figure 4-4.
Specify the directory for users using FTP to reach the ftp-server topdir dir CONFIGURATION
system. The default is the internal flash.
Specify a user name for all FTP users and configure either ftp-server username username CONFIGURATION
a plain text or encrypted password. Configure the password [encryption-type]
following optional and required parameters: password
• username: Enter a text string
• encryption-type: Enter 0 for plain text or 7 for
encrypted text.
• password: Enter a text string.
68 | System Management
Note: You cannot use the change directory (cd) command until ftp-server topdir is configured.
Display your FTP configuration using the command show running-config ftp from EXEC Privilege mode,
as shown in Figure 4-4.
When the system will be an FTP client, configure FTP client parameters:
Display the FTP configuration using the command show running-config ftp from EXEC Privilege mode,
Figure 4-4
Terminal Lines
You can access the system remotely and restrict access to the system by creating user profiles. The terminal
lines on the system provide different means of accessing the system. The console line (console) connects
you through the Console port in the RPMs. The virtual terminal lines (VTY) connect you through Telnet to
the system. The auxiliary line (aux) connects secondary devices such as modems.
• Layer 3 ACL deny all traffic that is not explicitly permitted, but in the case of VTY lines, an ACL with
no rules does not deny any traffic.
• You cannot use show ip accounting access-list to display the contents of an ACL that is applied only to
a VTY line.
To view the configuration, enter the show config command in the LINE mode, as shown in Figure 4-5.
System Management | 69
Figure 4-5. Applying an Access List to a VTY Line
www.dell.com | support.dell.com
FTOS(config-std-nacl)#show config
!
ip access-list standard myvtyacl
seq 5 permit host 10.11.0.1
FTOS(config-std-nacl)#line vty 0
FTOS(config-line-vty)#show config
line vty 0
access-class myvtyacl
FTOS Behavior: Prior to FTOS version 7.4.2.0, in order to deny access on a VTY line, you must apply
an ACL and AAA authentication to the line. Then users are denied access only after they enter a
username and password. Beginning in FTOS version 7.4.2.0, only an ACL is required, and users are
denied access before they are prompted for a username and password.
2 Apply the method list from Step 1 to login authentication {method-list-name | CONFIGURATION
a terminal line. default}
70 | System Management
Step Task Command Syntax Command Mode
In Figure 4-6 VTY lines 0-2 use a single authentication method, line.
Set the number of minutes and seconds. exec-timeout minutes [seconds] LINE
Default: 10 minutes on console, 30 minutes on VTY.
Disable EXEC timeout by setting the timeout period to 0.
View the configuration using the command show config from LINE mode.
System Management | 71
Figure 4-7. Configuring EXEC Timeout
www.dell.com | support.dell.com
FTOS(conf)#line con 0
FTOS(config-line-console)#exec-timeout 0
FTOS(config-line-console)#show config
line console 0
exec-timeout 0 0
FTOS(config-line-console)#
Telnet to the peer RPM. You do not need to configure the management telnet-peer-rpm
EXEC Privilege
port on the peer RPM to be able to telnet to it.
Telnet to a device with an IPv4 or IPv6 address. If you do not enter an IP telnet [ipv4-address | EXEC Privilege
address, FTOS enters a Telnet dialog that prompts you for one. ipv6-address]
• Enter an IPv4 address in dotted decimal format (A.B.C.D).
• Enter an IPv6 address in the format
0000:0000:0000:0000:0000:0000:0000:0000. Elision of zeros is
supported.
Note: Telnet to link-local addresses is not supported.
72 | System Management
A two types of locks can be set: auto and manual.
• Set an auto-lock using the command configuration mode exclusive auto from CONFIGURATION
mode. When you set an auto-lock, every time a user is in CONFIGURATION mode all other users are
denied access. This means that you can exit to EXEC Privilege mode, and re-enter
CONFIGURATION mode without having to set the lock again.
• Set a manual lock using the command configure terminal lock from CONFIGURATION mode. When
you configure a manual lock, which is the default, you must enter this command time you want to enter
CONFIGURATION mode and deny access to others.
Figure 4-9. Locking CONFIGURATION mode
R1(conf)#configuration mode exclusive auto
BATMAN(conf)#exit
3d23h35m: %RPM0-P:CP %SYS-5-CONFIG_I: Configured from console by console
R1#config
! Locks configuration mode exclusively.
R1(conf)#
If another user attempts to enter CONFIGURATION mode while a lock is in place, Message 1 appears on
their terminal.
If any user is already in CONFIGURATION mode when while a lock is in place, Message 2 appears on
their terminal.
% Error: Can't lock configuration mode exclusively since the following users are currently
configuring the system:
User "admin" on line vty1 ( 10.1.1.1 )
Note: The CONFIGURATION mode lock corresponds to a VTY session, not a user. Therefore, if you
configure a lock and then exit CONFIGURATION mode, and another user enters CONFIGURATION
mode, when you attempt to re-enter CONFIGURATION mode, you are denied access even though you
are the one that configured the lock.
Note: If your session times out and you return to EXEC mode, the CONFIGURATION mode lock is
unconfigured.
System Management | 73
You can then send any user a message using the send command from EXEC Privilege mode. Alternatively
www.dell.com | support.dell.com
you can clear any line using the command clear from EXEC Privilege mode. If you clear a console session,
the user is returned to EXEC mode.
2 Power-cycle the chassis by switching off all of the power modules and then switching them back on.
74 | System Management
Step Task Command Syntax Command Mode
3 Power-cycle the chassis by switching off all of the power modules and then switching them back on.
System Management | 75
www.dell.com | support.dell.com
76 | System Management
Recovering from a Failed Start
A system that does not start correctly might be attempting to boot from a corrupted FTOS image or from a
incorrect location. To resolve the problem, you can restart the system and interrupt the boot process to
point the system to another boot location by using the boot change command, as described below. For
details on the boot change command, its supporting commands, and other commands that can help recover
from a failed start, refer to the BOOT_USER chapter in the FTOS Command Reference.
1 Power-cycle the chassis (pull the power cord and reinsert it).
2 Abort bootup by sending the break Ctrl-Shift 6 (Ctrl-^)—C-Series and E-Series (during bootup)
signal when prompted. (On the S-Series, hit any key)
3 Tell the system where to access the boot change {primary | secondary | default} BOOT_USER
FTOS image used to boot the system: After entering the keywords and desired option,
• Enter primary to configure the boot press Enter. The software prompts you to enter
parameters used in the first attempt the following:
to boot the system. • boot device (ftp, tftp, flash, slot0)
• Enter secondary for when the Note: S-Series can only use a TFTP location.
primary operating system boot • image file name
selection is not available.
• IP address of the server with the image
• Enter default to configure boot
parameters used if the secondary • username and password (only for FTP)
operating system boot parameter
selection is not available. The
default location should always be
the internal flash device (flash:),
and a verified image should be
stored there.
4 On S-Series systems only, assign a port interface management ethernet port portID BOOT_USER
to be the Management Ethernet
interface.
System Management | 77
Very similar to the options of the boot change command, the boot system command is available in
www.dell.com | support.dell.com
CONFIGURATION mode on the C-Series and E-Series to set the boot parameters that, when saved to the
startup configuration file, are stored in NVRAM and are then used routinely:
Configure the system to routinely boot from the boot system {rpm0 | rpm1} (default | CONFIGURATION
designated location. primary | secondary} file-url
After entering rpm0 or rpm1, enter one of the three For file-url, to boot from a file:
keywords and then the file-url. • on the internal Flash, enter flash://
You can use the command for each of the followed by the filename.
combinations of RPM and option. • on an FTP server, enter ftp://
user:password@hostip/filepath
• on the external Flash, enter slot0://
followed by the filename.
• on a TFTP server, enter tftp://hostip/
filepath
Also, because the C-Series and E-Series can boot from an external flash, you can recover from a failed
boot image on the flash by simply fixing that source. For details on boot code and FTOS setup, see the
FTOS Release Notes for the specific FTOS versions that you want to use.
The network boot facility has only become available on the S-Series with FTOS 7.8.1.0 and its
accompanying boot code. In addition to installing FTOS 7.8.1.0, you must separately install that new boot
code. For installation details, see the S-Series and FTOS Release Notes for Version 7.8.1.0.
78 | System Management
5
802.1ag
802.1ag is available only on platform: s
Ethernet Operations, Administration, and Maintenance (OAM) is a set of tools used to install, monitor,
troubleshoot and manage Ethernet infrastructure deployments. Ethernet OAM consists of three main areas:
Ethernet CFM
Ethernet CFM is an end-to-end, per-service-instance Ethernet OAM scheme which enables: proactive
connectivity monitoring, fault verification, and fault isolation.
The service-instance in the OAM for Metro/Carrier Ethernet context is a VLAN. This service is sold to an
end-customer by a network service provider. Typically the service provider contracts with multiple
network operators to provide end-to-end service between customers. For end-to-end service between
customer switches, connectivity must be present across the service provider through multiple network
operators.
Layer 2 Ethernet networks usually cannot be managed with IP tools such as ICMP Ping and IP Traceroute.
Traditional IP tools often fail because:
• there are complex interactions between various Layer 2 and Layer 3 protocols such as STP, LAG,
VRRP and ECMP configurations.
• Ping and traceroute are not designed to verify data connectivity in the network and within each node in
the network (such as in the switching fabric and hardware forwarding tables).
• when networks are built from different operational domains, access controls impose restrictions that
cannot be overcome at the IP level, resulting in poor fault visibility. There is a need for hierarchical
domains that can be monitored and maintained independently by each provider or operator.
• routing protocols choose a subset of the total network topology for forwarding, making it hard to detect
faults in links and nodes that are not included in the active routing topology. This is made more
complex when using some form of Traffic Engineering (TE) based routing.
• network and element discovery and cataloging is not clearly defined using IP troubleshooting tools.
802.1ag | 79
There is a need for Layer 2 equivalents to manage and troubleshoot native Layer 2 Ethernet networks. With
www.dell.com | support.dell.com
these tools, you can identify, isolate, and repair faults quickly and easily, which reduces operational cost of
running the network. OAM also increases availability and reduces mean time to recovery, which allows for
tighter service level agreements, resulting in increased revenue for the service provider.
In addition to providing end-to-end OAM in native Layer 2 Ethernet Service Provider/Metro networks,
you can also use CFM to manage and troubleshoot any Layer 2 network including enterprise, datacenter,
and cluster networks.
Maintenance Domains
Connectivity Fault Management (CFM) divides a network into hierarchical maintenance domains, as
shown in Figure 5-1.
A CFM maintenance domain is a management space on a network that is owned and operated by a single
management entity. The network administrator assigns a unique maintenance level (0 to 7) to each domain
to define the hierarchical relationship between domains. Domains can touch or nest but cannot overlap or
intersect as that would require management by multiple entities.
Maintenance Points
Domains are comprised of logical entities called Maintenance Points. A maintenance point is an interface
demarcation that confines CFM frames to a domain. There are two types of maintenance points:
• Maintenance End Points (MEPs): a logical entity that marks the end-point of a domain
• Maintenance Intermediate Points (MIPs): a logical entity configured at a port of a switch that is an
intermediate point of a Maintenance Entity (ME). An ME is a point-to-point relationship between two
MEPs within a single domain. MIPs are internal to a domain, not at the boundary, and respond to CFM
only when triggered by linktrace and loopback messages. MIPs can be configured to snoop Continuity
Check Messages (CCMs) to build a MIP CCM database.
80 | 802.1ag
These roles define the relationships between all devices so that each device can monitor the layers under its
responsibility. Maintenance points drop all lower-level frames and forward all higher-level frames.
MEP MIP
• Up-MEP: monitors the forwarding path internal to an bridge on the customer or provider edge; on
Dell Force10 systems the internal forwarding path is effectively the switch fabric and forwarding
engine.
• Down-MEP: monitors the forwarding path external another bridge.
Configure Up- MEPs on ingress ports, ports that send traffic towards the bridge relay. Configure
Down-MEPs on egress ports, ports that send traffic away from the bridge relay.
Up-MEP
Down-MEP
802.1ag | 81
Implementation Information
www.dell.com | support.dell.com
• Since the S-Series has a single MAC address for all physical/LAG interfaces, only one MEP is allowed
per MA (per VLAN or per MD level).
Configure CFM
Configuring CFM is a five-step process:
1. Configure the ecfmacl CAM region using the cam-acl command. See Configure Ingress Layer 2 ACL
Sub-partitions.
2. Enable Ethernet CFM. See page 83.
3. Create a Maintenance Domain. See page 83.
4. Create a Maintenance Association. See page 84.
5. Create Maintenance Points. See page 84.
6. Use CFM tools:
a Continuity Check Messages on page 87
b Loopback Message and Response on page 88
c Linktrace Message and Response on page 88
82 | 802.1ag
Enable Ethernet CFM
Task Command Syntax Command Mode
Disable Ethernet CFM without stopping the CFM disable ETHERNET CFM
process.
2 Display maintenance domain information. show ethernet cfm domain [name | EXEC Privilege
brief]
802.1ag | 83
Create a Maintenance Association
www.dell.com | support.dell.com
• Maintenance End Points (MEPs): a logical entity that marks the end-point of a domain
• Maintenance Intermediate Points (MIPs): a logical entity configured at a port of a switch that
constitutes intermediate points of an Maintenance Entity (ME). An ME is a point-to-point relationship
between two MEPs within a single domain.
These roles define the relationships between all devices so that each device can monitor the layers under its
responsibility.
• Up-MEP: monitors the forwarding path internal to an bridge on the customer or provider edge; on
Dell Force10 systems the internal forwarding path is effectively the switch fabric and forwarding
engine.
• Down-MEP: monitors the forwarding path external another bridge.
Configure Up- MEPs on ingress ports, ports that send traffic towards the bridge relay. Configure
Down-MEPs on egress ports, ports that send traffic away from the bridge relay.
Create an MEP. ethernet cfm mep {up-mep | down-mep} domain {name | INTERFACE
level } ma-name name mepid mep-id
Range: 1-8191
Display configured MEPs and show ethernet cfm maintenance-points local [mep | mip] EXEC Privilege
MIPs.
84 | 802.1ag
Task Command Syntax Command Mode
Create an MIP. ethernet cfm mip domain {name | level} ma-name name INTERFACE
Display configured MEPs and show ethernet cfm maintenance-points local [mep | mip] EXEC Privilege
MIPs.
MP Databases
CFM maintains two MP databases:
• MEP Database (MEP-DB): Every MEP must maintain a database of all other MEPs in the MA that
have announced their presence via CCM.
802.1ag | 85
• MIP Database (MIP-DB): Every MIP must maintain a database of all other MEPs in the MA that
www.dell.com | support.dell.com
Display the MEP Database. show ethernet cfm maintenance-points remote detail [active EXEC Privilege
| domain {level | name} | expired | waiting]
Display the MIP Database. show ethernet cfm mipdb EXEC Privilege
MP Database Persistence
Set the amount of time that data database hold-time minutes ECFM DOMAIN
from a missing MEP is kept in Default: 100 minutes
the Continuity Check Database. Range: 100-65535 minutes
86 | 802.1ag
Continuity Check Messages
Continuity Check Messages (CCM) are periodic hellos used to:
Continuity Check Messages (CCM) are multicast Ethernet frames sent at regular intervals from each MEP.
They have a destination address based on the MD level (01:80:C2:00:00:3X where X is the MD level of
the transmitting MEP from 0 to 7). All MEPs must listen to these multicast MAC addresses and process
these messages. MIPs may optionally processes the CCM messages originated by MEPs and construct a
MIP CCM database.
MEPs and MIPs filter CCMs from higher and lower domain levels as described in Table 5-1.
All the remote MEPs in the maintenance domain are defined on each MEP. Each MEP then expects a
periodic CCM from the configured list of MEPs. A connectivity failure is then defined as:
1. Loss of 3 consecutive CCMs from any of the remote MEP, which indicates a network failure
2. Reception of a CCM with an incorrect CCM transmission interval, which indicates a configuration
error.
3. Reception of CCM with an incorrect MEP ID or MAID, which indicates a configuration or
cross-connect error. This could happen when different VLANs are cross-connected due to a
configuration error.
4. Reception of a CCM with an MD level lower than that of the receiving MEP, which indicates a
configuration or cross-connect error.
5. Reception of a CCM containing a port status/interface status TLV, which indicates a failed bridge or
aggregated port.
The Continuity Check protocol sends fault notifications (Syslogs, and SNMP traps if enabled) whenever
any of the above errors are encountered.
802.1ag | 87
Enable CCM
www.dell.com | support.dell.com
2 Configure the transmit interval (mandatory). ccm transmit-interval seconds ECFM DOMAIN
The interval specified applies to all MEPs in Default: 10 seconds
the domain.
Enable Cross-checking
Task Command Syntax Command Mode
Start the cross-check operation for an MEP. mep cross-check mep-id ETHERNET CFM
Configure the amount of time the system waits for a mep cross-check start-delay ETHERNET CFM
remote MEP to come up before the cross-check operation number
is started.
Send a Loopback message. ping ethernet domain name ma-name ma-name remote EXEC Privilege
{mep-id | mac-addr mac-address} source {mep-id | port
interface}
88 | 802.1ag
Figure 5-4. Linktrace Message and Response
MPLS Core
Lin
ktra ge
c e m M essa
L i n k t ra ce R e s p o n s e
Link trace messages carry a unicast target address (the MAC address of an MIP or MEP) inside a multicast
frame. The destination group address is based on the MD level of the transmitting MEP
(01:80:C2:00:00:3[8 to F]). The MPs on the path to the target MAC address reply to the LTM with an LTR,
and relays the LTM towards the target MAC until the target MAC is reached or TTL equals 0.
Send a Linktrace message. Since the traceroute ethernet domain EXEC Privilege
LTM is a Multicast message sent to the
entire ME, there is no need to specify a
destination.
Set the amount of time a trace result is cached. traceroute cache hold-time minutes ETHERNET CFM
Default: 100 minutes
Range: 10-65535 minutes
Set the size of the Link Trace Cache. traceroute cache size entries ETHERNET CFM
Default: 100
Range: 1 - 4095 entries
Display the Link Trace Cache. show ethernet cfm traceroute-cache EXEC Privilege
802.1ag | 89
www.dell.com | support.dell.com
------------------------------------------------------------------------------
Hops Host IngressMAC Ingr Action Relay Action
Next Host Egress MAC Egress Action FWD Status
------------------------------------------------------------------------------
Delete all Link Trace Cache entries. clear ethernet cfm traceroute-cache EXEC Privilege
Enable SNMP trap messages for snmp-server enable traps ecfm CONFIGURATION
Ethernet CFM.
A Trap is sent only when one of the five highest priority defects occur, as shown in Table 5-2.
90 | 802.1ag
Three values are given within the trap messages: MD Index, MA Index, and MPID. You can reference
these values against the output of show ethernet cfm domain and show ethernet cfm maintenance-points
local mep.
1 test 0 1s enabled
Display MEP CCM statistics. show ethernet cfm statistics [domain {name | level} EXEC Privilege
vlan-id vlan-id mpid mpid
CCMs:
Transmitted: 1503 RcvdSeqErrors: 0
LTRs:
Unexpected Rcvd: 0
LBRs:
Received: 0 Rcvd Out Of Order: 0
Received Bad MSDU: 0
Transmitted: 0
802.1ag | 91
www.dell.com | support.dell.com
Display CFM statistics by port. show ethernet cfm port-statistics [interface] EXEC Privilege
RX Statistics
=============
Total CFM Pkts 75394 CCM Pkts 75394
LBM Pkts 0 LTM Pkts 0
LBR Pkts 0 LTR Pkts 0
Bad CFM Pkts 0 CFM Pkts Discarded 0
CFM Pkts forwarded 102417
TX Statistics
=============
Total CFM Pkts 10303 CCM Pkts 0
LBM Pkts 0 LTM Pkts 3
LBR Pkts 0 LTR Pkts 0
92 | 802.1ag
6
802.3ah
802.3ah is available only on platform: s
A metropolitan area network (MAN) is a set of LANs, geographically separated but managed by a single
entity. If the distance is large—across a city, for example—connectivity between LANs is managed by a
service provider. While LANs use Ethernet, service providers networks use an array of protocols (PPP and
ATM), and a variety access technologies. Implementing Ethernet from end to end, across the service
provider network, simplifies design and management, increases scalability and bandwidth, and reduces
costs.
Ethernet in a service provider environment introduces the concept of Carrier-class Ethernet and requires
some basic management and diagnostic tools. Ethernet Operations, Administration, and Maintenance
(OAM) is that toolset, which can be used to install, monitor, troubleshoot, and manage Ethernet
infrastructure deployments. It consists of three main areas:
Link Layer OAM performs four primary operations for the purposes of link status, performance
monitoring, and fault detection and isolation for Ethernet in the First Mile:
• OAM Discovery—detects whether the remote system is OAM capable, and negotiates OAM
parameters.
• Link Event Monitoring—defines a set of events that may impact link operation, and monitors the link
for those events.
802.3ah | 93
• Remote Loopback—directs the remote system to reflects back frames that the local system transmits
www.dell.com | support.dell.com
Destination MAC Source MAC Length/Type Sub-type Flags Code Payload Padding FCS
(01-80-c2-00-00-02) (0x8809) (0x03) (TLVs)
• Information—carries state information and Local Information and/or Remote Information TLVs.
Information OAMPDUs are used in discovery, and as keepalives.
• Local Information TLVs—indicates support for variable retrieval, link performance events, and
remote loopback, unidirectional support, and OAM mode
• Remote Information TLVs—a copy of the peer’s Local Information TLV.
• Event Notification—carries TLVs for each concurrent link fault.
• Variable Request—carries MIB object descriptors for which the remote peer should return values.
• Variable Response—carries the requested MIB object values.
• Loopback Control—carries the loopback control command (enable and disable).
• Organization Specific—contains and OUI followed by data, the format and function of which is
defined by the organization.
OAMPDU Flags
1-bit flags are used it indicate OAM state and link state. During discovery, flags 3-6 are used to indicate the
state of peership establishment. Flags 0-2 are used to indicate a local critical link event to the remote peer.
94 | 802.3ah
Link Layer OAM Operational Modes
When participating in EFM OAM, system may operate in active or passive mode.
• Active mode—Active mode systems initiate discovery. Once the Discovery process completes, they
can send any OAMPDU while connected to a peer in Active mode, and a subset of OAMPDUs if the
peer is in Passive mode (see Table 6-1).
• Passive mode—Passive mode systems wait for an active mode system to initiate discovery, and do not
send Variable Request or Loopback Control OAMPDUs.
Taken from IEEE 802.3ah, Table 6-1 summarizes the permitted actions in each role.
1. If the link is not in Fault state, Active mode systems send Information OAMPDUs that contain (only)
the Local Information TLV.
2. Once a system receives an Information OAMPDU, it responds with an Information OAMPDU that
contains the Local and Remote Information TLV. Negotiation is complete when both systems have
received their peer’s information and are satisfied with it; to be satisfied, both peers on the link must be
have link performance event monitoring enabled.
3. When negotiation is complete, both peers may send any type of OAMPDU.
802.3ah | 95
Link Layer OAM Events
www.dell.com | support.dell.com
Link Layer OAM defines a set of events that may impact link operation, and monitors the link for those
events. If an event occurs, the detecting system notifies its peer. There are two types of events:
• Critical Link Events—There are three critical events; each has an associated flag which can be set in
the OAMPDU when the event occurs. Critical link events are communicated to the peer using Remote
Failure Indication.
• Link Fault—A fault occurred in the receive direction of the local peer.
• Dying Gasp—An unrecoverable local failure condition occurred. Dying Gasp notification is not
supported on S-Series.
• Critical Event—An unspecified critical event occurred. Critical Event notification is not
supported on S-Series.
• Link Performance Events—Link events are either symbol errors or frame errors, and are
communicated using Link Event TLVs.
• Symbol Errors—a symbol is an (electrical or optical) pulse on the physical medium that
represents one or more bits. A symbol error occurs when a symbol degrades in transit so that the
receiver is not able to decode it. Gigabit and 10-Gigabit Ethernet have and expect symbol rate, also
called Baud.
• Frame Errors—frame errors are frames with a bad CRC.
Remote Loopback
An active-mode device can place a passive peer into loopback mode by sending a Loopback Control
OAMPDU. When in loopback mode:
• the remote peer returns unaltered all non-OAMPDU frames sent by the local peer, and
• all outbound data frames are discarded (control frames are still forwarded).
Implementation Information
• Critical Link Events Dying Gasp and Critical Event are not supported.
• MIB retrieval is not supported.
• Both peers on a link must have Link Performance Monitoring Enabled, or else discovery does not
complete.
• Control frames are still forwarded when an interface is in loopback mode.
96 | 802.3ah
Configure Link Layer OAM
Configuring Link Layer OAM is a two-step process:
Display the OAM discovery status. show ethernet oam discovery interface interface EXEC Privilege
802.3ah | 97
www.dell.com | support.dell.com
Local client
__________
Administrative configurations:
Mode:active
Unidirection:not supported
Link monitor:supported (on)
Remote loopback:not supported
MIB retrieval:not supported
Mtu size:1500
Operational status:
Port status:operational
Loopback status:no loopback
PDU permission:any
PDU revision:1
Remote client
___________
MAC address:0030.88fe.87de
Vendor(OUI):0x00 0x00 0x0C
Administrative configurations:
Mode:active
Unidirection:not supported
Link monitor:supported
Remote loopback:not supported
MIB retrieval:not supported
Mtu size:1500
Display Link Layer OAM sessions. show ethernet oam summary EXEC Privilege
FTOS# show ethernet oam summary
Output format :
LocalRemote
InterfaceMAC AddressOUIModeCapability
Gi6/1/10023.84ac.b8000000DactiveL R
98 | 802.3ah
Adjust the OAMPDU Transmission Parameters
Task Command Syntax Command Mode
Specify a the maximum or minimum ethernet oam [max-rate value | min-rate value] INTERFACE
number of OAMPDUs to be sent per Range: 1-10
second. Default: 10
Set the transmission mode to active or ethernet oam mode {active | passive} INTERFACE
passive. Default: Active
Specify the amount of time that the ethernet oam timeout value INTERFACE
system waits to receive an OAMPDU Range: 2-30 seconds
from a peer before considering it Default: 5 seconds
non-operational.
There is a high and low threshold for each pre-defined error; an event occurs when any threshold is
exceeded. FTOS periodically polls hardware registers for the current frame and symbol error count. If an
interface exceeds a threshold, a notification is sent to the peer and the interface is placed in error-disabled
state.
Enable (or disable) support for Link ethernet oam link-monitor supported INTERFACE
Performance Monitoring on an interface. no ethernet oam link-monitor supported
Default: Enabled
802.3ah | 99
Set Threshold Values
www.dell.com | support.dell.com
• Symbol Errors—a symbol is an (electrical or optical) pulse on the physical medium that represents
one or more bits. A symbol error occurs when a symbol degrades in transit so that the receiver is not
able to decode it. Gigabit and 10-Gigabit Ethernet have and expect symbol rate, also called Baud.
• Frame Errors—frame errors are frames with a bad CRC.
• Symbol Errors per Second—the number of symbol errors during a specified period exceeds a
threshold.
• Frame Errors per Second—the number of frame errors during a specified period exceeds a threshold.
• Frame Errors per Frame Period—the number of frame errors within the last N frames exceeds a
threshold.
• Frame Error Seconds per Time Period—an error second is a 1-second period with at least one
frame error. The Frame Error Seconds per Time Period error occurs when the number of error seconds
within the last M seconds exceeds a threshold.
Specify the high threshold value for ethernet oam link-monitor symbol-period threshold INTERFACE
symbol errors, or disable the high high {symbols | none}
threshold. Range: 1-65535
Default: None
Specify the low threshold for symbol ethernet oam link-monitor symbol-period threshold INTERFACE
errors. low symbols
Range: 0-65535
Default: 10
Specify the time period for symbol ethernet oam link-monitor symbol-period window INTERFACE
errors per second condition. symbols
Range: 1-65535 (times 1,000,000 symbols)
Default: 10 (10,000,000 symbols)
100 | 802.3ah
Frame Errors per Second
Specify the high threshold value for ethernet oam link-monitor frame threshold high INTERFACE
frame errors, or disable the high {frames | none}
threshold. Range: 1-65535
Default: None
Specify the low threshold for frame ethernet oam link-monitor frame threshold low frames INTERFACE
errors. Range: 0-65535
Default: 1
Specify the time period for frame ethernet oam link-monitor frame window milliseconds INTERFACE
errors per second condition. Range: 10-600 milliseconds
Default: 100 milliseconds
Specify the high threshold value for ethernet oam link-monitor frame-period threshold INTERFACE
frame errors per frame period, or high {frames | none}
disable the high threshold. Range: 1-65535
Default: None
Specify the low threshold for frame ethernet oam link-monitor frame-period threshold low INTERFACE
errors per frame period. frames
Range: 0-65535
Default: 1
Specify the frame period for frame ethernet oam link-monitor frame-period window INTERFACE
errors per frame period condition. milliseconds
Range: 1-65535 (times 10,000 frames)
Default: 1000 (10 million frames)
Specify the high threshold value for ethernet oam link-monitor frame-seconds threshold INTERFACE
frame error seconds per time period, or high {milliseconds | none}
disable the high threshold. Range: 1-900
Default: None
Specify the low threshold for frame ethernet oam link-monitor frame-seconds threshold INTERFACE
error seconds per time period. low milliseconds
Range: 1-900
Default: 1
802.3ah | 101
www.dell.com | support.dell.com
Specify the time period for error ethernet oam link-monitor frame-seconds window INTERFACE
second per time period condition. milliseconds
Range: 100-900, in multiples of 100
Default: 1000 milliseconds
Disable an interface when the high ethernet oam link-monitor high-threshold action INTERFACE
threshold is exceeded for any of the error-disable-interface
monitored error conditions. Default: Enabled
• Link Fault—A fault occurred in the receive direction of the local peer.
• Dying Gasp—An unrecoverable local failure condition occurred. Dying Gasp notification is not
supported on S-Series.
• Critical Event—An unspecified critical event occurred. Critical Event notification is not supported on
S-Series.
When a link fault, dying gasp, or critical event occurs, the system sets an associated bit in subsequent
OAMPDUs until the error is resolved (polling occurs every 100ms), and you can configure the system to
take an additional action.
102 | 802.3ah
Remote Loopback
An active-mode device can place a passive peer into loopback mode by sending a Loopback Control
OAMPDU. When in loopback mode:
• the remote peer returns unaltered all non-OAMPDU frames sent by the local peer, and
• all outbound data frames are discarded.
Note: Control traffic egresses from loopback initiator and from interface in loopback mode. You must
explicitly disable L2/L3 protocols to stop control traffic.
Enable support for the OAM loopback ethernet oam remote-loopback supported INTERFACE
capability on an interface so that it can Default: Enabled
exchange information with a remote peer.
Configure the maximum amount of time ethernet oam remote-loopback timeout seconds INTERFACE
the local peer waits for a frame to be
returned before considering the remote
peer to be non-operational.
Start or stop loopback operation on a local ethernet oam remote-loopback {start | stop} EXEC Privilege
interface with a remote peer. interface interface
802.3ah | 103
Display Link Layer OAM Configuration and Statistics
www.dell.com | support.dell.com
Display Link Layer OAM status per show ethernet oam status interface interface EXEC Privilege
interface.
FTOS# show ethernet oam status interface <interface-name>
Output Format :
<interface-name>
General
______
Mode:active
PDU max rate:10 packets per second
PDU min rate:1 packet per second
Link timeout:5 seconds
High threshold action:no action
Link Monitoring
____________
Status supported (on)
Display Link Layer OAM statistics per show ethernet oam statistics interface interface EXEC Privilege
interface.
104 | 802.3ah
Task Command Syntax Command Mode
<interface-name>
Counters:
_________
Information OAMPDU Tx: 3439489
Information OAMPDU Rx: 9489
Unique Event Notification OAMPDU Tx: 0
Unique Event Notification OAMPDU x: 0
Duplicate Event Notification OAMPDU Tx: 0
Duplicate Event Notification OAMPDU Rx: 0
Loopback Control OAMPDU Tx: 0
Loopback Control OAMPDU Rx: 2
Variable Request OAMPDU Tx: 0
Variable Request OAMPDU Rx: 0
Variable Response OAMPDU Tx: 0
Variable Response OAMPDU Rx: 0
Force10 OAMPDU Tx:: 10
Force10 OAMPDU Rx:: 21
Unsupported OAMPDU Tx:: 0
Unsupported OAMPDU Rx:0
Frame Lost due to OAM:0
Local Faults:
0 Link Fault Records
0 Dying Gasp Records
Total dying Gasps:: 2
Time Stamp: 00:40:23
Total dying Gasps:: 1
Time Stamp: 00:41:23
0 Critical Event Records
Remote Faults:
_________
0 Link Fault Records
0 Dying Gasp Records
0 Critical Event Records
Clear Link Layer OAM statistics. clear ethernet oam statistics interface interface EXEC Privilege
802.3ah | 105
Manage Link Layer OAM
www.dell.com | support.dell.com
You must enable MIB retrieval support and the MIB retrieval function.
Enable MIB retrieval support and/or ethernet oam mib-retrieval {supported | on} INTERFACE
the MIB retrieval function. Default: Disabled
Configure the size of the OAM event ethernet oam event-log size entries CONFIGURATION
log. Range: 0 to 200. Default: 50.
106 | 802.3ah
7
802.1X
802.1X is supported on platforms: ces
This chapter has the following sections:
Protocol Overview
802.1X is a method of port security. A device connected to a port that is enabled with 802.1X is disallowed
from sending or receiving traffic on the network until its identity can be verified (through a username and
password, for example); all ingress frames, except those used for 802.1X authentication, are dropped. This
feature is named for its IEEE specification.
802.1X | 107
802.1X employs Extensible Authentication Protocol (EAP)* to transfer a device’s credentials to an
www.dell.com | support.dell.com
authentication server (typically RADIUS) via a mandatory intermediary network access device, in this
case, a Dell Force10 switch. The network access device mediates all communication between the end-user
device and the authentication server so that the network remains secure. The network access device uses
EAP over Ethernet (EAPOL) to communicate with the end-user device and EAP over RADIUS to
communicate with the server.
End-user Device Force10 switch RADIUS Server
Figure 7-1 and Figure show how EAP frames are encapsulated in Ethernet and Radius frames.
Note: FTOS supports 802.1X with EAP-MD5, EAP-OTP, EAP-TLS, EAP-TTLS, PEAPv0, PEAPv1, and
*
Figure 7-1.
Preamble
MS-CHAPv2 with PEAP.
Range: 1-4
Codes: 1: Request Code ID Length EAP-Method Frame
2: Response (0-4) (Seq Number)
3: Success
4: Failure
Range: 1-255
Codes: 1: Identity
2: Notification EAP-Method Length EAP-Method Data
3: NAK Code (Supplicant Requested Credentials)
4: MD-5 Challenge (0-255)
5: One-Time Challenge
6: Generic Token Card
• The device attempting to access the network is the supplicant. The supplicant is not allowed to
communicate on the network until the port is authorized by the authenticator. It can only communicate
with the authenticator in response to 802.1X requests.
• The device with which the supplicant communicates is the authenticator. The authenicator is the gate
keeper of the network. It translates and forwards requests and responses between the authentication
server and the supplicant. The authenticator also changes the status of the port based on the results of
the authentication process. The Dell Force10 switch is the authenticator.
108 | 802.1X
• The authentication-server selects the authentication method, verifies the information provided by the
supplicant, and grants it network access privileges.
• Ports are in an unauthorized state by default. In this state, non-802.1X traffic cannot be forwarded in
or out of the port.
• The authenticator changes the port state to authorized if the server can authenticate the supplicant. In
this state, network traffic can be forwarded normally.
Note: The Dell Force10 switches place 802.1X-enabled ports in the unauthorized state by default.
1. When the authenticator senses a link state change, it requests that the supplicant identify itself using an
EAP Identity Request Frame.
2. The supplicant responds with its identity in an EAP Response Identity frame.
3. The authenticator decapsulates the EAP Response from the EAPOL frame, encapsulates it in a
RADIUS Access-Request frame, and forwards the frame to the authentication server.
4. The authentication server replies with an Access-Challenge. The Access-Challenge is request that the
supplicant prove that it is who it claims to be, using a specified method (an EAP-Method). The
challenge is translated and forwarded to the supplicant by the authenticator.
5. The supplicant can negotiate the authentication method, but if it is acceptable, the supplicant provides
the requested challenge information in an EAP Response, which is translated and forwarded to the
authentication server as another Access-Request.
6. If the identity information provided by the supplicant is valid, the authentication server sends an
Access-Accept frame in which network privileges are specified. The authenticator changes the port
state to authorized, and forwards an EAP Success frame. If the identity information is invalid, the
server sends and Access-Reject frame. The port state remains unauthorized, and the authenticator
forwards EAP Failure frame.
802.1X | 109
Figure 7-2. 802.1X Authentication Process
www.dell.com | support.dell.com
Request Identity
Response Identity
Access Request
Access Challenge
EAP Request
EAP Reponse
Access Request
Range: 1-4
Codes: 1: Access-Request
2: Access-Accept Type Length EAP-Method Data
3: Access-Reject (79) (Supplicant Requested Credentials)
11: Access-Challenge
110 | 802.1X
RADIUS Attributes for 802.1 Support
Dell Force10 systems includes the following RADIUS attributes in all 802.1X-triggered Access-Request
messages:
Configuring 802.1X
Configuring 802.1X on a port is a two-step process:
802.1X | 111
Important Points to Remember
www.dell.com | support.dell.com
• FTOS supports 802.1X with EAP-MD5, EAP-OTP, EAP-TLS, EAP-TTLS, PEAPv0, PEAPv1, and
MS-CHAPv2 with PEAP.
• All platforms support only RADIUS as the authentication server.
• On E-Series ExaScale, if the primary RADIUS server becomes unresponsive, the authenticator begins
using a secondary RADIUS server, if configured.
• 802.1X is not supported on port-channels or port-channel members.
• On the C-series and S-Series platforms:
• Traffic may be forwarded on an 802.1X-enabled port that is in an unauthorized state and
interoperates with a device through a MAC-authentication bypass (MAB) or the guest VLAN.
802.1X authentication on the port returns to normal operation only after a port flap or if you
disable and then re-enable 802.1X authentication on the port.
• If you enable multi-supplicant authorization on a port, configure a maximum number of
supplicants that can be authenticated, and enable periodic re-authentication, if some of the
supplicants fail re-authentication, these unauthorized supplicants are still counted in the total
number of supplicants that can access the port.
• Traffic may be transmitted on an 802.1X-enabled port before the port changes to an authorized
state.
• A MAB-authenticated port becomes unauthorized after an RPM failover.
Enabling 802.1X
802.1X must be enabled globally and at interface level.
2/1 2/2
112 | 802.1X
To enable 802.1X:
Verify that 802.1X is enabled globally and at interface level using the command show running-config | find
dot1x from EXEC Privilege mode, as shown in Figure 7-5.
View 802.1X configuration information for an interface using the command show dot1x interface, as
shown in Figure 7-6.
802.1X | 113
Configuring Request Identity Re-transmissions
www.dell.com | support.dell.com
If the authenticator sends a Request Identity frame, but the supplicant does not respond, the authenticator
waits 30 seconds and then re-transmits the frame. The amount of time that the authenticator waits before
re-transmitting and the maximum number of times that the authenticator re-transmits are configurable.
Note: There are several reasons why the supplicant might fail to respond; the supplicant might have been
booting when the request arrived, there might be a physical layer problem, or the supplicant might not be
802.1x capable.
To configure the amount of time that the authenticator waits before re-transmitting an EAP Request
Identity frame:
1 Configure the amount of time that the authenticator dot1x tx-period number INTERFACE
waits before re-transmitting an EAP Request Identity Range: 1-31536000 (1 year)
frame. Default: 30
1 Configure a maximum number of times that a Request dot1x max-eap-req number INTERFACE
Identity frame can be re-transmitted by the Range: 1-10
authenticator. Default: 2
Figure 7-7 shows configuration information for a port for which the authenticator re-transmits an EAP
Request Identity frame after 90 seconds and re-transmits a maximum of 10 times.
Note: The quiet period (dot1x quiet-period) is an transmit interval for after a failed authentication where as
the Request Identity Re-transmit interval (dot1x tx-period) is for an unresponsive supplicant.
1 Configure the amount of time that the authenticator dot1x quiet-period seconds INTERFACE
waits to re-transmit a Request Identity frame after a Range: 1-65535
failed authentication.
Default: 60
114 | 802.1X
Figure 7-7 shows configuration information for a port for which the authenticator re-transmits an EAP
Request Identity frame:
• Auto is an unauthorized state by default. A device connected to this port is this state is subjected to the
authentication process. If the process is successful, the port is authorized and the connected device can
communicate on the network. All ports are placed in the auto state by default.
802.1X | 115
To place a port in one of these three states:
www.dell.com | support.dell.com
Figure 7-8 shows configuration information for a port that has been force-authorized.
Re-Authenticating a Port
Periodic Re-Authentication
After the supplicant has been authenticated and the port has been authorized, the authenticator can be
configured to re-authenticate the supplicant periodically. If re-authentication is enabled, the supplicant is
required to re-authenticate every 3600 seconds, but this interval can be configured. A maximum number of
re-authentications can be configured as well.
116 | 802.1X
To configure a maximum number of re-authentications:
Configuring Timeouts
If the supplicant or the authentication server is unresponsive, the authenticator terminates the
authentication process after 30 seconds by default. The amount of time that the authenticator waits for a
response can be configured. The timeout for the supplicant applies to all EAP frames except for Request
Identity frames which are governed by the tx-period and max-eap-req configurations.
To terminate the authentication process due to an unresponsive supplicant:
802.1X | 117
To terminate the authentication process due to an unresponsive authentication server:
www.dell.com | support.dell.com
Note: When you configure the dot1x server-timeout value, you must take into account the communication medium used to
communicate with an authentication server and the number of RADIUS servers configured. Ideally, the dot1x
server-timeout value (in seconds) is based on the configured RADIUS-server timeout and retransmit values and calculated
according to the following formula:
dot1x server-timeout seconds > (radius-server retransmit seconds + 1) * radius-server timeout seconds
Where the default values are as follows: dot1x server-timeout (30 seconds), radius-server retransmit
(3 seconds), and radius-server timeout (5 seconds).
For example:
FTOS(conf)#radius-server host 10.11.197.105 timeout 6
FTOS(conf)#radius-server host 10.11.197.105 retransmit 4
FTOS(conf)#interface gigabitethernet 2/23
FTOS(conf-if-gi-2/23)#dot1x server-timeout 40
Figure 7-10 shows configuration information for a port for which the authenticator terminates the
authentication process for an unresponsive supplicant or server after 15 seconds.
Figure 7-10. Configuring a Timeout
FTOS(conf-if-gi-2/1)#dot1x port-control force-authorized
FTOS(conf-if-gi-2/1)#do show dot1x interface gigabitethernet 2/1
118 | 802.1X
Dynamic VLAN Assignment with Port Authentication
Dynamic VLAN Assignment with Port Authentication is supported on platforms: c s et
FTOS supports dynamic VLAN assignment when using 802.1X. During 802.1x authentication, the
existing VLAN configuration of a port assigned to a non-default VLAN is overwritten and the port is
assigned to a specified VLAN.
• If 802.1x authentication is disabled on the port, the port is re-assigned to the previously-configured
VLAN.
• If 802.1x authentication fails and if the authentication-fail VLAN is enabled for the port (see
Configuring an Authentication-Fail VLAN on page 122), the port is assigned to the authentication-fail
VLAN.
The dynamic VLAN assignment is based on RADIUS attribute 81, Tunnel-Private-Group-ID, and uses the
following standard dot1x procedure:
Step Task
1 Configure 802.1x globally and at interface level (see Enabling 802.1X on page 112) along with relevant RADIUS
server configurations.
5 Verify that the port has been authorized and placed in the desired VLAN by entering the show dot1x interface
and show vlan commands (red text in Figure 7-11).
802.1X | 119
Figure 7-11 shows the configuration on a Dell Force10 switch that uses dynamic VLAN assignment with
www.dell.com | support.dell.com
802.1X before you connect the end-user device (black and blue text), and after you connect the device (red
text).
The blue text corresponds to the numbered steps on page 119. Note that the GigabitEthernet 1/11 port, on
which dynamic VLAN assignment with 802.1X is configured, is initially an untagged member of VLAN
300. After a successful 802.1x authentication with dynamic VLAN configuration, the port becomes an
untagged member of VLAN 400 (assigned by the RADIUS server during authentication).
4
1/11 1
radius-server host 10.11.197.169
auth-port 1645
key 7 387a7f2df5969da4
Note: In the show vlan command output, if the statically-configured VLAN and the 802.1X
dynamically-assigned VLAN are the same, the 802.1x-authorized port is displayed with U for Untagged.
If the two VLANs are not the same, the 802.1x-authorized port is displayed with x for Dot1X untagged.
120 | 802.1X
Guest and Authentication-Fail VLANs
Typically, the authenticator (Dell Force10 system) denies the supplicant access to the network until the
supplicant is authenticated. If the supplicant is authenticated, the authenticator enables the port and places
it in either the VLAN for which the port is configured, or the VLAN that the authentication server indicates
in the authentication data.
If the supplicant fails authentication, the authenticator typically does not enable the port. In some cases this
behavior is not appropriate. External users of an enterprise network, for example, might not be able to be
authenticated, but still need access to the network. Also, some dumb-terminals such as network printers do
not have 802.1X capability and therefore cannot authenticate themselves. To be able to connect such
devices, they must be allowed access the network without compromising network security.
The Guest VLAN 802.1X extension addresses this limitation with regard to non-802.1X capable devices,
and the Authentication-fail VLAN 802.1X extension addresses this limitation with regard to external users.
• If the supplicant fails authentication a specified number of times, the authenticator places the port in
the Authentication-fail VLAN.
• If a port is already forwarding on the Guest VLAN when 802.1X is enabled, then the port is moved out
of the Guest VLAN, and the authentication process begins.
Configure a port to be placed in the Guest VLAN after failing to respond within the timeout period using
the command dot1x guest-vlan from INTERFACE mode, as shown in Figure 7-12.
View your configuration using the command show config from INTERFACE mode, as shown in
Figure 7-12, or using the command show dot1x interface command from EXEC Privilege mode as shown
in Figure 7-14.
802.1X | 121
Configuring an Authentication-Fail VLAN
www.dell.com | support.dell.com
If the supplicant fails authentication, the authenticator re-attempts to authenticate after a specified amount of
time (30 seconds by default, see Configuring a Quiet Period after a Failed Authentication on page 114). You
can configure the maximum number of times the authenticator re-attempts authentication after a failure (3 by
default), after which the port is placed in the Authentication-fail VLAN.
Configure a port to be placed in the VLAN after failing the authentication process as specified number of
times using the command dot1x auth-fail-vlan from INTERFACE mode, as shown in Figure 7-13. Configure
the maximum number of authentication attempts by the authenticator using the keyword max-attempts with
this command.
View your configuration using the command show config from INTERFACE mode, as shown in
Figure 7-12, or using the command show dot1x interface command from EXEC Privilege mode as shown in
Figure 7-14.
122 | 802.1X
Multi-Host Authentication
Multi-Host Authentication is available on platforms: c et s
802.1x assumes that a single end-user is connected to a single authenticator port, as shown in Figure 7-15;
this one-to-one mode of authentication is called Single-host mode. If multiple end-users are connected to
the same port, a many-to-one configuration, only the first end-user to respond to the identity request is
authenticated. Subsequent responses are ignored, and a system log is generated to indicate reception of
unexpected 802.1x frames. When a port is authorized, the authenticated supplicant MAC address is
associated with the port, and traffic from any other source MACs is dropped.
When multiple end-users are connected to a single authenticator port, Single-host mode authentication
does not authenticate all end-users, and all but one are denied access to the network. For these cases
(Figure 7-16), FTOS offers Multi-host mode authentication.
End-user Devices
When Multi-host mode authentication is configured, the first client to respond to an identity request is
authenticated, and subsequent responses are still ignored, but since the authenticator expects the possibility
of multiple responses, no system log is generated. After the first supplicant is authenticated, all end-users
attached to the authorized port are allowed to access the network.
If the authorized port becomes unauthorized due to re-authentication failure or the supplicant sends an
EAPOL logoff frame, all attached end-users are denied access to the network.
802.1X | 123
When the host mode is changed on a port that is already authenticated:
www.dell.com | support.dell.com
• Single-host to Multi-host: all devices attached to the port that were previously blocked may access
the network; the supplicant does not re-authenticate.
• Multi-host to Single-host: the port restarts the authentication process, and the first end-user to
respond is authenticated and allowed access.
124 | 802.1X
Task Command Syntax Command Mode
Multi-Supplicant Authentication
Multi-Supplicant Authentication is available on platforms: cs
The 802.1X Multi-supplicant Authentication enables multiple devices on a single authenticator port to
access the network by authenticating each device. In addition, Multi-supplicant Authentication uses
dynamic MAC-based VLAN assignment to place devices on different VLANs. This feature is different
from Multi-host Authentication in which multiple devices connected to a single authenticator port can
access the network after only the one device is authenticated, and all hosts are placed in the same VLAN as
the authenticated device.
Multi-supplicant authentication is needed, for example, in the case of a workstation at which a VOIP phone
and PC are connected to a single authenticator port. Multi-host authentication could authenticate the first
device to respond, and then both devices could access the network. However, if you wanted to place them
in different VLANs—a VOIP VLAN and a data VLAN— you would need to authenticate the devices
separately so that the RADIUS server can send each device’s VLAN assignment during that devices
authentication process.
802.1X | 125
During the authentication process, the Dell Force10 system is able to learn the MAC address of the device
www.dell.com | support.dell.com
though the EAPoL frames, and the VLAN assignment from the RADIUS server. With this information it
creates an authorized-MAC to VLAN mapping table per port. Then, the system can tag all incoming
untagged frames with the appropriate VLAN-ID based on the table entries.
Supplicants on Gi 1/3:
----------------------
00:01:e9:45:00:03 AUTHENTICATED
00:01:e9:55:00:10 AUTHENTICATING
00:01:e9:B5:00:03 UNAUTHENTICATED
Note: On the C-Series, during multi-supplicant authentication, devices that fail authentication may still be
counted towards the maximum number of supplicants supported by 802.1X authentication to access the
port, thus preventing the full number of supplicants to be authenticated.
126 | 802.1X
MAC Authentication Bypass
MAC Authentication Bypass is supported on platforms: cs
MAC Authentication Bypass (MAB) enables you to provide MAC-based security by allowing only known
MAC addresses within the network using a RADIUS server.
802.1X-enabled clients can authenticate themselves using the 802.1X protocol. Other devices that do not
use 802.1X—like IP phones, printers, and IP fax machines—still need connectivity to the network. The
guest VLAN provides one way to access the network. However, placing trusted devices on the quarantined
VLAN is not the best practice. MAB allows devices that have known static MAC addresses to be
authenticated using their MAC address, and places them into a VLAN different from the VLAN in which
unknown devices are placed.
For an 802.1X-incapable device, 802.1X time will out if the device does not respond to the Request
Identity frame. If MAB is enabled, the port is then put into learning state and waits indefinitely until the
device sends a packet. Once its MAC is learned, it is sent for authentication to the RADIUS server (as both
the username and password, in hexadecimal format without any colons). If the server authenticates
successfully, the port is dynamically assigned to a MAB VLAN using a RADIUS attribute 81, or is
assigned to the untagged VLAN of the port. Afterwards, packets from any other MAC address are
dropped. If authentication fails, the authenticator waits the quiet-period and then restarts the authentication
process.
MAC authentication bypass works in conjunction and in competition with the guest VLAN and
authentication-fail VLAN. When both features are enabled:
If both MAB and re-authentication are enabled, when the re-auth period finishes and whether the previous
authentication was through MAB or 802.1X, 802.1X authentication is tried first. If 802.1X times out,
MAB authentication is tried. The port remains authorized throughout the reauthentication process. Once a
port is enabled/disabled through 802.1X authentication, changes to MAB do not take effect until the MAC
is asked to re-authenticate or the port status is toggled.
Note: On the C-Series and S-Series, a MAB-authenticated port becomes unauthorized after an RPM
failover.
802.1X | 127
MAB in Single-host and Multi-Host Mode
www.dell.com | support.dell.com
In single-host and multi-host mode, the switch attempts to authenticate a supplicant using 802.1X. If
802.1X times out because the supplicant does not respond to the Request Identity frame and MAB is
enabled, the switch attempts to authenticate the first MAC it learns on the port. Subsequently, for
single-host mode, traffic from all other MACs is dropped; for multi-host mode, all traffic from all other
MACs is accepted.
After a port is authenticated by MAB, if the switch detects an 802.1X EAPoL start message from the
authenticated MAC, the switch re-authenticates using 802.1X first, while keeping the port authorized.
Note: On the C-Series and S-Series, if the switch is in multi-host mode, a MAC address that was
MAB-authenticated but later was disabled from MAB authentication, is not denied access but moved to
the guest VLAN. If the switch is in single-host mode, the MAC address is disallowed access.
If any supplicant that has been authenticated using MAB starts to speak EAPoL, the switch
re-authenticates that supplicant using 802.1X first, while keeping the MAC authorized through the
re-authentication process.
128 | 802.1X
Step Task Command Syntax Command Mode
802.1X | 129
Dynamic CoS with 802.1X
www.dell.com | support.dell.com
For incoming traffic, FTOS allows you to set a static priority value on a per-port basis or dynamically set a
priority on a per-port basis by leveraging 802.1X.
Note: When priority is statically configured using dynamic dot1p and dynamically configured using
Dynamic CoS with 802.1X, the dynamic configuration takes precedence.
One use for Dynamic CoS with 802.1X is when the traffic from a server should be classified based on the
application that it is running. Static dot1p priority configuration done from the switch is not sufficient in
this case, as the server application might change. You would instead need to push the CoS configuration to
the switches based on the application the server is running.
Dynamic CoS uses RADIUS attribute 59, called User-Priority-Table, to specify the priority value for
incoming frames. Attribute 59 has an 8-octet field that maps the incoming dot1p values to new values; it is
essentially a dot1p re-mapping table. The position of each octet corresponds to a priority value: the first
octet maps to incoming priority 0, the second octet maps to incoming priority 1, etc. The value in each
octet represents the corresponding new priority.
To use the Dynamic CoS with 802.1X authentication, no configuration command is required. You must
only configure the supplicant records on the RADIUS server, including VLAN assignment and CoS
priority re-mapping table. VLAN and priority values are automatically applied to incoming packets. The
RADIUS server finds the appropriate record based on the supplicant’s credentials and sends the priority
re-mapping table to the Dell Force10 system by including Attribute 59 in the AUTH-ACCEPT packet.
130 | 802.1X
FTOS Behavior: The following conditions are applied to the use of dynamic CoS with 802.1X
authentication on C-Series and S-Series platforms:
• In accordance with port-based QoS, incoming dot1p values can be mapped to only four priority values: 0, 2,
4, and 6. If the RADIUS server returns any other dot1p value (1, 3, 5, or 7), the value is not used and frames
are forwarded on egress queue 0 without changing the incoming dot1p value. The example shows how
dynamic CoS remaps (or does not remap) the dot1p priority in 802.1X-authenticated traffic and how the
frames are forwarded:
• The priority of untagged packets is assigned according to the remapped value of priority 0 traffic in the
RADIUS-based table. For example, in the following remapping table, untagged packets are tagged with
priority 2:
FTOS#show dot1x cos-mapping interface Gigabitethernet 2/32
• After being re-tagged by dynamic CoS for 802.1X, packets are forwarded in the switch according to their
new CoS priority.
• When a supplicant logs off from an 802.1X authentication session, the dynamic CoS table is deleted or reset.
When an 802.1x session is re-authenticated, the previously assigned CoS table is retained through
the re-authentication process. If the re-authentication fails, the CoS table is deleted. If the
re-authentication is successful and the authentication server does not include a CoS table in the
AUTH-ACCEPT packet, the previously assigned CoS table MUST be deleted. If the
re-authentication is successful and the server sends a CoS table, the old CoS table is overwritten
with the new one.
• If multi-supplicant authentication mode is enabled on a port, you can configure a CoS mapping table for
specified MAC addresses in the RADIUS server. FTOS will then maintain a per-MAC CoS table for each
port, and mark the priority of all traffic originating from a configured MAC address with the corresponding
table value.
• To display the CoS priority-mapping table provided by the RADIUS server and applied to authenticated
supplicants on an 802.1X-enabled port, enter the show dot1x cos-mapping interface
• command.
802.1X | 131
www.dell.com | support.dell.com
132
|
802.1X
8
IP Access Control Lists (ACL), Prefix Lists, and
Route-maps
IP Access Control Lists, Prefix Lists, and Route-maps are supported on platforms: ces
ces
Ingress IP ACLs are supported on platforms:
Overview
At their simplest, Access Control Lists (ACLs), Prefix lists, and Route-maps permit or deny traffic based
on MAC and/or IP addresses. This chapter discusses implementing IP ACLs, IP Prefix lists and
Route-maps. For MAC ACLS, refer to the Access Control Lists (ACLs) chapter in the FTOS Command
Line Reference Guide.
An ACL is essentially a filter containing some criteria to match (examine IP, TCP, or UDP packets) and an
action to take (permit or deny). ACLs are processed in sequence so that if a packet does not match the
criterion in the first filter, the second filter (if configured) is applied. When a packet matches a filter, the
switch drops or forwards the packet based on the filter’s specified action. If the packet does not match any
of the filters in the ACL, the packet is dropped ( implicit deny).
The number of ACLs supported on a system depends on your CAM size. See CAM Profiling, CAM
Allocation, and CAM Optimization in this chapter for more information. Refer to Chapter 11, Content
Addressable Memory, on page 281 for complete CAM profiling information.
For extended ACL TCP and UDP filters, you can match criteria on specific or ranges of TCP or UDP
ports. For extended ACL TCP filters, you can also match criteria on established TCP sessions.
When creating an access list, the sequence of the filters is important. You have a choice of assigning
sequence numbers to the filters as you enter them, or FTOS will assign numbers in the order the filters are
created. The sequence numbers, whether configured or assigned by FTOS, are listed in the show config
and show ip accounting access-list command display output.
Ingress and egress Hot Lock ACLs allow you to append or delete new rules into an existing ACL (already
written into CAM) without disrupting traffic flow. Existing entries in CAM are shuffled to accommodate
the new entries. Hot Lock ACLs are enabled by default and support both standard and extended ACLs on
all platforms.
The default CAM profile has 1K Layer 2 ingress ACL entries. If you need more memory for Layer 2
ingress ACLs, select the profile l2-ipv4-inacl.
When budgeting your CAM allocations for ACLs and QoS configurations, remember that ACL and QoS
rules might consume more than one CAM entry depending on complexity. For example, TCP and UDP
rules with port range options might require more than one CAM entry.
The Layer 2 ACL CAM partition has sub-partitions for several types of information. Table 8-1 lists the
sub-partition and the percentage of the Layer 2 ACL CAM partition that FTOS allocates to each by default.
Partition % Allocated
Sysflow 6
L2ACL 14
*PVST 50
QoS 12
L2PT 13
FRRP 5
You can re-configure the amount of space, in percentage, allocated to each sub-partition. As with the
IPv4Flow partition, you can configure the Layer 2 ACL partition from EXEC Privilege mode or
CONFIGURATION mode.
The amount of space that you can distribute to the sub-partitions is equal to the amount of CAM space that
the selected CAM profile allocates to the Layer 2 ACL partition. FTOS requires that you specify the
amount of CAM space for all sub-partitions and that the sum of all sub-partitions is 100%. FTOS displays
the following message if the total allocated space is not correct:
mode.
The CAM space is allotted in FP blocks. The total space allocated must equal 13 FP blocks. Note that there
are 16 FP blocks, but the System Flow requires 3 blocks that cannot be reallocated. The default CAM
Allocation settings on a C-Series matching are:
• L3 ACL (ipv4acl): 6
• L2 ACL(l2acl) : 5
• IPv6 L3 ACL (ipv6acl): 0
• L3 QoS (ipv4qos): 1
• L2 QoS (l2qos): 1
The ipv6acl allocation must be entered as a factor of 2 (2, 4, 6, 8, 10). All other profile allocations can use
either even or odd numbered ranges.
You must save the new CAM settings to the startup-config (write-mem or copy run start) then reload the
system for the new settings to take effect.
CAM optimization
Use this command to determine whether sufficient ACL CAM space is available to enable a service-policy.
Create a Class Map with all required ACL rules, then execute the test cam-usage command in Privilege
mode to verify the actual CAM space required. Figure 8-1 gives a sample of the output shown when
executing the command. The status column indicates whether or not the policy can be enabled.
Linecard | Portpipe | CAM Partition | Available CAM | Estimated CAM per Port | Status
------------------------------------------------------------------------------------------
2 | 1 | IPv4Flow | 232 | 0 | Allowed
2 | 1 | IPv6Flow | 0 | 0 | Allowed
4 | 0 | IPv4Flow | 232 | 0 | Allowed
4 | 0 | IPv6Flow | 0 | 0 | Allowed
FTOS#
The number of entries allowed per ACL is hardware-dependent. Refer to your line card documentation for
detailed specification on entries allowed per ACL.
If counters are enabled on IP ACL rules that are already configured, those counters are reset when a new
rule is inserted or prepended. If a rule is appended, the existing counters are not affected. This is applicable
to the following features:
Note: IP ACLs are supported over VLANs in Version 6.2.1.1 and higher.
V
There are some differences when assigning ACLs to a VLAN rather than a physical port. For example,
when using a single port-pipe, if you apply an ACL to a VLAN, one copy of the ACL entries would get
installed in the ACL CAM on the port-pipe. The entry would look for the incoming VLAN in the packet.
Whereas if you apply an ACL on individual ports of a VLAN, separate copies of the ACL entries would be
installed for each port belonging to a port-pipe.
When you use the log keyword, CP processor will have to log details about the packets that match.
Depending on how many packets match the log entry and at what rate, CP might become busy as it has to
log these packets’ details. However the other processors (RP1 and RP2) should be unaffected. This option
is typically useful when debugging some problem related to control traffic. We have used this option
numerous times in the field and have not encountered any problems in such usage so far.
ACL Optimization
If an access list contains duplicate entries, FTOS deletes one entry to conserve CAM space.
When you link class-maps to queues using the command service-queue, FTOS matches the class-maps
according to queue priority (queue numbers closer to 0 have lower priorities). For example, in Figure 8-2,
class-map cmap2 is matched against ingress packets before cmap1.
ACLs acl1 and acl2 have overlapping rules because the address range 20.1.1.0/24 is within 20.0.0.0/8.
Therefore, (without the keyword order) packets within the range 20.1.1.0/24 match positive against cmap1
and are buffered in queue 7, though you intended for these packets to match positive against cmap2 and be
buffered in queue 4.
In cases such as these, where class-maps with overlapping ACL rules are applied to different queues, use
the order keyword to specify the order in which you want to apply ACL rules, as shown in Figure 8-2. The
order can range from 0 to 254. FTOS writes to the CAM ACL rules with lower order numbers (order
numbers closer to 0) before rules with higher order numbers so that packets are matched as you intended.
By default, all ACL rules have an order of 254.
IP Fragment Handling
FTOS supports a configurable option to explicitly deny IP fragmented packets, particularly second and
subsequent packets. It extends the existing ACL command syntax with the fragments keyword for all
Layer 3 rules applicable to all Layer protocols (permit/deny ip/tcp/udp/icmp).
The following configuration permits all packets (both fragmented & non-fragmented) with destination IP
10.1.1.1. The second rule does not get hit at all.
FTOS(conf)#ip access-list extended ABC
FTOS(conf-ext-nacl)#permit ip any 10.1.1.1/32
FTOS(conf-ext-nacl)#deny ip any 10.1.1.1./32 fragments
FTOS(conf-ext-nacl)
To deny second/subsequent fragments, use the same rules in a different order. These ACLs deny all second
& subsequent fragments with destination IP 10.1.1.1 but permit the first fragment & non fragmented
packets with destination IP 10.1.1.1 .
In the below scenario, first fragments non-fragmented TCP packets from 10.1.1.1 with TCP destination
port equal to 24 are permitted. All other fragments are denied.
destination port equal to 24 are permitted. Additionally, all TCP non-first fragments from host 10.1.1.1 are
permitted. All other IP packets that are non-first fragments are denied.
FTOS(conf)#ip access-list extended ABC
FTOS(conf-ext-nacl)#permit tcp host 10.1.1.1 any eq 24
FTOS(conf-ext-nacl)#permit tcp host 10.1.1.1 any fragment
FTOS(conf-ext-nacl)#deny ip any any fragment
FTOS(conf-ext-nacl)
To log all the packets denied and to override the implicit deny rule and the implicit permit rule for TCP/
UDP fragments, use a configuration similar to the following.
FTOS(conf)#ip access-list extended ABC
FTOS(conf-ext-nacl)#permit tcp any any fragment
FTOS(conf-ext-nacl)#permit udp any any fragment
FTOS(conf-ext-nacl)#deny ip any any log
FTOS(conf-ext-nacl)
Note the following when configuring ACLs with the fragments keyword.
When an ACL filters packets it looks at the Fragment Offset (FO) to determine whether or not it is a fragment.
FO = 0 means it is either the first fragment or the packet is a non-fragment.
FO > 0 means it is dealing with the fragments of the original packet.
Permit ACL line with L3 information only, and the fragments keyword is present:
If a packet's L3 information matches the L3 information in the ACL line, the packet's fragment offset (FO) is
checked.
•If a packet's FO > 0, the packet is permitted.
•If a packet's FO = 0 , the next ACL entry is processed.
Deny ACL line with L3 information only, and the fragments keyword is present:
If a packet's L3 information does match the L3 information in the ACL line, the packet's fragment offset (FO) is
checked.
•If a packet's FO > 0, the packet is denied.
•If a packet's FO = 0, the next ACL line is processed.
For a complete listing of all commands related to IP ACLs, refer to the FTOS Command Line Interface
Reference document.
Note: On E-Series ExaScale systems, TCP ACL flags are not supported in standard or extended ACLs
with IPv6 microcode. An error message is shown if IPv6 microcode is configured and an ACL is entered
with a TCP filter included.
FTOS(conf-ipv6-acl)#seq 8 permit tcp any any urg
May 5 08:32:34: %E90MJ:0 %ACL_AGENT-2-ACL_AGENT_ENTRY_ERROR: Unable to write seq 8 of
list test as individual TCP flags are not supported on linecard 0
2 seq sequence-number {deny | permit} CONFIG-STD-NACL Configure a drop or forward filter. The
{source [mask] | any | host ip-address} parameters are:
[count [byte] | log] [order] [monitor] • log and monitor options are
[fragments] supported on E-Series only.
Note: When assigning sequence numbers to filters, keep in mind that you might need to insert a
new filter. To prevent reconfiguring multiple filters, assign sequence numbers in multiples of five or
another number.
When you use the log keyword, CP processor logs details about the packets that match. Depending on how
many packets match the log entry and at what rate, the CP may become busy as it has to log these packets’
details.
To view the rules of a particular ACL configured on a particular interface, use the show ip accounting
access-list ACL-name interface interface command (Figure 226) in EXEC Privilege mode.
Figure 8-3. Command Example: show ip accounting access-list
FTOS#show ip accounting access ToOspf interface gig 1/6
Standard IP access list ToOspf
seq 5 deny any
seq 10 deny 10.2.0.0 /16
seq 15 deny 10.3.0.0 /16
seq 20 deny 10.4.0.0 /16
seq 25 deny 10.5.0.0 /16
seq 30 deny 10.6.0.0 /16
seq 35 deny 10.7.0.0 /16
seq 40 deny 10.8.0.0 /16
seq 45 deny 10.9.0.0 /16
seq 50 deny 10.10.0.0 /16
FTOS#
Figure 8-4 illustrates how the seq command orders the filters according to the sequence number assigned.
In the example, filter 25 was configured before filter 15, but the show config command displays the filters
in the correct order.
To delete a filter, use the no seq sequence-number command in the IP ACCESS LIST mode.
If you are creating a standard ACL with only one or two filters, you can let FTOS assign a sequence
number based on the order in which the filters are configured. The software assigns filters in multiples of 5.
To configure a filter without a specified sequence number, use these commands in the following sequence,
starting in the CONFIGURATION mode:
2 {deny | permit} {source [mask] | any CONFIG-STD-NACL Configure a drop or forward IP ACL filter.
| host ip-address} [count [byte] | • log and monitor options are supported
log] [order] [monitor] [fragments] on E-Series only.
When you use the log keyword, CP processor logs details about the packets that match. Depending on how
many packets match the log entry and at what rate, the CP may become busy as it has to log these packets’
details.
Figure 8-5 illustrates a standard IP ACL in which the sequence numbers were assigned by the FTOS. The
filters were assigned sequence numbers based on the order in which they were configured (for example,
the first filter was given the lowest sequence number). The show config command in the IP ACCESS
LIST mode displays the two filters with the sequence numbers 5 and 10.
Figure 8-5. Standard IP ACL
To view all configured IP ACLs, use the show ip accounting access-list command (Figure 229) in the
EXEC Privilege mode.
To delete a filter, enter the show config command in the IP ACCESS LIST mode and locate the sequence
number of the filter you want to delete. Then use the no seq sequence-number command in the IP ACCESS
LIST mode.
Since traffic passes through the filter in the order of the filter’s sequence, you can configure the extended
IP ACL by first entering the IP ACCESS LIST mode and then assigning a sequence number to the filter.
Note: On E-Series ExaScale systems, TCP ACL flags are not supported in standard or extended ACLs
with IPv6 microcode. An error message is shown if IPv6 microcode is configured and an ACL is entered
with a TCP filter included.
FTOS(conf-ipv6-acl)#seq 8 permit tcp any any urg
May 5 08:32:34: %E90MJ:0 %ACL_AGENT-2-ACL_AGENT_ENTRY_ERROR: Unable to write seq 8 of
list test as individual TCP flags are not supported on linecard 0
To create a filter for packets with a specified sequence number, use these commands in the following
sequence, starting in the CONFIGURATION mode:
When you use the log keyword, CP processor logs details about the packets that match. Depending on how
many packets match the log entry and at what rate, the CP may become busy as it has to log these packets’
details.
TCP packets: To create a filter for TCP packets with a specified sequence number, use these commands in
the following sequence, starting in the CONFIGURATION mode:
2 seq sequence-number {deny | CONFIG-EXT-NACL Configure an extended IP ACL filter for TCP
permit} tcp {source mask | any packets.
| host ip-address}} [count • log and monitor options are supported on
[byte] | log] [order] [monitor] E-Series only.
[fragments]
When you use the log keyword, CP processor logs details about the packets that match. Depending on how
many packets match the log entry and at what rate, the CP may become busy as it has to log these packets’
details.
UDP packets: To create a filter for UDP packets with a specified sequence number, use these commands
in the following sequence, starting in the CONFIGURATION mode:
2 seq sequence-number {deny | CONFIG-EXT-NACL Configure an extended IP ACL filter for UDP
permit} {ip-protocol-number packets.
udp} {source mask | any | • log and monitor options are supported on
host ip-address} {destination E-Series only.
mask | any | host ip-address}
[operator port [port]] [count
[byte] | log] [order] [monitor]
[fragments]
Note: When assigning sequence numbers to filters, keep in mind that you might need to insert a
new filter. To prevent reconfiguring multiple filters, assign sequence numbers in multiples of five or
another number.
Figure 8-7 illustrates how the seq command orders the filters according to the sequence number assigned.
In the example, filter 15 was configured before filter 5, but the show config command displays the filters
in the correct order.
Figure 8-7. Command Example: seq
FTOS(config-ext-nacl)#seq 15 deny ip host 112.45.0.0 any log
FTOS(config-ext-nacl)#seq 5 permit tcp 12.1.3.45 0.0.255.255 any
FTOS(config-ext-nacl)#show confi
!
ip access-list extended dilling
seq 5 permit tcp 12.1.0.0 0.0.255.255 any
seq 15 deny ip host 112.45.0.0 any log
FTOS(config-ext-nacl)#
If you are creating an extended ACL with only one or two filters, you can let FTOS assign a sequence
number based on the order in which the filters are configured. FTOS assigns filters in multiples of 5.
To configure a filter for an extended IP ACL without a specified sequence number, use any or all of the
following commands in the IP ACCESS LIST mode:
{deny | permit} {source mask | any | host CONFIG-EXT-NACL Configure a deny or permit filter to
ip-address} [count [byte] | log] [order] examine IP packets.
[monitor] [fragments] • log and monitor options are
supported on E-Series only.
{deny | permit} tcp {source mask] | any | CONFIG-EXT-NACL Configure a deny or permit filter to
host ip-address}} [count [byte] | log] examine TCP packets.
[order] [monitor] [fragments] • log and monitor options are
supported on E-Series only.
{deny | permit} udp {source mask | any | CONFIG-EXT-NACL Configure a deny or permit filter to
host ip-address}} [count [byte] | log] examine UDP packets.
[order] [monitor] [fragments] • log and monitor options are
supported on E-Series only.
When you use the log keyword, CP processor logs details about the packets that match. Depending on how
many packets match the log entry and at what rate, the CP may become busy as it has to log these packets’
details.
The filters were assigned sequence numbers based on the order in which they were configured (for
example, the first filter was given the lowest sequence number). The show config command in the IP
ACCESS LIST mode displays the two filters with the sequence numbers 5 and 10.
Figure 8-8. Extended IP ACL
To view all configured IP ACLs and the number of packets processed through the ACL, use the show ip
accounting access-list command (Figure 232) in the EXEC Privilege mode.
Established Flag
The est (established) flag is deprecated for Terascale series line cards.The flag is only available on legacy
Etherscale linecards. Employ the ack and rst flags in their stead to achieve the same functionality.
• The packets routed by FTOS are governed by the L3 ACL only, since they are not filtered against an
L2 ACL.
• The packets switched by FTOS are first filtered by the L3 ACL, then by the L2 ACL.
• When packets are switched by FTOS, the egress L3 ACL does not filter the packet.
For the following features, if counters are enabled on rules that have already been configured and a new
rule is either inserted or prepended, all the existing counters will be reset:
Note: If an interface is configured as a “vlan-stack access” port, the packets are filtered by an
L2 ACL only. The L3 ACL applied to such a port does not affect traffic. That is, existing rules
for other features (such as trace-list, PBR, and QoS) are applied accordingly to the permitted
traffic.
For information on MAC ACLs, refer to the Access Control Lists (ACLs) chapter in the FTOS Command
Line Reference Guide.
To pass traffic through a configured IP ACL, you must assign that ACL to a physical interface, a port
channel interface, or a VLAN. The IP ACL is applied to all traffic entering a physical or port channel
interface and the traffic is either forwarded or dropped depending on the criteria and actions specified in
the ACL.
The same ACL may be applied to different interfaces and that changes its functionality. For example, you
can take ACL "ABCD", and apply it using the in keyword and it becomes an ingress access list. If you
apply the same ACL using the out keyword, it becomes an egress access list. If you apply the same ACL to
the loopback interface, it becomes a loopback access list.
For more information on Layer-3 interfaces, refer to Chapter 13, Interfaces, on page 47.
To view which IP ACL is applied to an interface, use the show config command (Figure 232) in the
INTERFACE mode or the show running-config command in the EXEC mode.
Figure 8-9. Command example: show config in the INTERFACE Mode
FTOS(conf-if)#show conf
!
interface GigabitEthernet 0/0
ip address 10.2.1.100 255.255.255.0
ip access-group nimule in
no shutdown
FTOS(conf-if)#
Use only Standard ACLs in the access-class command to filter traffic on Telnet sessions.
Step Task
1 Create an ACL that uses rules with the count option. See Configure a standard IP ACL on page 140
2 Apply the ACL as an inbound or outbound ACL on an interface. See Assign an IP ACL to an Interface on
page 147
3 View the number of packets matching the ACL using the show ip accounting access-list from EXEC
Privilege mode.
To create an ingress ACLs, use the ip access-group command (Figure 233) in the EXEC Privilege mode.
This example also shows applying the ACL, applying rules to the newly created access group, and viewing
the access list:
Figure 8-10. Creating an Ingress ACL
traffic is isolated to one particular interface, you can apply an egress ACL to block that particular flow
from exiting the box, thereby protecting downstream devices.
To create an egress ACLs, use the ip access-group command (Figure 234) in the EXEC Privilege mode.
This example also shows viewing the configuration, applying rules to the newly created access group, and
viewing the access list:
Figure 8-11. Creating an Egress ACL
Apply Egress ACLs to IPv6 system ipv6 control-plane [egress filter] CONFIGURATION
traffic.
Create a Layer 3 ACL using permit permit ip {source mask | any | CONFIG-NACL
rules with the count option to describe host ip-address} {destination mask
the desired CPU traffic | any | host ip-address} count
The ACLs on loopback interfaces are applied only to the CPU on the RPM—this eliminates the need to
apply specific ACLs onto all ingress interfaces and achieves the same results. By localizing target traffic, it
is a simpler implementation.
The ACLs target and handle Layer 3 traffic destined to terminate on the system including routing
protocols, remote access, SNMP, ICMP, and etc. Effective filtering of Layer 3 traffic from Layer 3 routers
reduces the risk of attack.
Loopback interfaces do not support ACLs using the IP fragment option. If you configure an ACL with the
fragments option and apply it to a loopback interface, the command is accepted, but the ACL entries are
not actually installed the offending rule in CAM.
2 [seq number] permit CONFIGURATION If you are applying an extended ACL, and it has
loopback-logging any any a deny ip any any entry, this entry denies
internally generated packets as well as packets
received from external devices. To prevent
internally generated packets from being dropped,
make sure that the ACL you intend to apply has
the following entry: [seq number] permit
loopback-logging any any. This line may be
anywhere in the ACL.
To apply ACLs on loopback, use the ip access-group command (Figure 235) in the INTERFACE mode.
This example also shows the interface configuration status, adding rules to the access group, and
displaying the list of rules in the ACL:
Figure 8-12. Applying an ACL to the Loopback Interface
FTOS(conf)#interface loopback 0
FTOS(conf-if-lo-0)#ip access-group abcd in Use the in keyword.
FTOS(conf-if-lo-0)#show config
!
interface Loopback 0
no ip address
ip access-group abcd in
no shutdown
FTOS(conf-if-lo-0)#end
FTOS#configure terminal
FTOS(conf)#ip access-list extended abcd Add rules to the ACL
FTOS(config-ext-nacl)#permit tcp any any
FTOS(config-ext-nacl)#deny icmp any any
named “abcd.”
FTOS(config-ext-nacl)#permit 1.1.1.2
FTOS(config-ext-nacl)#end
FTOS#show ip accounting access-list Display the ACL.
!
Extended Ingress IP access list abcd on Loopback 0
seq 5 permit tcp any any
seq 10 deny icmp any any
seq 10 deny icmp any any
Note: See also the section VTY Line Local Authentication and Authorization on page 948.
A route prefix is an IP address pattern that matches on bits within the IP address. The format of a route
prefix is A.B.C.D/X where A.B.C.D is a dotted-decimal address and /X is the number of bits that should be
matched of the dotted decimal address. For example, in 112.24.0.0/16, the first 16 bits of the address
112.24.0.0 match all addresses between 112.24.0.0 to 112.24.255.255.
Below are some examples that permit or deny filters for specific routes using the le and ge parameters,
where x.x.x.x/x represents a route prefix:
• To deny only /8 prefixes, enter deny x.x.x.x/x ge 8 le 8
• To permit routes with the mask greater than /8 but less than /12, enter permit x.x.x.x/x ge 8
le 12
• To deny routes with a mask less than /24, enter deny x.x.x.x/x le 24
• To permit routes with a mask greater than /20, enter permit x.x.x.x/x ge 20
Implementation Information
In FTOS, prefix lists are used in processing routes for routing protocols (for example, RIP, OSPF, and
BGP).
Note: The S-Series platform does not support all protocols. It is important to know which protocol you are
supporting prior to implementing Prefix-Lists.
For a complete listing of all commands related to prefix lists, refer to the FTOS Command Line Interface
Reference document.
To configure a prefix list, use these commands in the following sequence, starting in the
CONFIGURATION mode:
2 seq sequence-number {deny | CONFIG-NPREFIXL Create a prefix list with a sequence number
permit} ip-prefix [ge and a deny or permit action. The optional
min-prefix-length] [le parameters are:
max-prefix-length] • ge min-prefix-length: is the minimum
prefix length to be matched (0 to 32).
• le max-prefix-length: is the maximum
prefix length to be matched (0 to 32).
If you want to forward all routes that do not match the prefix list criteria, you must configure a prefix list
filter to permit all routes (permit 0.0.0.0/0 le 32). The “permit all” filter should be the last filter in your
prefix list. To permit the default route only, enter permit 0.0.0.0/0.
Figure 8-13 illustrates how the seq command orders the filters according to the sequence number assigned.
In the example, filter 20 was configured before filter 15 and 12, but the show config command displays
the filters in the correct order.
Figure 8-13. Command Example: seq
FTOS(conf-nprefixl)#seq 20 permit 0.0.0.0/0 le 32
FTOS(conf-nprefixl)#seq 12 deny 134.23.0.0 /16
FTOS(conf-nprefixl)#seq 15 deny 120.23.14.0 /8 le 16
FTOS(conf-nprefixl)#show config
!
ip prefix-list juba
seq 12 deny 134.23.0.0/16
seq 15 deny 120.0.0.0/8 le 16
seq 20 permit 0.0.0.0/0 le 32
FTOS(conf-nprefixl)#
Note the last line in the prefix list Juba contains a “permit all” statement. By including this line in a prefix
list, you specify that all routes not matching any criteria in the prefix list are forwarded.
To delete a filter, use the no seq sequence-number command in the PREFIX LIST mode.
To configure a filter without a specified sequence number, use these commands in the following sequence
starting in the CONFIGURATION mode:
2 {deny | permit} ip-prefix [ge CONFIG-NPREFIXL Create a prefix list filter with a deny or
min-prefix-length] [le permit action. The optional parameters are:
max-prefix-length] • ge min-prefix-length: is the minimum
prefix length to be matched (0 to 32).
• le max-prefix-length: is the maximum
prefix length to be matched (0 to 32).
Figure 8-14 illustrates a prefix list in which the sequence numbers were assigned by the software. The
filters were assigned sequence numbers based on the order in which they were configured (for example,
the first filter was given the lowest sequence number). The show config command in the PREFIX LIST
mode displays the two filters with the sequence numbers 5 and 10.
Figure 8-14. Prefix List
FTOS(conf-nprefixl)#permit 123.23.0.0 /16
FTOS(conf-nprefixl)#deny 133.24.56.0 /8
FTOS(conf-nprefixl)#show conf
!
ip prefix-list awe
seq 5 permit 123.23.0.0/16
seq 10 deny 133.0.0.0/8
FTOS(conf-nprefixl)#
To delete a filter, enter the show config command in the PREFIX LIST mode and locate the sequence
number of the filter you want to delete; then use the no seq sequence-number command in the PREFIX
LIST mode.
To view all configured prefix lists, use either of the following commands in the EXEC mode:
show ip prefix-list detail [prefix-name] EXEC Privilege Show detailed information about configured Prefix
lists.
show ip prefix-list summary EXEC Privilege Show a table of summarized information about
[prefix-name] configured Prefix lists.
To pass traffic through a configured prefix list, you must use the prefix list in a route redistribution
command. The prefix list is applied to all traffic redistributed into the routing process and the traffic is
either forwarded or dropped depending on the criteria and actions specified in the prefix list.
To apply a filter to routes in RIP (RIP is supported on C and E-Series.), use either of the following
commands in the ROUTER RIP mode:
distribute-list prefix-list-name out CONFIG-ROUTER-RIP Apply a prefix list to filter network prefixes
[interface | connected | static | ospf] advertised in outgoing route updates. You
can specify an interface or type of route.
If you enter the name of a non-existent prefix
list, all routes are forwarded.
To view the configuration, use the show config command in the ROUTER RIP mode (Figure 240) or the
show running-config rip command in the EXEC mode.
To apply a filter to routes in OSPF, use either of the following commands in the ROUTER OSPF mode:
To view the configuration, use the show config command in the ROUTER OSPF mode (Figure 241) or the
show running-config ospf command in the EXEC mode.
Figure 8-18. Command Example: show config in ROUTER OSPF Mode
FTOS(conf-router_ospf)#show config
!
router ospf 34
network 10.2.1.1 255.255.255.255 area 0.0.0.1
distribute-list prefix awe in
FTOS(conf-router_ospf)#
ACL Resequencing
Resequencing an ACL or Prefix List is supported on platform e
ACL Resequencing allows you to re-number the rules and remarks in an access or prefix list. The
placement of rules within the list is critical because packets are matched against rules in sequential order.
Use Resequencing whenever there is no longer an opportunity to order new rules as desired using current
numbering scheme.
For example, Table 8-3 contains some rules that are numbered in increments of 1. No new rules can be
placed between these, so apply resequencing to create numbering space, as shown in Table 8-4. In the
same example, apply resequencing if more than two rules must be placed between rules 7 and 10.
Note: ACL Resequencing does not affect the rules or remarks or the order in which they are applied. It
merely renumbers them so that new rules can be placed within the list as desired.
Figure 8-19 shows the resequencing of an IPv4 access-list beginning with the number 2 and incrementing
by 2.
Remarks and rules that originally have the same sequence number have the same sequence number after
the resequence command is applied. Remarks that do not have a corresponding rule will be incremented as
as a rule. These two mechanisms allow remarks to retain their original position in the list.
For example, in Figure 8-20, remark 10 corresponds to rule 10 and as such they have the same number
before and after the command is entered. Remark 4 is incremented as a rule, and all rules have retained
their original positions.
Route Maps
Route-maps are supported on platforms: ces
Like ACLs and prefix lists, route maps are composed of a series of commands that contain a matching
criterion and an action, yet route maps can change the packets meeting the criterion. ACLs and prefix lists
can only drop or forward the packet or traffic. Route maps process routes for route redistribution. For
example, a route map can be called to filter only specific routes and to add a metric.
Route maps also have an “implicit deny.” Unlike ACLs and prefix lists, however, where the packet or
traffic is dropped, in route maps, if a route does not match any of the route map conditions, the route is not
redistributed.
Implementation Information
The FTOS implementation of route maps allows route maps with no match command or no set command.
When there is no match command, all traffic matches the route map and the set command applies.
The following list includes the configuration tasks for route maps:
Route maps, ACLs, and prefix lists are similar in composition because all three contain filters, but route
map filters are do not contain the permit and deny actions found in ACLs and prefix lists. Route map filters
match certain routes and set or specify values.
To create a route map and enter the ROUTE-MAP mode, use the following command in the
CONFIGURATION mode:
route-map map-name [permit | deny] CONFIGURATION Create a route map and assign it a unique name.
[sequence-number] The optional permit and deny keywords are the
action of the route map. The default is permit.
The optional parameter seq allows you to assign
a sequence number to the route map instance.
The default action is permit and the default sequence number starts at 10. When the keyword deny is used
in configuring a route map, routes that meet the match filters are not redistributed.
FTOS(config-route-map)#show config
!
route-map dilling permit 10
FTOS(config-route-map)#
You can create multiple instances of this route map by using the sequence number option to place the route
maps in the correct order. FTOS processes the route maps with the lowest sequence number first. When a
configured route map is applied to a command, like redistribute, traffic passes through all instances of that
route map until a match is found. Figure 8-22 shows an example with two instances of a route map.
Figure 8-22. Command Example: show route-map with Multiple Instances of a Route Map
FTOS#show route-map
route-map zakho, permit, sequence 10
Match clauses: Route map zakho has two instances
Set clauses:
route-map zakho, permit, sequence 20
Match clauses:
interface GigabitEthernet 0/1
Set clauses:
tag 35
level stub-area
FTOS#
To delete all instances of that route map, use the no route-map map-name command. To delete just one
instance, add the sequence number to the command syntax (Figure 8-24).
Figure 8-23. Deleting One Instance of a Route Map
FTOS(conf)#no route-map zakho 10
FTOS(conf)#end
FTOS#show route-map
route-map zakho, permit, sequence 20
Match clauses:
interface GigabitEthernet 0/1
Set clauses:
tag 35
level stub-area
FTOS#
Figure 8-24 shows an example of a route map with multiple instances. The show config command
displays only the configuration of the current route map instance. To view all instances of a specific route
map, use the show route-map command.
To delete a route map, use the no route-map map-name command in the CONFIGURATION mode.
Within the ROUTE-MAP mode, there are match and set commands. Basically, match commands search
for a certain criterion in the routes and the set commands change the characteristics of those routes, either
adding something or specifying a level.
When there are multiple match commands of the same parameter under one instance of route-map, then
FTOS does a match between either of those match commands. If there are multiple match commands of
different parameter, then FTOS does a match ONLY if there is a match among ALL match commands.
The following example explains better:
Example 1
In the above route-map, if a route has any of the tag value specified in the match commands, then there is a
match.
Example 2
In the above route-map, only if a route has both the characteristics mentioned in the route-map, it is
matched. Explaining further, the route must have a tag value of 1000 and a metric value of 2000. Only
then is there a match.
In the above route-map, instance 10 permits the route having a tag value of 1000 and instances 20 & 30
denies the route having a tag value of 1000. In the above scenario, FTOS scans all the instances of the
route-map for any permit statement. If there is a match anywhere, the route is permitted, though other
instances of the route-map denies it.
To configure match criterion for a route map, use any or all of the following commands in the
ROUTE-MAP mode:
match as-path as-path-name CONFIG-ROUTE-MAP Match routes with the same AS-PATH numbers.
match interface interface CONFIG-ROUTE-MAP Match routes whose next hop is a specific
interface. The parameters are:
• For a Fast Ethernet interface, enter the
keyword FastEthernet followed by the slot/
port information.
• For a 1-Gigabit Ethernet interface, enter the
keyword gigabitEthernet followed by the
slot/port information.
• For a loopback interface, enter the keyword
loopback followed by a number between
zero (0) and 16383.
• For a port channel interface, enter the keyword
port-channel followed by a number from 1
to 255 for TeraScale and ExaScale, 1 to 32 for
EtherScale.
• For a SONET interface, enter the keyword
sonet followed by the slot/port information.
• For a 10-Gigabit Ethernet interface, enter the
keyword tengigabitEthernet followed by
the slot/port information.
• For a VLAN, enter the keyword vlan followed
by a number from 1 to 4094.
E-Series ExaScale platforms support
4094 VLANs with FTOS version 8.2.1.0
and later. Earlier ExaScale supports 2094
VLANS.
match ip address prefix-list-name CONFIG-ROUTE-MAP Match destination routes specified in a prefix list
(IPv4).
match ipv6 address prefix-list-name CONFIG-ROUTE-MAP Match destination routes specified in a prefix list
(IPv6).
match ip next-hop CONFIG-ROUTE-MAP Match next-hop routes specified in a prefix list
{access-list-name | prefix-list (IPv4).
prefix-list-name}
match ipv6 next-hop CONFIG-ROUTE-MAP Match next-hop routes specified in a prefix list
{access-list-name | prefix-list (IPv6).
prefix-list-name}
match ipv6 route-source CONFIG-ROUTE-MAP Match source routes specified in a prefix list
{access-list-name | prefix-list (IPv6).
prefix-list-name}
match origin {egp | igp | CONFIG-ROUTE-MAP Match BGP routes based on the ORIGIN attribute.
incomplete}
To configure a set condition, use any or all of the following commands in the ROUTE-MAP mode:
set as-path prepend as-number [... CONFIG-ROUTE-MAP Add an AS-PATH number to the beginning of
as-number] the AS-PATH
set automatic-tag CONFIG-ROUTE-MAP Generate a tag to be added to redistributed
routes.
set level {backbone | level-1 | level-1-2 CONFIG-ROUTE-MAP Specify an OSPF area or ISIS level for
| level-2 | stub-area } redistributed routes.
set local-preference value CONFIG-ROUTE-MAP Specify a value for the BGP route’s
LOCAL_PREF attribute.
set metric-type {external | internal | CONFIG-ROUTE-MAP Specify an OSPF or ISIS type for redistributed
type-1 | type-2} routes.
set next-hop ip-address CONFIG-ROUTE-MAP Assign an IP address as the route’s next hop.
set ipv6 next-hop ip-address CONFIG-ROUTE-MAP Assign an IPv6 address as the route’s next hop.
set origin {egp | igp | incomplete} CONFIG-ROUTE-MAP Assign an ORIGIN attribute.
set tag tag-value CONFIG-ROUTE-MAP Specify a tag for the redistributed routes.
Use these commands to create route map instances. There is no limit to the number of set and match
commands per route map, but the convention is to keep the number of match and set filters in a route map
low. Set commands do not require a corresponding match command.
Route maps on their own cannot affect traffic and must be included in different commands to affect routing
traffic. To apply a route map to traffic on the E-Series, you must call or include that route map in a
command such as the redistribute or default-information originate commands in OSPF, ISIS, and BGP.
Route redistribution occurs when FTOS learns the advertising routes from static or directly connected
routes or another routing protocol. Different protocols assign different values to redistributed routes to
identify either the routes and their origins. The metric value is the most common attribute that is changed
to properly redistribute other routes into a routing protocol. Other attributes that can be changed include
the metric type (for example, external and internal route types in OSPF) and route tag. Use the redistribute
command in OSPF, RIP, ISIS, and BGP to set some of these attributes for routes that are redistributed into
those protocols.
Route maps add to that redistribution capability by allowing you to match specific routes and set or change
more attributes when redistributing those routes.
In Figure 8-25, the redistribute command calls the route map static ospf to redistribute only certain
static routes into OSPF. According to the route map static ospf, only routes that have a next hop of
Gigabitethernet interface 0/0 and that have a metric of 255 will be redistributed into the OSPF backbone
area.
Note: When re-distributing routes using route-maps, the user must take care to create the
route-map defined in the redistribute command under the routing protocol. If no route-map is
created, then NO routes are redistributed.
One method for identifying routes from different routing protocols is to assign a tag to routes from that
protocol. As the route enters a different routing domain, it is tagged and that tag is passed along with the
route as it passes through different routing protocols. This tag can then be used when the route leaves a
routing domain to redistribute those routes again.
In Figure 8-26, the redistribute ospf command with a route map is used in the ROUTER RIP mode to
apply a tag of 34 to all internal OSPF routes that are redistributed into RIP.
Figure 8-26. Tagging OSPF Routes Entering a RIP Routing Domain
!
router rip
redistribute ospf 34 metric 1 route-map torip
!
route-map torip permit 10
match route-type internal
set tag 34
!
Continue clause
Normally, when a match is found, set clauses are executed, and the packet is then forwarded; no more
route-map modules are processed. If the continue command is configured at the end of a module, the next
module (or a specified module) is processed even after a match is found. Figure 8-27 shows a continue
clause at the end of a route-map module. In this example, if a match is found in the route-map “test”
module 10, module 30 will be processed.
Note: If the continue clause is configured without specifying a module, the next sequential module is
processed.
!
route-map test permit 10
match commu comm-list1
set community 1:1 1:2 1:3
set as-path prepend 1 2 3 4 5
continue 30!
Protocol Overview
Bidirectional Forwarding Detection (BFD) is a protocol that is used to rapidly detect communication
failures between two adjacent systems. It is a simple and lightweight replacement for existing routing
protocol link state detection mechanisms. It also provides a failure detection solution for links on which no
routing protocol is used.
BFD is a simple hello mechanism. Two neighboring systems running BFD establish a session using a
three-way handshake. After the session has been established, the systems exchange periodic control
packets at sub-second intervals. If a system does not receive a hello packet within a specified amount of
time, routing protocols are notified that the forwarding path is down.
BFD provides forwarding path failure detection times on the order of milliseconds rather than seconds as
with conventional routing protocol hellos. It is independent of routing protocols, and as such provides a
consistent method of failure detection when used across a network. Networks converge faster because BFD
triggers link state changes in the routing protocol sooner and more consistently, because BFD can
eliminate the use of multiple protocol-dependent timers and methods.
BFD also carries less overhead than routing protocol hello mechanisms. Control packets can be
encapsulated in any form that is convenient, and, on Dell Force10 routers, sessions are maintained by BFD
Agents that reside on the line card, which frees resources on the RPM. Only session state changes are
reported to the BFD Manager (on the RPM), which in turn notifies the routing protocols that are registered
with it.
BFD is an independent and generic protocol, which all media, topologies, and routing protocols can
support using any encapsulation. Dell Force10 has implemented BFD at Layer 3 and with UDP
encapsulation. BFD functionality will be implemented in phases. OSPF, IS-IS (not on C-Series), VRRP,
VLANs, LAGs, static routes, and physical ports support BFD, based on the IETF internet draft
draft-ietf-bfd-base-03.
Two neighboring systems running BFD establish a session using a three-way handshake. After the session
has been established, the systems exchange control packets at agreed upon intervals. In addition, systems
send a control packet anytime there is a state change or change in a session parameter; these control
packets are sent without regard to transmit and receive intervals.
If a system does not receive a control packet within an agreed-upon amount of time, the BFD Agent
changes the session state to Down. It then notifies the BFD Manager of the change, and sends a control
packet to the neighbor that indicates the state change (though it might not be received if the link or
receiving interface is faulty). The BFD Manager notifies the routing protocols that are registered with it
(clients) that the forwarding path is down, and a link state change is triggered in all protocols.
Note: A session state change from Up to Down is the only state change that triggers a link state change in
the routing protocol client.
Control packets are encapsulated in UDP packets. Figure 9-1 shows the complete encapsulation of a BFD
control packet inside an IPv4 packet.
Preamble Start Frame Destination MAC Source MAC Ethernet Type IP Packet Padding FCS
Delimiter (0x8800)
BFD in IPv4 Packet Format
Version IHL TOS Total Length Flags Frag Offset TTL Protocol Header Src IP Addr Dest IP Addr Options Padding UDP Packet
(4) (255) Checksum
Version Diag Code State Flags Detect Mult Length My Your Desired Required Required Min Auth Type Auth Length Auth Data
(1) Discriminator Discriminator Min TX Interval Min RX Interval Echo RX Interval
Range: 0-31
Code: 0: AdminDown Random number generated by The minimum interval between
Range: 0-31 1: Down the local system to identify control packets that the local
Code: 0: No Diagnostic Bit: P: Poll
2: Init a session system is capable of supporting
1: Control Detection Time Expired F: Final
3: Up C: Control Plane Independent The minimum interval between
2: Echo Function Failed Random number generated by
A: Authentication Present remote system to identify a Echo packtes that the local system
3: Neighbor Signaled Session Down
D: Demand session is capable of supporting
4: Forwarding Plane Reset
5: Path Down (Final bit reserved)
6: Concatenated Path Down
7: Administratively Down
8: Reverse Concatenated Path Down
9-31: Reserved for Future Use
Field Description
Diagnostic Code The reason that the last session failed.
State The current local session state. See BFD sessions.
Flag A bit that indicates packet function. If the poll bit is set, the receiving system must respond as
soon as possible, without regard to its transmit interval. The responding system clears the poll
bit and sets the final bit in its response. The poll and final bits are used during the handshake
and Demand mode (see BFD sessions).
Note: FTOS does not currently support multi-point sessions, Demand mode,
authentication, or control plane independence; these bits are always clear.
Detection Multiplier The number of packets that must be missed in order to declare a session down.
Length The entire length of the BFD packet.
My Discriminator A random number generated by the local system to identify the session.
Your Discriminator A random number generated by the remote system to identify the session. Discriminator
values are necessary to identify the session to which a control packet belongs since there can
be many sessions running on a single interface.
Desired Min TX Interval The minimum rate at which the local system would like to send control packets to the remote
system.
Required Min RX Interval The minimum rate at which the local system would like to receive control packets from the
remote system.
Required Min Echo RX The minimum rate at which the local system would like to receive echo packets.
Note: FTOS does not currently support the echo function.
Authentication Type
An optional method for authenticating control packets.
Authentication Length
Note: FTOS does not currently support the BFD authentication function.
Authentication Data
Two important parameters are calculated using the values contained in the control packet.
• Transmit interval — Transmit interval is the agreed-upon rate at which a system sends control
packets. Each system has its own transmit interval, which is the greater of the last received remote
Desired TX Interval and the local Required Min RX Interval.
• Detection time — Detection time is the amount of time that a system does not receive a control
packet, after which the system determines that the session has failed. Each system has its own
detection time.
• In Asynchronous mode: Detection time is the remote Detection Multiplier multiplied by greater of
the remote Desired TX Interval and the local Required Min RX Interval.
• In Demand mode: Detection time is the local Detection Multiplier multiplied by the greater of the
local Desired Min TX and the remote Required Min RX Interval.
BFD must be enabled on both sides of a link in order to establish a session. The two participating systems
can assume either of two roles:
• Active—The active system initiates the BFD session. Both systems can be active for the same session.
• Passive—The passive system does not initiate a session. It only responds to a request for session
initialization from the active system.
A session can have four states: Administratively Down, Down, Init, and Up.
• Administratively Down—The local system will not participate in a particular session.
• Down—The remote system is not sending any control packets or at least not within the detection time
for a particular session.
• Init—The local system is communicating.
• Up—The both systems are exchanging control packets.
A three-way handshake must take place between the systems that will participate in the BFD session. The
handshake shown in Figure 9-2 assumes that there is one active and one passive system, and that this is the
first session established on this link. The default session state on both ports is Down.
1. The active system sends a steady stream of control packets that indicates that its session state is Down,
until the passive system responds. These packets are sent at the desired transmit interval of the Active
system, and the Your Discriminator field is set to zero.
2. When the passive system receives any of these control packets, it changes its session state to Init, and
sends a response that indicates its state change. The response includes its session ID in the My
Discriminator field, and the session ID of the remote system in the Your Discriminator field.
3. The active system receives the response from the passive system, and changes its session state to Up. It
then sends a control packet indicating this state change. This is the third and final part of of the
Figure 9-3 shows how the session state on a system changes based on the status notification it receives
from the remote system. For example, if a session on a system is down, and it receives a Down status
notification from the remote system, the session state on the local system changes to Init.
Down Init
Down
BFD on physical ports is useful when no routing protocol is enabled. Without BFD, if the remote system
fails, the local system does not remove the connected route until the first failed attempt to send a packet.
When BFD is enabled, the local system removes the route as soon as it stops receiving periodic control
packets from the remote system.
Verify that BFD is enabled globally using the command show running bfd, as shown in Figure 9-4.
To establish a session, BFD must be enabled at interface level on both ends of the link, as shown in
Figure 9-5. The configuration parameters do not need to match.
To establish a session:
2 Assign an IP address to the interface if one is not already ip address ip-address INTERFACE
assigned.
3 Identify the neighbor with which the interface will bfd neighbor ip-address INTERFACE
participate in the BFD session.
Verify that the session is established using the command show bfd neighbors, as shown in Figure 9-6.
The command show bfd neighbors detail shows more specific information about BFD sessions
(Figure 9-7).
Session Discriminator: 1
Neighbor Discriminator: 1
Local Addr: 2.2.2.1
Local MAC Addr: 00:01:e8:09:c3:e5
Remote Addr: 2.2.2.2
Remote MAC Addr: 00:01:e8:06:95:a2
Int: GigabitEthernet 4/24
State: Up
Configured parameters:
TX: 100ms, RX: 100ms, Multiplier: 3
Neighbor parameters:
TX: 100ms, RX: 100ms, Multiplier: 3
Actual parameters:
TX: 100ms, RX: 100ms, Multiplier: 3
Role: Active
Delete session on Down: False
Client Registered: CLI
Uptime: 00:03:57
Statistics:
Number of packets received from neighbor: 1775
Number of packets sent to neighbor: 1775
Number of state changes: 1
Number of messages from IFA about port state change: 0
Number of messages communicated b/w Manager and Agent: 4
When both interfaces are configured for BFD, log messages are displayed indicating state changes, as
shown in Message 1.
BFD sessions are configured with default intervals and a default role (active). The parameters that can be
configured are: Desired TX Interval, Required Min RX Interval, Detection Multiplier, and system role.
These parameters are configured per interface; if you change a parameter, the change affects all physical
port sessions on that interface. Dell Force10 recommends maintaining the default values.
1 Change session parameters for all bfd interval milliseconds min_rx milliseconds INTERFACE
sessions on an interface. multiplier value role [active | passive]
View session parameters using the show bfd neighbors detail command.
Session Discriminator: 1
Neighbor Discriminator: 1
Local Addr: 2.2.2.1
Local MAC Addr: 00:01:e8:09:c3:e5
Remote Addr: 2.2.2.2
Remote MAC Addr: 00:01:e8:06:95:a2
Int: GigabitEthernet 4/24
State: Up
Configured parameters:
TX: 100ms, RX: 100ms, Multiplier: 4 Parameter Changes
Neighbor parameters:
TX: 100ms, RX: 100ms, Multiplier: 3
Actual parameters:
TX: 100ms, RX: 100ms, Multiplier: 4
Role: Passive
Delete session on Down: False
Client Registered: CLI
Uptime: 00:09:06
Statistics:
Number of packets received from neighbor: 4092
Number of packets sent to neighbor: 4093
Number of state changes: 1
Number of messages from IFA about port state change: 0
Number of messages communicated b/w Manager and Agent: 7
BFD is enabled on all interfaces by default, though sessions are not created unless explicitly configured. If
BFD is disabled, all of the sessions on that interface are placed in an Administratively Down state
(Message 2), and the remote systems are notified of the session state change (Message 3).
Message 3 Remote System State Change due to Local State Admin Down
R2>01:32:53: %RPM0-P:RP2 %BFDMGR-1-BFD_STATE_CHANGE: Changed session state to Down for neighbor 2.2.2.1
on interface Gi 2/1 (diag: 7)
Sessions are established for all neighbors that are the next hop of a static route.
R1 R2 R3
fnC0039mp
1 Establish BFD sessions for all neighbors that are the next hop ip route bfd CONFIGURATION
of a static route.
Verify that sessions have been created for static routes using the command show bfd neighbors, as shown
in Figure 9-10. View detailed session information using the command show bfd neighbors detail, as shown
in Figure 9-8.
BFD sessions are configured with default intervals and a default role. The parameters that can be
configured are: Desired TX Interval, Required Min RX Interval, Detection Multiplier, and system role.
These parameters are configured for all static routes; if you change a parameter, the change affects all
sessions for static routes.
1 Change parameters for all static route ip route bfd interval milliseconds min_rx CONFIGURATION
sessions. milliseconds multiplier value role [active |
passive]
View session parameters using the command show bfd neighbors detail, as shown in Figure 9-8 on
page 179.
If BFD is disabled, all static route BFD sessions are torn down. A final Admin Down packet is sent to all
neighbors on the remote systems, and those neighbors change to the Down state (Message 3 on page 179).
BFD sessions can be established with all OSPF neighbors at once, or sessions can be established with all
neighbors out of a specific interface. Sessions are only established when the OSPF adjacency is in the full
state.
AREA 0 AREA 1
R1 R2 R3
4/24 2/1 2/2 6/0
R4 2.2.4.2/24
1/1
fnC0040mp
1 Establish sessions with all OSPF neighbors on a ip ospf bfd all-neighbors INTERFACE
single interface.
View the established sessions using the command show bfd neighbors, as shown in Figure 9-12.
BFD sessions are configured with default intervals and a default role. The parameters that can be
configured are: Desired TX Interval, Required Min RX Interval, Detection Multiplier, and system role.
These parameters are configured for all OSPF sessions or all OSPF sessions on a particular interface; if
you change a parameter globally, the change affects all OSPF neighbors sessions. If you change a
parameter at interface level, the change affects all OSPF sessions on that interface.
1 Change parameters for all OSPF ip ospf bfd all-neighbors interval INTERFACE
sessions on an interface. milliseconds min_rx milliseconds multiplier
value role [active | passive]
View session parameters using the command show bfd neighbors detail, as shown in Figure 9-8 on
page 179.
If BFD is disabled globally, all sessions are torn down, and sessions on the remote system are placed in a
Down state. If BFD is disabled on an interface, sessions on the interface are torn down, and sessions on the
remote system are placed in a Down state (Message 3 on page 179). Disabling BFD does not trigger a
change in BFD clients; a final Admin Down packet is sent before the session is terminated.
1 Disable BFD sessions with all OSPF ip ospf bfd all-neighbors disable INTERFACE
neighbors out of an interface
Prerequisites
Before configuring BFD for BGP, you must first perform the following tasks:
1. Configure BGP on the routers that you want to interconnect as described in BGP Configuration on
page 225.
2. Enable fast fall-over for BGP neighbors to reduce convergence time (neighbor fall-over command) as
described in BGP fast fall-over on page 235.
Router 1 Router 2
2/2 1/1
2.2.4.2 2.2.4.3
Exterior BGP
AS 1 AS 2
Force10(conf )# bfd enable Force10(conf )# bfd enable
Force10(conf )# router bgp 1 Force10(conf )# router bgp 2
Force10(conf-router-bgp)# neighbor 2.2.4.3 remote-as 2 Force10(conf-router-bgp)# neighbor 2.2.4.2 remote-as 1
Force10(conf-router-bgp)# neighbor 2.2.4.3 no shutdown Force10(conf-router-bgp)# neighbor 2.2.4.2 no shutdown
Force10(conf-router-bgp)# bfd all-neighbors interval 200 min_rx 200 Force10(conf-router-bgp)# bfd all-neighbors interval 200 min_rx 200
multiplier 6 role active multiplier 6 role active
OR OR
Force10(conf-router-bgp)# neighbor 2.2.4.3 bfd Force10(conf-router-bgp)# neighbor 2.2.4.2 bfd
neighbor:
• By establishing BFD sessions with all neighbors discovered by BGP (bfd all-neighbors command)
• By establishing a BFD session with a specified BGP neighbor (neighbor {ip-address | peer-group-name}
bfd command)
BFD packets originating from a router are assigned to the highest priority egress queue to minimize
transmission delays. Incoming BFD control packets received from the BGP neighbor are assigned to the
highest priority queue within the Control Plane Policing (COPP) framework to avoid BFD packets drops
due to queue congestion.
BFD notifies BGP of any failure conditions that it detects on the link. Recovery actions are initiated by
BGP.
BFD for BGP is supported only on directly-connected BGP neighbors and only in BGP IPv4 networks.
• On an E-Series TeraScale or C-Series router, up to 100 simultaneous BFD sessions are supported per
line card.
• On an S4810 router, up to 64 simultaneous BFD sessions are supported.
As long as each BFD for BGP neighbor receives a BFD control packet within the configured BFD interval
for failure detection, the BFD session remains up and BGP maintains its adjacencies. If a BFD for BGP
neighbor does not receive a control packet within the detection interval, the router informs any clients of
the BFD session (other routing protocols) about the failure. It then depends on the individual routing
protocols that uses the BGP link to determine the appropriate response to the failure condition. The typical
response is usually to terminate the peering session for the routing protocol and reconverge by bypassing
the failed neighboring router. A log message is generated whenever BFD detects a failure condition.
You can configure BFD for BGP on the following types of interfaces: physical port (10GE or 40GE), port
channel, and VLAN.
To establish a BFD session with one or all BGP neighbors, follow these steps:
2 Specify the AS number and enter ROUTER router bgp as-number CONFIGURATION
BGP configuration mode.
5 Configure parameters for a BFD session bfd all-neighbors [interval millisecs CONFIG-ROUTER-
established with all neighbors discovered by min_rx millisecs multiplier value role BGP
BGP. {active | passive}]
OR OR
Notes:
- When you establish a BFD session with a specified BGP neighbor or peer group using the neighbor bfd
command, the default BFD session parameters are used (interval: 100 milliseconds, min_rx: 100 milliseconds,
multiplier: 3 packets, and role: active).
- When you explicitly enable or disable a BGP neighbor for a BFD session with the neighbor bfd or neighbor
bfd disable commands:
- The neighbor does not inherit the BFD enable/disable values configured with the bfd all-neighbors command
or configured for the peer group to which the neighbor belongs.
- The neighbor only inherits the global timer values configured with the bfd all-neighbors command (interval,
min_rx, and multiplier).
To disable a BFD for BGP session with a specified neighbor, enter the neighbor {ip-address |
peer-group-name} bfd disable command in ROUTER BGP configuration mode.
To remove the disabled state of a BFD for BGP session with a specified neighbor, enter the no neighbor
{ip-address | peer-group-name} bfd disable command in ROUTER BGP configuration mode. The BGP link
with the neighbor returns to normal operation and uses the BFD session parameters globally configured
with the bfd all-neighbors command or configured for the peer group to which the neighbor belongs.
If you establish a BFD session for the members of a peer group (neighbor peer-group-name bfd command
in ROUTER BGP configuration mode), members of the peer group may have BFD:
• Explicitly enabled (neighbor ip-address bfd command)
• Explicitly disabled (neighbor ip-address bfd disable command)
• Inherited (neither explicitly enabled or disabled) according to the current BFD configuration of the
peer group. For information on BGP peer groups, see Configure Peer Groups on page 232.
If you explicitly enable (or disable) a BGP neighbor for BFD that belongs to a peer group:
• The neighbor does not inherit the BFD enable/disable values configured with the bfd all-neighbors
command or configured for the peer group to which the neighbor belongs.
If you explicitly enable (or disable) a peer group for BFD that has no BFD parameters configured (e.g.
advertisement interval) using the neighbor peer-group-name bfd command, the peer group inherits any
BFD settings configured with the bfd all-neighbors command.
To display information about BFD for BGP sessions on a router, enter one of the following show
commands:
Verify a BFD for BGP configuration. show running-config bgp EXEC Privilege
Figure 9-14
Verify that a BFD for BGP session has been show bfd neighbors [interface] [detail] EXEC Privilege
successfully established with a BGP neighbor. A Figure 9-15 and Figure 9-16
line-by-line listing of established BFD
adjacencies is displayed.
Display BFD packet counters for sessions with show bfd counters bgp [interface] EXEC Privilege
BGP neighbors. Figure 9-17
Check to see if BFD is enabled for BGP show ip bgp summary EXEC Privilege
connections. Figure 9-18
Displays routing information exchanged with show ip bgp neighbors [ip-address] EXEC Privilege
BGP neighbors, including BFD for BGP Figure 9-19
sessions.
Figure 9-15. Verifying BFD Sessions with BGP Neighbors: show bfd neighbors Command
R2# show bfd neighbors
Session Discriminator: 9
Neighbor Discriminator: 10
Local Addr: 1.1.1.3
Local MAC Addr: 00:01:e8:66:da:33
Remote Addr: 1.1.1.2
Remote MAC Addr: 00:01:e8:8a:da:7b
Int: TenGigabitEthernet 6/0
State: Up
Configured parameters:
TX: 100ms, RX: 100ms, Multiplier: 3 BFD session parameters: TX (packet transmission), RX
Neighbor parameters: (packet reception), and multiplier (maximum number of
TX: 100ms, RX: 100ms, Multiplier: 3 missed packets)
Actual parameters:
TX: 100ms, RX: 100ms, Multiplier: 3
Role: Active
Delete session on Down: True
Client Registered: BGP
Uptime: 00:07:55
Statistics:
Number of packets received from neighbor: 4762
Number of packets sent to neighbor: 4490
Number of state changes: 2
Number of messages from IFA about port state change: 0
Number of messages communicated b/w Manager and Agent: 5
Session Discriminator: 10
Neighbor Discriminator: 11
Local Addr: 2.2.2.3
Local MAC Addr: 00:01:e8:66:da:34
Remote Addr: 2.2.2.2
Remote MAC Addr: 00:01:e8:8a:da:7b
Int: TenGigabitEthernet 6/1
State: Up
Configured parameters:
TX: 100ms, RX: 100ms, Multiplier: 3
Neighbor parameters:
TX: 100ms, RX: 100ms, Multiplier: 3
Actual parameters:
TX: 100ms, RX: 100ms, Multiplier: 3
Role: Active
Delete session on Down: True
Client Registered: BGP
Uptime: 00:02:22
Statistics:
Number of packets received from neighbor: 1428
Number of packets sent to neighbor: 1428
Number of state changes: 1
Number of messages from IFA about port state change: 0
Number of messages communicated b/w Manager and Agent: 4
Figure 9-18. Displaying BFD for BGP Status: show ip bgp summary Command
R2# show ip bgp summary
Message displayed when BFD is enabled for
BGP router identifier 10.0.0.1, local AS number 2
BGP table version is 0, main routing table version 0 BGP connections
BFD is enabled, Interval 100 Min_rx 100 Multiplier 3 Role Active
3 neighbor(s) using 24168 bytes of memory
BFD sessions can be established for all IS-IS neighbors at once or sessions can be established for all
neighbors out of a specific interface.
6/0
1 Establish sessions with all IS-IS neighbors out of an isis bfd all-neighbors INTERFACE
interface.
View the established sessions using the command show bfd neighbors, as shown in Figure 9-21.
BFD sessions are configured with default intervals and a default role. The parameters that can be
configured are: Desired TX Interval, Required Min RX Interval, Detection Multiplier, and system role.
These parameters are configured for all IS-IS sessions or all IS-IS sessions out of an interface; if you
change a parameter globally, the change affects all IS-IS neighbors sessions. If you change a parameter at
interface level, the change affects all IS-IS sessions on that interface.
1 Change parameters for all IS-IS bfd all-neighbors interval milliseconds ROUTER-ISIS
sessions. min_rx milliseconds multiplier value role
[active | passive]
1 Change parameters for all IS-IS isis bfd all-neighbors interval milliseconds INTERFACE
sessions out of an interface. min_rx milliseconds multiplier value role
[active | passive]
View session parameters using the command show bfd neighbors detail, as shown in Figure 9-8 on
page 179.
If BFD is disabled globally, all sessions are torn down, and sessions on the remote system are placed in a
Down state. If BFD is disabled on an interface, sessions on the interface are torn down, and sessions on the
remote system are placed in a Down state (Message 3 on page 179). Disabling BFD does not trigger a
change in BFD clients; a final Admin Down packet is sent before the session is terminated.
1 Disable BFD sessions with all IS-IS isis bfd all-neighbors disable INTERFACE
neighbors out of an interface
BFD sessions can be established for all VRRP neighbors at once, or a session can be established with a
particular neighbor.
VIRTUAL
IP Address: 2.2.5.4
fnC0042mp
1 Establish sessions with all VRRP neighbors. vrrp bfd all-neighbors INTERFACE
The master router does not care about the state of the backup router, so it does not participate in any VRRP
BFD sessions. Therefore, VRRP BFD sessions on the backup router cannot change to the UP state. The
master router must be configured to establish an individual VRRP session the backup router.
1 Establish a session with a particular VRRP vrrp bfd neighbor ip-address INTERFACE
neighbor.
View the established sessions using the command show bfd neighbors, as shown in Figure 9-23.
Session state information is also shown in the show vrrp command output, as shown in Figure 9-24.
BFD sessions are configured with default intervals and a default role. The parameters that can be
configured are: Desired TX Interval, Required Min RX Interval, Detection Multiplier, and system role.
You can change parameters for all VRRP sessions for a particular neighbor.
1 Change parameters for all VRRP vrrp bfd all-neighbors interval milliseconds INTERFACE
sessions. min_rx milliseconds multiplier value role
[active | passive]
1 Change parameters for a particular vrrp bfd neighbor ip-address interval INTERFACE
VRRP session. milliseconds min_rx milliseconds multiplier
value role [active | passive]
View session parameters using the command show bfd neighbors detail, as shown in Figure 9-8 on
page 179.
If any or all VRRP sessions are disabled, the sessions are torn down. A final Admin Down control packet
is sent to all neighbors and sessions on the remote system change to the Down state (Message 3 on
page 179).
To establish a session, BFD must be enabled at interface level on both ends of the link, as shown in
Figure 9-25. The session parameters do not need to match.
fnC0043mp
1 Establish sessions with a VLAN neighbor. bfd neighbor ip-address INTERFACE VLAN
View the established sessions using the command show bfd neighbors, as shown in Figure 9-26.
Caution: When configuring BFD on VLAN or LAG interfaces on the C-Series, Dell Force10 recommends
a minimum value of 500 milliseconds for both the transmit and minimum receive time, which yields a final
detection time of (500ms *3) 1500 milliseconds.
1 Change session parameters for all bfd interval milliseconds min_rx milliseconds INTERFACE VLAN
sessions on an interface. multiplier value role [active | passive]
View session parameters using the command show bfd neighbors detail, as shown in Figure 9-8 on
page 179.
If BFD is disabled on an interface, sessions on the interface are torn down. A final Admin Down control
packet is sent to all neighbors, and sessions on the remote system change to the Down state (Message 3 on
page 179).
There is one BFD Agent for VLANs and port-channels, which resides on RP2 as opposed to the other
agents which are on the line card. Therefore, the 100 total possible sessions that this agent can maintain is
shared for VLANs and port-channels.
To establish a session, BFD must be enabled at interface level on both ends of the link, as shown in
Figure 9-5. The session parameters do not need to match.
4/24
4 24 2/1
Port Channel 1
4
4/25 2/2
Force10(config-if-range-gi-2/1-2)# port-channel-protocol lacp
Force10(config-if-range-gi-2/1-2)# port-channel 1 mode active
Force10(config-if-range-gi-2/1-2)# no shutdown
Force10(config-if-range-gi-2/1-2)# interface port-channel 1
Force10(config-if-po-1)# ip address 2.2.2.2/24
Force10(config-if-po-1)# no shutdown
Force10(config-if-po-1)# bfd neighbor 2.2.2.1
fnC0044mp
View the established sessions using the command show bfd neighbors, as shown in Figure 9-21.
BFD sessions are configured with default intervals and a default role. The parameters that can be
configured are: Desired TX Interval, Required Min RX Interval, Detection Multiplier, and system role.
These parameters are configured per interface; if you change a parameter, the change affects all sessions on
that interface.
Caution: When configuring BFD on VLAN or LAG interfaces on the C-Series, Dell Force10 recommends
a minimum value of 500 milliseconds for both the transmit and minimum receive time, which yields a final
detection time of (500ms *3) 1500 milliseconds.
1 Change session parameters for all bfd interval milliseconds min_rx milliseconds INTERFACE
sessions on a port-channel interface. multiplier value role [active | passive] PORT-CHANNEL
View session parameters using the command show bfd neighbors detail, as shown in Figure 9-8 on
page 179.
If BFD is disabled on an interface, sessions on the interface are torn down. A final Admin Down control
packet is sent to all neighbors, and sessions on the remote system are placed in a Down state (Message 3 on
page 179).
Troubleshooting BFD
Examine control packet field values using the command debug bfd detail. Figure 9-29 shows a three-way
handshake using this command.
Examine control packets in hexadecimal format using the command debug bfd packet.
RX packet dump:
20 c0 03 18 00 00 00 05 00 00 00 04 00 01 86 a0
00 01 86 a0 00 00 00 00
00:34:13 : Sent packet for session with neighbor 2.2.2.2 on Gi 4/24
TX packet dump:
20 c0 03 18 00 00 00 04 00 00 00 05 00 01 86 a0
00 01 86 a0 00 00 00 00
00:34:14 : Received packet for session with neighbor 2.2.2.2 on Gi 4/24
RX packet dump:
20 c0 03 18 00 00 00 05 00 00 00 04 00 01 86 a0
00 01 86 a0 00 00 00 00
00:34:14 : Sent packet for session with neighbor 2.2.2.2 on Gi 4/24
TX packet dump:
The output for the command debug bfd event is the same as the log messages that appear on the console by
default.
This chapter is intended to provide a general description of Border Gateway Protocol version 4 (BGPv4) as
it is supported in the Dell Force10 Operating System (FTOS).
• Protocol Overview
• Autonomous Systems (AS)
• Sessions and Peers
• Route Reflectors
• Confederations
• BGP Attributes
• Best Path Selection Criteria
• Weight
• Local Preference
• Multi-Exit Discriminators (MEDs)
• AS Path
• Next Hop
• Multiprotocol BGP
BGP protocol standards are listed in the Appendix 63, Standards Compliance chapter.
Protocol Overview
Border Gateway Protocol (BGP) is an external gateway protocol that transmits interdomain routing
information within and between Autonomous Systems (AS). Its primary function is to exchange network
reachability information with other BGP systems. BGP generally operates with an Internal Gateway
Protocol (IGP) such as OSPF or RIP, allowing you to communicate to external ASs smoothly. BGP adds
reliability to network connections be having multiple paths from one router to another.
AS Numbers (ASNs) are important because the ASN uniquely identifies each network on the Internet. The
IANA has reserved AS numbers 64512 through 65534 to be used for private purposes. The ASNs 0 and
65535 are reserved by the IANA and should not be used in a live environment.
Autonomous Systems can be grouped into three categories, defined by their connections and operation.
A multihomed AS is one that maintains connections to more than one other AS. This allows the AS to
remain connected to the internet in the event of a complete failure of one of their connections. However,
this type of AS does not allow traffic from one AS to pass through on its way to another AS. A simple
example of this is seen in Figure 10-1.
A transit AS is one that provides connections through itself to separate networks. For example as seen in
Figure 10-1, Router 1 can use Router 2 (the transit AS) to connect to Router 4. ISPs are always transit ASs,
because they provide connections from one network to another. The ISP is considered to be “selling transit
service” to the customer network, so thus the term Transit AS.
When BGP operates inside an Autonomous System (AS1 or AS2 as seen in Figure 10-1), it is
referred to as Internal BGP (IBGP Interior Border Gateway Protocol). When BGP operates
between Autonomous Systems (AS1 and AS2), it is called External BGP (EBGP Exterior Border
Gateway Protocol). IBGP provides routers inside the AS with the knowledge to reach routers external to
the AS. EBGP routers exchange information with other EBGP routers as well as IBGP routers to maintain
connectivity and accessibility.
Router 3 Router 5
Exterior BGP
Router 7
AS 1 AS 2
BGP version 4 (BGPv4) supports classless interdomain routing and aggregate routes and AS paths. BGP
is a path vector protocol - a computer network in which BGP maintains the path that update
information takes as it diffuses through the network. Updates traveling through the network and
returning to the same node are easily detected and discarded.
BGP does not use traditional Interior Gateway Protocol (IGP) matrix, but makes routing decisions based
on path, network policies and/or rulesets. Unlike most protocols, BGP uses TCP as its transport protocol.
Since each BGP routers talking to another router is a session, a BGP network needs to be in “full mesh”.
This is a topology that has every router directly connected to every other router. For example, as seen in
Figure 10-2, four routers connected in a full mesh have three peers each, six routers have 5 peers each, and
eight routers in full mesh will have seven peers each.
4 Routers
6 Routers
8 Routers
The number of BGP speakers each BGP peer must maintain increases exponentially. Network
management quickly becomes impossible.
Establishing a session
Information exchange between peers is driven by events and timers. The focus in BGP is on the traffic
routing policies.
The first state is the Idle mode. BGP initializes all resources, refuses all inbound BGP connection attempts,
and initiates a TCP connection to the peer.
The next state is Connect. In this state the router waits for the TCP connection to complete, transitioning
to the OpenSent state if successful.
If that transition is not successful, BGP resets the ConnectRetry timer and transitions to the Active state
when the timer expires.
In the Active state, the router resets the ConnectRetry timer to zero, and returns to the Connect state.
Upon successful OpenSent transition, the router sends an Open message and waits for one in return.
Keepalive messages are exchanged next, and upon successful receipt, the router is placed in the
Established state. Keepalive messages continue to be sent at regular periods (established by the Keepalive
timer) to verify connections.
Once established, the router can now send/receive Keepalive, Update, and Notification messages to/from
its peer.
Peer Groups
Peer Groups are neighbors grouped according to common routing policies. They enable easier system
configuration and management by allowing groups of routers to share and inherit policies.
Peer groups also aid in convergence speed. When a BGP process needs to send the same information to a
large number of peers, it needs to set up a long output queue to get that information to all the proper peers.
If they are members of a peer group, however, the information can be sent to one place then passed onto
the peers within the group.
Route Reflectors
Route Reflectors reorganize the iBGP core into a hierarchy and allows some route advertisement rules.
Route reflection divides iBGP peers into two groups: client peers and nonclient peers. A route reflector and
its client peers form a route reflection cluster. Since BGP speakers announce only the best route for a given
prefix, route reflector rules are applied after the router makes its best path decision.
• If a route was received from a nonclient peer, reflect the route to all client peers.
• If the route was received from a client peer, reflect the route to all nonclient and all client peers.
G are members of the same AS - AS100. These routers are also in the same Route Reflection Cluster,
where Router D is the Route Reflector. Router E and H are client peers of Router D; Routers B and C and
nonclient peers of Router D.
{
Router A Router B Router E Router F
iBGP Routes
{
eBGP Route
1. Router B receives an advertisement from Router A through eBGP. Since the route is learned through
eBGP, Router B advertises it to all its iBGP peers: Routers C and D.
2. Router C receives the advertisement but does not advertise it to any peer because its only other peer is
Router D, an iBGP peer, and Router D has already learned it through iBGP from Router B.
3. Router D does not advertise the route to Router C because Router C is a nonclient peer and the route
advertisement came from Router B who is also a non-client peer.
4. Router D does reflect the advertisement to Routers E and G because they are client peers of Router D.
5. Routers E and G then advertise this iBGP learned route to their eBGP peers Routers F and H.
Confederations
Communities
BGP communities are sets of routes with one or more common attributes. This is a way to assign
common attributes to multiple routes at the same time.
• Weight
• Local Preference
• Multi-Exit Discriminators (MEDs)
• Origin
• AS Path
• Next Hop
The best path in each group is selected based on specific criteria. Only one “best path” is selected at a time.
If any of the criteria results in more than one path, BGP moves on to the next option in the list. For
example, two paths may have the same weights, but different local preferences. BGP sees that the Weight
criteria results in two potential “best paths” and moves to local preference to reduce the options. If a
number of best paths is determined, this selection criteria is applied to group’s best to determine the
ultimate best path.
In non-deterministic mode (the bgp non-deterministic-med command is applied), paths are compared in
the order in which they arrive. This method can lead to FTOS choosing different best paths from a set of
paths, depending on the order in which they were received from the neighbors, since MED may or may not
get compared between adjacent paths. In deterministic mode, FTOS compares MED between adjacent
paths within an AS group since all paths in the AS group are from the same AS.
Figure 10-4 illustrates the decisions BGP goes through to select the best path. The list following the
illustration details the path selection criteria.
Tie Breakers
Lowest
Cluster ID
List
from
Lowest
Router ID
from
Lowest
Neighbor
Addr
• Routes originated with the network or redistribute commands are preferred over routes originated
with the aggregate-address command.
4. Prefer the path with the shortest AS_PATH (unless the bgp bestpath as-path ignore command is
configured, then AS_PATH is not considered). The following criteria apply:
• An AS_SET has a path length of 1, no matter how many ASs are in the set.
• A path with no AS_PATH configured has a path length of 0.
• AS_CONFED_SET is not included in the AS_PATH length.
After a number of best paths is determined, this selection criteria is applied to group’s best to determine the
ultimate best path.
In non-deterministic mode (the bgp non-deterministic-med command is applied), paths are compared in
the order in which they arrive. This method can lead to FTOS choosing different best paths from a set of
paths, depending on the order in which they were received from the neighbors since MED may or may not
get compared between adjacent paths. In deterministic mode, FTOS compares MED between adjacent
paths within an AS group since all paths in the AS group are from the same AS.
The Weight attribute is local to the router and is not advertised to neighboring routers. If the router learns
about more than one route to the same destination, the route with the highest weight will be preferred. The
route with the highest weight is installed in the IP routing table.
Local Preference
Local Preference (LOCAL_PREF) represents the degree of preference within the entire AS. The higher the
number, the greater the preference for the route.
The Local Preference (LOCAL_PREF) is one of the criteria used to determine the best path, so keep in
mind that other criteria may impact selection, as shown in Figure 10-4. For this example, assume that
LOCAL_PREF is the only attribute applied. In Figure 10-5, AS100 has two possible paths to AS 200.
Although the path through the Router A is shorter (one hop instead of two) the LOCAL_PREF settings
have the preferred path go through Router B and AS300. This is advertised to all routers within AS100
causing all BGP speakers to prefer the path through Router B.
Router E
Set Local Preference to 200
OC3 Link
Router E
Router D
AS 300
Router F
An MED is a non-transitive attribute. If AS100 sends an MED to AS200, AS200 does not pass it on to
AS300 or AS400. The MED is a locally relevant attribute to the two participating Autonomous Systems
(AS100 and AS200).
Note that the MEDs are advertised across both links, so that if a link goes down AS 1 still has connectivity
to AS300 and AS400.
Router E
OC3 Link
Router D
Set MED to 50
Note: With FTOS Release 8.3.1.0, configuring the set metric-type internal command in a route-map
advertises the IGP cost as MED to outbound EBGP peers when redistributing routes. The configured set
metric value overwrites the default IGP cost.
Origin
The Origin indicates the origin of the prefix, or how the prefix came into BGP. There are three Origin
codes: IGP, EGP, INCOMPLETE.
• IGP indicated the prefix originated from information learned through an interior gateway protocol.
• EGP indicated the prefix originated from information learned from an EGP protocol, which NGP
replaced.
• INCOMPLETE indicates that the prefix originated from an unknown source.
means that a route was learned from an external gateway protocol. An INCOMPLETE origin code
generally results from aggregation, redistribution or other indirect ways of installing routes into BGP.
In FTOS, these origin codes appear as shown in Figure 10-7. The question mark (?) indicates an Origin
code of INCOMPLETE. The lower case letter (i) indicates an Origin code of IGP.
FTOS#show ip bgp
BGP table version is 0, local router ID is 10.101.15.13
Status codes: s suppressed, d damped, h history, * valid, > best
Path source: I - internal, a - aggregate, c - confed-external, r - redistributed, n - network
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path
The AS Path is the list of all Autonomous Systems that all the prefixes listed in the update have passed
through. The local AS number is added by the BGP speaker when advertising to a eBGP neighbor.
In FTOS the AS Path is shown in Figure 10-8. Note that the Origin attribute is shown following the AS
Path information.
FTOS allows you to set the Next Hop attribute in the CLI. Setting the Next Hop attribute lets you
determine a router as the next hop for a BGP neighbor.
Multiprotocol BGP
MBGP for IPv6 unicast is supported on platforms ec
MBGP for IPv4 Multicast is supported on platform c e s
Multiprotocol Extensions for BGP (MBGP) is defined in IETF RFC 2858. MBGP allows different types of
address families to be distributed in parallel. This allows information about the topology of IP
Multicast-capable routers to be exchanged separately from the topology of normal IPv4 and IPv6 unicast
routers. It allows a multicast routing topology different from the unicast routing topology.
Note: It is possible to configure BGP peers that exchange both unicast and multicast network layer
reachability information (NLRI), but you cannot connect Multiprotocol BGP with BGP. Therefor, You
cannot redistribute Multiprotocol BGP routes into BGP.
When using multipath connectivity to an external AS, you can advertise the MED value selectively to each
peer for redistributed routes. For some peers you can set the internal/IGP cost as the MED while setting
others to a constant pre-defined metric as MED value.
FTOS 8.3.1.0 and later support configuring the set metric-type internal command in a route-map to
advertise the IGP cost as the MED to outbound EBGP peers when redistributing routes. The configured set
metric value overwrites the default IGP cost.
By using the redistribute command in conjunction with the route-map command, you can specify whether a
peer advertises the standard MED or uses the IGP cost as the MED.
does have metric-type internal configured, BGP advertises the IGP cost as MED.
• If the redistribute command has metric configured (route-map set metric or redistribute route-type
metric) and the BGP Peer out-bound route-map has metric-type internal configured, BGP advertises the
metric configured in the redistribute command as MED.
• If BGP peer out-bound route-map has metric configured, then all other metrics are overwritten by this.
Note: When redistributing static, connected or OSPF routes, there is no metric option. Simply assign the
appropriate route-map to the redistributed route.
redistribute isis metric 100 MED: IGP cost 100 MED: 100 MED: 100
FTOS 8.3.1.0 and later allow you to avoid unnecessary BGP best-path transitions between external paths
under certain conditions. The bgp bestpath router-id ignore command reduces network disruption caused
by routing and forwarding plane changes and allows for faster convergence.
4-Byte AS Numbers
FTOS Version 7.7.1 and later support 4-Byte (32-bit) format when configuring Autonomous System
Numbers (ASNs). The 4-Byte support is advertised as a new BGP capability (4-BYTE-AS) in the OPEN
message. If a 4-Byte BGP speaker has sent and received this capability from another speaker, all the
messages will be 4-octet. The behavior of a 4-Byte BGP speaker will be different with the peer depending
on whether the peer is 4-Byte or 2-Byte BGP speaker.
65001 Is 0.65501
4294967295 65535.65535
When creating Confederations, all the routers in a Confederation must be either 4-Byte or 2-Byte identified
routers. You cannot mix them.
Note: The ASDOT and ASDOT+ representations are supported only in conjunction with the 4-Byte AS
Numbers feature. If 4-Byte AS Numbers are not implemented, only ASPLAIN representation is supported.
ASPLAIN is the method FTOS has used for all previous FTOS versions.It remains the default method with
FTOS 8.2.1.0 and later. With the ASPLAIN notation, a 32 bit binary AS number is translated into a
decimal value.
• All AS Numbers between 0-65535 are represented as a decimal number when entered in the CLI as
well as when displayed in the show command outputs.
• AS Numbers larger than 65535 are represented using ASPLAIN notation as well. 65546 is
represented as 65546.
ASDOT+ representation splits the full binary 4-byte AS number into two words of 16 bits separated by a
decimal point (.): <high-order 16 bit value>.<low-order 16 bit value>. Some examples are shown in
Table 10-2.
• All AS Numbers between 0-65535 are represented as a decimal number, when entered in the CLI as
well as when displayed in the show command outputs.
• AS Numbers larger than 65535 is represented using ASDOT notation as <higher 2 bytes in
decimal>.<lower 2 bytes in decimal>. For example: AS 65546 is represented as 1.10.
65536 appear in integer format (asplain); AS Numbers equal to or greater than 65536 appear using the
decimal method (asdot+). For example, the AS Number 65526 appears as 65526, and the AS Number
65546 appears as 1.10.
FTOS 8.3.1.0 applies the ASN Notation type change dynamically to the running-config statements. When
you apply or change an asnotation, the type selected is reflected immediately in the running-configuration
and the show commands (Figure 10-9 and Figure 10-10).
Figure 10-9. Dynamic changes of the bgp asnotation command in the show running config
ASDOT
FTOS(conf-router_bgp)#bgp asnotation asdot
FTOS(conf-router_bgp)#show conf
!
router bgp 100
bgp asnotation asdot
bgp four-octet-as-support
neighbor 172.30.1.250 local-as 65057
<output truncated>
ASDOT+
FTOS(conf-router_bgp)#bgp asnotation asdot+
FTOS(conf-router_bgp)#show conf
!
router bgp 100
bgp asnotation asdot+
bgp four-octet-as-support
neighbor 172.30.1.250 local-as 65057
<output truncated>
AS-PLAIN
FTOS(conf-router_bgp)#bgp asnotation asplain
FTOS(conf-router_bgp)#sho conf
!
router bgp 100
bgp four-octet-as-support
neighbor 172.30.1.250 local-as 65057
<output truncated>
AS Number Migration
When migrating one AS to another, perhaps combining ASs, an eBGP network may lose its routing to an
iBGP if the ASN changes. Migration can be difficult as all the iBGP and eBGP peers of the migrating
network need to be updated to maintain network reachability. With this feature you can transparently
change the AS number of entire BGP network and ensure that the routes are propagated throughout the
network while the migration is in progress. Essentially, Local-AS provides a capability to the BGP speaker
to operate as if it belongs to “virtual” AS network besides its physical AS network.
Figure 10-11 shows a scenario where Router A, Router B and Router C belong to AS 100, 200, 300
respectively. Router A acquired Router B; Router B has Router C as its customer. When Router B is
migrating to Router A, it needs to maintain the connection with Router C without immediately updating
Router C's configuration. Local-AS allows this to happen by allowing Router B to appear as if it still
belongs to Router B's old network (AS 200) as far as communicating with Router C is concerned.
Router A
AS 100
Router C
AS 300
Router B
AS 200
Before Migration
Router A
AS 100
Router C
AS 100
AS 300
Router B
Local AS
200
If the “no prepend” option is used, the local-as will not be prepended to the updates received from the
eBGP peer. If “no prepend” is not selected (the default), the local-as is added to the first AS segment in the
AS-PATH. If an inbound route-map is used to prepend the as-path to the update from the peer, the local-as
is added first. For example, consider the topology described in Figure 10-11. If Router B has an inbound
route-map applied on Router C to prepend "65001 65002" to the as-path, the following events will take
place on Router B
Note: See the Dell Force10 iSupport webpage for the Force10-BGP4-V2-MIB and other MIB
documentation.
SAFI (IPv4 Unicast or IPv6 Multicast) is used for various outbound counters. Counters corresponding
to IPv4 Multicast cannot be queried.
• The f10BgpM2[Cfg]PeerReflectorClient field is populated based on the assumption that
route-reflector clients are not in a full mesh if BGP client-2-client reflection is enabled and that the
BGP speaker acting as reflector will advertise routes learned from one client to another client. If
disabled, it is assumed that clients are in a full mesh, and there is no need to advertise prefixes to the
other clients.
• High CPU utilization may be observed during an SNMP walk of a large BGP Loc-RIB.
• To avoid SNMP timeouts with a large-scale configuration (large number of BGP neighbors and a large
BGP Loc-RIB), Dell Force10 recommends setting the timeout and retry count values to a relatively
higher number. e.g. t = 60 or r = 5.
• To return all values on an snmpwalk for the f10BgpM2Peer sub-OID, use the -C c option, such as
snmpwalk -v 2c -C c -c public <IP_address> <OID>.
• An SNMP walk may terminate pre-maturely if the index does not increment lexicographically. Dell
Force10 recommends using options to ignore such errors.
• Multiple BPG process instances are not supported. Thus, the F10BgpM2PeerInstance field in various
tables is not used to locate a peer.
• Multiple instances of the same NLRI in the BGP RIB are not supported and are set to zero in the
SNMP query response.
• F10BgpM2NlriIndex and f10BgpM2AdjRibsOutIndex fields are not used.
• Carrying MPLS labels in BGP is not supported. F10BgpM2NlriOpaqueType and
f10BgpM2NlriOpaquePointer fields are set to zero.
• 4-byte ASN is supported. f10BgpM2AsPath4byteEntry table contains 4-byte ASN-related
parameters based on the configuration.
Traps (notifications) specified in the BGP4 MIB draft <draft-ietf-idr-bgp4-mibv2-05.txt> are not
supported. Such traps (bgpM2Established and bgpM2BackwardTransition) are supported as part of
RFC 1657.
Configuration Information
The software supports BGPv4 as well as the following:
Defaults
By default, FTOS compares the MED attribute on different paths from within the same AS (the bgp
always-compare-med command is not enabled).
Note: In FTOS, all newly configured neighbors and peer groups are disabled. You must enter the
neighbor {ip-address | peer-group-name} no shutdown command to enable a neighbor or peer
group.
Item Default
BGP Neighbor Adjacency changes All BGP neighbor changes are logged.
Fast External Fallover feature Enabled
graceful restart feature Disabled
Local preference 100
MED 0
Route Flap Damping Parameters half-life = 15 minutes
reuse = 750
suppress = 2000
max-suppress-time = 60 minutes
Distance external distance = 20
internal distance = 200
local distance = 200
Timers keepalive = 60 seconds
holdtime = 180 seconds
• Enable BGP
• Configure AS4 Number Representations
• Configure Peer Groups
• BGP fast fall-over
Enable BGP
By default, BGP is not enabled on the system. FTOS supports one Autonomous System (AS) and you must
assign the AS Number (ASN). To establish BGP sessions and route traffic, you must configure at least one
BGP neighbor or peer.
In BGP, routers with an established TCP connection are called neighbors or peers. Once a connection is
established, the neighbors exchange full BGP routing tables with incremental updates afterwards. In
addition, neighbors exchange KEEPALIVE messages to maintain the connection.
In BGP, neighbor routers or peers can be classified as internal or external. External BGP peers must be
connected physically to one another (unless you enable the EBGP multihop feature), while internal BGP
peers do not need to be directly connected. The IP address of an EBGP neighbor is usually the IP address
of the interface directly connected to the router. First, the BGP process determines if all internal BGP peers
are reachable, and then it determines which peers outside the AS are reachable.
Note: Sample Configurations for enabling BGP routers are found at the end of this chapter.
1a bgp four-octet-as-support CONFIG-ROUTER-B Enable 4-Byte support for the BGP process.
GP Note: This is an OPTIONAL command.
Enable if you want to use 4-Byte AS
numbers or if you support AS4 Number
Representation.
Use it only if you support 4-Byte AS Numbers or if you support AS4
Number Representation. If you are supporting 4-Byte ASNs, this
command must be enabled first.
Disable 4-Byte support and return to the default 2-Byte format by using
the no bgp four-octet-as-support command. You cannot disable
4-Byte support if you currently have a 4-Byte ASN configured.
Note: When you change the configuration of a BGP neighbor, always reset it by entering the clear
ip bgp command in EXEC Privilege mode.
show ip bgp summary command in EXEC Privilege mode to view the BGP status. Figure 10-12 shows
the summary with a 2-Byte AS Number displayed; Figure 10-13 shows the summary with a 4-Byte AS
Number displayed.
Figure 10-12. Command example: show ip bgp summary (2-Byte AS Number displayed)
R2#show ip bgp summary
BGP router identifier 192.168.10.2, local AS number 65123 2-Byte AS Number
BGP table version is 1, main routing table version 1
1 network entrie(s) using 132 bytes of memory
1 paths using 72 bytes of memory
BGP-RIB over all using 73 bytes of memory
1 BGP path attribute entrie(s) using 72 bytes of memory
1 BGP AS-PATH entrie(s) using 47 bytes of memory
5 neighbor(s) using 23520 bytes of memory
Figure 10-13. Command example: show ip bgp summary (4-Byte AS Number displayed)
R2#show ip bgp summary
BGP router identifier 192.168.10.2, local AS number 48735.59224 4-Byte AS Number
BGP table version is 1, main routing table version 1
1 network entrie(s) using 132 bytes of memory
1 paths using 72 bytes of memory
BGP-RIB over all using 73 bytes of memory
1 BGP path attribute entrie(s) using 72 bytes of memory
1 BGP AS-PATH entrie(s) using 47 bytes of memory
5 neighbor(s) using 23520 bytes of memory
For the router’s identifier, FTOS uses the highest IP address of the Loopback interfaces configured. Since
Loopback interfaces are virtual, they cannot go down, thus preventing changes in the router ID. If no
Loopback interfaces are configured, the highest IP address of any interface is used as the router ID.
To view the status of BGP neighbors, use the show ip bgp neighbors (Figure 10-14) command in EXEC
Privilege mode. For BGP neighbor configuration information, use the show running-config bgp
command in EXEC Privilege mode (Figure 10-15). Note that the showconfig command in
CONFIGURATION ROUTER BGP mode gives the same information as thew show running-config bgp.
The third line of the show ip bgp neighbors output contains the BGP State. If anything other than
ESTABLISHED is listed, the neighbor is not exchanging information and routes. For more details on using
the show ip bgp neighbors command, refer to the FTOS Command Line Interface Reference.
Figure 10-14. Command example: show ip bgp neighbors
BGP neighbor is 10.114.8.60, remote AS 18508, external link External BGP neighbor
BGP version 4, remote router ID 10.20.20.20
BGP state ESTABLISHED, in this state for 00:01:58
Last read 00:00:14, hold time is 90, keepalive interval is 30 seconds
Received 18552 messages, 0 notifications, 0 in queue
Sent 11568 messages, 0 notifications, 0 in queue
Received 18549 updates, Sent 11562 updates
Minimum time between advertisement runs is 30 seconds
BGP neighbor is 10.1.1.1, remote AS 65535, internal link Internal BGP neighbor
Administratively shut down
BGP version 4, remote router ID 10.0.0.0
BGP state IDLE, in this state for 17:12:40
Last read 17:12:40, hold time is 180, keepalive interval is 60 seconds
Received 0 messages, 0 notifications, 0 in queue
Sent 0 messages, 0 notifications, 0 in queue
Received 0 updates, Sent 0 updates
Minimum time between advertisement runs is 5 seconds
• ASPLAIN is the method FTOS has used for all previous FTOS versions. It remains the default method
with FTOS 8.2.1.0 and later. With the ASPLAIN notation, a 32 bit binary AS number is translated into
a decimal value.
• ASDOT+ representation splits the full binary 4-byte AS number into two words of 16 bits separated by
a decimal point (.): <high-order 16 bit value>.<low-order 16 bit value>.
• ASDOT representation combines the ASPLAIN and ASDOT+ representations. AS Numbers less than
65536 appear in integer format (asplain); AS Numbers equal to or greater than 65536 appear using the
decimal method (asdot+). For example, the AS Number 65526 appears as 65526, and the AS Number
65546 appears as 1.10.
Note: The ASDOT and ASDOT+ representations are supported only in conjunction with the 4-Byte AS
Numbers feature. If 4-Byte AS Numbers are not implemented, only ASPLAIN representation is supported.
Only one form of AS Number Representation is supported at a time. You cannot combine the types of
representations within an AS.
Note: ASPLAIN is the default method FTOS uses and does not appear in
the configuration display.
To configure multiple BGP neighbors at one time, create and populate a BGP peer group. Another
advantage of peer groups is that members of a peer groups inherit the configuration properties of the group
and share same update policy.
You create a peer group by assigning it a name, then adding members to the peer group. Once a peer group
is created, you can configure route policies for it. Refer to Filter BGP routes for information on configuring
route policies for a peer group.
Note: Sample Configurations for enabling Peer Groups are found at the end of this chapter.
Use these commands in the following sequence starting in the CONFIGURATION ROUTER BGP mode
to create a peer group
5 neighbor ip-address peer-group CONFIG-ROUTER- Add an enabled neighbor to the peer group.
peer-group-name BGP
After you create a peer group, you can use any of the commands beginning with the keyword neighbor to
configure that peer group.
A neighbor cannot become part of a peer group if it has any of the following commands are configured:
• neighbor advertisement-interval
• neighbor distribute-list out
• neighbor filter-list out
• neighbor next-hop-self
• neighbor route-map out
• neighbor route-reflector-client
• neighbor send-community
A neighbor may keep its configuration after it was added to a peer group if the neighbor’s configuration is
more specific than the peer group’s, and the neighbor’s configuration does not affect outgoing updates.
Note: When you configure a new set of BGP policies for a peer group, always reset the peer
group by entering the clear ip bgp peer-group peer-group-name command in EXEC Privilege mode.
Use the show config command in the CONFIGURATION ROUTER BGP mode to view the
configuration. When you create a peer group, it is disabled (shutdown). Figure 10-19 shows the creation
of a peer group (zanzibar).
Use the neighbor peer-group-name no shutdown command in the CONFIGURATION ROUTER BGP
mode to enable a peer group.
To disable a peer group, use the neighbor peer-group-name shutdown command in the CONFIGURATION
ROUTER BGP mode. The configuration of the peer group is maintained, but it is not applied to the peer
group members. When you disable a peer group, all the peers within the peer group that are in
ESTABLISHED state are moved to IDLE state.
Use the show ip bgp peer-group command in EXEC Privilege mode (Figure 10-21) to view the status of
peer groups.
By default, a BGP session is governed by the hold time. BGP routers typically carry large routing tables, so
frequent session resets are not desirable. The BGP fast fall-over feature reduces the convergence time
while maintaining stability. The connection to a BGP peer is immediately reset if a link to a directly
connected external peer fails.
When fall-over is enabled, BGP tracks IP reachability to the peer remote address and the peer local
address. Whenever either address becomes unreachable (for example, no active route exists in the routing
table for peer IPv6 destinations/local address), BGP brings down the session with the peer.
default.
To disable Fast Fall-Over, use the [no] neighbor [neighbor | peer-group] fall-over command in
CONFIGURATION ROUTER BGP mode
Use the show ip bgp neighbors command as shown in Figure 10-22 to verify that fast fall-over is enabled
on a particular BGP neighbor. Note that since Fast Fall-Over is disabled by default, it will appear only if it
has been enabled
Fall-over enabled
Fast Fall-Over Indicator
Notification History
'Connection Reset' Sent : 5 Recv: 0
FTOS#
Use the show ip bgp peer-group command to verify that fast fall-over is enabled on a peer-group.
Peer-group test
Fall-over enabled
BGP version 4
Minimum time between advertisement runs is 5 seconds
FTOS#
When you enable a peer-group, the software sends an OPEN message to initiate a TCP connection. If you
enable passive peering for the peer group, the software does not send an OPEN message, but it will
respond to an OPEN message.
When a BGP neighbor connection with authentication configured is rejected by a passive peer-group,
FTOS does not allow another passive peer-group on the same subnet to connect with the BGP neighbor. To
work around this, change the BGP configuration or change the order of the peer group configuration.
Use these commands in the following sequence, starting in the CONFIGURATION ROUTER BGP mode
to configure passive peering.
1 neighbor peer-group-name CONFIG-ROUTER- Configure a peer group that does not initiate TCP
peer-group passive [match-af] BGP connections with other peers.
(Optional) Enter the match-af keyword to
restrict the peer adjacency established in the
passive peer group. match-af requires that a
peer’s address family matches the address family
of the subnet assigned to the peer group (Step 2)
before a peering session is brought up.
2 neighbor peer-group-name subnet CONFIG-ROUTER- Assign a subnet to the peer group. The peer
subnet-number mask BGP group will respond to OPEN messages sent on
this subnet.
Only after the peer group responds to an OPEN message sent on the subnet does its BGP state change to
ESTABLISHED. Once the peer group is ESTABLISHED, the peer group is the same as any other peer
group.
For more information on peer groups, refer to Configure Peer Groups on page 232.
The local-as feature smooths out the BGP network migration operation and allows you to maintain
existing ASNs during a BGP network migration.
When you complete your migration, be sure to reconfigure your routers with the new information and
disable this feature.
neighbor {IP address | CONFIG-ROUTER- Allow external routes from this neighbor.
peer-group-name local-as as BGP Format:
number [no prepend] IP Address: A.B.C.D
Peer Group Name: 16 characters
AS-number: 0-65535 (2-Byte) or 1-4294967295 (4-Byte)
or
0.1-65535.65535 (Dotted format)
Disable this feature, using the no neighbor local-as command in CONFIGURATION ROUTER BGP mode.
R2(conf-router_bgp)#show conf
!
router bgp 65123
bgp router-id 192.168.10.2
network 10.10.21.0/24
network 10.10.32.0/24
network 100.10.92.0/24
network 192.168.10.0/24
bgp four-octet-as-support
neighbor 10.10.21.1 remote-as 65123
neighbor 10.10.21.1 filter-list Laura in
neighbor 10.10.21.1 no shutdown Actual AS Number
neighbor 10.10.32.3 remote-as 65123
neighbor 10.10.32.3 no shutdown
neighbor 100.10.92.9 remote-as 65192
neighbor 100.10.92.9 local-as 6500 Local-AS Number 6500
neighbor 100.10.92.9 no shutdown Maintained During Migration
neighbor 192.168.10.1 remote-as 65123
neighbor 192.168.10.1 update-source Loopback 0
neighbor 192.168.10.1 no shutdown
neighbor 192.168.12.2 remote-as 65123
neighbor 192.168.12.2 update-source Loopback 0
neighbor 192.168.12.2 no shutdown
R2(conf-router_bgp)#
This command allows you to set the number of times a particular AS number can occur in the AS path. The
allow-as feature permits a BGP speaker to allow the ASN to be present for specified number of times in
the update received from the peer, even if that ASN matches its own. The AS-PATH loop is detected if the
local ASN is present more than the specified number of times in the command.
neighbor {IP address | CONFIG-ROUTER- Allow this neighbor ID to use the AS path the specified
peer-group-name} allowas-in BGP number of times.
number Format:
IP Address: A.B.C.D
Peer Group Name: 16 characters
Number: 1-10
To disable this feature, use the no neighbor allow-as in number command in the CONFIGURATION
ROUTER BGP mode.
Use this feature to lessen the negative effects of a BGP restart. FTOS advertises support for this feature to
BGP neighbors through a capability advertisement. You can enable graceful restart by router and/or by
peer or peer group.
The default role for BGP on is as a receiving or restarting peer. If you enable BGP, when a peer that
supports graceful restart resumes operating, FTOS performs the following tasks:
• Continues saving routes received from the peer if the peer advertised it had graceful restart capability.
Continues forwarding traffic to the peer.
• Flags routes from the peer as Stale and sets a timer to delete them if the peer does not perform a
graceful restart.
• Deletes all routes from the peer if forwarding state information is not saved.
• Speeds convergence by advertising a special update packet known as an end-of-RIB marker. This
marker indicates the peer has been updated with all routes in the local RIB.
If you configure your system to do so, FTOS can perform the following actions during a hot failover:
• Save all FIB and CAM entries on the line card and continue forwarding traffic while the secondary
RPM is coming online.
This prompts all peers to continue saving the routes they receive from your E-Series and to continue
forwarding traffic.
• Bring the secondary RPM online as the primary and re-open sessions with all peers operating in “no
shutdown” mode.
• Defer best path selection for a certain amount of time. This helps optimize path selection and results in
fewer updates being sent out.
Enable graceful restart using the configure router bgp graceful-restart command. The table below shows
the command and its available options:
bgp graceful-restart CONFIG-ROUTER- Enable graceful restart for the BGP node.
BGP
bgp graceful-restart [restart-time CONFIG-ROUTER- Set maximum restart time for all peers. Default is
time-in-seconds] BGP 120 seconds.
bgp graceful-restart [stale-path-time CONFIG-ROUTER- Set maximum time to retain the restarting peer’s stale
time-in-seconds] BGP paths. Default is 360 seconds.
bgp graceful-restart [role CONFIG-ROUTER- Local router supports graceful restart as a receiver
receiver-only] BGP only.
BGP graceful restart is active only when the neighbor becomes established. Otherwise it is disabled.
Graceful-restart applies to all neighbors with established adjacency.
With the graceful restart feature, FTOS enables the receiving/restarting mode by default. In receiver-only
mode, graceful restart saves the advertised routes of peers that support this capability when they restart.
However, the E-Series does not advertise that it saves these forwarding states when it restarts. This option
provides support for remote peers for their graceful restart without supporting the feature itself.
You can implement BGP graceful restart either by neighbor or by BGP peer-group. For more information,
please see the following table or the FTOS Command Line Interface Reference.
neighbor {ip-address | CONFIG-ROUTER- Set maximum restart time for the neighbor or
peer-group-name} graceful-restart BGP peer-group. Default is 120 seconds.
[restart-time time-in-seconds]
neighbor {ip-address | CONFIG-ROUTER- Local router supports graceful restart for this
peer-group-name} graceful-restart BGP neighbor or peer-group as a receiver only.
[role receiver-only]
The BGP attribute, AS_PATH, can be used to manipulate routing policies. The AS_PATH attribute
contains a sequence of AS numbers representing the route’s path. As the route traverses an Autonomous
System, the AS number is prepended to the route. You can manipulate routes based on their AS_PATH to
affect interdomain routing. By identifying certain AS numbers in the AS_PATH, you can permit or deny
routes based on the number in its AS_PATH.
To view all BGP path attributes in the BGP database, use the show ip bgp paths command in EXEC
Privilege mode (Figure 10-26).
Figure 10-26. Command example: show ip bgp paths
AS-PATH ACLs use regular expressions to search AS_PATH values. AS-PATH ACLs have an “implicit
deny.” This means that routes that do not meet a deny or match filter are dropped.
Use these commands in the following sequence, starting in the CONFIGURATION mode to configure an
AS-PATH ACL to filter a specific AS_PATH value.
1 ip as-path access-list CONFIGURATION Assign a name to a AS-PATH ACL and enter AS-PATH
as-path-name ACL mode.
2 {deny | permit} filter CONFIG-AS-PATH Enter the parameter to match BGP AS-PATH for
parameter filtering. This is the filter that will be used to match the
AS-path. The entries can be any format, letters,
numbers, or regular expressions.
This command can be entered multiple times if multiple
filters are desired.
See Table 10-4 for accepted expressions.
5 neighbor {ip-address | CONFIG-ROUTER-B Use a configured AS-PATH ACL for route filtering and
peer-group-name} GP manipulation.
filter-list as-path-name {in If you assign an non-existent or empty AS-PATH ACL,
| out} the software allows all routes.
Regular expressions are used to filter AS paths or community lists. A regular expression is a special
character used to define a pattern that is then compared with an input string.
For an AS-path access list as shown in the commands above, if the AS path matches the regular expression
in the access list, then the route matches the access list.
Figure 10-27 applies access list Eagle to routes inbound from BGP peer 10.5.5.2. Access list Eagle uses a
regular expression to deny routes originating in AS 32.
FTOS(conf)#ip as-path access-list Eagle Create the Access List and Filter
FTOS(config-as-path)#deny 32$
FTOS(config-as-path)#ex
FTOS(conf)#router bgp 99
FTOS(conf-router_bgp)#neighbor AAA filter-list Eagle in
FTOS(conf-router_bgp)#show conf
!
router bgp 99
neighbor AAA peer-group
neighbor AAA filter-list Eaglein
neighbor AAA no shutdown
neighbor 10.155.15.2 remote-as 32
neighbor 10.155.15.2 filter-list 1 in
neighbor 10.155.15.2 shutdown
FTOS(conf-router_bgp)#ex
FTOS(conf)#ex
FTOS#show ip as-path-access-lists
ip as-path access-list Eagle Regular Expression shown
deny 32$ as part of Access List filter
FTOS#
Regular
Expression Definition
Regular
Expression Definition
( ) (parenthesis) Specifies patterns for multiple use when followed by one of the multiplier metacharacters:
asterisk *, plus sign +, or question mark ?
As seen in Figure 10-27, the expressions are displayed when using the show commands. Use the show
config command in the CONFIGURATION AS-PATH ACL mode and the show ip as-path-access-list
command in EXEC Privilege mode to view the AS-PATH ACL configuration.
For more information on this command and route filtering, refer to Filter BGP routes.
Redistribute routes
In addition to filtering routes, you can add routes from other routing instances or protocols to the BGP
process. With the redistribute command syntax, you can include ISIS, OSPF, static, or directly connected
routes in the BGP process.
Use any of the following commands in ROUTER BGP mode to add routes from other routing instances or
protocols.
redistribute isis [level-1 | level-1-2 | ROUTER BGP or Include specific ISIS routes in BGP.
level-2] [metric value] [route-map CONF-ROUTER_BGPv6_ Configure the following parameters:
map-name] AF • level-1, level-1-2, or level-2: Assign
all redistributed routes to a level.
Default is level-2.
• metric range: 0 to 16777215. Default is
0.
• map-name: name of a configured route
map.
redistribute ospf process-id [match ROUTER BGP or Include specific OSPF routes in IS-IS.
external {1 | 2} | match internal] CONF-ROUTER_BGPv6_ Configure the following parameters:
[metric-type {external | internal}] AF • process-id range: 1 to 65535
[route-map map-name] • match external range: 1 or 2
• match internal
• metric-type: external or internal.
• map-name: name of a configured route
map.
Within FTOS, you have multiple methods of manipulating routing attributes. One attribute you can
manipulate is the COMMUNITY attribute. This attribute is an optional attribute that is defined for a group
of destinations. In FTOS, you can assign a COMMUNITY attribute to BGP routers by using an IP
Community list. After you create an IP Community list, you can apply routing decisions to all routers
meeting the criteria in the IP Community list.
IETF RFC 1997 defines the COMMUNITY attribute and the pre-defined communities of INTERNET,
NO_EXPORT_SUBCONFED, NO_ADVERTISE, and NO_EXPORT. All BGP routes belong to the
INTERNET community. In the RFC, the other communities are defined as follows:
• All routes with the NO_EXPORT_SUBCONFED (0xFFFFFF03) community attribute are not sent to
CONFED-EBGP or EBGP peers, but are sent to IBGP peers within CONFED-SUB-AS.
• All routes with the NO_ADVERTISE (0xFFFFFF02) community attribute must not be advertised.
• All routes with the NO_EXPORT (0xFFFFFF01) community attribute must not be advertised outside a
BGP confederation boundary, but are sent to CONFED-EBGP and IBGP peers.
FTOS also supports BGP Extended Communities as described in RFC 4360—BGP Extended
Communities Attribute.
IP community list.
Use these commands in the following sequence, starting in the CONFIGURATION mode to configure an
IP extended community list.
2 {permit | deny} {{rt | soo} CONFIG-COMMUNITY- Two types of extended communities are supported.
{ASN:NN | IPADDR:N} | regex LIST Filter routes based on the type of extended
REGEX-LINE} communities they carry using one of the following
keywords:
• rt: Route Target
• soo: Route Origin or Site-of-Origin.
Support for matching extended communities against
regular expression is also supported. Match against a
regular expression using the following keyword:
• regexp: regular expression
To set or modify an extended community attribute, use the set extcommunity {rt | soo} {ASN:NN |
IPADDR:NN} command.
To view the configuration, use the show config command in the CONFIGURATION
COMMUNITY-LIST or CONFIGURATION EXTCOMMUNITY LIST mode or the show ip
{community-lists | extcommunity-list} command in EXEC Privilege mode (Figure 10-28).
FTOS#show ip community-lists
ip community-list standard 1
deny 701:20
deny 702:20
deny 703:20
deny 704:20
deny 705:20
deny 14551:20
deny 701:112
deny 702:112
deny 703:112
deny 704:112
deny 705:112
deny 14551:112
deny 701:667
deny 702:667
deny 703:667
Use these commands in the following sequence, starting in the CONFIGURATION mode, To use an IP
Community list or Extended Community List to filter routes, you must apply a match community filter to
a route map and then apply that route map to a BGP neighbor or peer group.
1 route-map map-name [permit | CONFIGURATION Enter the ROUTE-MAP mode and assign
deny] [sequence-number] a name to a route map.
To view the BGP configuration, use the show config command in CONFIGURATION ROUTER BGP
mode. To view a route map configuration, use the show route-map command in EXEC Privilege mode.
To view which BGP routes meet an IP Community or Extended Community list’s criteria, use the show ip
bgp {community-list | extcommunity-list} command in EXEC Privilege mode.
In addition to permitting or denying routes based on the values of the COMMUNITY attributes, you can
manipulate the COMMUNITY attribute value and send the COMMUNITY attribute with the route
information.
Use the following command in the CONFIGURATION ROUTER BGP mode to send the COMMUNITY
attribute to BGP neighbors.
To view the BGP configuration, use the show config command in the CONFIGURATION ROUTER BGP
mode.
If you want to remove or add a specific COMMUNITY number from a BGP path, you must create a route
map with one or both of the following statements in the route map. Then apply that route map to a BGP
neighbor or peer group. Use these commands in the following sequence, starting in the
CONFIGURATION mode:
1 route-map map-name CONFIGURATION Enter the ROUTE-MAP mode and assign a name
[permit | deny] to a route map.
[sequence-number]
5 neighbor {ip-address | CONFIG-ROUTER-BGP Apply the route map to the neighbor or peer
peer-group-name} group’s incoming or outgoing routes.
route-map map-name {in |
out}
To view the BGP configuration, use the show config command in CONFIGURATION ROUTER BGP
mode. To view a route map configuration, use the show route-map command in EXEC Privilege mode.
Use the show ip bgp community command in EXEC Privilege mode (Figure 10-29) to view BGP routes
matching a certain community number or pre-defined BGP community.
By default, FTOS uses the MULTI_EXIT_DISC or MED attribute when comparing EBGP paths from the
same AS.
bgp always-compare-med CONFIG-ROUTER- Enable MED comparison in the paths from neighbors
BGP with different ASs.
By default, this comparison is not performed.
bgp bestpath med {confed | CONFIG-ROUTER- Change the bestpath MED selection to one of the
missing-as-best} BGP following:
confed: Chooses the bestpath MED comparison of
paths learned from BGP confederations.
missing-as-best: Treat a path missing an MED as
the most preferred one
Use the show config command in the CONFIGURATION ROUTER BGP mode to view the nondefault
values.
Use the following command in the CONFIGURATION ROUTER BGP mode to change the default values
of this attribute for all routes received by the router.
Use the show config command in CONFIGURATION ROUTER BGP mode or the show running-config
bgp command in EXEC Privilege mode to view BGP configuration.
A more flexible method for manipulating the LOCAL_PREF attribute value is to use a route map.
Use these commands in the following sequence, starting CONFIGURATION mode to change the default
value of the LOCAL_PREF attribute for specific routes.
1 route-map map-name [permit | CONFIGURATION Enter the ROUTE-MAP mode and assign a
deny] [sequence-number] name to a route map.
5 neighbor {ip-address | CONFIG-ROUTER-BGP Apply the route map to the neighbor or peer
peer-group-name} route-map group’s incoming or outgoing routes.
map-name {in | out}
To view the BGP configuration, use the show config command in the CONFIGURATION ROUTER BGP
mode. To view a route map configuration, use the show route-map command in EXEC Privilege mode.
Use the following command in the CONFIGURATION ROUTER BGP mode to change the how the
NEXT_HOP attribute is used.
neighbor {ip-address | CONFIG-ROUTER-B Disable next hop processing and configure the
peer-group-name} next-hop-self GP router as the next hop for a BGP neighbor.
Use the show config command in CONFIGURATION ROUTER BGP mode or the show running-config
bgp command in EXEC Privilege mode to view BGP configuration.
You can also use route maps to change this and other BGP attributes. For example, you can include the
following command in a route map to specify the next hop address:
Use the following command in CONFIGURATION ROUTER BGP mode to change the how the WEIGHT
attribute is used.
Use the show config command in CONFIGURATION ROUTER BGP mode or the show running-config
bgp command in EXEC Privilege mode to view BGP configuration.
Enable multipath
By default, the software allows one path to a destination. You can enable multipath to allow up to 16
parallel paths to a destination.
Use the following command in the CONFIGURATION ROUTER BGP mode to allow more than one path.
The show ip bgp network command includes multipath information for that network.
Filtering routes allows you to implement BGP policies. You can use either IP prefix lists, route maps,
AS-PATH ACLs or IP Community lists (via a route map) to control which routes are accepted and
advertised by the BGP neighbor or peer group. Prefix lists filter routes based on route and prefix length,
while AS-Path ACLs filter routes based on the Autonomous System number. Route maps can filter and set
conditions, change attributes, and assign update policies.
Note: FTOS supports up to 255 characters in a set community statement inside a route map.
Note: With FTOS, you can create inbound and outbound policies. Each of the commands used for
filtering, has in and out parameters that must be applied. In FTOS, the order of preference varies
depending on whether the attributes are applied for inbound updates or outbound updates.
Prior to filtering BGP routes, you must create the prefix list, AS-PATH ACL, or route map to be used.
Note: When you configure a new set of BGP policies, always reset the neighbor or peer group by
entering the clear ip bgp command in EXEC Privilege mode.
Use these commands in the following sequence, starting in the CONFIGURATION mode to filter routes
using prefix lists.
2 seq sequence-number {deny | CONFIG-PREFIX Create multiple prefix list filters with a deny
permit} {any | ip-prefix [ge | le] } LIST or permit action.
ge: Minimum prefix length to be matched
le: maximum prefix length to me matched
Refer to Chapter 8, “IP Access Control Lists
(ACL), Prefix Lists, and Route-maps,” on
page 133 for information on configuring
prefix lists.
To view the BGP configuration, use the show config command in the ROUTER BGP mode. To view a
prefix list configuration, use the show ip prefix-list detail or show ip prefix-list summary commands in
EXEC Privilege mode.
1 route-map map-name [permit | CONFIGURATION Create a route map and assign it a name.
deny] [sequence-number]
Use the show config command in CONFIGURATION ROUTER BGP mode to view the BGP
configuration. Use the show route-map command in EXEC Privilege mode to view a route map
configuration.
Use these commands in the following sequence, beginning in the CONFIGURATION mode to filter routes
based on AS-PATH information.
2 {deny | permit} AS-PATH ACL Create a AS-PATH ACL filter with a deny or
as-regular-expression permit action.
Use the show config command in CONFIGURATION ROUTER BGP mode and show ip
as-path-access-list command in EXEC Privilege mode to view which commands are configured.
Include this filter permit .* in your AS-PATH ACL to forward all routes not meeting the AS-PATH ACL
criteria.
BGP route reflectors are intended for Autonomous Systems with a large mesh and they reduce the amount
of BGP control traffic. With route reflection configured properly, IBGP routers are not fully meshed within
a cluster but all receive routing information.
Configure clusters of routers where one router is a concentration router and others are clients who receive
their updates from the concentration router.
Use the following commands in the CONFIGURATION ROUTER BGP mode to configure a route
reflector.
To view a route reflector configuration, use the show config command in the CONFIGURATION
ROUTER BGP mode or show running-config bgp in EXEC Privilege mode.
When you enable a route reflector, FTOS automatically enables route reflection to all clients. To disable
route reflection between all clients in this reflector, use the no bgp client-to-client reflection command in
CONFIGURATION ROUTER BGP mode. All clients should be fully meshed before you disable route
reflection.
FTOS provides multiple ways to aggregate routes in the BGP routing table. At least one specific route of
the aggregate must be in the routing table for the configured aggregate to become active.
Use the following command in the CONFIGURATION ROUTER BGP mode to aggregate routes.
aggregate-address ip-address mask CONFIG-ROUTER- Assign the IP address and mask of the prefix to be
[advertise-map map-name] [as-set] BGP aggregated.
[attribute-map map-name] Optional parameters are:
[summary-only] [suppress-map • advertise-map map-name: set filters for
map-name] advertising an aggregate route
• as-set: generate path attribute information and
include it in the aggregate.
• attribute-map map-name: modify attributes of the
aggregate, except for the AS_PATH and NEXT_HOP
attributes
• summary-only: advertise only the aggregate
address. Specific routes will not be advertised
• suppress-map map-name: identify which
more-specific routes in the aggregate are suppressed
AS_SET includes AS_PATH and community information from the routes included in the aggregated route.
In the show ip bgp command, aggregates contain an ‘a’ in the first column and routes suppressed by the
aggregate contain an ‘s’ in the first column.
Figure 10-30. Command Example: show ip bgp
FTOS#show ip bgp
BGP table version is 0, local router ID is 10.101.15.13
Status codes: s suppressed, d damped, h history, * valid, > best
Path source: I - internal, a - aggregate, c - confed-external, r - redistributed, n - network
Origin codes: i - IGP, e - EGP, ? - incomplete
Another way to organize routers within an AS and reduce the mesh for IBGP peers is to configure BGP
confederations. As with route reflectors, BGP confederations are recommended only for IBGP peering
involving a large number of IBGP peering sessions per router. Basically, when you configure BGP
confederations, you break the AS into smaller sub-AS, and to those outside your network, the
confederations appear as one AS. Within the confederation sub-AS, the IBGP neighbors are fully meshed
and the MED, NEXT_HOP, and LOCAL_PREF attributes are maintained between confederations.
bgp confederation peers CONFIG-ROUTER- Specifies which confederation sub-AS are peers.
as-number [... as-number] BGP AS-number: 0-65535 (2-Byte) or 1-4294967295
(4-Byte)
All Confederation routers must be either 4-Byte or 2-Byte. You cannot have a
mix of router ASN support,
Use the show config command in the CONFIGURATION ROUTER BGP mode to view the
configuration.
When EBGP routes become unavailable, they “flap” and the router issues both WITHDRAWN and
UPDATE notices. A flap is when a route
• is withdrawn
• is readvertised after being withdrawn
• has an attribute change
The constant router reaction to the WITHDRAWN and UPDATE notices causes instability in the BGP
process. To minimize this instability, you may configure penalties, a numeric value, for routes that flap.
When that penalty value reaches a configured limit, the route is not advertised, even if the route is up. In
FTOS, that penalty value is 1024. As time passes and the route does not flap, the penalty value decrements
or is decayed. However, if the route flaps again, it is assigned another penalty.
The penalty value is cumulative and penalty is added under following cases:
• Withdraw
• Readvertise
• Attribute change
When dampening is applied to a route, its path is described by one of the following terms:
The CLI example below shows configuring values to start reusing or restarting a route, as well as their
default values.
FTOS(conf-router_bgp)#bgp dampening ?
<1-45> Half-life time for the penalty (default = 15) Set time before
route-map Route-map to specify criteria for dampening value decrements
<cr>
FTOS(conf-router_bgp)#bgp dampening 2 ? Set readvertise value
<1-20000> Value to start reusing a route (default = 750)
FTOS(conf-router_bgp)#bgp dampening 2 2000 ? Set suppress value
<1-20000> Value to start suppressing a route (default = 2000)
FTOS(conf-router_bgp)#bgp dampening 2 2000 3000 ? Set time to suppress
<1-255> Maximum duration to suppress a stable route (default = 60) a route
FTOS(conf-router_bgp)#bgp dampening 2 2000 3000 10 ?
route-map Route-map to specify criteria for dampening
<cr>
Use the following command in the CONFIGURATION ROUTER BGP mode to configure route flap
dampening parameters.
To view the BGP configuration, use show config in the CONFIGURATION ROUTER BGP mode or
show running-config bgp in EXEC Privilege mode.
set dampening half-life reuse CONFIG-ROUTE-MAP Enter the following optional parameters to
suppress max-suppress-time configure route dampening parameters:
• half-life range: 1 to 45. Number of minutes after
which the Penalty is decreased. After the router
assigns a Penalty of 1024 to a route, the
Penalty is decreased by half after the half-life
period expires. (Default: 15 minutes)
• reuse range: 1 to 20000. This number is
compared to the flapping route’s Penalty value.
If the Penalty value is less than the reuse value,
the flapping route is once again advertised (or
no longer suppressed). (Default: 750)
• suppress range: 1 to 20000. This number is
compared to the flapping route’s Penalty value.
If the Penalty value is greater than the suppress
value, the flapping route is no longer
advertised (that is, it is suppressed). (Default:
2000.)
• max-suppress-time range: 1 to 255. The
maximum number of minutes a route can be
suppressed. The default is four times the
half-life value. (Default: 60 minutes.)
To view a count of dampened routes, history routes and penalized routes when route dampening is enabled,
look at the seventh line of the show ip bgp summary command output (Figure 10-32).
To view which routes are dampened (non-active), use the show ip bgp dampened-routes command in
EXEC Privilege mode.
clear ip bgp dampening [ip-address EXEC Privilege Clear all information or only information on a specific
mask] route.
Use the following command in EXEC and EXEC Privilege mode to view statistics on route flapping.
show ip bgp flap-statistics EXEC View all flap statistics or for specific routes meeting the
[ip-address [mask]] [filter-list EXEC Privilege following criteria:
as-path-name] [regexp • ip-address [mask]: enter the IP address and mask
regular-expression] • filter-list as-path-name: enter the name of an
AS-PATH ACL.
• regexp regular-expression: enter a regular express
to match on.
By default, the path selection in FTOS is deterministic, that is, paths are compared irrespective of the order
of their arrival. You can change the path selection method to non-deterministic, that is, paths are compared
in the order in which they arrived (starting with the most recent). Furthermore, in non-deterministic mode,
the software may not compare MED attributes though the paths are from the same AS.
Use the following command in CONFIGURATION ROUTER BGP mode to change the path selection
from the default mode (deterministic) to non-deterministic.
Note: When you change the best path selection method, path selection for existing paths remains
unchanged until you reset it by entering the clear ip bgp command in EXEC Privilege mode.
Use either or both of the following commands in the CONFIGURATION ROUTER BGP mode to
configure BGP timers.
neighbors {ip-address | CONFIG-ROUTER- Configure timer values for a BGP neighbor or peer
peer-group-name} timers keepalive BGP group.
holdtime • keepalive range: 1 to 65535. Time interval, in
seconds, between keepalive messages sent to the
neighbor routers. (Default: 60 seconds)
• holdtime range: 3 to 65536. Time interval, in
seconds, between the last keepalive message and
declaring the router dead. (Default: 180 seconds)
timers bgp keepalive holdtime CONFIG-ROUTER- Configure timer values for all neighbors.
BGP • keepalive range: 1 to 65535. Time interval, in
seconds, between keepalive messages sent to the
neighbor routers. (Default: 60 seconds)
• holdtime range: 3 to 65536. Time interval, in
seconds, between the last keepalive message and
declaring the router dead. (Default: 180 seconds)
Use the show config command in CONFIGURATION ROUTER BGP mode or the show running-config
bgp command in EXEC Privilege mode to view non-default values.
Timer values configured with the neighbor timers command override the timer values configured with the
timers bgp command.
When two neighbors, configured with different keepalive and holdtime values, negotiate for new values, the
resulting values will be as follows:
• the lower of the holdtime values is the new holdtime value, and
• whichever is the lower value; one-third of the new holdtime value, or the configured keepalive value is
the new keepalive value.
Changing routing policies typically requires a reset of BGP sessions (the TCP connection) for the policies
to take effect. This type of reset causes undue interruption to traffic due to the hard reset of the BGP cache
and the time it takes to re-establish the session.
BGP soft reconfiguration allows you to re-apply policies to a session without resetting the BGP session.
You can perform soft reconfiguration on a per-neighbor basis for either inbound or outbound policies. BGP
soft reconfiguration clears and reapplies policies without resetting the TCP connection.
reconfiguration.
clear ip bgp { * | as-number | ipv4- EXEC Privilege Clears and reapplies policies on:
neighbor-addr | ipv6-neighbor-addr | *: All peers
peer-group name} {ipv4 unicast | ipv4 as-number: BGP routers that belong to the specified
multicast | ipv6 unicast} soft [in | out] AS
neighbor-addr: BGP neighbor with specified IP
address
Type of routes to be reapplied:
ipv4 unicast, ipv4 multicast, or ipv6 unicast
in: Reapplies only inbound policies
out: Reapplies only outbound policies
When inbound soft reconfiguration is enabled on a neighbor and you enter the clear ip bgp soft in
command, the update database stored in the router is replayed and updates are reevaluated. The replay and
update process is triggered only if a route-refresh request is not negotiated with the peer. If a route-refresh
request is negotiated, BGP sends a request to the neighbor and receives all of the peer’s updates.
To use soft reconfiguration (or soft reset) without preconfiguration, both BGP peers must support the soft
route refresh capability, which is advertised in the open message sent when the peers establish a TCP
session. To determine whether a BGP router supports this capability, use the show ip bgp neighbors
command. If a router supports the route refresh capability, the following message is displayed:
If you specify a BGP peer group by using the peer-group-name argument, all members of the peer group
inherit the characteristic configured with this command.
The following example (Figure 10-33) shows how to enable inbound soft reconfiguration for the neighbor
10.108.1.1. All updates received from this neighbor are stored unmodified, regardless of the inbound
policy. When inbound soft reconfiguration is performed later, the stored information is used to generate a
new set of inbound updates.
The BGP route map continue feature (in ROUTE-MAP mode) allows movement from one route-map
entry to a specific route-map entry (the sequence number). If the sequence number is not specified, the
continue feature moves to the next sequence number (also known as an implied continue). If a match
clause exists, the continue feature executes only after a successful match occurs. If there are no successful
matches, continue is ignored.
continue [sequence-number]
The continue feature can exist without a match clause. Without a match clause, the continue clause
executes and jumps to the specified route-map entry. With a match clause and a continue clause, the match
clause executes first and the continue clause next in a specified route map entry. The continue clause
launches only after a successful match. The behavior is:
• A successful match with a continue clause—the route map executes the set clauses and then goes to the
specified route map entry upon execution of the continue clause.
• If the next route map entry contains a continue clause, the route map executes the continue clause if a
successful match occurs.
• If the next route map entry does not contain a continue clause, the route map evaluates normally. If a
match does not occur, the route map does not continue and falls-through to the next sequence number,
if one exists.
If the route-map entry contains sets with the continue clause, then the set actions operation is performed
first followed by the continue clause jump to the specified route map entry.
• If a set actions operation occurs in the first route map entry and then the same set action occurs with a
different value in a subsequent route map entry, the last set of actions overrides the previous set of
actions with the same set command.
• If the set community additive and set as-path prepend commands are configured, the communities
and AS numbers are prepended.
Multiprotocol BGP (MBGP) is an enhanced BGP that carries IP multicast routes. BGP carries two sets of
routes: one set for unicast routing and one set for multicast routing. The routes associated with multicast
routing are used by the Protocol Independent Multicast (PIM) to build data distribution trees.
FTOS MBGP is implemented as per RFC 1858. The MBGP feature can be enabled per router and/or per
peer/peer-group.
When a peer is configured to support IPv4 Multicast, FTOS takes the following actions:
• Send a capacity advertisement to the peer in the BGP Open message specifying IPv4 Multicast as a
supported AFI/SAFI (Subsequent Address Family Identifier).
• If the corresponding capability is received in the peer’s Open message, BGP will mark the peer as
supporting the AFI/SAFI.
• When exchanging updates with the peer, BGP sends and receives IPv4 Multicast routes if the peer is
marked as supporting that AFI/SAFI.
• Exchange of IPv4 Multicast route information occurs through the use of two new attributes called
MP_REACH_NLRI and MP_UNREACH_NLRI, for feasible and withdrawn routes, respectively.
• If the peer has not been activated in any AFI/SAFI, the peer remains in Idle state.
Most FTOS BGP IPv4 Unicast commands are extended to support the IPv4 Multicast RIB using extra
options to the command. See the FTOS Command Line Interface Reference for a detailed description of the
MBGP commands.
Debugging BGP
Use any of the commands in EXEC Privilege mode to enable BGP debugging.
debug ip bgp [ip-address | peer-group EXEC Privilege View all information on BGP, including BGP
peer-group-name] [in | out] events, keepalives, notifications, and updates.
debug ip bgp dampening [in | out] EXEC Privilege View information on BGP route being
dampened.
debug ip bgp [ip-address | peer-group EXEC Privilege View information on local BGP state changes
peer-group-name] events [in | out] and other BGP events.
debug ip bgp [ip-address | peer-group EXEC Privilege View information about BGP KEEPALIVE
peer-group-name] keepalive [in | out] messages.
debug ip bgp [ip-address | peer-group EXEC Privilege View information about BGP notifications
peer-group-name] notifications [in | out] received from or sent to neighbors.
debug ip bgp [ip-address | peer-group EXEC Privilege View information about BGP updates and filter
peer-group-name] updates [in | out] by prefix name
[prefix-list name]
bgp soft-reconfig-backup
FTOS displays debug messages on the console. To view which debugging commands are enabled, use the
show debugging command in EXEC Privilege mode.
Use the keyword no followed by the debug command To disable a specific debug command. For example,
to disable debugging of BGP updates, enter no debug ip bgp updates command.
Notification History
'UPDATE error/Missing well-known attr' Sent : 1 Recv: 0
'Connection Reset' Sent : 1 Recv: 0
Capturing PDUs
Capture incoming and outgoing PDUs on a per-peer basis using the command capture bgp-pdu neighbor
direction. Disable capturing using the no form of this command.
are cyclic and reaching the limit prompts the system to overwrite the oldest PDUs when new ones are
received for a given neighbor or direction. Setting the buffer size to a value lower than the current max,
might cause captured PDUs to be freed to set the new limit.
Note: Memory on RP1 is not pre-allocated, and is allocated only when a PDU needs to be captured.
Use the command capture bgp-pdu max-buffer-size (Figure 10-35) to change the maximum buffer size.
View the captured PDUs using the command show capture bgp-pdu neighbor.
• BGP is disabled
• A neighbor is unconfigured
• clear ip bgp is issued
• New PDU are captured and there is no more space to store them
• The max buffer size is reduced. (This may cause PDUs to be cleared depending upon the buffer space
consumed and the new limit.)
FTOS(conf-router_bgp)#do sho ip bg s
BGP router identifier 172.30.1.56, local AS number 65056
BGP table version is 313511, main routing table version 313511
207896 network entrie(s) and 207896 paths using 42364576 bytes of memory
59913 BGP path attribute entrie(s) using 2875872 bytes of memory
59910 BGP AS-PATH entrie(s) using 2679698 bytes of memory
3 BGP community entrie(s) using 81 bytes of memory
PDU Counters
FTOS version 7.5.1.0 introduces additional counters for various types of PDUs sent and received from
neighbors. These are seen in the output of the command show ip bgp neighbor.
Sample Configurations
The following configurations are examples for enabling BGP and setting up some peer groups. These are
not comprehensive directions. They are intended to give you a some guidance with typical configurations.
You can copy and paste from these examples to your CLI. Be sure you make the necessary changes to
support your own IP Addresses, Interfaces, Names, etc.
Figure 10-37 is a graphic illustration of the configurations shown on the following pages. These
configurations show how to create BGP areas using physical and virtual links. They include setting up the
interfaces and peers groups with each other.
AS 99 Physical Links
Virtual Links
GigE 1/21 GigE 2/11
10.0.1.21 /24 10.0.1.22 /24
Peer Group AAA
Loopback 1
Lo
Loopbackck 1 192.168.128.2 /24
19
192.168.128.1 /24 C
Pe
CC
e
p
rG
o u GigE 2/31
Gr
ro
GigE 1/31
er
u
10.0.2.2 /24
p
10.0.3.31 /24 Pe
BB
B
AS 100
192.168.128.2 99 4 5 4 0 0 00:00:32 1
192.168.128.3 100 5 4 1 0 0 00:00:09 4
R1#
R2# conf
R2(conf)#int loop 0
R2(conf-if-lo-0)#ip address 192.168.128.2/24
R2(conf-if-lo-0)#no shutdown
R2(conf-if-lo-0)#show config
!
interface Loopback 0
ip address 192.168.128.2/24
no shutdown
R2(conf-if-lo-0)#int gig 2/11
R2(conf-if-gi-2/11)#ip address 10.0.1.22/24
R2(conf-if-gi-2/11)#no shutdown
R2(conf-if-gi-2/11)#show config
!
interface GigabitEthernet 2/11
ip address 10.0.1.22/24
no shutdown
R2(conf-if-gi-2/11)#int gig 2/31
R2(conf-if-gi-2/31)#ip address 10.0.2.2/24
R2(conf-if-gi-2/31)#no shutdown
R2(conf-if-gi-2/31)#show config
!
interface GigabitEthernet 2/31
ip address 10.0.2.2/24
no shutdown
R2(conf-if-gi-2/31)#
R2(conf-if-gi-2/31)#router bgp 99
R2(conf-router_bgp)#network 192.168.128.0/24
R2(conf-router_bgp)#neighbor 192.168.128.1 remote 99
R2(conf-router_bgp)#neighbor 192.168.128.1 no shut
R2(conf-router_bgp)#neighbor 192.168.128.1 update-source loop 0
R2(conf-router_bgp)#neighbor 192.168.128.3 remote 100
R2(conf-router_bgp)#neighbor 192.168.128.3 no shut
R2(conf-router_bgp)#neighbor 192.168.128.3 update loop 0
R2(conf-router_bgp)#show config
!
router bgp 99
bgp router-id 192.168.128.2
network 192.168.128.0/24
bgp graceful-restart
neighbor 192.168.128.1 remote-as 99
neighbor 192.168.128.1 update-source Loopback 0
neighbor 192.168.128.1 no shutdown
neighbor 192.168.128.3 remote-as 100
neighbor 192.168.128.3 update-source Loopback 0
neighbor 192.168.128.3 no shutdown
R2(conf-router_bgp)#end
R3(conf-if-gi-3/21)#
R3(conf-if-gi-3/21)#router bgp 100
R3(conf-router_bgp)#show config
!
router bgp 100
R3(conf-router_bgp)#network 192.168.128.0/24
R3(conf-router_bgp)#neighbor 192.168.128.1 remote 99
R3(conf-router_bgp)#neighbor 192.168.128.1 no shut
R3(conf-router_bgp)#neighbor 192.168.128.1 update-source loop 0
R3(conf-router_bgp)#neighbor 192.168.128.2 remote 99
R3(conf-router_bgp)#neighbor 192.168.128.2 no shut
R3(conf-router_bgp)#neighbor 192.168.128.2 update loop 0
R3(conf-router_bgp)#show config
!
router bgp 100
network 192.168.128.0/24
neighbor 192.168.128.1 remote-as 99
neighbor 192.168.128.1 update-source Loopback 0
neighbor 192.168.128.1 no shutdown
neighbor 192.168.128.2 remote-as 99
neighbor 192.168.128.2 update-source Loopback 0
neighbor 192.168.128.2 no shutdown
R3(conf)#end
R3#show ip bgp summary
BGP router identifier 192.168.128.3, local AS number 100
BGP table version is 1, main routing table version 1
1 network entrie(s) using 132 bytes of memory
3 paths using 204 bytes of memory
BGP-RIB over all using 207 bytes of memory
2 BGP path attribute entrie(s) using 128 bytes of memory
2 BGP AS-PATH entrie(s) using 90 bytes of memory
2 neighbor(s) using 9216 bytes of memory
Neighbor AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/Pfx
192.168.128.1 99 24 25 1 0 0 00:14:20 1
192.168.128.2 99 14 14 1 0 0 00:10:22 1
R1#conf
R1(conf)#router bgp 99
R1(conf-router_bgp)# network 192.168.128.0/24
R1(conf-router_bgp)# neighbor AAA peer-group
R1(conf-router_bgp)# neighbor AAA no shutdown
R1(conf-router_bgp)# neighbor BBB peer-group
R1(conf-router_bgp)# neighbor BBB no shutdown
R1(conf-router_bgp)# neighbor 192.168.128.2 peer-group AAA
R1(conf-router_bgp)# neighbor 192.168.128.3 peer-group BBB
R1(conf-router_bgp)#
R1(conf-router_bgp)#show config
!
router bgp 99
network 192.168.128.0/24
neighbor AAA peer-group
neighbor AAA no shutdown
neighbor BBB peer-group
neighbor BBB no shutdown
neighbor 192.168.128.2 remote-as 99
neighbor 192.168.128.2 peer-group AAA
neighbor 192.168.128.2 update-source Loopback 0
neighbor 192.168.128.2 no shutdown
neighbor 192.168.128.3 remote-as 100
neighbor 192.168.128.3 peer-group BBB
neighbor 192.168.128.3 update-source Loopback 0
neighbor 192.168.128.3 no shutdown
R1#
R1#show ip bgp summary
BGP router identifier 192.168.128.1, local AS number 99
BGP table version is 1, main routing table version 1
1 network entrie(s) using 132 bytes of memory
3 paths using 204 bytes of memory
BGP-RIB over all using 207 bytes of memory
2 BGP path attribute entrie(s) using 96 bytes of memory
2 BGP AS-PATH entrie(s) using 74 bytes of memory
2 neighbor(s) using 8672 bytes of memory
Notification History
'Connection Reset' Sent : 1 Recv: 0
Last notification (len 21) sent 00:00:57 ago
ffffffff ffffffff ffffffff ffffffff 00150306 00000000
Local host: 192.168.128.1, Local port: 179
Foreign host: 192.168.128.2, Foreign port: 65464
R2#conf
R2(conf)#router bgp 99
R2(conf-router_bgp)# neighbor CCC peer-group
R2(conf-router_bgp)# neighbor CC no shutdown
R2(conf-router_bgp)# neighbor BBB peer-group
R2(conf-router_bgp)# neighbor BBB no shutdown
R2(conf-router_bgp)# neighbor 192.168.128.1 peer AAA
R2(conf-router_bgp)# neighbor 192.168.128.1 no shut
R2(conf-router_bgp)# neighbor 192.168.128.3 peer BBB
R2(conf-router_bgp)# neighbor 192.168.128.3 no shut
R2(conf-router_bgp)#show conf
!
router bgp 99
network 192.168.128.0/24
neighbor AAA peer-group
neighbor AAA no shutdown
neighbor BBB peer-group
neighbor BBB no shutdown
neighbor 192.168.128.1 remote-as 99
neighbor 192.168.128.1 peer-group CCC
neighbor 192.168.128.1 update-source Loopback 0
neighbor 192.168.128.1 no shutdown
neighbor 192.168.128.3 remote-as 100
neighbor 192.168.128.3 peer-group BBB
neighbor 192.168.128.3 update-source Loopback 0
neighbor 192.168.128.3 no shutdown
R2(conf-router_bgp)#end
R2#
R2#show ip bgp summary
BGP router identifier 192.168.128.2, local AS number 99
BGP table version is 2, main routing table version 2
1 network entrie(s) using 132 bytes of memory
3 paths using 204 bytes of memory
BGP-RIB over all using 207 bytes of memory
2 BGP path attribute entrie(s) using 128 bytes of memory
2 BGP AS-PATH entrie(s) using 90 bytes of memory
2 neighbor(s) using 9216 bytes of memory
R3(conf-router_bgp)#end
Notification History
'HOLD error/Timer expired' Sent : 1 Recv: 0
'Connection Reset' Sent : 2 Recv: 2
CAM Profiles
Dell Force10 systems partition each CAM module so that it can store the different types of information.
The size of each partition is specified in the CAM profile. A CAM profile is stored on every card,
including each RPM. The same profile must be on every line card and RPM in the chassis.
There is a default CAM profile and several other CAM profiles available so that you can partition the
CAM according to your performance requirements. For example, the default profile has 1K Layer 2
ingress ACL entries. If you need more memory for Layer 2 ingress ACLs, select the profile l2-ipv4-inacl.
Table 11-1 describes the available profiles. The default profile is an all-purpose profile that allocates CAM
space according to the way Dell Force10 systems are most commonly used. In general, non-default profiles
allocate more space to particular regions to accommodate specific applications. The size of CAM
partitions is measured in entries. The total CAM space is finite, therefor adding entries to one region
necessarily decreases the number available to other regions.
Note: Not all CAM profiles and microcodes are available for all systems. Refer to the Command Line
Interface Reference Guide for details regarding available profiles for each system.
Default An all-purpose profile that allocates CAM space according to the way Dell Force10 systems are most
commonly used.
Available Microcodes: default, lag-hash-align, lag-hash-mpls, l2-switched-pbr
eg-default For EG-series line cards only. EG series line cards have two CAM modules per Port-pipe.
Available Microcodes: default, ipv6-extacl
ipv4-320k Provides 320K entries for the IPv4 Forwarding Information Base (FIB) and reduces the IPv4 Flow
partition to 12K.
Available Microcodes: default, lag-hash-mpls, l2-switched-pbr
l2-ipv4-inacl Provides 32K entries for Layer 2 ingress ACLs and 28K entries for Layer 3 IPv4 ingress ACLs.
Available Microcodes: default
unified-default Maintains the CAM allocations for the and IPv4 FIB while allocating more CAM space for the Ingress
and Egress Layer 2 ACL, and IPv4 ACL regions.
Available Microcodes: ipv6-extacl
ipv4-64k-ipv6 Provides IPv6 functionality; an alternate to ipv6-extacl that redistributes CAM space from the IPv4FIB
to IPv4Flow and IPv6FIB.
Available Microcodes: ipv6-extacl
The size of CAM partitions is measured in entries. Table 11-1 shows the number of entries available in
each partition for all CAM profiles. The total CAM space is finite, therefor adding entries to one region
necessarily decreases the number available to other regions.
EgIPv4ACL
EgIPv6ACL
EgL2ACL
Reserved
IPv4Flow
IPv6Flow
Partition
IPv4ACL
IPv6ACL
IPv4FIB
IPv6FIB
L2ACL
L2FIB
Profile
Microcode
Microcode is a compiled set of instructions for a CPU. On Dell Force10 systems, the microcode controls
how packets are handled.
There is a default microcode, and several other microcodes are available, so that you can adjust packet
handling according to your application. Specifying a microcode is mandatory when selecting a CAM
profile (though you are not required to change it).
Note: Not all CAM profiles and microcodes are available for all systems. Refer to the Command Line
Interface Reference Guide for details regarding available profiles for each system.
Microcode Description
lag-hash-align For applications that require the same hashing for bi-directional traffic (for example, VoIP
call or P2P file sharing). For port-channels, this microcode maps both directions of a
bi-directional flow to the same output link.
Microcode Description
lag-hash-mpls For hashing based on MPLS labels (up to five labels deep). With the default microcode, MPLS
packets are distributed over a port-channel based on the MAC source and destination address. With
the lag-hash-mpls microcode, MPLS packets are distributed across the port-channel based on IP
source and destination address and IP protocol. This is applicable for MPLS packets with up to five
labels. When the IP header is not available after the 5th label, hashing for default load-balance is
based on MPLS labels. For packets with more than 5 labels, hashing is always based on the MAC
source and destination address.
acl-group For applications that need 16k egress IPv4 ACLs (for example, the VLAN ACL Group feature,
which permits group VLANs IP egress ACLs.
l2-switched-pbr E-Series TeraScale only: If you apply a PBR redirect list (using the ip re-direct group command)
to a VLAN interface, Layer 2 traffic is redirected and dropped by default. To avoid having Layer 2
traffic affected by PBR, configure a CAM profile that supports l2-switched-pbr (IPv4-LDA)
microcode. l2-switched-pbr microcode allows only Layer 3 traffic to be redirected while Layer 2
traffic is switched within the VLAN.
The default CAM profile has 1K Layer 2 ingress ACL entries. If you need more memory for Layer 2
ingress ACLs, select the profile l2-ipv4-inacl.
When budgeting your CAM allocations for ACLs and QoS configurations, remember that ACL and QoS
rules might consume more than one CAM entry depending on complexity. For example, TCP and UDP
rules with port range options might require more than one CAM entry.
The Layer 2 ACL CAM partition has sub-partitions for several types of information. Table 11-4 lists the
sub-partition and the percentage of the Layer 2 ACL CAM partition that FTOS allocates to each by default.
Partition % Allocated
Sysflow 6
L2ACL 14
*PVST 50
Partition % Allocated
QoS 12
L2PT 13
FRRP 5
You can re-configure the amount of space, in percentage, allocated to each sub-partition. As with the
IPv4Flow partition, you can configure the Layer 2 ACL partition from EXEC Privilege mode or
CONFIGURATION mode.
The amount of space that you can distribute to the sub-partitions is equal to the amount of CAM space that
the selected CAM profile allocates to the Layer 2 ACL partition. FTOS requires that you specify the
amount of CAM space for all sub-partitions and that the sum of all sub-partitions is 100%. FTOS displays
the following message if the total allocated space is not correct:
Boot Behavior
The profile and microcode loaded on the primary RPM determines the profile and microcode that is
required on all other chassis components and is called the “chassis profile.” A profile mismatch condition
exists if either the CAM profile or the microcode does not match. The following points describe line
card boot behavior when the line card profile does not match the chassis profile.
# Before reload:
01:09:56: %RPM0-P:CP %CHMGR-4-EG_PROFILE_WARN: If EG CAM profile is selected, non-EG cards
will be in problem state after reload
# After reload:
00:04:46: %RPM0-P:CP %CHMGR-3-PROFILE_MISMATCH: Mismatch: line card 1 has mismatch CAM
profile or microcode
# Before reload:
01:09:56: %RPM0-P:CP %CHMGR-4-EH_PROFILE_WARN: If EH CAM profile is selected, non-EJ cards
will be in problem state after reload
# After reload:
00:04:46: %RPM0-P:CP %CHMGR-3-PROFILE_MISMATCH: Mismatch: line card 1 has mismatch CAM
profile or microcode
-- Line card 1 --
Status : card problem - mismatch cam profile
Next Boot : online
Required Type : E48TF - 48-port 10/100/1000Base-T line card with RJ-45 interfaces (EF)
Current Type : E48TF - 48-port 10/100/1000Base-T line card with RJ-45 interfaces (EF)
Hardware Rev : Base - 1.1 PP0 - 1.1 PP1 - 1.1
Num Ports : 48
Up Time : 0 sec
FTOS Version : 7.6.1.0
Jumbo Capable : yes
-- Line card 1 --
Status : card problem - mismatch cam profile
Next Boot : online
Required Type : E90MH - 90-port 10/100/1000Base-T line card with mini RJ-21 interfaces (EH)
Current Type : E90MH - 90-port 10/100/1000Base-T line card with mini RJ-21 interfaces (EH)
Hardware Rev : Base - 0.3 PP0 - 1.1 PP0 - PP1 -
Num Ports : 90
Up Time : 0 sec
FTOS Version : 8.1.1.0
Jumbo Capable : yes
• Configure more Layer 2 FIB entries when the system is deployed as a switch.
• Configure more Layer 3 FIB entries when the system is deployed as a router.
• Configure more ACLs (when IPv6 is not employed).
• Hash MPLS packets based on source and destination IP addresses for LAGs. See LAG Hashing on
page 298.
• Hash based on bidirectional flow for LAGs. See LAG Hashing based on Bidirectional Flow on
page 299.
All components in the chassis must have the same CAM profile and microcode. The profile and microcode
loaded on the primary RPM determines the profile that is required on all other chassis components.
• If a newly installed line card has a profile different from the primary RPM, the card reboots so that it
can load the proper profile.
• If a the standby RPM has a profile different from the primary RPM, the card reboots so that it can load
the proper profile.
Note: If selecting a cam-profile for VRF (cam-profile ipv4-vrf or ipv4-v6-vrf), implement the command
in the CONFIGURATION mode only. If you use EXEC Privilege mode, the linecards may go into an
error state.
3 Verify that the new CAM profile will be show cam-profile summary EXEC Privilege
written to the CAM on the next boot.
4 Reload the system. reload EXEC Privilege
CAM Allocation
User Configurable CAM Allocations is available on platforms: cs
Allocate space for IPV4 ACLs and QoS regions, and IPv6 6 ACLs and QoS regions on the C-Series and
S-Series by using the cam-acl command in CONFIGURATION mode.
The CAM space is allotted in FP blocks. The total space allocated must equal 13 FP blocks. The default
CAM Allocation settings on a C-Series system are:
• L3 ACL (ipv4acl): 5
• L2 ACL(l2acl) : 6
• IPv6 L3 ACL (ipv6acl): 0
• L3 QoS (ipv4qos): 1
• L2 QoS (l2qos): 1
• L2PT (l2pt): 0
• MAC ACLs (ipmacacl): 0
• ECFMACL (ecfmacl): 0
• VMAN QoS (vman-qos): 0
• VMAN Dual QoS (vman-dual-qos): 0
Note: The ipmacacl region was introduced for Secure DHCP. These ACL are not created through CLI,
but rather are system generated from the DHCP snooping table. Whenever a new DHCP client is
assigned an IP, and ip dhcp snooping source-address-validation ipmac is configured on the interface
connected to the client, a single ACL is installed on the interface to permit (only) the source IP and source
MAC pair.
You must save the new CAM settings to the startup-config (write-mem or copy run start) then reload the
system for the new settings to take effect.
To configure the IPv4 and IPv6 ACLs and Qos regions on the entire system:
Note: Selecting default resets the CAM entries to the default settings. Select l2acl to allocate space
for the ACLs, and QoS regions.
2 Enter the number of FP blocks for each l2acl number ipv4acl number ipv6acl EXEC Privilege
region. number, ipv4qos number l2qos
number, l2pt number ipmacacl
number ecfmacl number [vman-qos |
vman-dual-qos number
3 Verify that the new settings will be written show cam-acl EXEC Privilege
to the CAM on the next boot.
Use this command to determine whether sufficient ACL CAM space is available to enable a service-policy.
Create a Class Map with all required ACL rules, then execute the test cam-usage command in Privilege
mode to verify the actual CAM space required. Figure 11-3 gives a sample of the output shown when
executing the command. The status column indicates whether or not the policy can be enabled.
Linecard | Portpipe | CAM Partition | Available CAM | Estimated CAM per Port | Status
------------------------------------------------------------------------------------------
2 | 1 | IPv4Flow | 232 | 0 | Allowed
2 | 1 | IPv6Flow | 0 | 0 | Allowed
4 | 0 | IPv4Flow | 232 | 0 | Allowed
4 | 0 | IPv6Flow | 0 | 0 | Allowed
FTOS#
FTOS#show cam-profile
CamSize : 18-Meg
: Current Settings : Next Boot
Profile Name : Default : Default
L2FIB : 32K entries : 32K entries
L2ACL : 1K entries : 1K entries
IPv4FIB : 256K entries : 256K entries
IPv4ACL : 12K entries : 12K entries
IPv4Flow : 24K entries : 24K entries
EgL2ACL : 1K entries : 1K entries
EgIPv4ACL : 1K entries : 1K entries
Reserved : 8K entries : 8K entries
FIB : 0 entries : 0 entries
ACL : 0 entries : 0 entries
Flow : 0 entries : 0 entries
EgACL : 0 entries : 0 entries
MicroCode Name : Default : Default
--More--
View a brief output of the command show cam-profile using the summary option.
The command show running-config cam-profile shows the current profile and microcode (Figure 11-5).
Note: If you select the CAM profile from CONFIGURATION mode, the output of this command does not
reflect any changes until you save the running-configuration and reload the chassis.
FTOS#
-- Line card 0 --
Current Settings(in block sizes)
L2Acl : 2
Ipv4Acl : 2
Ipv6Acl : 2
Ipv4Qos : 2
L2Qos : 2
L2PT : 1
IpMacAcl : 2
VmanQos : 0
VmanDualQos : 0
-- Line card 6 --
Current Settings(in block sizes)
L2Acl : 2
Ipv4Acl : 2
Ipv6Acl : 2
Ipv4Qos : 2
L2Qos : 2
L2PT : 1
IpMacAcl : 2
VmanQos : 0
VmanDualQos : 0
ACL 8K — —
Multicast FIB/ACL 9K 3K 3K
PBR 1K 1K 1K
QoS 8K 2K 2K
System Flow 5K 5K 5K
Trace Lists 1 1K 1K
You can re-configure the amount of space allocated for each type of entry. FTOS requires that you specify
an amount of CAM space for all types and in the order shown in Table 11-5.
from CONFIGURATION mode, however, you must save the running-configuration to affect the
change.
The amount of space that is allocated among the sub-partitions must be equal to the amount of CAM space
allocated to IPv4Flow by the selected CAM profile (see Table 11-1.); Message 3 is displayed if the total
allocated space is not correct.
% Error: Total size must add up to match IPv4flow size of 24K required by the configured
profile.
The minimum amount of space that can be allocated to any sub-partition is 1K, except for System flow, for
which the minimum is 4K.
To re-allocate CAM space within the IPv4Flow partition on the entire system:
3 Verify that the new CAM configuration will show cam-ipv4flow EXEC Privilege
be written to the CAM on the next boot.
FTOS(conf)#cam-ipv4flow default
FTOS#copy running-config startup-config
File with same name already exist.
Proceed to copy the file [confirm yes/no]: yes
!
3914 bytes successfully copied
FTOS#sh cam-ipv4flow
-- Chassis Cam Ipv4Flow --
Current Settings Next Boot
Multicast Fib/Acl : 8K 9K
Pbr : 2K 1K
Qos : 7K 8K
System Flow : 6K 5K
Trace Lists : 1K 1K
-- Line card 0 --
-- Line card 1 --
Current Settings Next Boot
Multicast Fib/Acl : 8K 9K
Pbr : 2K 1K
Qos : 7K 8K
System Flow : 6K 5K
Trace Lists : 1K 1K
Partition % Allocated
Sysflow 6
L2ACL 14
*PVST 50
QoS 12
Partition % Allocated
L2PT 13
FRRP 5
You can re-configure the amount of space, in percentage, allocated to each sub-partition.
• Apply the Ingress Layer 2 ACL configuration to entire system by entering the command cam-l2acl
from CONFIGURATION mode, however, you must save the running-configuration to affect the
change.
The amount of space that you can distribute to the sub-partitions is equal to the amount of CAM space that
the selected CAM profile allocates to the Ingress Layer 2 ACL partition (see Table 11-1). FTOS requires
that you specify the amount of CAM space for all sub-partitions and that the sum of all sub-partitions is
100%. FTOS displays message Message 4 if the total allocated space is not correct.
Note: You must allocate at least (<number of VLANs> * <Number of switching ports per port-pipe>)
* entries at least when employing PVST+ . For example, the default CAM Profile allocates 1000 entries to
the Ingress Layer 2 ACL CAM region, and a 48-port linecard has two port-pipes with 24 ports each. If
you have 5 VLANs, then you must allocate at least 120 (5*24) entries to the PVST Ingress Layer 2 ACL
CAM region, which is 12% of the total 1000 available entries.
To re-allocate CAM space within the Ingress Layer 2 ACL partition on the entire system (Figure 11-9):
3 Verify that FTOS will write the new CAM show cam-l2acl EXEC Privilege
configuration to the CAM on the next boot.
[output omitted]
FTOS(conf)#cam-l2acl system-flow 100 l2acl 0 p 0 q 0 l 0 f 0
FTOS(conf)#do show cam-l2acl | find “Line card 1”
-- Line card 1 --
Current Settings(in percent)
Sysflow : 6
L2Acl : 14
Pvst : 50
Qos : 12
L2pt : 13
Frrp : 5
[output omitted]
FTOS(conf)#cam-profile ?
default Enable default CAM profile
eg-default Enable eg-default CAM profile
ipv4-320k Enable 320K CAM profile
ipv4-egacl-16k Enable CAM profile with 16K IPv4 egress ACL
ipv6-extacl Enable CAM profile with extended ACL
l2-ipv4-inacl Enable CAM profile with 32K L2 and 28K IPv4 ingress ACL
unified-default Enable default unified CAM profile
FTOS(conf)#cam-profile default microcode ?
default Enable default microcode
lag-hash-align Enable microcode with LAG hash align
lag-hash-mpls Enable microcode with LAG hash MPLS
FTOS(conf)#cam-profile default microcode default
FTOS(conf)#cam-ipv4flow ?
default Reset IPv4flow CAM entries to default setting
multicast-fib Set multicast FIB entries
FTOS(conf)#cam-l2acl ?
default Reset L2-ACL CAM entries to default setting
system-flow Set system flow entries
CAM Optimization
CAM optimization is supported on platforms cs
When this command is enabled, if a Policy Map containing classification rules (ACL and/or dscp/
ip-precedence rules) is applied to more than one physical interface on the same port-pipe, only a single
copy of the policy is written (only 1 FP entry will be used). When the command is disabled, the system
behaves as described in this chapter.
LAG Hashing
FTOS includes a CAM profile and microcode that treats MPLS packets as non-IP packets. Normally,
switching and LAG hashing is based on source and destination MAC addresses. Alternatively, you can
base LAG hashing for MPLS packets on source and destination IP addresses. This type of hashing is
allowed for MPLS packets with 5 labels or less.
• When MPLS IP packets are received, FTOS looks up to 5 labels deep for the IP header.
• When an IP header is present, hashing is based on IP 3 tuple (source IP address, destination IP address,
and IP protocol).
• If an IP header is not found after the 5th label, hashing is based on the MPLS labels.
To enable this type of hashing, use the default CAM profile with the microcode lag-hash-mpls.
Note: Do not use this CAM profile for Layer 2 egress ACLs.
• Use the eg-default CAM profile in a chassis that has only EG Series line cards. If this profile is used in
a chassis with non-EG line cards, the non-EG line cards enter a problem state.
• Before moving a card to a new chassis, change the CAM profile on a card to match the new system
profile.
• After installing a secondary RPM into a chassis, copy the running-configuration to the
startup-configuration.
• Change to the default profile if downgrading to and FTOS version earlier than 6.3.1.1.
• Use the CONFIGURATION mode commands so that the profile is change throughout the system.
• Use the EXEC Privilege mode commands to match the profile of a component to the profile of the
target system.
The default CAM profile allocates a partition within the IPv4Flow region to store QoS service policies. If
the QoS CAM space is exceeded, messages similar to the ones in Message 5 are displayed.
Step Task
1 Verify that you have configured a CAM profile that allocates 24K entries to the IPv4 system flow region. See
View CAM Profiles on page 291.
2 Allocate more entries in the IPv4Flow region to QoS. See Configure IPv4Flow Sub-partitions on page 293.
FTOS version 7.4.1 introduced the ability to view the actual CAM usage before applying a service-policy.
The command test cam-usage service-policy provides this test framework, see Pre-calculating Available
QoS CAM Space on page 874.
Note: For troubleshooting other CAM issues see the E-Series Network Operations Guide.
Configuration Replace and Rollback enables you to replace the current running-configuration with
different configuration without restarting the chassis.
Without this feature, if you want to load a new running configuration, you must copy the desired
configuration file to the startup-configuration (using the command copy file startup-configuration) and
reboot the chassis (using the command reload). Copying the desired configuration file to the
running-configuration file (using the command copy file running-configuration) merely appends the running
configuration; any conflicts between the two files is reported to the console, but FTOS does not overwrite
the running configuration, therefore the new configuration is not fully implemented.
The reboot process takes several minutes by default, and if your startup-configuration is extensive, the
process can take several minutes more. As a result, when the Dell Force10 system is deployed in
production environment, you must wait for a maintenance window to load a new configuration.
The Configuration Replace and Rollback feature allows you to archive your running configuration, and at
a later time, replace your running configuration with the archived one without rebooting the chassis.
During replacement FTOS calculates and applies only the difference between the archived file and the
running-configuration, making the process faster. Once the archived configuration is loaded, you can
confirm the replacement, or revert (roll back) to your previous configuration. Rolling back allows you to
view and test a configuration before completing the change.
Archived Files
Archived files are stored on the internal flash in a hidden directory. The maximum number of archived files
is configurable between 10 and 15. If you archive more than the configured maximum, the oldest archived
file is deleted to create space. You can view the name, size, and date of creation of a file, but you cannot
view the contents of the archived file directly (using the command show file). To view the contents of a file
you can backup the archive file to another location and then use the command show file, or view the the
differences between the archived file and another file using the show diff command.
In Figure 12-3:
2. The running configuration is replaced with archive_0, in which the hostname is “R1.”
Figure 12-3. Replacing the Running-configuration with and Archived Configuration
R1#config
R1(conf)#hostname FTOS
FTOS#configure replace archive_0
Use the keyword force to bypass the FTOS confirmation dialog, as shown in Figure 12-4.
• If you do not like the configuration, wait for the specified time to expire, as shown in Figure 12-5.
• If you like the configuration, enter the command configure confirm from EXEC Privilege mode before
the specified time, as shown in Figure 12-6.
• If you attempt to archive more configurations than the maximum allowed, the oldest archived
configuration is deleted (Figure 12-8) to create space. However, the number in the name of the
archived file is still incremented (up to 14, after which the numbering convention restarts at 0; if
present, archive_0 is overwritten).
• If you configure a maximum less than the number of archived files you already have, then archived
files are deleted to satisfy the maximum.
Figure 12-7. Configuring an Archive Maximum
R1(conf-archive)#maximum 2
R1(conf-archive)#show config
!
archive
maximum 2
R1(conf-archive)#
R1#archive config
configuration archived as archive_1
R1#show archive
Archive directory: flash:/CFGARCH_DIR
Configuring Auto-archive
You can configure the system to archive the running-configuration periodically so that you do not have to
archive manually. Configure auto-archiving using the command time-period from ARCHIVE mode. Note
that if you do not make any changes to the running-configuration for the configured length of time, then
the running-configuration is not archived, and periodic archiving pauses; it resumes when you make a
change to the running-configuration.
flash:/CFGARCH_DIR/archive_3
-------
> hostname R1
FTOS(conf)#
Protocol Overview
Dynamic Host Configuration Protocol (DHCP) is an application layer protocol that dynamically assigns IP
addresses and other configuration parameters to network end-stations (hosts) based on configuration
policies determined by network administrators. DHCP:
• relieves network administrators of manually configuring hosts, which is a can be a tedious and
error-prone process when hosts often join, leave, and change locations on the network.
• reclaims IP addresses that are no longer in use to prevent address exhaustion.
DHCP is based a client-server model. A host discovers the DHCP server and requests an IP address, and
the server either leases or permanently assigns one. There are three types of devices that are involved in
DHCP negotiation:
DHCP uses UDP as its transport protocol. The server listens on port 67 and transmits to port 68; the client
listens on port 68 and transmits to port 67. The configuration parameters are carried as options in the
DHCP packet in Type, Length, Value (TLV) format; many options are specified in RFC 2132. To limit the
number parameters that servers must provide, hosts specify the parameters that they require, and the server
sends only those; some common options are given in Table 13-1.
1. The client initially broadcasts a DHCPDISCOVER message on the subnet to discover available
DHCP servers. This message includes the parameters that the client requires and might include
suggested values for those parameters.
2. Servers unicast or broadcast a DHCPOFFER message in response to the DHCPDISCOVER that
offers to the client values for the requested parameters. Multiple servers might respond to a single
DHCPDISCOVER; the client might wait a period of time and then act on the most preferred offer.
3. The client broadcasts a DHCPREQUEST message in response to the offer, requesting the offered
values.
4. Upon receiving a DHCPREQUEST, the server binds the clients’ unique identifier (the hardware
address plus IP address) to the accepted configuration parameters and stores the data in a database
called a binding table. The server then broadcasts a DHCPACK message, which signals to the client
that it may begin using the assigned parameters.
5. When the client leaves the network, or the lease time expires, returns its IP address to the server in a
DHCPRELEASE message.
There are additional messages that are used in case the DHCP negotiation deviates from the process
previously described and shown in Figure 13-2.
• DHCPDECLINE—A client sends this message to the server in response to a DHCPACK if the
configuration parameters are unacceptable, for example, if the offered address is already in use. In this
case, the client starts the configuration process over by sending a DHCPDISCOVER.
• DHCPINFORM—A client uses this message to request configuration parameters when it assigned an
IP address manually rather than with DHCP. The server responds by unicast.
• DHCPNAK—A server sends this message to the client if it is not able to fulfill a DHCPREQUEST,
for example if the requested address is already in use. In this case, the client starts the configuration
process over by sending a DHCPDISCOVER.
Figure 13-2. Assigning Network Parameters using DHCP
• The Dell Force10 implementation of DHCP is based on RFC 2131 and RFC 3046.
• DHCP is available on VLANs and Private VLANs.
• IP Source Address Validation is a sub-feature of DHCP Snooping; FTOS uses ACLs internally to
implement this feature and as such, you cannot apply ACLs to an interface which has IP Source
Address Validation. If you configure IP Source Address Validation on a member port of a VLAN and
then attempt to apply a access list to the VLAN, FTOS displays the first line in Message 1. If you first
apply an ACL to a VLAN and then attempt enable IP Source Address Validation an one of its member
ports, FTOS displays the second line in Message 1.
• FTOS provides 40K entries that can be divided between leased addresses and excluded addresses. By
extension, the maximum number of pools you can configure depends on the on the subnet mask that
you give to each pool. FTOS displays an error message for configurations that exceed the allocated
memory.
• E-Series supports 16K DHCP Snooping entries across 500 VLANs.
• C-Series and S-Series support 4K DHCP Snooping entries.
• All platforms support DAI on 16 VLANs per system.
Configuration Tasks
• Configure the System to be a DHCP Server on page 314
• Configure the System to be a Relay Agent on page 320
• Configure Secure DHCP on page 321
1. Address Storage and Management: DHCP servers are the owners of the addresses used by DHCP
clients.The server stores the addresses and manages their use, keeping track of which addresses have
been allocated and which are still available.
Configuration Tasks
To configure DHCP, an administrator must first set up a DHCP server and provide it with configuration
parameters and policy information including IP address ranges, lease length specifications, and
configuration data that DHCP hosts need.
An address pool is a range of IP addresses that may be assigned by the DHCP server. Address pools are
indexed by subnet number.
3 Specify the range of IP addresses from which the network network /prefix-length DHCP <POOL>
DHCP server may assign addresses. Prefix-length Range: 17-31
• network is the subnet address.
• prefix-length specifies the number of bits
used for the network portion of the address
you specify.
Once an IP address is leased to a client, only that client may release the address. FTOS performs a IP +
MAC source address validation to ensure that no client can release another clients address. This is a default
behavior, and is separate from IP+MAC Source Address Validation on page 328.
The DHCP server assumes that all IP addresses in a DHCP address pool are available for assigning to
DHCP clients. You must specify the IP address that the DHCP server should not assign to clients.
Specify an address lease time for the addresses in lease {days [hours] [minutes] | infinite} DHCP <POOL>
a pool. Default: 24 hours
Specify default gateway(s) for the clients on the subnet, in default-router address DHCP <POOL>
order of preference.
In Figure 13-3, an IP phone is powered by PoE and has acquired an IP address from the Dell Force10
system, which is advertising LLDP-MED. The leased IP address is displayed using show ip dhcp binding,
and confirmed with show lldp neighbors.
DNS Server
7/1
Relay Agent
A domain is a group of networks. DHCP clients query DNS IP servers when they need to correlate host
names to IP addresses.
2 Specify in order of preference the DNS servers that are dns-server address DHCP <POOL>
available to a DHCP client.
Windows Internet Naming Service (WINS) is a name resolution service that Microsoft DHCP clients use
to correlate host names to IP addresses within a group of networks. Microsoft DHCP clients can be one of
four types of NetBIOS nodes: broadcast, peer-to-peer, mixed, or hybrid.
1 Specify the NetBIOS Windows Internet Naming netbios-name-server address DHCP <POOL>
Service (WINS) name servers, in order of preference,
that are available to Microsoft Dynamic Host
Configuration Protocol (DHCP) clients.
2 Specify the NetBIOS node type for a Microsoft netbios-node-type type DHCP <POOL>
DHCP client. Dell Force10 recommends specifying
clients as hybrid.
Enables address allocation to BOOTP clients. The ip dhcp bootp automatic DHCP
addresses are from the DHCP address pool for the
subnet.
Note: FTOS does not prevent you from using a network IP as a host IP; be sure to not use a network IP
as a host IP.
3 Specify the client hardware address or hardware-address hardware-address type DHCP <POOL>
client-identifier. client-identifier unique-identifier
• hardware-address is the client
MAC address.
type is the protocol of the hardware
platform. The default protocol is
Ethernet.
client-identifier is required for
Microsoft clients instead of a hardware
addresses. The client identifier is
formed by concatenating the media
type and the MAC address of the client.
Refer to the "Address Resolution
Protocol Parameters" section of RFC
1700—Assigned Numbers, for a list of
media type codes.
Specify the number of ping packets the DHCP server sends ip dhcp ping packets number CONFIGURATION
to the pool address before assigning the address. Default: 2
Change the amount of time the server waits for a ping reply ip dhcp ping timeout milliseconds CONFIGURATION
before considering the ping a failure. Default: 500 milliseconds
An address conflict occurs when two hosts use the same IP address. The server checks for a conflict using
ping and the client checks for conflict using gratuitous ARP. If a conflict is detected, the address is
removed from the pool. The address will not be assigned until the administrator resolves the conflict.
Clear DHCP binding entries for the entire binding clear ip dhcp binding EXEC Privilege
table.
Clear a DHCP binding entry for an individual IP clear ip dhcp binding ip address EXEC Privilege
address.
Clear DHCP server counters. clear ip dhcp server statistics EXEC Privilege
You can configure an interface on the Dell Force10 system to relay the DHCP messages to a specific
DHCP server using the command ip helper-address dhcp-address from INTERFACE mode, as shown in
Figure 13-4. Specify multiple DHCP servers by entering the ip helper-address dhcp-address command
multiple times.
When ip helper-address is configured, the system listens for DHCP broadcast messages on port 67. The
system rewrites packets received from the client and forwards it via unicast; the system rewrites the
destination IP address and writes its own address as the relay device. Responses from the server are unicast
back to the relay agent on port 68, and the relay agent rewrites the destination address and forwards the
packet to the client subnet via broadcast.
Unicast
Source IP : 10.11.1.5 Source IP : 10.11.1.5 10.11.1.5
Destination IP: 255.255.255.255 Destination IP: 10.11.0.3
Source Port: 67 Source Port: 67
Destination Port: 68 Destination Port: 68
1/4
1/3
Broadcast
Unicast
Source IP : 0.0.0.0
Source IP : 0.0.0.0
Destination IP: 255.255.255.255
Destination IP: 10.11.1.5
Source Port: 68
Source Port: 68
Destination Port: 67
Destination Port: 67
Relay Agent Address: 0.0.0.0
Relay Agent Address: 10.11.0.3
R1(conf-if-gi-1/3)#show config
!
interface GigabitEthernet 1/3
ip address 10.11.0.3/24
ip helper-address 10.11.1.5
ip helper-address 10.11.2.5 DHCP 001
no shutdown
To view the ip helper-address configuration for an interface, use the command show ip interface from
EXEC privilege mode, Figure 250.
Figure 13-5. Displaying the Helper Address Configuration
R1_E600#show ip int gig 1/3
GigabitEthernet 1/3 is up, line protocol is down
Internet address is 10.11.0.1/24
Broadcast address is 10.11.0.255
Address determined by user input
IP MTU is 1500 bytes
Helper address is 192.168.0.1
192.168.0.2
Directed broadcast forwarding is disabled
Proxy ARP is enabled
Split Horizon is enabled
Poison Reverse is disabled
ICMP redirects are not sent
ICMP unreachables are not sent
Option 82
RFC 3046 (Relay Agent Information option, or Option 82) is used for class-based IP address assignment.
The code for the Relay Agent Information option is 82, and is comprised of two sub-options, Circuit ID
and Remote ID.
The DHCP relay agent inserts Option 82 before forwarding DHCP packets to the server. The server can
use this information to:
• track the number of address requests per relay agent; restricting the number of addresses available per
relay agent can harden a server against address exhaustion attacks.
• associate client MAC addresses with a relay agent to prevent offering an IP address to a client spoofing
the same MAC address on a different relay agent.
• assign IP addresses according to the relay agent. This prevents generating DHCP offers in response to
requests from an unauthorized relay agent.
The server echoes the option back to the relay agent in its response, and the relay agent can use the
information in the option to forward a reply out the interface on which the request was received rather than
flooding it on the entire VLAN.
The relay agent strips Option 82 from DHCP responses before forwarding them to the client.
DHCP Snooping
DHCP Snooping protects networks from spoofing. In the context of DHCP Snooping, all ports are either
trusted or untrusted. By default, all ports are untrusted. Trusted ports are ports through which attackers
cannot connect. Manually configure ports connected to legitimate servers and relay agents as trusted.
The relay agent then checks all subsequent DHCP client-originated IP traffic (DHCPRELEASE,
DHCPNACK, and DHCPDECLINE) against the binding table to ensure that the MAC-IP address pair is
legitimate, and that the packet arrived on the correct port; packets that do not pass this check are forwarded
to the the server for validation. This check-point prevents an attacker from spoofing a client and declining
or releasing the real client’s address. Server-originated packets (DHCPOFFER, DHCPACK,
DHCPNACK) that arrive on an untrusted port are also dropped. This check-point prevents an attacker
from impostering as a DHCP server to facilitate a man-in-the-middle attack.
Binding table entries are deleted when a lease expires, or the relay agent encounters a DHCPRELEASE,
DHCPNACK, DHCPDECLINE.
FTOS Behavior: Introduced in FTOS version 7.8.1.0, DHCP Snooping was available for Layer 3 only
and dependent on DHCP Relay Agent (ip helper-address). FTOS version 8.2.1.0 extends DHCP
Snooping to Layer 2, and you do not have to enable relay agent to snoop on Layer 2 interfaces.
FTOS Behavior: Binding table entries are deleted when a lease expires or when the relay agent
encounters a DHCPRELEASE. Starting with FTOS Release 8.2.1.2, line cards maintain a list of
snooped VLANs. When the binding table is exhausted, DHCP packets are dropped on snooped
VLANs, while these packets are forwarded across non-snooped VLANs. Since DHCP packets are
dropped, no new IP address assignments are made. However, DHCPRELEASE and DHCPDECLINE
packets are allowed so that the DHCP snooping table can decrease in size. Once the table usage falls
below the maximum limit of 4000 entries, new IP address assignments are allowed.
FTOS Behavior: In 8.2.1 releases, ip dhcp snooping trust was required on the port-channel interface
as well as on channel members. In subsequent releases, it is no longer necessary nor permitted to
configure port-channel members as trusted; configuring the port-channel interface alone as trusted is
sufficient, and ports must have the default configuration to be a channel members. When upgrading
q
from 8.2.1 releases, the channel-member configurations are applied first, so when the port-channel is
configured, its membership configuration is rejected, since the member ports no longer have the
default configuration. In this case, you must manually remove ip dhcp snooping trust on the channel
members add the ports to the port-channel.
Note: DHCP server packets will be dropped on all untrusted interfaces of a system configured for DHCP
snooping. To prevent these packets from being dropped, configure ip dhcp snooping trust on the
server-connected port.
2 Specify ports connected to DHCP servers as trusted. ip dhcp snooping trust INTERFACE
Add a static entry in the binding table. ip dhcp snooping binding mac EXEC Privilege
Delete all of the entries in the binding clear ip dhcp snooping binding EXEC Privilege
table
Display the contents of the binding show ip dhcp snooping EXEC Privilege
table.
View the DHACP Snooping statistics with the show ip dhcp snooping command.
Starting with FTOS Release 8.2.1.1, line cards maintain a list of snooped VLANs. When the binding table
fills, DHCP packets are dropped only on snooped-VLANs, while such packets will be forwarded across
non-snooped VLANs. Since DHCP packets are dropped, no new IP address assignments are made.
However, DHCP Release and Decline packets are allowed so that the DHCP snooping table can decrease
in size. Once the table usage falls below the max limit of 4000 entries, new IP address assignments are
allowed.
View the number of entries in the table with the show ip dhcp snooping binding command. This output
displays the snooping binding table created using the ACK packets from the trusted port.
ARP is a stateless protocol that provides no authentication mechanism. Network devices accepts ARP
request and replies from any device, and ARP replies are accepted even when no request was sent. If a
client receives an ARP message for which a relevant entry already exists in its ARP cache, it overwrites the
existing entry with the new information.
The lack of authentication in ARP makes it vulnerable to spoofing. ARP spoofing is a technique attackers
use to inject false IP to MAC mappings into the ARP cache of a network device. It is used to launch
man-in-the-middle (MITM), and denial-of-service (DoS) attacks, among others.
A spoofed ARP message is one in which MAC address in the sender hardware address field and the IP
address in the sender protocol field are strategically chosen by the attacker. For example, in an MITM
attack, the attacker sends a client an ARP message containing the attacker’s MAC address and the
gateway’s IP address. The client then thinks that the attacker is the gateway, and sends all internet-bound
address and the client’s IP address. The gateway then thinks that the attacker is the client, and forwards all
packets addressed to the client to it. As a result, the attacker is able to sniff all packets to and from the
client.
• broadcast—an attacker can broadcast an ARP reply that specifies FF:FF:FF:FF:FF:FF as the gateway’s
MAC address, resulting in all clients broadcasting all internet-bound packets.
• MAC flooding—an attacker can send fraudulent ARP messages to the gateway until the ARP cache is
exhausted, after which, traffic from the gateway is broadcast.
• denial of service—an attacker can send a fraudulent ARP messages to a client to associate a false
MAC address with the gateway address, which would blackhole all internet-bound packets from the
client.
Note: DAI uses entries in the L2SysFlow CAM region, a sub-region of SystemFlow. One CAM entry is
required for every DAI-enabled VLAN, and you can enable DAI on up to 16 VLANs on a system. However,
the ExaScale default CAM profile allocates only 9 entries to the L2SysFlow region for DAI. You can
configure 10 to 16 DAI-enabled VLANs by allocating more CAM space to the L2SysFlow region before
enabling DAI.
SystemFlow has 102 entries by default. This region is comprised of two sub-regions: L2Protocol and
L2SystemFlow. L2Protocol has 87 entries, and L2SystemFlow has 15 entries. Six L2SystemFlow entries are used by
Layer 2 protocols, leaving 9 for DAI. L2Protocol can have a maximum of 100 entries, and this region must be
expanded to capacity before you can increase the size of L2SystemFlow. This is relevant when you are enabling DAI
on VLANs. If, for example, you want to enable DAI on 16 VLANs, you need 7 more entries; in this case,
reconfigure the SystemFlow region for 122 entries:
layer-2 eg-acl value fib value frrp value ing-acl value learn value l2pt value qos value system-flow 122
L2Protocol has 87 entries by default and must be expanded to its maximum capacity, 100 entries, before
L2SystemFlow can be increased; therefore 13 more L2Protocol entries are required. L2SystemFlow has 15 entries
by default, but only 9 are for DAI; to enable DAI on 16 VLANs, 7 more entries are required. 87 L2Protocol + 13
additional L2Protocol + 15 L2SystemFlow + 7 additional L2SystemFlow equals 122.
Use show arp inspection statistics command to see how many valid and invalid ARP packets have been
processed.
You can configure a port to skip ARP inspection by defining the interface as trusted, which is useful in
multi-switch environments. ARPs received on trusted ports bypass validation against the binding table. All
ports are untrusted by default.
Specify an interface as trusted so that ARPs are not arp inspection-trust INTERFACE
validated against the binding table.
FTOS Behavior: Introduced in FTOS version 8.2.1.0, Dynamic ARP Inspection (DAI) was available for
Layer 3 only. FTOS version 8.2.1.1 extends DAI to Layer 2.
• IP Source Address Validation on page 328 prevents IP spoofing by forwarding only IP packets that
have been validated against the DHCP binding table.
address matches the client hardware address field (CHADDR) in the payload.
• IP+MAC Source Address Validation on page 328 verifies that the IP source address and MAC source
address are a legitimate pair.
IP Source Address Validation (SAV) prevents IP spoofing by forwarding only IP packets that have been
validated against the DHCP binding table. A spoofed IP packet is one in which the IP source address is
strategically chosen to disguise the attacker. For example, using ARP spoofing an attacker can assume a
legitimate client’s identity and receive traffic addressed to it. Then the attacker can spoof the client’s IP
address to interact with other clients.
The DHCP binding table associates addresses assigned by the DHCP servers, with the port on which the
requesting client is attached. When IP Source Address Validation is enabled on a port, the system verifies
that the source IP address is one that is associated with the incoming port. If an attacker is impostering as a
legitimate client the source address appears on the wrong ingress port, and the system drops the packet.
Likewise, if the IP address is fake, the address will not be on the list of permissible addresses for the port,
and the packet is dropped.
DHCP MAC Source Address Validation (SAV) validates a DHCP packet’s source hardware address
against the client hardware address field (CHADDR) in the payload.
FTOS Release 8.2.1.1 ensures that the packet’s source MAC address is checked against the CHADDR
field in the DHCP header only for packets from snooped VLANs.
FTOS creates an ACL entry for each IP+MAC address pair in the binding table and applies it to the
interface.
Display the IP+MAC ACL for an show ip dhcp snooping source-address-validation EXEC Privilege
interface for for the entire system. [interface]
• ECMP for Flow-based Affinity (E-Series), including the configurable hash algorithm
• Configurable ECMP Hash Algorithm (C- and S-Series)
If flow-based affinity is to be maintained by an ExaScale and TeraScale chassis, they must both use the
same hashing algorithm and seed value, and ECMP must deterministically choose a next hop. To
reconfigure these values, see:
• Configurable Hash Algorithm (E-Series) on page 331
• Configurable Hash Algorithm Seed on page 332
• Deterministic ECMP Next Hop on page 332
Change the ExaScale hash-algorithm for LAG, ECMP, hash-algorithm ecmp checksum 0 CONFIGURATION
and NH-ECMP to match TeraScale. lag checksum 0 nh-ecmp checksum
0
FTOS Behavior: In FTOS versions prior to 8.2.1.2, the ExaScale default hash-algorithm is 0.
Beginning with version 8.2.1.2, the default hash-algorithm is 24.
For information on the load-balancing criteria used by the hash algorithm to distribute traffic among
ECMP paths and LAG members on an E-Series system, see E-Series load-balancing on page 436.
With 8 or less ECMPs, the ordering is lexicographic and deterministic. With more than 8 ECMPs, ordering
is deterministic, but it is not in lexicographic order.
Note: Packet loss might occur when you enable ip/ipv6 ecmp-deterministic for the first-time only.
FTOS provides a CLI-based solution for modifying the hash seed to ensure that on each configured
system, the ECMP selection is same. When configured, the same seed is set for ECMP, LAG, and NH, and
is used for incoming traffic only.
Note: While the seed is stored separately on each port-pipe, the same seed is used across all CAMs.
Note: You cannot separate LAG and ECMP, but you can use different algorithms across chassis with the
same seed. If LAG member ports span multiple port-pipes and line cards, set the seed to the same value
on each port-pipe to achieve deterministic behavior.
Note: If the hash algorithm configuration is removed. Hash seed will not go to original factory default
setting.
Specify the hash algorithm seed. hash-algorithm seed value [linecard number] CONFIGURATION
[port-set number]
Range: 0 - 4095
In Figure 14-1, Core Router 1 is an E-Series TeraScale and Core Router 2 is an E-Series ExaScale. They
have similar configurations and have routes for prefix P with two possible next-hops. When Deterministic
ECMP is enabled and the hash algorithm and seed are configured the same, each flow is consistently sent
to the same next hop even though they are routed through two different chassis.
Figure 14-1. Deterministic ECMP Next Hop + Configurable Hash Algorithm Seed
Backbone router
A
w
F lo
Flo
wB
Core Router 1 Core Router 2
TeraScale ExaScale
Next-hop 1 Next-hop 2
Prefix: P
To change to a different hash scheme for ECMP, use the following command in the CONFIGURATION
mode:
The different hash algorithms for ECMP are based on the number of ECMP group members and packet
values. The default hash algorithm yields the most balanced results in various test scenarios, but if the
default algorithm does not provide satisfactory distribution of traffic, then use this command to designate
another algorithm.
When a member leaves or is added to the ECMP group, the hash algorithm is recalculated to balance traffic
across the members.
Force10 Resilient Ring Protocol (FRRP) provides fast network convergence to Layer 2 switches
interconnected in a ring topology, such as a Metropolitan Area Network (MAN) or large campuses. FRRP
is similar to what can be achieved with the Spanning Tree Protocol (STP), though even with optimizations,
STP can take up to 50 seconds to converge (depending on the size of network and node of failure) may
require 4 to 5 seconds to reconverge. FRRP can converge within 150ms to 1500ms when a link in the ring
breaks (depending on network configuration).
To operate a deterministic network, a network administrator must run a protocol that converges
independently of the network size or node of failure. The Force10 Resilient Ring Protocol (FRRP) is a
proprietary protocol that provides this flexibility, while preventing Layer 2 loops. FRRP provides
sub-second ring-failure detection and convergence/re-convergence in a Layer 2 network while eliminating
the need for running spanning-tree protocol. With its two-way path to destination configuration, FRRP
provides protection against any single link/switch failure and thus provides for greater network uptime.
Protocol Overview
FRRP is built on a ring topology. Up to 255 rings can be configured on a system. FRRP uses one Master
node and multiple Transit nodes in each ring. There is no limit to the number of nodes on a ring. The
Master node is responsible for the intelligence of the Ring and monitors the status of the Ring. The Master
node checks the status of the Ring by sending Ring Health Frames (RHF) around the Ring from its Primary
port and returning on its Secondary port. If the Master node misses three consecutive RHFs, it determines
the ring to be in a failed state. The Master then sends a Topology Change RHF to the Transit Nodes
informing them that the ring has changed. This causes the Transit Nodes to flush their forwarding tables,
and re-converge to the new network structure.
One port of the Master node is designated the Primary port (P) to the ring; another port is designated as the
Secondary port (S) to the ring. In normal operation, the Master node blocks the Secondary port for all
non-control traffic belonging to this FRRP group, thereby avoiding a loop in the ring, like STP. Layer 2
switching and learning mechanisms operate per existing standards on this ring.
distinction is ignored as long as the node is configured as a Transit node. If the ring is complete, the Master
node logically blocks all data traffic in the transmit and receive directions on the Secondary port to prevent
a loop. If the Master node detects a break in the ring, it unblocks its Secondary port and allows data traffic
to be transmitted and received through it. See Figure 15-1 for a simple example of this FRRP topology.
Note that ring direction is determined by the Master node’s Primary and Secondary ports.
Primary Secondary
Forwarding Forwarding
R ing D ire
ction
Primary
Primary Forwarding
Forwarding
Secondary Secondary
Blocking Forwarding
R1 R3
MASTER TRANSIT
A Virtual LAN (VLAN) is configured on all node ports in the ring. All ring ports must be members of the
Member VLAN and the Control VLAN.
The Member VLAN is the VLAN used to transmit data as described earlier.
The Control VLAN is used to perform the health checks on the ring. The Control VLAN can always pass
through all ports in the ring, including the secondary port of the Master node.
Ring Status
The Ring Failure notification and the Ring Status checks provide two ways to ensure the ring remains up
and active in the event of a switch or port failure.
Ring Checking
At specified intervals, the Master Node sends a Ring Health Frame (RHF) through the ring. If the ring is
complete, the frame is received on its secondary port, and the Master node resets its fail-period timer and
continues normal operation.
Ring Failure
If a Transit node detects a link down on any of its ports on the FRRP ring, it immediately sends a
link-down control frame on the Control VLAN to the Master node. When the Master node receives this
control frame, the Master node moves from the Normal state to the Ring-Fault state and unblocks its
Secondary port. The Master node clears its routing table, and sends a control frame to all other ring nodes,
instructing them to clear their routing tables as well. Immediately after clearing its routing table, each node
begins learning the new topology.
Ring Restoration
The Master node continues sending Ring Health Frames out its primary port even when operating in the
Ring-Fault state. Once the ring is restored, the next status check frame is received on the Master node's
Secondary port. This will cause the Master node to transition back to the Normal state. The Master node
then logically blocks non-control frames on the Secondary port, clears its own forwarding table, and sends
a control frame to the Transit nodes, instructing them to clear their forwarding tables and re-learn the
topology.
During the time between the Transit node detecting that its link is restored and the Master node detecting
that the ring is restored, the Master node’s Secondary port is still forwarding traffic. This can create a
temporary loop in the topology. To prevent this, the Transit node places all the ring ports transiting the
newly restored port into a temporary blocked state. The Transit node remembers which port has been
temporarily blocked and places it into a pre- forwarding state. When the Transit node in the pre-forwarding
state receives the control frame instructing it to clear its routing table, it does so and unblocks the
previously blocked ring ports on the newly restored port. Then the Transit node returns to the Normal state.
A Member VLAN can span two rings interconnected by a common switch, in a figure-eight style topology.
A switch can act as a Master node for one FRRP Group and a Transit for another FRRP group, or it can be
a Transit node for both rings.
its own Control VLAN running on another ring. A Member VLAN that spans both rings is added as a
Member VLAN to both FRRP groups. Switch R3 has two instances of FRRP running on it: one for each
ring. The example topology that follows shows R3 assuming the role of a Transit node for both FRRP 101
and FRRP 202.
Primary Secondary
Forwarding Ring 101
Blocking Direction
Primary
Primary
Forwarding
Forwarding
TRANSIT
R2
TRANSIT
R3
TRANSIT
R3 Secondary Secondary
Forwarding Forwarding
Secondary
Forwarding
Primary
Forwarding
TRANSIT Primary
R7 Forwarding
Secondary
Forwarding TRANSIT
Secondary
Forwarding
R4
Primary
Forwarding
Ring 202
Direction
Primary
Forwarding
Primary
TRANSIT Forwarding
R6
FRRP 202
Secondary
Secondary MASTER
Forwarding
Blocking R5
• A single FRRP flap will occur wen a line card is reset or a stack unit fails over to the standby.
Concept Explanation
Ring ID Each ring has a unique 8-bit ring ID through which the ring is identified (e.g.
FRRP 101 and FRRP 202 as shown in Figure 15-2.
Control VLAN Each ring has a unique Control VLAN through which tagged Ring Health
Frames (RHF) are sent. Control VLANs are used only for sending Ring Health
Frames, and cannot be used for any other purpose.
Member VLAN Each ring maintains a list of member VLANs. Member VLANs must be
consistent across the entire ring.
Port Role Each node has two ports for each ring: Primary and Secondary. The Master node
Primary port generates Ring Health Frames (RHF). The Master node Secondary
port receives the RHF frames. On Transit nodes, there is no distinction between
a Primary and Secondary interface when operating in the Normal state.
Concept Explanation
Ring Interface State Each interface (port) that is part of the ring maintains one of four states
• Blocking State: Accepts ring protocol packets but blocks data packets.
LLDP, FEFD, or other Layer 2 control packets are accepted. Only the master
node Secondary port can enter this state.
• Pre-Forwarding State: A transition state before moving to the Forward
state. Control traffic is forwarded but data traffic is blocked. The Master
node Secondary port transitions through this state during ring bring-up. All
ports transition through this state when a port comes up.
• Forwarding State—Both ring control and data traffic is passed. When the
ring is in Normal operation, the Primary port on the Master node and both
Primary and Secondary ports on the Transit nodes are in forwarding state.
When the ring is broken, all ring ports are in this state.
• Disabled State—When the port is disabled or down, or is not on the VLAN.
Ring Protocol Timers Hello Interval: The interval when ring frames are generated from the Master
node’s Primary interface (default 500 ms). The Hello interval is configurable in
50 ms increments from 50 ms to 2000 ms.
Dead Interval: The interval when data traffic is blocked on a port. The default is
3 times the Hello interval rate. The dead interval is configurable in 50 ms
increments from 50 ms to 6000 ms.
Ring Status The state of the FRRP ring. During initialization/configuration, the default ring
status is Ring-down (disabled). The Primary and Secondary interfaces, Control
VLAN, and Master and Transit node information must be configured for the ring
to be up.
• Ring-Up: Ring is up and operational
• Ring-Down: Ring is broken or not set up
Ring Health-check Frame Two types of RHFs are generated by the Master node. RHFs never loop the ring
(RHF) because they terminate at the Master node’s secondary port.
• Hello RHF (HRHF): These frames are processed only on the Master node’s
Secondary port. The Transit nodes pass the HRHF through the without
processing it. An HRHF is sent at every Hello interval.
• Topology Change RHF (TCRHF): These frames contains ring status,
keepalive, and the Control and Member VLAN hash. It is processed at each
node of the ring. TCRHFs are sent out the Master Node’s Primary and
Secondary interface when the ring is declared in a Failed state with the same
sequence number, on any topology change to ensure all Transit nodes receive
it. There is no periodic transmission of TCRHFs. The TCRHFs are sent on
triggered events of ring failure or ring restoration only.
Implementing FRRP
• FRRP is media and speed independent.
• FRRP is a Dell Force10 proprietary protocol that does not interoperate with any other vendor.
• Spanning Tree must be disabled on both Primary and Secondary interfaces before FRRP is enabled.
• All ring ports must be Layer 2 ports. This is required for both Master and Transit nodes.
• A VLAN configured as control VLAN for a ring cannot be configured as a control or member VLAN
for any other ring.
FRRP Configuration
These are the tasks to configure FRRP.
Use the commands in the following sequence to create the FRRP group.
protocol frrp ring-id CONFIGURATION Create the FRRP group with this Ring ID
Ring ID: 1-255
Control and Member VLANS are configured normally for Layer 2. Their status as Control or Member is
determined at the FRRP group commands. For complete information about configuring VLANS in Layer 2
mode, see Chapter 25, Layer 2.
Use the commands in the following sequence, on the switch that will act as the Master node, to create the
Control VLAN for this FRRP group.
2 tagged interface slot/ CONFIG-INT-VLAN Tag the specified interface or range of interfaces
port {range} to this VLAN.
Interface:
• For a 10/100/1000 Ethernet interface, enter
the keyword keyword GigabitEthernet
followed by the slot/port information.
• For a Gigabit Ethernet interface, enter the
keyword GigabitEthernet followed by the
slot/port information
• For a 10 Gigabit Ethernet interface, enter the
keyword TenGigabitEthernet followed by
the slot/port information.
Slot/Port, Range: Slot and Port ID for the
interface. Range is entered Slot/Port-Port.
3 interface primary int CONFIG-FRRP Assign the Primary and Secondary ports, and the
slot/port secondary int Control VLAN for the ports on the ring.
slot/port control-vlan Interface:
vlan id • For a 10/100/1000 Ethernet interface, enter
the keyword keyword GigabitEthernet
followed by the slot/port information.
• For a Gigabit Ethernet interface, enter the
keyword GigabitEthernet followed by the
slot/port information
• For a SONET interface, enter the keyword
sonet followed by slot/port information.
• For a 10 Gigabit Ethernet interface, enter the
keyword TenGigabitEthernet followed by
the slot/port information.
Slot/Port: Slot and Port ID for the interface.
VLAN ID: The VLAN identification of the
Control VLAN.
5 member-vlan vlan-id CONFIG-FRRP Identify the Member VLANs for this FRRP
{range} group
VLAN-ID, Range: VLAN IDs for the ring’s
Member VLANS.
Control and Member VLANS are configured normally for Layer 2. Their status as Control or Member is
determined at the FRRP group commands. For complete information about configuring VLANS in Layer 2
mode, see Chapter 25, Layer 2.
Use the commands in the following sequence, on all of the Transit switches in the ring, to create the
Members VLANs for this FRRP group.
2 tagged interface slot/ CONFIG-INT-VLAN Tag the specified interface or range of interfaces
port {range} to this VLAN.
Interface:
• For a 10/100/1000 Ethernet interface, enter
the keyword keyword GigabitEthernet
followed by the slot/port information.
• For a Gigabit Ethernet interface, enter the
keyword GigabitEthernet followed by the
slot/port information
• For a SONET interface, enter the keyword
sonet followed by slot/port information.
• For a 10 Gigabit Ethernet interface, enter the
keyword TenGigabitEthernet followed by
the slot/port information.
Slot/Port, Range: Slot and Port ID for the
interface. Range is entered Slot/Port-Port.
3 interface primary int CONFIG-FRRP Assign the Primary and Secondary ports, and the
slot/port secondary int Control VLAN for the ports on the ring.
slot/port control-vlan Interface:
vlan id • For a 10/100/1000 Ethernet interface, enter
the keyword keyword GigabitEthernet
followed by the slot/port information.
• For a Gigabit Ethernet interface, enter the
keyword GigabitEthernet followed by the
slot/port information
• For a SONET interface, enter the keyword
sonet followed by slot/port information.
• For a 10 Gigabit Ethernet interface, enter the
keyword TenGigabitEthernet followed by
the slot/port information.
Slot/Port: Slot and Port ID for the interface.
VLAN ID: Identification number of the Control
VLAN
5 member-vlan vlan-id CONFIG-FRRP Identify the Member VLANs for this FRRP
{range} group
VLAN-ID, Range: VLAN IDs for the ring’s
Member VLANs.
clear frrp ring-id EXEC PRIVELEGED Clear the counters associated with this Ring ID
Ring ID: 1-255
clear frrp EXEC PRIVELEGED Clear the counters associated with all FRRP
groups
Use the following command to view the configuration for the FRRP group.
show configuration CONFIG-FRRP Show the configuration for this FRRP group
show frrp ring-id EXEC or EXEC Show the information for the identified FRRP
PRIVELEGED group.
Ring ID: 1-255
show frrp summary EXEC or EXEC Show the state of all FRRP groups.
PRIVELEGED Ring ID: 1-255
Troubleshooting FRRP
Configuration Checks
• Each Control Ring must use a unique VLAN ID.
• Only two interfaces on a switch can be Members of the same Control VLAN.
• There can be only one Master node for any FRRP Group.
• FRRP can be configured on Layer 2 interfaces only.
• Spanning Tree (if enabled globally) must be disabled on both Primary and Secondary interfaces when
FRRP is enabled.
• When the interface ceases to be a part of any FRRP process, if Spanning Tree is enabled globally,
it must be enabled explicitly for the interface.
• The maximum number of rings allowed on a chassis is 255.
Primary Secondary
Forwarding Forwarding
R ing D irec GigE 2/14 GigE 2/31
tion
Primary
Primary
Forwarding
Forwarding
GigE 3/21
GigE 1/24
Secondary Secondary
Blocking Forwarding
R1 GigE 1/34 GigE 3/14 R3
MASTER TRANSIT
Accurate and timely resolution of problems in your system or network requires gathering relevant data at
the time a condition manifests, and getting that information to administrators as soon as possible.
• a problem is serious enough that the initial reaction is to reboot the router, which might eliminate the
opportunity to gather symptomatic data.
• a data collection plan is complex or misunderstood.
• a problem is intermittent and so collection opportunities are missed.
Force10 Service Agent (FTSA) is designed automate data collection to relieve these issues. It periodically
monitors Dell Force10 or user-specified system variables. If a match condition exists, it triggers data
collection via the CLI. For example, you can configure FTSA to search for a specific value in the show
command for output throttles on an interface if CPU usage exceeds 85%. FTSA then automatically E-mails
the information in XML format to network administrators, and/or the Dell Force10 Technical Assistance
Center.
Implementation Information
It is possible to omit the admin email and smtp server-address configurations and instead log messages
locally (on the Dell Force10 system itself). The enable all command can therefore have several outcomes
depending on the configuration prior to execution:
1. When no servers are configured and no enable all is configured (the default), all policies including
log-only policies are inactive.
2. When no servers are configured and enable all is configured, log-only policies are active, and messages
are logged to the internal flash. All other (no log-only) policies are active.
3. When servers are configured and enable all is configured, log-only policies log messages to the internal
flash while policies that have no log-only log to the configured email servers.
The system displays Message 1 when you enable or disable FTSA. Figure 16-1 shows the default FTSA
configuration.
1 The administrator E-mail address is the one that admin-email email-address CALLHOME
FTSA uses to originate E-mails.
• Enter the administrator’s full E-mail address, in
the form: [email protected], or
• Enter the username without the domain name.
Dell Force10 recommends using the system name
for username your company’s domain name for
domain.
2 If you did not enter the domain name when entering domain-name domain_name CALLHOME
the administrator E-mail address, enter a domain
name in the form domain-name.com
If you specify a domain with both the admin-email
and domain-name command the domain-name
configuration supersedes.
The purpose of FTSA is to automatically send information about the switch to the network administrators
or Dell Force10 TAC, so that when there is a network problem, the relevant information is collected at the
time the problem manifests.
The E-mail body of every message always contains the message type, chassis name, transmission time,
and, when encrypted, the public encryption key.
FTSA is pre-configured to send PGP5-encrypted E-mails containing basic system inventory information to
the Dell Force10 Technical Assistance Center (TAC) at [email protected], as shown in
Figure 16-2. However messaging (for all recipients) is disabled by default.
Note: You may not remove the Dell Force10 server label or default recipient, but you may modify either.
Each recipient has a (user-configurable) mnemonic label. FTOS creates a CLI context based on this label
from which you can enable messaging and modify the E-mail parameters for the recipient. You can enter
the context for a recipient by entering the command server label from the CALLHOME context. For
example, the default label is Force10. Enter the context conf-callhome-Force10 by entering the command
server Force10, as shown in Figure 16-2.
You may enable messaging for all recipients at once, or enable messaging for each recipient individually.
in which you can configure the E-mail parameters for the recipient. For example, the default recipient is
Dell Force10 TAC and the label for this recipient is Force10. FTOS creates the context
conf-callhome-Force10 in which you can configure the parameters for E-mails destined for Dell Force10
TAC only, as shown in Figure 16-2.
Figure 16-2. Displaying the Default FTSA E-mail Recipient Configuration
FTOS(conf-callhome)#show config
!
call-home
no enable-all
server Force10
recipient [email protected]
keyadd Force10DefaultPublicKey
encrypt
no enable
FTOS(conf-callhome-Force10)#?
enable Enable call-home service for this server
encrypt Encrypt emails for this server
end Exit from configure mode
exit Exit from call-home server mode
keyadd Add server's public key for encryption
log-messages Add log information
no Reset a command
recipient Enter server email
show Show call-home server configuration
FTOS(conf-callhome-Force10)#show config
server Force10
recipient [email protected]
keyadd Force10DefaultPublicKey
encrypt
no enable
To add a recipient:
2 Enter the recipient E-mail address in the form recipient email-address CONFIGURATION
[email protected].
1 Copy the encryption key file to the copy source-path/file flash:// EXEC Privilege
internal flash. The key keyfilename
Force10DefaultPublicKey for the
default recipient is packed with FTOS,
so enable encryption for it, proceed to
Step 3.
Step Task
1 Use a PGP5-compatible program such as PGP or GnuPG to generate the public or private key. The user name that
you choose in the program will be the one that you use in the server command.
2 Export the public key to a file.
Provide the postal service mailing address at which the network contact-address CALLHOME
administrator can be contacted.
Provide the E-mail address at which the network administrator can be contact-email CALLHOME
contacted.
Provide the name of the network administrator to be contacted upon an contact-name CALLHOME
FTSA trigger event.
Provide the phone number of the network administrator to be contacted contact-phone CALLHOME
upon an FTSA trigger event.
Note: The contact fields may contain any character, however, be aware that FTSA generates all messages are
XML format, for example <contact-name> </contact-name>, so non-alphanumeric characters might create XML
errors.
When messaging is enabled, FTSA sends an E-mail every 24 hours containing inventory information to all
recipients. There is no facility for setting the frequency for individual recipients.
After the initial message, subsequent messages only include log entries with that were generated after the
last message was sent to the server so that log messages are not repeated in multiple E-mails.
All E-mails are generated in XML format by message-format {xml | text} CALLHOME ACTIONLIST
default. For Type 5 messages only, you may
generate E-mails in clear text format. The
configuration is per action list.
FTOS Behavior: FTOS versions prior to 8.2.1.0 diverted Type 5 messages to the internal flash root
directory when you enter the command log-only. Beginning in version 8.2.1.0, FTOS stores these
messages in /CALL-HOME-LOGs on the internal flash.
FTSA generates Type 1 messages when messaging is disabled. Messaging is disabled when:
<AgentInfo>
<messagetype>Type - 2</messagetype>
<time>00:25:36.893 UTC Thu Feb 19 2009</time>
<serialnum>0036232 </serialnum>
<hostname>Force10</hostname>
<messagenum>0</messagenum>
</AgentInfo>
FTSA periodically generates Type 3 messages, which contain the output of the command show inventory.
---------------------------------Message Body------------------------------------------
<AgentInfo>
<messagetype>Type - 3</messagetype>
<time>00:30:46.172 UTC Thu Feb 19 2009</time>
<serialnum>0036232 </serialnum>
<hostname>Force10</hostname>
<messagenum>0</messagenum>
</AgentInfo>
---------------------------------Message Attachment------------------------------------
Chassis Type : E300
Chassis Mode : TeraScale
Software Version : 7.8.1.0
<hardware>
E300 0036232 7520009603 D
1 LC-EF3-GE-48T 0029961 7520009704 01
0* LC-EF3-RPM FX000017082 7520025400 04
1 LC-EF3-RPM 0031177 7520013808 05
0 CC-E-SFM ** 0004903 7490007411 A
1 CC-E-SFM 0010745 7520003706 A
0 CC-E300-1200-AC CKTE31420 7520022300 A
1 CC-E300-1200-AC CKTE31303 7520022300 A
2 CC-E300-1200-AC SJ32670 7520022300 A
0 CC-E300-FAN N/A N/A N/A
* - standby
</hardware>
<software>
</software>
FTSA periodically generates Type 4 messages, only when Type 4 messaging is enabled, which contains
system log messages.
---------------------------------Message Attachment------------------------------------
Chassis Type : E300
Chassis Mode : TeraScale
Software Version : 7.8.1.0
<log_messages>
how logging severity 7 session 1 | display xml
<?xml version="1.0" encoding="UTF-8" ?>
<response MajorVersion="1" MinorVersion="0">
<action>
<syslog_properties>
<logging>enabled</logging>
<console_level>debugging</console_level>
<monitor_level>debugging</monitor_level>
<buffer_level>debugging, 36 Messages Logged, Size (40960 bytes)</buffer_level>
<trap_level>informational</trap_level>
<bufferclearedat></bufferclearedat>
</syslog_properties>
<syslog>
<time>1d0h50m</time>
<card>RPM1-P</card>
<slot>CP</slot>
<facility>CALL</facility>
<severity>HOME</severity>
<msgid>HELPER-3-CALLHOME</msgid>
<msg> Callhome service sent a message to Force10 at [email protected]
</msg>
</syslog>
</action>
</response>
FTOS#
</log_messages>
For FTSA Type 5 Messages, see FTSA Policy Sample Configurations on page 364.
FTSA Policies
FTSA policies are a list of user-defined problematic conditions for which the FTSA periodically searches.
If any of the conditions exist, FTSA executes a user-defined set of actions. FTOS allows up five active
FTSA policies and an unlimited number of inactive ones.
1. Create a policy-test-list. See Create an FTSA Policy Test List on page 358.
Action List 1 Test List 1 Action List 2 Test List 2 Action List 3 Test List 3
Create a policy test list and name it. policy-test-list name CALLHOME
Once you create a policy test list, FTOS enters the CALLHOME TESTLIST context. The list you created
is initially empty. You may choose one of three pre-defined condition lists, or create your own.
Exception CPU above 85%, crash, task crash, dump, reload due to error, RPM failover due to error
Software SWP Timeout, IPC Timeout, IRC timeout, CPU > 85%, Memory usage > 85%
Table 16-2 shows the test conditions that are available to add to a custom policy test list. See the Dell
Force10 MIB for further description of the given Object Identifiers (OID). You may only specify one test
condition within a policy.
• decrease—If the difference between samples, calculated by subtracting the first value from the last, is
or less than or equal to the specified value, then the action list is executed.
• equal-to—If the value of the probed system variable is the same as the specified value, then the action
list is executed.
• greater-than—If the value of the probed system variable is greater than the specified value, then the
action list is executed.
Match any one of the test-conditions, all test conditions, match [any | all | simultaneous] CALLHOME
or all conditions during the same sample period. TESTLIST
Default: any
While an action list is executing, pending action lists do not execute until the current action list completes.
For example, if a test list matches a condition and triggers an action list, and during the execution of the
action list another test list matches a condition, execution of the second action list is postponed until the
first action list completes.
If a policy action list is unconfigured while executing, data already gathered is stored in a local file, and
then data gathering is terminated.
Create a policy action list and name it. policy-action-list name CALLHOME
Once you create a policy action list, FTOS enters the CALLHOME ACTIONLIST context. The list you
created is initially empty. You may choose one of three pre-defined action lists and add an unlimited
number of custom actions.
Execute a show debug when seq number cli-debug “debug-command” time seconds CALLHOME ACTIONLIST
FTSA discovers a test
condition. While debug is
running, FTSA will execute
other pending action list
items.
Execute a show command seq number cli-show “show-command” repeat number CALLHOME ACTIONLIST
when FTSA discovers a test delay seconds
condition.
Reset an interface when seq number interface-reset interface delay seconds CALLHOME ACTIONLIST
FTSA discovers a test
condition.
1 Create an FTSA policy and name it. policy name CALLHOME POLICY
Associate a Dell Force10 TAC case number with the case-number number CALLHOME POLICY
policy. Configure a case number only if you already
have a case open with Dell Force10 for the policy. This
case number is included in action-list messages sent to
Dell Force10.
Delay the subsequent execution of the test list after a dampen minutes CALLHOME POLICY
match occurs. This configuration reduces the risk of
burdening the CPU with sampling when a failure
condition has already been detected.
Default: 5 minutes
Associate a Dell Force10 Problem Report (PR) number pr-number number CALLHOME POLICY
with the policy. Configure a PR number only if you
already have a case open with Dell Force10 for the
policy. This PR number is included in action-list
messages sent to Dell Force10.
Execute the action list contingent upon the state of CPU run-cpu {cpu | {cp slot | any} | CALLHOME POLICY
utilization. The CPU utilization is calculated in rpm-any} {{less-than |
percentage using the 1 minute rolling average of all greater-than} percentage
RPM CPUs.
Default: unconditional
Note: If a test-list match is found, but the action-list does not execute because the run-cpu less-than condition is
exists, then FTSA logs the test-list match and indicates that the action-list was prevented. However, if the trigger
event was a high or specified CPU usage condition in the test-list, then the FTSA ignores the run-cpu less-than
configuration.
Specify the interval at which the system variables sample-rate CALLHOME POLICY
specified in the test-list are sampled.
Default: 1 minute
Execute the test list multiple times. If the test limit is test-limit CALLHOME POLICY
greater than 1, the test list is executed immediately after
the previous execution is complete.
Default: unlimited
The following FTSA policy configuration uses the default test list hardware, which contains a
line-card-state-change condition, and the default action list hardware plus the custom action show linecard
4 | grep Status. Linecard 4 is then taken offline to trigger a match against the card-state-change test
condition.
Figure 16-10. System Log Messages during an a Linecard Down with FTSA
R6_E300(conf-callhome)#do offline linecard 4
2d9h24m: %RPM0-P:CP %CHMGR-2-CARD_DOWN: Line card 4 down - card offline
2d9h24m: %RPM0-P:CP %IFMGR-1-DEL_PORT: Removed port: Gi 4/0-47
R6_E300(conf-callhome)#2d9h24m: %RPM1-S:CP %IFMGR-1-DEL_PORT: Removed port: Gi 4/0-47
2d9h24m: %RPM0-P:CP %CALL-HOME-6-CALLHOME: Call-home executes remote exec command
2d9h24m: %RPM0-P:CP %CLI-0-REMOTE-EXEC: remote-exec CP: dhsTestCp
2d9h25m: %RPM0-P:CP %CALL-HOME-6-CALLHOME: Call-home executes remote exec command
2d9h25m: %RPM0-P:CP %CLI-0-REMOTE-EXEC: remote-exec CP: dhsTestCp
2d9h25m: %RPM0-P:CP %CALL-HOME-HELPER-3-CALLHOME: Callhome service sent a message to
Force10 at [email protected]
---------------------------------Message Body------------------------------------------
<AgentInfo>
<messagetype>Type - 5</messagetype>
<time>23:19:37.209 UTC Wed Feb 25 2009</time>
<serialnum>0036232 </serialnum>
<hostname>R6_E300</hostname>
<messagenum>0</messagenum>
</AgentInfo>
---------------------------------Message Attachment------------------------------------
<action_list_message>
<AgentInfo>
<messagetype>Type - 5</messagetype>
<time>23:19:37.230 UTC Wed Feb 25 2009</time>
<serialnum>0036232 </serialnum>
</AgentInfo>
<contact_info>
</contact_info>
<F10_info>
<policy_name>lcdown</policy_name>
</F10_info>
<action_list_name>lcdown</action_list_name>
<test_list_match>
<match>
<test_condition>hardware</test_condition>
<test_value>Line card 4 down</test_value>
</match>
</test_list_match>
<content>
<item>
<item_name>show tech-support</item_name>
<item_time>23:19:37.232 UTC Wed Feb 25 2009</item_time>
<item_output>
show tech-support
[output omitted]
</item_output>
</item>
<item>
<item_name>show trace</item_name>
<item_time>23:19:45.425 UTC Wed Feb 25 2009</item_time>
<item_output>
show trace
[output omitted]
</item_output>
</item>
<item>
<item_name>show trace hardware</item_name>
<item_time>23:19:45.988 UTC Wed Feb 25 2009</item_time>
<item_output>
show trace hardware
[output omitted]
</item_output>
</item>
<item>
<item_name>remote-exec cp dhsTestCp</item_name>
<item_time>23:19:54.597 UTC Wed Feb 25 2009</item_time>
<item_output>
remote-exec cp dhsTestCp
[output omitted]
</item_output>
</item>
<item>
<item_name>remote-exec cp dhsTestCp</item_name>
<item_time>23:20:00.663 UTC Wed Feb 25 2009</item_time>
<item_output>
remote-exec cp dhsTestCp
[output omitted]
</item_output>
</item>
<item>
<item_name>show linecard 4 | grep Status</item_name>
<item_time>23:20:07.755 UTC Wed Feb 25 2009</item_time>
<item_output>
show linecard 4 | grep Status
Status : offline
Power Status : AC
R6_E300#
</item_output>
</item>
</content>
</action_list_message>
<contact_info>
</contact_info>
<F10_info>
<policy_name>bgpdown</policy_name>
</F10_info>
<action_list_name>bgpdown</action_list_name>
<test_list_match>
<match>
<test_condition>show logging 10</test_condition>
<test_value>Search string "BGP-5-ADJCHANGE: Connection with neighbor 172.16.2.1
closed." is matched</test_value>
</match>
</test_list_match>
<content>
<item>
<item_name>show ip bgp summary | grep 172.16.2.1</item_name>
<item_time>17:14:28.417 UTC Thu Feb 26 2009</item_time>
<item_output>
show ip bgp summary | grep 172.16.2.1
172.16.2.1 200 29 39 0 0 0 00:02:40 (shut)
R6_E300#
</item_output>
</item>
</content>
</action_list_message>
The following FTSA policy configuration uses the interface-crc match condition to monitor
GigabitEthernet 1/2 for greater than 500 CRC errors. When this condition exists, FTSA triggers the action
list, which captures a partial output of the command show interfaces gigabitethernet 1/2.
call-home
admin-email [email protected]
smtp server-address 192.168.1.1
no enable-all
server Force10
recipient [email protected]
keyadd Force10DefaultPublicKey
no encrypt
enable
no log-messages
policy crcerror
action-list crcerror
test-list crcerror
policy-test-list crcerror
test-condition interface-crc 1 greater-than number 500
policy-action-list crcerror
no log-only
message-format text
cli-show "show int gig 1/2 | grep CRC" repeat 1 delay 1
<F10_info>
<policy_name>crcerror</policy_name>
</F10_info>
<action_list_name>crcerror</action_list_name>
<test_list_match>
<match>
<test_condition>interface-crc</test_condition>
<test_value>The current value 501 is greater than the configured value 500</
test_value>
</match>
</test_list_match>
<content>
<item>
<item_name>show int gig 1/2 | grep CRC</item_name>
<item_time>19:01:07.368 UTC Tue Mar 10 2009</item_time>
<item_output>
show int gig 1/2 | grep CRC
501 CRC, 0 overrun, 501 discarded
R6_E300#
</item_output>
</item>
</content>
</action_list_message>
Debugging FTSA
Display FTSA messages using the debug call-home command from EXEC Privilege mode.
Protocol Overview
Typical VLAN implementation involves manually configuring each Layer 2 switch that participates in a
given VLAN. GARP VLAN Registration Protocol (GVRP), defined by the IEEE 802.1q specification, is a
Layer 2 network protocol that provides for automatic VLAN configuration of switches. GVRP-compliant
switches use GARP to register and de-register attribute values, such as VLAN IDs, with each other.
GVRP exchanges network VLAN information to allow switches to dynamically forward frames for one or
more VLANs. Consequently, GVRP spreads this information and configures the needed VLAN(s) on any
additional switches in the network. Data propagates via the exchange of GVRP protocol data units (PDUs).
The purpose of GVRP is to simplify (but not eliminate) static configuration. The idea is to configure
switches at the edge and have the information dynamically propagate into the core. As such, the edge ports
must still be statically configured with VLAN membership information, and they do not run GVRP. It is
this information that is propagated to create dynamic VLAN membership in the core of the network.
.........
FTOS(conf)#protocol spanning-tree mstp
FTOS(conf-mstp)#no disable
% Error: GVRP running. Cannot enable MSTP.
.........
FTOS(conf)#protocol gvrp
FTOS(conf-gvrp)#no disable
% Error: PVST running. Cannot enable GVRP.
% Error: MSTP running. Cannot enable GVRP.
Configuring GVRP
Globally, enable GVRP on each switch to facilitate GVRP communications. Then, GVRP configuration is
per interface on a switch-by-switch basis. Enable GVRP on each port that connects to a switch where you
want GVRP information exchanged. In Figure 17-2, that kind of port is referred to as a VLAN trunk port,
but it is not necessary to specifically identify to FTOS that the port is a trunk port, as described in
Chapter 18, VLAN Stacking, on page 367.
Core Switches
VLANs 70-80
VLANs 30-50
NOTES:
VLAN 1 mode is always fixed and cannot be configured
All VLAN trunk ports must be configured for GVRP
All VLAN trunk ports must be configured as 802.1Q
FTOS(conf)#protocol gvrp
FTOS(config-gvrp)#no disable
FTOS(config-gvrp)#show config
!
protocol gvrp
no disable
FTOS(config-gvrp)#
Verification:
To support all the features within the HA collection, you should have the latest boot code. The following
table lists the boot code requirements as of this FTOS release.
Dell Force10 systems eliminates single points of failure by providing dedicated or load-balanced
redundancy for each component.
RPM Redundancy
The current version of FTOS supports 1+1 hitless Route Processor Module (RPM) redundancy. The
primary RPM performs all routing, switching, and control operations while the standby RPM monitors the
primary RPM. In the event that the primary RPM fails, the standby RPM can assume control of the system
without requiring a chassis reboot.
You can boot the chassis with one RPM and later add a second RPM, which automatically becomes the
standby RPM. FTOS displays Message 1 when the standby RPM is online.
On the C-Series, since the RPM also contains the switch fabric, even though the second RPM comes online
as the standby, the switch fabric is active and participates in routing. You can achieve line rate on all line
cards with a single RPM except for the 8-port 10G line card which requires both RPMs to achieve line rate.
When you boot the system with two RPMs installed, the RPM in slot R0 is the primary RPM by default.
Both RPMs should be running the same version of FTOS. You can configure either RPM to be the primary
upon the next chassis reboot using the command redundancy primary from CONFIGURATION mode.
In general, the two RPMs should have the same FTOS version. However, FTOS tolerates some degree of
difference between the two versions, as described in Table 18-1. View the configuration loaded on each
RPM using the show redundancy command as shown in Figure 18-1.
Table 18-1. System Behavior with RPMs with Mismatched FTOS Versions
************************************************
*
* Warning !!! Warning !!! Warning !!!
*
* ----------------------------------------------
*
* Incompatible SW Version detected !!
*
* This RPM -> 7.4.2.0
* Peer RPM -> 7.4.1.0
*
************************************************
00:00:12: %RPM0-U:CP %IRC-4-IRC_VERSION: Current RPM 7.4.2.0 Peer RPM 7.4.1.0 - Different
software version detected
00:00:12: %RPM0-U:CP %IRC-6-IRC_COMMUP: Link to peer RPM is up
00:00:14: %RPM0-U:CP %RAM-6-ELECTION_ROLE: RPM0 is transitioning to Primary RPM.
FTOS(standby)(bootfail)#
RPM failover is the process of the standby RPM becoming the primary RPM. FTOS fails over to the
standby RPM when:
Use the command show redundancy from EXEC Privilege mode to display the reason for the last failover.
-- RPM Status --
------------------------------------------------
RPM Slot ID: 0
RPM Redundancy Role: Primary
RPM State: Active
RPM SW Version: 7.6.1.0
Link to Peer: Up
Note: A system may not start correctly if it boots from a corrupted FTOS image or an incorrect boot
location. To troubleshoot a failed start, you can interrupt the boot process and configure a different boot
location with the boot change or boot system commands. For more information, see Recovering from a
Failed Start on page 77.
E-Series RPMs have three CPUs: Control Processor (CP), Routing Processor 1 (RP1), and Routing
Processor 2 (RP2). The CPUs use Fast Ethernet connections to communicate to each other and to the line
card CPUs (LP) using Inter-Processor Communication (IPC). The CP monitors the health status of the
other processors by sending a heartbeat message. If any CPU fails to acknowledge a consecutive number
of heartbeat messages, or the CP itself fails to send heartbeat messages (IPC timeout), the primary RPM
requests a failover to the standby RPM, and FTOS displays a message similar to Message 4.
C-Series RPMs have one CPU: Control Processor (CP). The CP on the RPM communicates with the LP
via IPC. Like the E-Series, the CP monitors the health status of the other processors by sending a heartbeat
message. If any CPU fails to acknowledge a consecutive number of heartbeat messages, or the CP itself
fails to send heartbeat messages (IPC timeout), the primary RPM requests a failover to the standby RPM,
and FTOS displays a message similar to Message 4.
In addition to IPC, the CP on the each RPM sends heartbeat messages to the CP on its peer RPM via a
process called Inter-RPM Communication (IRC). If the primary RPM fails to acknowledge a consecutive
number of heartbeat messages (IRC timeout), the standby RPM responds by assuming the role of primary
RPM, and FTOS displays message similar to message Message 5.
IPC or IRC timeouts can occur because heartbeat messages and acknowledgements are lost or arrive out of
sequence, or a software or hardware failure occurs that impacts IPC or IRC. Table 18-2 describes the
failover behavior for the possible failure scenarios.
ce Forced failover via the CLI CP on primary RPM notifies standby RPM and the standby RPM
initiates a failover. FTOS collects no system information. The former
primary RPM immediately reboots after failover.
ce Primary RPM is removed The standby RPM detects the removal and initiates a failover. FTOS
collects no system information.
After a failover, the new primary RPM prompts you for a username and password if authentication
methods was configured and that data was synchronized. The standby RPM does not use authentication
methods involving client/server protocols, such as RADIUS and TACACS+.
FTOS logs information about IPC timeouts in a log file that you can access. See:
• Chapter 60, C-Series Debugging and Diagnostics, C-Series Debugging and Diagnostics on page 1167
• Chapter 61, E-Series TeraScale Debugging and Diagnostics, Inter-CPU timeouts on page 1206
FTOS supports increasing levels of RPM redundancy (warm and hot) as described in Table 18-3.
Warm Failover The new primary RPM remains online, while the failed RPM, all line cards, and all
SFMs reboot.
ce
Hot Failover Only the failed RPM reboots.
All line cards and SFMs remain online.
ce
All application tasks are spawned on the secondary RPM before failover.
The running configuration is synchronized at runtime so it does not need to be reapplied
s
during failover.
Data between the two RPMs is synchronized immediately after bootup. Once the two RPMs have done an
initial full synchronization (block sync), thereafter FTOS only updates changed data (incremental sync).
The data that is synchronized consists of configuration data, operational data, state and status, and statistics
depending on the FTOS version.
Warm Failover some NVRAM information, startup-configuration, line card configurations, user-access
configurations
ec
s
Hot Failover some NVRAM information, startup-config, line card configurations, user-access
configurations, running-config, SFM and datapath states, run-time event log and
ec
configuration, interface state
s
RPM redundancy configuration tasks
The RPM in slot 0 is the primary RPM by default. Manually select the primary RPM using the command
redundancy primary from CONFIGURATION mode. View which RPM is the primary using the command
show running-config redundancy from EXEC Privilege mode, as shown in Figure 18-2.
Trigger an RPM failover between RPMs using the command redundancy force-failover rpm from EXEC
Privilege mode. Use this feature when:
When a non-recoverable fatal error is detected, an automatic failover occurs. However, FTOS is
configured to auto-failover only three times within any 60 minute period. You may specify a different
auto-failover count and period using the command redundancy auto-failover-limit.
To re-enable the auto-failover-limit with its default parameters, in CONFIGURATION mode, use the
redundancy auto-failover-limit command without parameters.
Disable Auto-reboot
Prevent a failed RPM from rebooting after a failover using the command redundancy disable-auto-reboot
from CONFIGURATION mode.
Manually synchronize RPMs at any time using the command redundancy synchronize full from EXEC
Privilege mode.
On the C-Series, when a secondary RPM with a logical SFM is inserted or removed, the system must add
or remove the backplane links to the switch fabric trunk. Any time such links are changed, traffic is
disrupted. Use the command redundancy sfm standby to avoid any traffic disruption when the secondary
RPM is inserted. When this command is executed, the logical SFM on the standby RPM is immediately
taken offline, and the SFM state set as standby. Use the command show sfm all to see SFM status
information.
-- Line cards --
Slot Status NxtBoot ReqTyp CurTyp Version Ports
---------------------------------------------------------------------------
0 not present
[output omitted]
-- Line cards --
Slot Status NxtBoot ReqTyp CurTyp Version Ports
---------------------------------------------------------------------------
0 online online E48VB E48VB 7-5-1-71 48
[output omitted]
FTOS(conf)#%RPM0-P:CP %CHMGR-2-CARD_DOWN: Line card 0 down - card removed
FTOS(conf)#do show linecard all
-- Line cards --
Slot Status NxtBoot ReqTyp CurTyp Version Ports
---------------------------------------------------------------------------
0 not present E48VB
[output omitted]
You may also pre-configure an empty line card slot with a logical line card using the command linecard
from CONFIGURATION mode. After creating the logical line card, you can configure the interfaces on
the line card as if it is present, as shown in Figure 18-6.
-- Line card 0 --
Status : not present
-- Line card 0 --
Status : not present
Required Type : E48VB - 48-port GE 10/100/1000Base-T line card with RJ45 interfaces and PoE
(CB)
If you are replacing a line card with a line card of the same type, you may replace the card without any
additional configuration.
If you are replacing a line card with a line card of a different type, remove the card and then remove the
existing line card configuration using the command no linecard. If you do not, FTOS reports a card
mismatch (Message 6) when you insert the new card, and the installed line card has a card mismatch status.
To clear this line card mismatch status and bring the line card online, specify the type of line card you
inserted using the command linecard, as shown in Figure 18-7.
%RPM0-P:CP %CHMGR-3-CARD_MISMATCH: Mismatch: line card 0 is type E48VB - type E48TB required
-- Line cards --
Slot Status NxtBoot ReqTyp CurTyp Version Ports
---------------------------------------------------------------------------
0 type mismatch online E48TB E48VB 7-5-1-71 48
[output omitted]
FTOS(conf)#linecard 0 E48VB
Aug 6 14:25:22: %RPM0-P:CP %IFMGR-1-DEL_PORT: Removed port: Gi 0/0-47
FTOS(conf)#Aug 6 14:25:24: %RPM0-P:CP %CHMGR-5-LINECARDUP: Line card 0 is up
-- Line cards --
Slot Status NxtBoot ReqTyp CurTyp Version Ports
---------------------------------------------------------------------------
0 online online E48VB E48VB 7-5-1-71 48
[output omitted]
Hitless Behavior
Hitless Behavior is supported only on platform: ce
Hitless behavior is supported on E-Series ExaScale ex with FTOS 8.2.1.0. and later.
Hitless is a protocol-based system behavior that makes an RPM failover on the local system transparent to
remote systems. The system synchronizes protocol information on the standby and primary RPMs such
that, the event of an RPM failover, there is no need to notify remote systems of a local state change.
• On the E-Series: Failovers triggered by software exception, hardware exception, forced failover via the
CLI, and manual removal of the primary RPM are all hitless.
• On the C-Series: Only failovers via the CLI are hitless. The system is not hitless in any other scenario.
Hitless protocols are compatible with other hitless and graceful restart protocols. For example, if hitless
OSPF is configured over hitless LACP LAGs, both features work seamlessly to deliver a hitless
OSPF-LACP result. However, if hitless behavior involves multiple protocols, all must be hitless in order to
achieve a hitless end result. For example, if OSPF is hitless but BFD is not, OSPF operates hitlessly and
BFD flaps upon an RPM failover.
• Link Aggregation Control Protocol. See Configure LACP as Hitless on page 549.
• Spanning Tree Protocol. See Configuring Spanning Trees as Hitless on page 1064.
• On the E-Series only, Bi-directional Forwarding Detection (line card ports). See Bidirectional
Forwarding Detection on page 169.
Graceful Restart
Graceful Restart is supported on platform: ecs
Graceful restart (also called non-stop forwarding) is a protocol-based mechanism that preserves the
forwarding table of the restarting router and its neighbors for a specified period to minimize the loss of
packets. A graceful-restart router does not immediately assume that a neighbor is permanently down and
so does not trigger a topology change. On E-Series, when you configure graceful restart, the system drops
no packets during an RPM failover for protocol-relevant destinations in the forwarding table, and is
therefore called “hitless”. On the C-Series and S-Series, packet loss is non-zero, but trivial, and so is still
called hitless.
Software Resiliency
During normal operations FTOS monitors the health of both hardware and software components in the
background to identify potential failures, even before these failures manifest.
There are some differences between the TeraScale and ExaScale line card and RPM testing:
• The TeraScale card test contains a loopback from the RPM to the SFM and a loopback from the line
cards to the SFM.
• The ExaScale card test contains a loopback from the RPM to the SFM and a loopback from the line
cards to the on-board TSF3.
• For TeraScale, each line card and RPM periodically sends out test frames that loop back through the
SFM. The loopback health check determines the overall status of the backplane and can identifies a
faulty SFM. If three consecutive RPM loopbacks fail, then the software initiates a fault isolation
procedure that sequentially disables one SFM at a time and performs the same loopback test.
• For ExaScale, the RPM alone RPM periodically sends out test frames that loop back through the SFM.
The loopback health check determines the overall status of the backplane and can identifies a faulty
SFM. If three consecutive RPM loopbacks fail, then the software initiates a fault isolation procedure
that sequentially disables one SFM at a time and performs the same loopback test.
Refer to the Chapter 61, E-Series TeraScale Debugging and Diagnostics for details on the different system
checks performed.
For more information on the PCDFO test, see Chapter 61, E-Series TeraScale Debugging and Diagnostics,
Respond to PCDFO events on page 1205.
Note: The BTM applies to E-Series TeraScale, and the FPTM applies to the E-Series ExaScale.
On each of the line cards and the RPM, there are a number of software components. FTOS performs a
periodic health check on each of these components by querying the status of a flag, which the
corresponding component resets within a specified time.
If any health checks on the RPM fail, then the FTOS fails over to standby RPM. If any health checks on a
line card fails, FTOS resets the card to bring it back to the correct state.
Trace Log
Developers interlace messages with software code to track a the execution of a program. These messages
are called trace messages; they are primarily used for debugging and provide lower level information than
event messages, which are primarily used by system administrators. FTOS retains executed trace messages
for hardware and software and stores them in files (logs) on the internal flash.
• NV Trace Log—contains line card bootup trace messages that FTOS never overwrites, and is stored in
internal flash under the directory NVTRACE_LOG_DIR.
• Trace Log—contains trace messages related to software and hardware events, state, and errors. Trace
Logs are stored in internal flash under the directory TRACE_LOG_DIR.
• Crash Log—contains trace messages related to IPC and IRC timeouts and task crashes on line cards,
and is stored under the directory CRASH_LOG_DIR.
Core Dumps
A core dump is the contents of RAM being used by a program at the time of a software exception and is
used to identify the cause of the exception. There are two types of core dumps, application and kernel.
System Log
Event messages provide system administrators diagnostics and auditing information. FTOS sends event
messages to the internal buffer, all terminal lines, the console, and optionally to a syslog server. For more
information on event messages and configurable options, see Chapter 4, System Management.
Hot-lock Behavior
FTOS Hot-lock features allow you to append and delete their corresponding CAM entries dynamically
without disrupting traffic. Existing entries are simply are shuffled to accommodate new entries.
• Hot-lock IP ACLs (supported on E-Series, C-Series, and S-Series) allow you to append rules to and
delete rules from an Access Control List that is already written to CAM. This behavior is enabled by
default and is available for both standard and extended ACLs on ingress and egress. For information
on configuring ACLs, see Chapter 8, “IP Access Control Lists (ACL), Prefix Lists, and Route-maps,”
on page 133.
• Hot-lock PBR (supported on E-Series only) allows you to append rules to and delete rules from a
redirect list that is already written to CAM without disrupting traffic. This behavior is enabled by
default. For information on configuring Policy-based Routing, see Chapter 37, “Policy-based
Routing,” on page 801.
Warm Upgrade
Warm Upgrade is supported on platform e
Warm software upgrades use warm failover, which means that FTOS reboots the secondary RPM and all
line cards and SFMs. The chassis remains online during the upgrade, but forwarding is interrupted, as
shown in Table 18-4.
• between consecutive feature releases where only the second digit differs between the running FTOS
version number and the upgrade version number. For example, and upgrade from FTOS version
7.6.1.0 to 7.7.1.0 is warm.
• between two consecutive maintenance releases of the same feature release. For example, upgrading
from 7.7.1.0 to 7.7.1.1 is warm.
Table 18-4. Control Plane and Data Plane Status during Warm Upgrade
FTOS Behavior: On E-Series ExaScale, the SFM auto upgrade feature is not supported with
cacheboot. If you attempt an SFM auto upgrade, you must reload the chassis to recover.
The Dell Force10 system has the ability to boot the chassis using a cached FTOS image. FTOS stores the
system image on the bootflash for each processor so that:
• the processors do not have to download the images during bootup, and
• the processors can boot in parallel rather than serially.
Booting the system by this method significantly reduces the time to bring the system online. Using Cache
Boot with Warm Upgrade significantly reduces downtime during an upgrade to bring the system online
during routine reloads.
Cache Boot can be configured during runtime. Dell Force10 recommends, however, that it be configured it
when the system is offline.
The bootflash is partitioned so that two separate images can be cached, one for each RPM.
The system must meet two requirements before you can use the cache boot feature:
1. On the E-Series, the cache boot feature requires RPM hardware revision 2.1 or later. Use the show rpm
command (Figure 18-8) to determine the version of your RPM. There is no hardware requirement for
C-Series.
FTOS#show rpm
-- RPM card 0 --
Status : active
Next Boot : online
Card Type : RPM - Route Processor Module (LC-EF3-RPM)
Hardware Rev : 2.2i Hardware Revision 2.1 or later
Num Ports : 1
Up Time : 1 day, 4 hr, 25 min
Last Restart : reset by user
FTOS Version : 4.7.5.427
Jumbo Capable : yes
CP Boot Flash : A: 2.4.1.1 [booted] B: 2.4.1.1 Specified boot code version
RP1 Boot Flash: A: 2.4.1.1 B: 2.4.1.1 [booted]
RP2 Boot Flash: A: 2.4.1.1 B: 2.4.1.1 [booted]
CP Mem Size : 536870912 bytes
RP1 Mem Size : 1073741824 bytes
RP2 Mem Size : 1073741824 bytes
MMC Mem Size : 520962048 bytes
External MMC : n/a
Temperature : 32C
Power Status : AC
Voltage : ok
Serial Number : FX000017082
--More--
2. The cache boot feature requires at least the boot code versions in Table 18-5. Use show rpm and show
linecard commands to verify that you have the proper version (Figure 18-8).
If you do not have the proper boot code version, the system displays a message similar to Message 7 when
you attempt to select a cache boot image (see Select the Cache Boot Image). See Upgrading the Boot Code
in the Release Notes for instructions on upgrading boot code.
Select the FTOS image that you want to cache using the command upgrade system-image, as shown in
Figure 18-9. Dell Force10 recommends using the keyword all with this command to avoid any
mis-matched configurations.
Note: The cache boot feature is not enabled by default; you must copy the running configuration to the
startup configuration (copy running-config startup-config) after selecting a cache boot image in order to
enable it.
Type A B
---------------------------------------------------------
CP invalid invalid
RP1 invalid[b][n] invalid
RP2 invalid invalid
linecard 0 invalid invalid
linecard 1 is not present.
linecard 2 is not present.
linecard 3 is not present.
linecard 4 invalid 6.5.1.8
linecard 5 is not present.
cache boot upgrade in progress. Please do NOT power off the card.
Note: Updating Flash Table of Contents...
Erasing TOC area...
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!
Upgrade result :
================
View your cache boot configuration using the command show boot system all, as shown in Figure 18-10.
If you attempt to cache a system image that does not support the cache boot feature, Message 8 appears.
Verify that the system is configured to boot with the selected cache boot image using the command show
bootvar as shown in Figure 18-11.
There is no need to reload or reboot the system when the patch is inserted. The In-Service Modular patch
replaces the existing process code. Once installation is complete, the system executes the patch code as
though it was always there.
Add the patch with the patch flash://RUNTIME_PATCH_DIR/<patchname> command. Remove a patch and
revert to the original code with the no patch flash://RUNTIME_PATCH_DIR/<patchname> command.
The patch name includes the FTOS version, the platform, the CPU, and the process it affects
(FTOS-platform-cpu-process-patchversion.rtp). For example, a patch labeled 7.8.1.0-EH-rp2-l2mgr-1.rtp
identifies that this patch applies to FTOS version 7.8.1.0, on the E-Series platform, for RP2, addressing the
layer 2 management process, and this is the first version of this patch.
1 If not already done, copy the patch to the copy file-origin rpm {0|1} flash:// EXEC Privilege
Runtime Patch directory RUNTIME_PATCH_DIR
Process Restartability
Process Restartability is supported on platforms: ces
Process Restartability is an extension to the FTOS High Availability system component that enables
application processes and system protocol tasks to be restarted. This extension increases system reliability
and uptime by first attempting to restart the crashed process on the primary RPM and then executing the
failover procedure only as a last resort.
• In a single-RPM system, the system generates a core dump and reboots. Reloads require the system to
read and apply the entire startup-configuration file, which might take long if the startup-configuration
is large. Restarting a process saves time because only a portion of the configuration related to the
crashed process is read and re-applied.
• In a dual-RPM system, the system generates a core dump and fails over to the standby RPM.
Restarting a process precludes launching the failover process. Recovery is attempted first locally on
the primary RPM, which involves less CPU overhead, increasing system availability for other
activities.
For both a single and dual-RPM system, when Process Restartability is enabled and a software exception
occurs, FTOS: executes a core dump, frees system resources, restarts the failed process, and then updates
the restart counter. By default, a process can be restarted a maximum of 3 times within 1 hour. If this limit
is exceeded, the FTOS reloads the system reloads or fails over to the secondary RPM.
failover, but by default, every process causes a system reload or RPM failover.
Enable Process Restartability for a process restartable [process] [count number] [period CONFIGURATION
process or task. hours]
Display the processes and tasks show process restartable [history] EXEC Privilege
configured for restartability.
FTOS#sho processes restartable
--------------------------------------------------------------------------------------------------
Process name State How many times restarted Timestamp last restarted
--------------------------------------------------------------------------------------------------
radius enabled 0 [-]
tacplus enabled 0 [-]
--------------------------------------------------------------------------------------------------
FTOS#show processes restartable history
--------------------------------------------------------------------------------------------------
Process name Timestamp last crashed
--------------------------------------------------------------------------------------------------
radius [5/23/2001 10:11:47]
--------------------------------------------------------------------------------------------------
You can specify the timestamp in hours so that if the number of restart attempts exceeds the configured
limit within this time frame, no further process restarts are attempted. The next time a software exception
occurs within this process, the system reloads for a single-RPM system and fails over to the standby RPM
for a dual-RPM system.
When a system exceeds the configured restart threshold, FTOS displays Message 10.
[for Dual RPM:] May 8 06:35:33: %RPM0-P:CP %TME-2-No More Restarts and do failover: process
tacplus reaches max restart with threshold 3
[for Single RPM:] Mar 1 10:21:47: %RPM0-P:CP %TME-2-No More Restarts: process tacplus reaches
max restart with threshold 3
402
|
High Availability
19
Internet Group Management Protocol
Table 19-1. FTOS Support for IGMP and IGMP Snooping
Feature Platform
IGMP version 1, 2, and 3 ces
IGMP Snooping version 1, 2, and 3 ces
Note: When both E-Series TeraScale and ExaScale are supported, only the e symbol is shown. If a
feature is supported by one or the other chassis, the specific symbols are shown: e t for E-Series
TeraScale or ex for E-Series ExaScale.
Multicast is premised on identifying many hosts by a single destination IP address; hosts represented by
the same IP address are a multicast group. Internet Group Management Protocol (IGMP) is a Layer 3
multicast protocol that hosts use to join or leave a multicast group. Multicast routing protocols (such as
PIM) use the information in IGMP messages to discover which groups are active and to populate the
multicast routing table.
IGMP version 2 improves upon version 1 by specifying IGMP Leave messages, which allows hosts to
notify routers that they no longer care about traffic for a particular group. Leave messages reduce the
amount of time that the router takes to stop forwarding traffic for a group to a subnet (leave latency) after
the last host leaves the group. In version 1 hosts quietly leave groups, and the router waits for a query
response timer several times the value of the query interval to expire before it stops forwarding traffic.
To receive multicast traffic from a particular source, a host must join the multicast group to which the
source is sending traffic. A host that is a member of a group is called a receiver. A host may join many
groups, and may join or leave any group at any time. A host joins and leaves a multicast group by sending
an IGMP message to its IGMP Querier. The querier is the router that surveys a subnet for multicast
receivers, and processes survey responses to populate the multicast routing table.
Version IHL TOS Total Length Flags Frag Offset TTL Protocol Header Src IP Addr Dest IP Addr Options Padding IGMP Packet
(4) (0xc0) (1) (2) Checksum (Router Alert)
8 bits 16 bits
Code: 0x11: Membership Query May be zero and ignored by hosts for
0x12: IGMP version 1 Membership Report general queries or contain a group
0x16: IGMP version 2 Membership Report address for group-specific queries
0x17: IGMP Leave Group
fnC0069mp
There are two ways that a host may join a multicast group: it may respond to a general query from its
querier, or it may send an unsolicited report to its querier.
A host does not have to wait for a general query to join a group. It may send an unsolicited IGMP
Membership Report, also called an IGMP Join message, to the querier.
IGMP version 3
Conceptually, IGMP version 3 behaves the same as version 2. There are differences:
• Version 3 adds the ability to filter by multicast source, which helps multicast routing protocols avoid
forwarding traffic to subnets where there are no interested receivers.
• To enable filtering, routers must keep track of more state information, that is, the list of sources that
must be filtered. An additional query type, the Group-and-Source-Specific Query, keeps track of state
changes, while the Group-Specific and General queries still refresh existing state.
• Reporting is more efficient and robust: hosts do not suppress query responses (non-suppression helps
track state and enables the immediate-leave and IGMP Snooping features), state-change reports are
retransmitted to insure delivery, and a single membership report bundles multiple statements from a
single host, rather than sending an individual packet for each statement.
The version 3 packet structure is different from version 2 to accommodate these protocol enhancements.
Queries (Figure 19-2) are still sent to the all-systems address 224.0.0.1, but reports (Figure 19-3) are sent
to the all IGMP version 3-capable multicast routers address 244.0.0.22.
Bit flag that when set to Query Interval derived Source addresses to be
Maximum Response Time
1 suppresses router query from this value filtered
derived from this value
response timer updates
Version IHL TOS Total Length Flags Frag Offset TTL Protocol Header Src IP Addr Dest IP Addr Options Padding IGMP Packet
(4) (0xc0) (1) (2) Checksum (224.0.0.22) (Router Alert)
Type Reserved Checksum Reserved Number of Group Group Record 1 Group Record 2 Group Record N
Records
Record Type Auxiliary Data Number of Multicast Address Source Auxiliary Data
Length Sources Addresses
0x12: IGMP version 1 Membership Report (0)
0x16: IGMP version 2 Membership Report
0x17: IGMP Leave Group
0x22: IGMP version 3 Membership Report
Length of Auxiliary Group address to which None defined in RFC 3376
Data field the group record pertains
Figure 19-4 shows how multicast routers maintain the group and source information from unsolicited
reports.
1. The first unsolicited report from the host indicates that it wants to receive traffic for group 224.1.1.1.
2. The host’s second report indicates that it is only interested in traffic from group 224.1.1.1, source
10.11.1.1. Include messages prevent traffic from all other sources in the group from reaching the
subnet, so before recording this request, the querier sends a group-and-source query to verify that there
are no hosts interested in any other sources. The multicast router must satisfy all hosts if they have
conflicting requests. For example, if another host on the subnet is interested in traffic from 10.11.1.3,
then the router cannot record the include request. There are no other interested hosts, so the request is
recorded. At this point, the multicast routing protocol prunes the tree to all but the specified sources.
3. The host’s third message indicates that it is only interested in traffic from sources 10.11.1.1 and
10.11.1.2. Since this request again prevents all other sources from reaching the subnet, the router sends
another group-and-source query so that it can satisfy all other hosts. There are no other interested hosts
so the request is recorded.
Type: 0x22
Type: 0x22
Number of Group Records: 1
Number of Group Records: 1
Record Type: 4 IGMP Join message 1
2 Change to Include Record Type: 3
Number of Sources: 0
Number of Sources: 1
Multicast Address: 224.1.1.1
Multicast Address: 224.1.1.1
Source Address: 10.11.1.1
Type: 0x22
Number of Group Records: 1
Record Type: 5 Allow New 4
Number of Sources: 1
Multicast Address: 224.1.1.1
State-change reports retransmitted Source Address: 10.11.1.2
Query Robustness Value-1 times at
Unsolicited Report Interval
fnC0072mp
Figure 19-5 shows how multicast routers track and refresh state changes in response to group-and-specific
and general queries.
1. Host 1 sends a message indicating it is leaving group 224.1.1.1 and that the include filter for 10.11.1.1
and 10.11.1.2 are no longer necessary.
2. The querier, before making any state changes, sends a group-and-source query to see if any other host
is interested in these two sources; queries for state-changes are retransmitted multiple times. If any are,
they respond with their current state information and the querier refreshes the relevant state
information.
3. Separately in Figure 19-5, the querier sends a general query to 224.0.0.1.
4. Host 2 responds to the periodic general query so the querier refreshes the state information for that
group.
Querier Non-Querier
Interface Multicast Group Filter Source Source Non-querier builds identical table
Address Timer Mode Timer and waits Other Querier Present
1/1 224.1.1.1 Include Interval to assume Querier role
10.11.1.1 LQMT 1/1 2/1
10.11.1.2 LQMT
224.2.2.2 GMI Exclude None
Queries retransmitted Last Member
Query Count times at Last Member Type: 0x11 IGMP General
Type: 0x11 2 Query Interval 3 Group Address: 224.0.0.1
Group Address: 224.1.1.1 Membership Query
IGMP Group-and-Source Number of Sources: 0
Specific Query Number of Sources: 2
Source Address: 10.11.1.1, 10.11.1.2
Type: 0x17 Type: 0x22
Number of Group Records: 1 Number of Group Records: 1
1 Record Type: 6 4 Record Type: 2 IGMP Membership Report
Number of Sources: 2 Number of Sources: 0
Multicast Address: 224.1.1.1 Multicast Address: 224.2.2.2
Source Addresses: 10.11.1.1, 10.11.1.2
Host 1 Host 2
Configuring IGMP
Configuring IGMP is a two-step process:
Adjusting Timers
View the current value of all IGMP timers using the command show ip igmp interface from EXEC
Privilege mode, as shown in Figure 19-6.
The Maximum Response Time is the amount of time that the querier waits for a response to a query before
taking further action. The querier advertises this value in the query (see Figure 19-1). Lowering this value
decreases leave latency but increases response burstiness since all host membership reports must be sent
before the Maximum Response Time expires. Inversely, increasing this value decreases burstiness at the
expense of leave latency.
• Adjust the period between queries using the command ip igmp query-interval from INTERFACE mode.
• Adjust the Maximum Response Time using the command ip igmp query-max-resp-time from
INTERFACE mode.
When the querier receives a leave message from a host, it sends a group-specific query to the subnet. If no
response is received, it sends another. The amount of time that the querier waits to receive a response to the
initial query before sending a second one is the Last Member Query Interval (LMQI). The switch waits one
LMQI after the second query before removing the group from the state table.
• Adjust the Last Member Query Interval using the command ip igmp last-member-query-interval from
INTERFACE mode.
1. Routers send queries to the all multicast systems address, 224.0.0.1. Initially, all routers send queries.
The amount of time that elapses before routers on a subnet assume that the querier is down is the Other
Querier Present Interval. Adjust this value using the command ip igmp querier-timeout from INTERFACE
mode.
Note: The timeout value for an IGMP querier is calculated differently on Dell Force10 FTOS routers than
on Cisco IOS routers. As a result, if the IGMP querier in a subnet goes down, a Cisco IOS router may be
elected as the new querier before a Dell Force10 FTOS router.
View the static groups using the command show ip igmp groups from EXEC Privilege mode. Static groups
have an expiration value of Never and a Last Reporter value of CLI, as shown in Figure 19-8.
IGMP Immediate Leave reduces leave latency by enabling a router to immediately delete the group
membership on an interface upon receiving a Leave message (it does not send any group-specific or
group-and-source queries before deleting the entry). Configure the system for IGMP Immediate Leave
using the command ip igmp immediate-leave.
View the enable status of this feature using the command show ip igmp interface from EXEC Privilege
mode, as shown in Figure 19-7.
Multicast packets are addressed with multicast MAC addresses, which represent a group of devices, rather
than one unique device. Switches forward multicast frames out of all ports in a VLAN by default, even
though there may be only some interested hosts, which is a waste of bandwidth. IGMP Snooping enables
switches to use information in IGMP packets to generate a forwarding table that associates ports with
multicast groups so that when they receive multicast frames, they can forward them only to interested
receivers.
On the E-Series, you can configure the switch to only forward unregistered packets to ports on a VLAN
that are connected to multicast routers (mrouter ports) using the command no ip igmp snooping flood from
CONFIGURATION mode. When flooding is disabled, if there are no such ports in the VLAN connected to
a multicast router, the switch drops the packets.
On the C-Series and S-Series, when you configure no ip igmp snooping flood, the system drops the packets
immediately. The system does not forward the frames on mrouter ports, even if they are present. On the
C-Series and S-Series, Layer 3 multicast must be disabled (no ip multicast-routing) in order to disable
multicast flooding.
View the ports that are connected to multicast routers using the command show ip igmp snooping mrouter
from EXEC Privilege mode.
Configure the switch to be the querier for a VLAN by first assigning an IP address to the VLAN interface,
and then using the command ip igmp snooping querier from INTERFACE VLAN mode.
• IGMP snooping Querier does not start if there is a statically configured multicast router interface in the
VLAN.
• The switch may lose the querier election if it does not have the lowest IP address of all potential
queriers on the subnet.
(with IP SA lower than its VLAN IP address) is received on any of its VLAN members.
When the querier receives a leave message from a receiver, it sends a group-specific query out of the ports
specified in the forwarding table. If no response is received, it sends another. The amount of time that the
querier waits to receive a response to the initial query before sending a second one is the Last Member
Query Interval (LMQI). The switch waits one LMQI after the second query before removing the
group-port entry from the forwarding table.
Adjust the Last Member Query Interval using the command ip igmp snooping last-member-query-interval
from INTERFACE VLAN mode.
When an IGMP snooping switch is not acting as a Querier it sends out the general query, in response to the
MSTP triggered link-layer topology change, with the source IP address of 0.0.0.0 to avoid triggering
Querier election.
This chapter describes interface types, both physical and logical, and how to configure them with FTOS.
10/100/1000 Mbps Ethernet, Gigabit Ethernet, and 10 Gigabit Ethernet interfaces are supported on
platforms ces
SONET interfaces are only supported on platform e and are covered in the SONET/SDH chapter.
Basic Interface Configuration:
• Interface Types
• View Basic Interface Information
• Enable a Physical Interface
• Physical Interfaces
• Management Interfaces
• VLAN Interfaces
• Loopback Interfaces
• Null Interfaces on page 427
• Port Channel Interfaces
Interfaces | 415
Interface Types
www.dell.com | support.dell.com
Modes Requires
Interface Type Possible Default Mode Creation Default State
Physical L2, L3 Unset No Shutdown (disabled)
Management N/A N/A No No Shutdown (enabled)
Loopback L3 L3 Yes No Shutdown (enabled)
Null N/A N/A No Enabled
Port Channel L2, L3 L3 Yes Shutdown (disabled)
VLAN L2, L3 L2 Yes (except L2 - No Shutdown (enabled)
default) L3 - Shutdown (disabled)
Note: To end output from the system, such as the output from the show interfaces command, enter
CTRL+C and FTOS will return to the command prompt.
Note: Unicast counters in the show interface output will increment when the interface receives multicast or
broadcast packets.
Figure 20-1 displays the configuration and status information for one interface.
416 | Interfaces
Figure 20-1. show interfaces Command Example
FTOS#show interfaces tengigabitethernet 1/0
TenGigabitEthernet 1/0 is up, line protocol is up
Hardware is Force10Eth, address is 00:01:e8:05:f3:6a
Current address is 00:01:e8:05:f3:6a
Pluggable media present, XFP type is 10GBASE-LR.
Medium is MultiRate, Wavelength is 1310nm
XFP receive power reading is -3.7685
Interface index is 67436603
Internet address is 65.113.24.238/28
MTU 1554 bytes, IP MTU 1500 bytes
LineSpeed 10000 Mbit, Mode full duplex, Master
ARP type: ARPA, ARP Timeout 04:00:00
Last clearing of "show interface" counters 00:09:54
Queueing strategy: fifo
Input Statistics:
0 packets, 0 bytes
0 Vlans
0 64-byte pkts, 0 over 64-byte pkts, 0 over 127-byte pkts
0 over 255-byte pkts, 0 over 511-byte pkts, 0 over 1023-byte pkts
0 Multicasts, 0 Broadcasts
Use the show ip interfaces brief command in the EXEC Privilege mode to view which interfaces are
enabled for Layer 3 data transmission. In Figure 20-2, GigabitEthernet interface 1/5 is in Layer 3 mode
since an IP address has been assigned to it and the interface’s status is operationally up.
Figure 20-2. show ip interfaces brief Command Example (Partial)
Use the show interfaces configured command in the EXEC Privilege mode to view only configured
interfaces. In Figure 20-2, GigabitEthernet interface 1/5 is in Layer 3 mode since an IP address has been
assigned to it and the interface’s status is operationally up.
To determine which physical interfaces are available, use the show running-config command in EXEC
mode. This command displays all physical interfaces available on the line cards. (Figure 158).
Interfaces | 417
Figure 20-3. Interfaces listed in the show running-config Command (Partial)
www.dell.com | support.dell.com
FTOS#show running
Current Configuration ...
!
interface GigabitEthernet 9/6
no ip address
shutdown
!
interface GigabitEthernet 9/7
no ip address
shutdown
!
interface GigabitEthernet 9/8
no ip address
shutdown
!
interface GigabitEthernet 9/9
no ip address
shutdown
To enter the INTERFACE mode, use these commands in the following sequence, starting in the
CONFIGURATION mode:
1 interface interface CONFIGURATION Enter the keyword interface followed by the type of interface
and slot/port information:
• For a 10/100/1000 Ethernet interface, enter the keyword
GigabitEthernet followed by the slot/port information.
• For a Gigabit Ethernet interface, enter the keyword
GigabitEthernet followed by the slot/port information.
• For the Management interface on the RPM, enter the
keyword ManagementEthernet followed by the slot/port
information.
• For a SONET interface, enter the keyword sonet followed
by slot/port information.
• For a 10 Gigabit Ethernet interface, enter the keyword
TenGigabitEthernet followed by the slot/port
information.
418 | Interfaces
To confirm that the interface is enabled, use the show config command in the INTERFACE mode.
To leave the INTERFACE mode, use the exit command or end command.
Physical Interfaces
The Management Ethernet interface, is a single RJ-45 Fast Ethernet port on the Route Processor Module
(RPM) of the C-Series and E-Series, and provides dedicated management access to the system. The
S-Series systems supported by FTOS do not have this dedicated management interface, but you can use
any Ethernet port configured with an IP address and route.
Line card interfaces support Layer 2 and Layer 3 traffic over the 10/100/1000, Gigabit, and 10-Gigabit
Ethernet interfaces. SONET interfaces with PPP encapsulation support Layer 3 traffic. These interfaces
(except SONET interfaces with PPP encapsulation) can also become part of virtual interfaces such as
VLANs or port channels.
Link detection on ExaScale line cards is interrupt-based rather than poll-based, which enables ExaScale
cards to bring up and take down links faster.
For more information on VLANs, see Bulk Configuration on page 440 and for more information on port
channels, see Port Channel Interfaces on page 428.
FTOS Behavior: S-Series systems use a single MAC address for all physical interfaces while
E-Series and C-Series use a unique MAC address for each physical interface, though this results in no
functional difference between these platforms.
The following section includes information about optional configurations for physical interfaces:
Interfaces | 419
Overview of Layer Modes
www.dell.com | support.dell.com
On all systems running FTOS, you can place physical interfaces, port channels, and VLANs in Layer 2
mode or Layer 3 mode.
Possible Requires
Type of Interface Modes Creation Default State
10/100/1000 Ethernet, Gigabit Layer 2 No Shutdown (disabled)
Ethernet, 10 Gigabit Ethernet Layer 3
SONET (PPP encapsulation) Layer 3 No Shutdown (disabled)
Management n/a No Shutdown (disabled)
Loopback Layer 3 Yes No shutdown (enabled)
Null interface n/a No Enabled
Port Channel Layer 2 Yes Shutdown (disabled)
Layer 3
VLAN Layer 2 Yes, except for the No shutdown (active for Layer 2)
Layer 3 default VLAN Shutdown (disabled for Layer 3)
To configure an interface in Layer 2 mode, use these commands in the INTERFACE mode:
420 | Interfaces
For information on enabling and configuring Spanning Tree Protocol, see Chapter 10, Layer 2, on page 47.
To view the interfaces in Layer 2 mode, use the command show interfaces switchport in the EXEC mode.
Figure 20-5 shows how the show config command displays an example of a Layer 3 interface.
Figure 20-5. show config Command Example of a Layer 3 Interface
FTOS(conf-if)#show config
!
interface GigabitEthernet 1/5
ip address 10.10.10.1 /24
no shutdown
FTOS(conf-if)#
If an interface is in the incorrect layer mode for a given command, an error message is displayed to the
user. For example, in Figure 20-6, the command ip address triggered an error message because the
interface is in Layer 2 mode and the ip address command is a Layer 3 command only.
Figure 20-6. Error Message When Trying to Add an IP Address to Layer 2 Interface
FTOS(conf-if)#show config
!
interface GigabitEthernet 1/2
no ip address
switchport
no shutdown
FTOS(conf-if)#ip address 10.10.1.1 /24
% Error: Port is in Layer 2 mode Gi 1/2.
FTOS(conf-if)# Error message
To determine the configuration of an interface, you can use the show config command in INTERFACE
mode or the various show interface commands in EXEC mode.
To assign an IP address, use both of the following commands in the INTERFACE mode:
Interfaces | 421
www.dell.com | support.dell.com
ip address ip-address mask [secondary] INTERFACE Configure a primary IP address and mask on
the interface. The ip-address must be in
dotted-decimal format (A.B.C.D) and the
mask must be in slash format (/xx).
Add the keyword secondary if the IP
address is the interface’s backup IP address.
You can only configure one (1) primary IP address per interface. You can configure up to 255 secondary IP
addresses on a single interface.
To view all interfaces to see with an IP address assigned, use the show ip interfaces brief command in the
EXEC mode (Figure 176).
To view IP information on an interface in Layer 3 mode, use the show ip interface command in the EXEC
Privilege mode (Figure 159).
422 | Interfaces
Management Interfaces
The management interface supports IPv4 and IPv6 addressing, and supports ping and traceroute for IPv4
and IPv6 addresses.
To configure a Management interface, use the following command in the CONFIGURATION mode:
interface Managementethernet interface CONFIGURATION Enter the slot (0-1) and the port (0).
In a system with 2 RPMs, therefore, 2
Management interfaces, the slot number
differentiates between the two Management
interfaces.
If there are two RPMs on the system, each Management interface must be configured with a different IP
address. Unless the management route command is configured, you can only access the Management
interface from the local LAN. To access the Management interface from another LAN, the management
route command must be configured to point to the Management interface.
Alternatively, you can use virtual-ip to manage a system with one or two RPMs. A virtual IP is an IP
address assigned to the system (not to any management interfaces) and is a CONFIGURATION mode
command. You may enter an IPv4 or IPv6 address. When a virtual IP address is assigned to the system, the
active management interface of the RPM is recognized by the virtual IP address—not by the actual
interface IP address assigned to it. During an RPM failover, you do not have to remember the IP address of
the new RPM’s management interface—the system will still recognizes the virtual-IP address.
Interfaces | 423
Important Things to Remember — virtual-ip
www.dell.com | support.dell.com
• virtual-ip is a CONFIGURATION mode command. You may enter an IPv4 or IPv6 address.
• When applied, the management port on the primary RPM assumes the virtual IP address. Entering the
show interfaces and show ip interface brief commands on the primary RPM management interface will
display both the virtual IP address and the actual IP address configured on the interface (see
Displaying Information on a Management Interface on page 425).
• A duplicate IP address message is printed for management port’s virtual IP address on an RPM
failover. This is a harmless error that is generated due to a brief transitory moment during failover
when both RPMs’ management ports own the virtual IP address, but have different MAC addresses.
• The primary management interface will use only the virtual IP address if it is configured. The system
can not be accessed through the native IP address of the primary RPM’s management interface.
• Once the virtual IP address is removed, the system is accessible through the native IP address of the
primary RPM’s management interface.
• Primary and secondary management interface IP and virtual IP must be in the same subnet.
As shown in Figure 20-8, from EXEC Privilege mode, display the configuration for a given port by
entering the command show interface, and the routing table with the show ip route command.
424 | Interfaces
Displaying Information on a Management Interface
To view information about the primary RPM management port, use the show interface
Managementethernet command in EXEC or EXEC Privilege mode. If there are two RPMs on the system,
you cannot view information on the interface.
To view summary information about the primary RPM Management port, use the show ip interface brief
Managementethernet or show ipv6 interface brief Managementethernet commands in EXEC or EXEC
Privilege mode.
Interfaces | 425
VLAN Interfaces
www.dell.com | support.dell.com
VLANs are logical interfaces and are, by default, in Layer 2 mode. Physical interfaces and port channels
can be members of VLANs. For more information on VLANs and Layer 2, refer to Chapter 10, Layer 2, on
page 47. See also Chapter 18, VLAN Stacking, on page 367.
Note: To monitor VLAN interfaces, use the Management Information Base for Network Management of
TCP/IP-based internets: MIB-II (RFC 1213). Monitoring VLAN interfaces via SNMP is supported only on
E-Series.
FTOS supports Inter-VLAN routing (Layer 3 routing in VLANs). You can add IP addresses to VLANs and
use them in routing protocols in the same manner that physical interfaces are used. For more information
on configuring different routing protocols, refer to the chapters on the specific protocol.
A consideration for including VLANs in routing protocols is that the no shutdown command must be
configured. (For routing traffic to flow, the VLAN must be enabled.)
Note: An IP address cannot be assigned to the Default VLAN, which, by default, is VLAN 1. To assign
another VLAN ID to the Default VLAN, use the default vlan-id vlan-id command.
Assign an IP address to an interface with the following command the INTERFACE mode:
ip address ip-address mask [secondary] INTERFACE Configure an IP address and mask on the interface.
• ip-address mask: enter an address in
dotted-decimal format (A.B.C.D) and the mask
must be in slash format (/24).
• secondary: the IP address is the interface’s
backup IP address. You can configure up to eight
secondary IP addresses.
426 | Interfaces
Loopback Interfaces
A Loopback interface is a virtual interface in which the software emulates an interface. Packets routed to it
are processed locally. Since this interface is not a physical interface, you can configure routing protocols
on this interface to provide protocol stability. You can place Loopback interfaces in default Layer 3 mode.
To configure a Loopback interface, use the following command in the CONFIGURATION mode:
To view Loopback interface configurations, use the show interface loopback number command in the
EXEC mode.
To delete a Loopback interface, use the no interface loopback number command syntax in the
CONFIGURATION mode.
Many of the same commands found in the physical interface are found in Loopback interfaces.
Null Interfaces
The Null interface is another virtual interface created by the E-Series software. There is only one Null
interface. It is always up, but no traffic is transmitted through this interface.
To enter the INTERFACE mode of the Null interface, use the following command in the
CONFIGURATION mode:
interface null 0 CONFIGURATION Enter the INTERFACE mode of the Null interface.
The only configurable command in the INTERFACE mode of the Null interface is the ip unreachable
command.
Interfaces | 427
Port Channel Interfaces
www.dell.com | support.dell.com
Port channel interfaces support link aggregation, as described in IEEE Standard 802.3ad.
Link aggregation is defined by IEEE 802.3ad as a method of grouping multiple physical interfaces into a
single logical interface—a Link Aggregation Group (LAG) or port channel. A LAG is “a group of links
that appear to a MAC client as if they were a single link” according to IEEE 802.3ad. In FTOS, a LAG is
referred to as a port channel interface.
A port channel provides redundancy by aggregating physical interfaces into one logical interface. If one
physical interface goes down in the port channel, another physical interface carries the traffic.
For the E-Series, a port channel interface provides many benefits, including easy management, link
redundancy, and sharing.
Port channels are transparent to network configurations and can be modified and managed as one interface.
For example, you configure one IP address for the group and that IP address is used for all routed traffic on
the port channel.
With this feature, the user can create larger-capacity interfaces by utilizing a group of lower-speed links.
For example, the user can build a 5-Gigabit interface by aggregating five 1-Gigabit Ethernet interfaces
together. If one of the five interfaces fails, traffic is redistributed across the four remaining interfaces.
428 | Interfaces
• Dynamic—Port channels that are dynamically configured using Link Aggregation Control Protocol
(LACP). For details, see Chapter 24, Link Aggregation Control Protocol.
Table 20-2. Number of Port-channels per Platform
Table 20-4. As soon as a port channel is configured, FTOS treats it like a physical interface. For
example, IEEE 802.1Q tagging is maintained while the physical interface is in the port channel.
Member ports of a LAG are added and programmed into hardware in a predictable order based on the port
ID, instead of in the order in which the ports come up. With this implementation, load balancing yields
predictable results across line card resets and chassis reloads.
Each port channel must contain interfaces of the same interface type/speed.
Port channels can contain a mix of 10, 100, or 1000 Mbps Ethernet interfaces and Gigabit Ethernet
interfaces, and the interface speed (10, 100, or 1000 Mbps) used by the port channel is determined by the
first port channel member that is physically up. FTOS disables the interfaces that do match the interface
speed set by the first channel member. That first interface may be the first interface that is physically
brought up or was physically operating when interfaces were added to the port channel. For example, if the
first operational interface in the port channel is a Gigabit Ethernet interface, all interfaces at 1000 Mbps are
kept up, and all 10/100/1000 interfaces that are not set to 1000 speed or auto negotiate are disabled.
FTOS brings up 10/100/1000 interfaces that are set to auto negotiate so that their speed is identical to the
speed of the first channel member in the port channel.
When both 10/100/1000 interfaces and GigE interfaces are added to a port channel, the interfaces must
share a common speed. When interfaces have a configured speed different from the port channel speed, the
software disables those interfaces.
Interfaces | 429
The common speed is determined when the port channel is first enabled. At that time, the software checks
www.dell.com | support.dell.com
the first interface listed in the port channel configuration. If that interface is enabled, its speed
configuration becomes the common speed of the port channel. If the other interfaces configured in that port
channel are configured with a different speed, FTOS disables them.
For example, if four interfaces (Gi 0/0, 0/1, 0/2, 0/3) in which Gi 0/0 and Gi 0/3 are set to speed 100 Mb/s
and the others are set to 1000 Mb/s, with all interfaces enabled, and you add them to a port channel by
entering channel-member gigabitethernet 0/0-3 while in the port channel interface mode, and FTOS
determines if the first interface specified (Gi 0/0) is up. Once it is up, the common speed of the port
channel is 100 Mb/s. FTOS disables those interfaces configured with speed 1000 or whose speed is 1000
Mb/s as a result of auto-negotiation.
In this example, you can change the common speed of the port channel by changing its configuration so the
first enabled interface referenced in the configuration is a 1000 Mb/s speed interface. You can also change
the common speed of the port channel here by setting the speed of the Gi 0/0 interface to 1000 Mb/s.
To configure a port channel (LAG), you use the commands similar to those found in physical interfaces.
By default, no port channels are configured in the startup configuration.
• Create a port channel (mandatory)
• Add a physical interface to a port channel on page 431 (mandatory)
• Reassign an interface to a new port channel on page 433 (optional)
• Configure the minimum oper up links in a port channel (LAG) on page 434 (optional)
• Add or remove a port channel from a VLAN on page 434 (optional)
• Assign an IP address to a port channel on page 435 (optional)
• Delete or disable a port channel on page 435 (optional)
• Load balancing through port channels on page 436 (optional)
To configure a port channel, use these commands in the following sequence, starting in the
CONFIGURATION mode:
430 | Interfaces
The port channel is now enabled and you can place the port channel in Layer 2 or Layer 3 mode. Use the
switchport command to place the port channel in Layer 2 mode or configure an IP address to place the port
channel in Layer 3 mode.
You can configure a port channel as you would a physical interface by enabling or configuring protocols or
assigning access control lists.
The physical interfaces in a port channel can be on any line card in the chassis, but must be the same
physical type.
Note: Port channels can contain a mix of Gigabit Ethernet and 10/100/1000 Ethernet interfaces, but FTOS
disables the interfaces that are not the same speed of the first channel member in the port channel (see
10/100/1000 Mbps interfaces in port channels).
You can add any physical interface to a port channel if the interface configuration is minimal. Only the
following commands can be configured on an interface if it is a member of a port channel:
• description
• shutdown/no shutdown
• mtu
• ip mtu (if the interface is on a Jumbo-enabled by default.)
Note: The S-Series supports jumbo frames by default (the default maximum transmission unit (MTU) is
1554 bytes) You can configure the MTU using the mtu command from INTERFACE mode.
To view the interface’s configuration, enter the INTERFACE mode for that interface and enter the show
config command or from the EXEC Privilege mode, enter the show running-config interface interface
command.
When an interface is added to a port channel, FTOS recalculates the hash algorithm.
To add a physical interface to a port channel, use these commands in the following sequence in the
INTERFACE mode of a port channel:
2 show config INTERFACE Double check that the interface was added to
PORT-CHANNEL the port channel.
To view the port channel’s status and channel members in a tabular format, use the show interfaces
port-channel brief (Figure 177) command in the EXEC Privilege mode.
Interfaces | 431
Figure 20-13. show interfaces port-channel brief Command Example
www.dell.com | support.dell.com
Figure 20-14 displays the port channel’s mode (L2 for Layer 2 and L3 for Layer 3 and L2L3 for a Layer 2
port channel assigned to a routed VLAN), the status, and the number of interfaces belonging to the port
channel.
Figure 20-14. show interface port-channel Command Example
FTOS>show interface port-channel 20
Port-channel 20 is up, line protocol is up
Hardware address is 00:01:e8:01:46:fa
Internet address is 1.1.120.1/24
MTU 1554 bytes, IP MTU 1500 bytes
LineSpeed 2000 Mbit
Members in this channel: Gi 9/10 Gi 9/17
ARP type: ARPA, ARP timeout 04:00:00
Last clearing of "show interface" counters 00:00:00
Queueing strategy: fifo
1212627 packets input, 1539872850 bytes
Input 1212448 IP Packets, 0 Vlans 0 MPLS
4857 64-byte pkts, 17570 over 64-byte pkts, 35209 over 127-byte pkts
69164 over 255-byte pkts, 143346 over 511-byte pkts, 942523 over 1023-byte pkts
Received 0 input symbol errors, 0 runts, 0 giants, 0 throttles
42 CRC, 0 IP Checksum, 0 overrun, 0 discarded
2456590833 packets output, 203958235255 bytes, 0 underruns
Output 1640 Multicasts, 56612 Broadcasts, 2456532581 Unicasts
2456590654 IP Packets, 0 Vlans, 0 MPLS
0 throttles, 0 discarded
Rate info (interval 5 minutes):
Input 00.01Mbits/sec, 2 packets/sec
Output 81.60Mbits/sec, 133658 packets/sec
Time since last interface status change: 04:31:57
FTOS>
When more than one interface is added to a Layer 2 port channel, FTOS selects one of the active interfaces
in the port channel to be the Primary Port. The primary port replies to flooding and sends protocol PDUs.
An asterisk in the show interfaces port-channel brief command indicates the primary port.
As soon as a physical interface is added to a port channel, the properties of the port channel determine the
properties of the physical interface. The configuration and status of the port channel are also applied to the
physical interfaces within the port channel. For example, if the port channel is in Layer 2 mode, you cannot
add an IP address or a static MAC address to an interface that is part of that port channel. As Figure 20-15
illustrates, interface GigabitEthernet 1/6 is part of port channel 5, which is in Layer 2 mode, and an error
message appeared when an IP address was configured.
432 | Interfaces
Figure 20-15. Error Message
FTOS(conf-if-portch)#show config
!
interface Port-channel 5
no ip address
switchport
channel-member GigabitEthernet 1/6
FTOS(conf-if-portch)#int gi 1/6
FTOS(conf-if)#ip address 10.56.4.4 /24
% Error: Port is part of a LAG Gi 1/6. Error message
FTOS(conf-if)#
An interface can be a member of only one port channel. If the interface is a member of a port channel, you
must remove it from the first port channel and then add it to the second port channel.
Each time you add or remove a channel member from a port channel, FTOS recalculates the hash
algorithm for the port channel.
To reassign an interface to a new port channel, use these commands in the following sequence in the
INTERFACE mode of a port channel:
1 no channel-member interface INTERFACE Remove the interface from the first port
PORT-CHANNEL channel.
3 channel-member interface INTERFACE Add the interface to the second port channel.
PORT-CHANNEL
Figure 20-16 displays an example of moving the GigabitEthernet 1/8 interface from port channel 4 to port
channel 3.
Interfaces | 433
Figure 20-16. Command Example from Reassigning an Interface to a Different Port Channel
www.dell.com | support.dell.com
FTOS(conf-if-portch)#show config
!
interface Port-channel 4
no ip address
channel-member GigabitEthernet 1/8
no shutdown
FTOS(conf-if-portch)#no chann gi 1/8
FTOS(conf-if-portch)#int port 5
FTOS(conf-if-portch)#channel gi 1/8
FTOS(conf-if-portch)#sho conf
!
interface Port-channel 5
no ip address
channel-member GigabitEthernet 1/8
shutdown
FTOS(conf-if-portch)#
You can configure the minimum links in a port channel (LAG) that must be in “oper up” status for the port
channel to be considered to be in “oper up” status. Use the following command in the INTERFACE mode:
Figure 20-17 displays an example of configuring five minimum “oper up” links in a port channel.
As with other interfaces, you can add Layer 2 port channel interfaces to VLANs. To add a port channel to a
VLAN, you must place the port channel in Layer 2 mode (by using the switchport command).
434 | Interfaces
To add a port channel to a VLAN, use either of the following commands:
tagged port-channel id number INTERFACE Add the port channel to the VLAN as a tagged
VLAN interface. An interface with tagging enabled can
belong to multiple VLANs.
untagged port-channel id number INTERFACE Add the port channel to the VLAN as an untagged
VLAN interface. An interface without tagging enabled can
belong to only one VLAN.
To remove a port channel from a VLAN, use either of the following commands:
no tagged port-channel id number INTERFACE Remove the port channel with tagging enabled
VLAN from the VLAN.
no untagged port-channel id number INTERFACE Remove the port channel without tagging
VLAN enabled from the VLAN.
To see which port channels are members of VLANs, enter the show vlan command in the EXEC Privilege
mode.
You can assign an IP address to a port channel and use port channels in Layer 3 routing protocols.
ip address ip-address mask [secondary] INTERFACE Configure an IP address and mask on the interface.
• ip-address mask: enter an address in
dotted-decimal format (A.B.C.D) and the mask
must be in slash format (/24).
• secondary: the IP address is the interface’s
backup IP address. You can configure up to eight
secondary IP addresses.
To delete a port channel, you must be in the CONFIGURATION mode and use the no interface
portchannel channel-number command.
When you disable a port channel (using the shutdown command) all interfaces within the port channel are
operationally down also.
Interfaces | 435
Load balancing through port channels
www.dell.com | support.dell.com
FTOS uses hash algorithms for distributing traffic evenly over channel members in a port channel (LAG).
The hash algorithm distributes traffic among ECMP paths and LAG members. The distribution is based on
a flow, except for packet-based hashing. A flow is identified by the hash and is assigned to one link. In
packet-based hashing, a single flow can be distributed on the LAG and uses one link.
Packet based hashing is used to load balance traffic across a port-channel based on the IP Identifier field
within the packet. Load balancing uses source and destination packet information to get the greatest
advantage of resources by distributing traffic over multiple paths when transferring data to a destination.
FTOS allows you to modify the hashing algorithms used for flows and for fragments. The load-balance and
hash-algorithm commands are available for modifying the distribution algorithms. Their syntax and
implementation are somewhat different between the E-Series and the C-Series and S-Series.
Note: Hash-based load-balancing on MPLS does not work when packet-based hashing (load-balance
ip-selection packet-based) is enabled.
E-Series load-balancing
Balancing may be applied to IPv4, switched IPv6, and non-IP traffic. For these traffic types, the
IP-header-based hash and MAC-based hash may be applied to packets by using the following methods.
Layer 2 Layer 3
Hash (Header Based) Port Channel Port Channel
5-tuple X X
3-tuple X X
Packet-based X X
MAC source address (SA) and destination address (DA) X
436 | Interfaces
On the E-Series, to change the 5-tuple default to 3-tuple, MAC, or packet-based, use the following
command in CONFIGURATION mode:
[no] load-balance [ip-selection CONFIGURATION To designate a method to balance traffic over a port
{3-tuple | packet-based}] [mac] channel. By default, IP 5-tuple is used to distribute
traffic over members port channel.
ip-selection 3-tuple—Distribute IP traffic based on IP
source address, IP destination address, and IP protocol type.
ip-selection packet-based—Distribute IPV4 traffic
based on the IP Identification field in the IPV4 header.
mac—Distribute traffic based on the MAC source address,
and the MAC destination address.
See Table 20-7 for more information.
For details on the load-balance command, see the IP Routing chapter of the FTOS Command Reference.
To distribute IP traffic over an E-Series port channel member, FTOS uses the 5-tuple IP default. The
5-tuple and the 3-tuple hash use the following keys:
Note: For IPV6, only the first 32 bits (LSB) of IP Source Address and IP Destination Address are used for
hash generation.
Figure 20-18 shows the configuration and show command for packet-based hashing on the E-Series.
The load-balance packet based command can co-exist with load balance mac command to achieve the
functionality shown in Table 20-7.
Interfaces | 437
IPv4, IPv6, and non-IP traffic handling on the E-Series
www.dell.com | support.dell.com
The table below presents the combinations of the load-balance command and their effect on traffic types.
Routed
Switched Switched
Configuration Commands IP Traffic
IP Traffic Non-IP Traffic
(IPv4 only)
IP 5-tuple
Default (IP 5-tuple) IP 5-tuple MAC-based
(lower 32 bits)
IP 3-tuple
load-balance ip-selection 3-tuple IP 3-tuple MAC-based
(lower 32 bits)
load-balance ip-selection mac MAC-based IP 5-tuple MAC-based
load-balance ip-selection 3-tuple
MAC-based IP 3-tuple MAC-based
load-balance ip-selection mac
Packet based: IPV4
load-balance ip-selection packet-based Packet-based MAC-based
No distribution: IPV6
load-balance ip-selection packet-based
MAC-based Packet-based MAC-based
load-balance ip-selection mac
For LAG hashing on C-Series and S-Series, the source IP, destination IP, source TCP/UDP port, and
destination TCP/UDP port are used for hash computation by default. For packets without a Layer 3 header,
FTOS automatically uses load-balance mac source-dest-mac.
IP hashing or MAC hashing should not be configured at the same time. If you configure an IP and MAC
hashing scheme at the same time, the MAC hashing scheme takes precedence over the IP hashing scheme.
To change the IP traffic load balancing default on the C-Series and S-Series, use the following command:
[no] load-balance {ip-selection CONFIGURATION Replace the default IP 4-tuple method of balancing
[dest-ip | source-ip]} | {mac traffic over a port channel. You can select one, two, or
[dest-mac | source-dest-mac | all three of the following basic hash methods
source-mac]} | {tcp-udp enable} ip-selection [dest-ip | source-ip]—Distribute IP
traffic based on IP destination or source address.
mac [dest-mac | source-dest-mac |
source-mac]—Distribute IPV4 traffic based on the
destination or source MAC address, or both, along with the
VLAN, Ethertype, source module ID and source port ID.
tcp-udp enable—Distribute traffic based on TCP/UDP
source and destination ports.
438 | Interfaces
Hash algorithm
The load-balance command discussed above selects the hash criteria applied to port channels.
If even distribution is not obtained with the load-balance command, the hash-algorithm command can be
used to select the hash scheme for LAG, ECMP and NH-ECMP. The 12 bit Lag Hash can be rotated or
shifted till the desired hash is achieved.
The nh-ecmp option allows you to change the hash value for recursive ECMP routes independently of
non-recursive ECMP routes. This option provides for better traffic distribution over available equal cost
links that involve a recursive next hop lookup.
For the E-Series TeraScale and ExaScale, you can select one of 47 possible hash algorithms (16 on
EtherScale).
hash-algorithm {algorithm-number} | CONFIGURATION Change the default (0) to another algorithm and apply
{ecmp {checksum|crc|xor} it to ECMP, LAG hashing, or a particular line card.
[number]} lag
{checksum|crc|xor][number]}nh-ec Note: To achieve the functionality of hash-align
mp {[checksum|crc|xor] [number]}}| on the ExaScale platform, do not use CRC as an
{linecard number ip-sa-mask value hash-algorithm method. For ExaScale systems,
ip-da-mask value} set the default hash-algorithm method to ensure
CRC is not used for LAG. For example,
hash-algorithm ecmp xor lag checksum nh-ecmp
checksum
Note: E-Series systems require the lag-hash-align microcode be configured in the in the CAM profile.
E-Series TeraScale et includes this microcode as an option with the Default cam profile. E-Series
ExaScale ex systems require that a CAM profile be created and specifically include lag-hash-align
microcode.
On C-Series and S-Series, the hash-algorithm command is specific to ECMP groups and has different
defaults from the E-Series. The default ECMP hash configuration is crc-lower. This takes the lower 32 bits
of the hash key to compute the egress port. Other options for ECMP hash-algorithms are:
• crc-upper — uses the upper 32 bits of the hash key to compute the egress port
Interfaces | 439
• dest-ip — uses destination IP address as part of the hash key
www.dell.com | support.dell.com
• lsb — always uses the least significant bit of the hash key to compute the egress port
To change to another method, use the following command in the CONFIGURATION mode:
For more on load-balancing, see “Equal Cost Multipath and Link Aggregation Frequently Asked
Questions” in the E-Series FAQ section (login required) of iSupport:
https://www.force10networks.com/CSPortal20/KnowledgeBase/ToolTips.aspx
Bulk Configuration
Bulk configuration enables you to determine if interfaces are present, for physical interfaces, or,
configured, for logical interfaces.
Interface Range
An interface range is a set of interfaces to which other commands may be applied, and may be created if
there is at least one valid interface within the range. Bulk configuration excludes from configuration any
non-existing interfaces from an interface range. A default VLAN may be configured only if the interface
range being configured consists of only VLAN ports.
The interface range command allows you to create an interface range allowing other commands to be
applied to that range of interfaces.
The interface range prompt offers the interface (with slot and port information) for valid interfaces. The
maximum size of an interface range prompt is 32. If the prompt size exceeds this maximum, it displays (...)
at the end of the output.
Note: Non-existing interfaces are excluded from interface range prompt. In the following example,
Tengigabit 3/0 and VLAN 1000 do not exist.
Note: When creating an interface range, interfaces appear in the order they were entered and are not
sorted.
The show range command is available under interface range mode. This command allows you to display
all interfaces that have been validated under the interface range context.
440 | Interfaces
The show configuration command is also available under the interface range mode. This command allows
you to display the running configuration only for interfaces that are part of interface range.
Create a single-range
Figure 20-20. Creating a Single-Range Bulk Configuration
Create a multiple-range
Figure 20-21. Creating a Multiple-Range Prompt
Duplicate single interfaces and port ranges are excluded from the resulting interface range prompt:
Figure 20-22. Interface Range Prompt Excluding Duplicate Entries
If interface range has multiple port ranges, the smaller port range is excluded from prompt:
Interfaces | 441
Figure 20-23. Interface Range Prompt Excluding a Smaller Port Range
www.dell.com | support.dell.com
If overlapping port ranges are specified, the port range is extended to the smallest start port number and
largest end port number:
Figure 20-24. Interface Range Prompt Including Overlapping Port Ranges
Commas
The example below shows how to use commas to add different interface types to the range, enabling all
Gigabit Ethernet interfaces in the range 5/1 to 5/23 and both Ten Gigabit Ethernet interfaces 1/1 and 1/2.
Figure 20-25. Multiple-Range Bulk Configuration Gigabit Ethernet and Ten-Gigabit Ethernet
Add ranges
The example below shows how to use commas to add VLAN and port-channel interfaces to the range.
Figure 20-26. Multiple-Range Bulk Configuration with VLAN, and Port-channel
442 | Interfaces
Interface Range Macros
The user can define an interface-range macro to automatically select a range of interfaces for
configuration. Before you can use the macro keyword in the interface-range macro command string, you
must define the macro.
FTOS (config)# define interface-range macro_name {vlan CONFIGURATION Defines the interface-range
vlan_ID - vlan_ID} | {{gigabitethernet | macro and saves it in the
tengigabitethernet} slot/interface - interface} [ , {vlan running configuration file.
vlan_ID - vlan_ID} {{gigabitethernet | tengigabitethernet}
slot/interface - interface}]
To show the defined interface-range macro configuration, use the command show running-config in the
EXEC mode. The example below shows how to display the defined interface-range macro named “test”:
FTOS#
Interfaces | 443
Choose an Interface-range Macro
www.dell.com | support.dell.com
To use an interface-range macro in the interface range command, enter this command:
interface range macro name CONFIGURATION Selects the interfaces range to be configured using the values
saved in a named interface-range macro.
The example below shows how to change to the interface-range configuration mode using the
interface-range macro named “test”.
monitor interface interface EXEC Privilege View the interface’s statistics. Enter the type of interface and
slot/port information:
• For a 10/100/1000 Ethernet interface, enter the keyword
GigabitEthernet followed by the slot/port information.
• For a Gigabit Ethernet interface, enter the keyword
GigabitEthernet followed by the slot/port information.
• For the Management interface on the RPM, enter the
keyword ManagementEthernet followed by the slot/
port information.
• For a SONET interface, enter the keyword sonet
followed by slot/port information.
• For a 10 Gigabit Ethernet interface, enter the keyword
TenGigabitEthernet followed by the slot/port
information.
The information (Figure 20-27) displays in a continuous run, refreshing every 2 seconds by default. Use
the following keys to manage the output.
444 | Interfaces
Figure 20-27. Command Example: monitor interface
FTOS#monitor interface gi 3/1
q
FTOS#
TDR is useful for troubleshooting an interface that is not establishing a link, that is, when the link is
flapping or not coming up. TDR is not intended to be used on an interface that is passing traffic. When a
TDR test is run on a physical cable, it is important to shut down the port on the far end of the cable.
Otherwise, it may lead to incorrect test results.
Note: TDR is an intrusive test. Do not run TDR on a link that is up and passing traffic.
Interfaces | 445
To test the condition of cables on 10/100/1000 BASE-T modules, use the tdr-cable-test command:
www.dell.com | support.dell.com
1 tdr-cable-test gigabitethernet <slot>/ EXEC Privilege To test for cable faults on the GigabitEthernet
<port> cable.
• Between two ports, the user must not start
the test on both ends of the cable.
• The user must enable the interface before
starting the test.
• The port should be enabled to run the test
or the test prints an error message.
2 show tdr gigabitethernet <slot>/ EXEC Privilege Displays TDR test results.
<port>
The Link Debounce Timer feature isolates upper layer protocols on Ethernet switches and routers from
very short-term, possibly repetitive interface flaps often caused by network jitter on the DWDM equipment
connecting the switch and other devices on a SONET ring. The Link Debounce Timer delays link change
notifications, thus decreasing traffic loss due to network configuration. All interfaces have a built-in timer
to manage traffic. This feature extends the time allowed by the upper layers.
The SONET ring has its own restore time whenever there is a failure. During this time, however,
the Ethernet interface connected to the switch will flap. Link Debounce Timer instructs the
Ethernet switch to delay the notification of the link change to the upper layers. If the link state
changes again within this period, no notification goes to the upper layers, so that the switch
remains unaware of the change.
Note: Enabling the link debounce timer causes link up and link down detections to be delayed, resulting in
traffic being blackholed during the debouncing period. This situation might affect the convergence and
reconvergence of some Layer 2 and Layer 3 protocols.
446 | Interfaces
• Changes made do not affect any ongoing debounces. The timer changes take affect from the next
debounce onward.
link debounce time [milliseconds] INTERFACE Enter the time to delay link status change notification on this
interface.
Range: 100-5000 ms
• Default for Copper is 3100 ms
• Default for Fiber is 100 ms
FTOS(conf)#int gi 3/1
FTOS(conf-if-gi-3/1)#link debounce time 150
FTOS(conf-if-gi-3/1)#=
FTOS#
FTOS#show interfaces debounce gigabitethernet 3/1
Interface Time(ms)
GigabitEthernet 3/1 200
FTOS#
Note: FTOS rounds the entered debounce time up to the nearest hundredth.
Note in Figure 20-28 that the timer was set at 150 ms, but appears as 200 in Figure 20-29.
Interfaces | 447
When an E300 system boots up and a single SFM is active this configuration, any ports configured with
www.dell.com | support.dell.com
this feature will be shut down. All other ports are booted up.
Similarly, if an SFM fails (or is removed) in an E300 system with two SFM, ports configured with this
feature will be shut down. All other ports are treated normally.
When a second SFM is installed or replaced, all ports are booted up and treated as normally. This feature
does not take affect until a single SFM is active in the E300 system.
Link Dampening
Interface state changes occur when interfaces are administratively brought up or down or if an interface
state changes. Every time an interface changes state or flaps, routing protocols are notified of the status of
the routes that are affected by the change in state, and these protocols go through momentous task of
re-converging. Flapping therefore puts the status of entire network at risk of transient loops and black
holes.
Link dampening minimizes the risk created by flapping by imposing a penalty for each interface flap and
decaying the penalty exponentially. Once the penalty exceeds certain threshold, the interface is put in an
"error-disabled" state, and for all practical purposes of routing, the interface is deemed to be "down." Once
the interface becomes stable and the penalty decays below a certain threshold, the interface comes up again
and the routing protocols re-converge.
Link dampening:
• reduces processing on the CPUs by reducing excessive interface flapping.
• improves network stability by penalizing misbehaving interfaces and redirecting traffic
• improves convergence times and stability throughout the network by isolating failures so that
disturbances are not propagated.
448 | Interfaces
Enable Link Dampening
Enable link dampening using the command dampening from INTERFACE mode, as shown in
Figure 20-30.
R1(conf-if-gi-1/1)#show config
!
interface GigabitEthernet 1/1
ip address 10.10.19.1/24
dampening 1 2 3 4
no shutdown
R1(conf-if-gi-1/1)#exit
View the link dampening configuration on an interface using the command show config, or view
dampening information on all or specific dampened interfaces using the command show interfaces
dampening from EXEC Privilege mode, as shown in Figure 20-31.
View a dampening summary for the entire system using the command show interfaces dampening
summary from EXEC Privilege mode, as shown in Figure 20-32.
Clear dampening counters and accumulated penalties using the command clear dampening, as shown in
Figure 20-33.
Interfaces | 449
Figure 20-33. Clearing Dampening Counters
www.dell.com | support.dell.com
View the output of the following show commands in XML by adding | display xml to the end of the
command:
• show interfaces dampening
• show interfaces dampening summary
• show interfaces interface x/y
The E-Series supports a link Maximum Transmission Unit (MTU) of 9252 bytes and maximum IP MTU of
9234 bytes. The link MTU is the frame size of a packet, and the IP MTU size is used for IP fragmentation.
If the system determines that the IP packet must be fragmented as it leaves the interface, FTOS divides the
packet into fragments no bigger than the size set in the ip mtu command.
In FTOS, MTU is defined as the entire Ethernet packet (Ethernet header + FCS + payload)
Since different networking vendors define MTU differently, check their documentation when planing
MTU sizes across a network.
Ethernet Pause Frames allow for a temporary stop in data transmission. A situation may arise where a
sending device may transmit data faster than a destination device can accept it. The destination sends a
PAUSE frame back to the source, stopping the sender’s transmission for a period of time.
450 | Interfaces
The globally assigned 48-bit Multicast address 01-80-C2-00-00-01 is used to send and receive pause
frames. To allow full duplex flow control, stations implementing the pause operation instruct the MAC to
enable reception of frames with destination address equal to this multicast address.
The PAUSE frame is defined by IEEE 802.3x and uses MAC Control frames to carry the PAUSE
commands. Ethernet Pause Frames are supported on full duplex only. The only configuration applicable to
half duplex ports is rx off tx off.
Note that if a port is over-subscribed, Ethernet Pause Frame flow control does not
ensure no loss behavior.
The following error message appears when trying to enable flow control when half duplex
is already configured: Can’t configure flowcontrol when half duplex is configure,
config ignored.
The following error message appears when trying to enable half duplex and flow control
configuration is on: Can’t configure half duplex when flowcontrol is on, config
ignored.
Threshold Settings
Threshold Settings are supported only on platforms: cs
When the transmission pause is set (tx on), 3 thresholds can be set to define the controls more closely.
Ethernet Pause Frames flow control can be triggered when either the flow control buffer threshold or flow
control packet pointer threshold is reached. The thresholds are:
The pause is started when either the packet pointer or the buffer threshold is met (whichever is met first).
When the discard threshold is met, packets are dropped.
The pause ends when both the packet pointer and the buffer threshold fall below 50% of the threshold
settings.
The discard threshold defines when the interface starts dropping the packet on the interface. This may be
necessary when a connected device doesn’t honor the flow control frame sent by S-Series.
The discard threshold should be larger than the buffer threshold so that the buffer holds at least hold at least
3 packets.
Interfaces | 451
Enable Pause Frames
www.dell.com | support.dell.com
Note: On the C-Series and S-Series platforms, Ethernet Pause Frames TX should be enabled only after
consulting with the Dell Force10 Technical Assistance Center.
Ethernet Pause Frames flow control must be enabled on all ports on a chassis or a line card. If not, the
system may exhibit unpredictable behavior.
On the C-Series and S-Series systems, the flow-control sender and receiver must be on the same
port-pipe. Flow control is not supported across different port-pipes on the C-Series or S-Series system.
On 4-port 10G line cards: Changes in the flow-control values are not reflected automatically in the show
interface output for 10G interfaces. This issue results from the fact that 10G interfaces do not support
auto-negotiation per-se. On 1G interfaces, changing the flow control values causes an automatic interface flap,
after which PAUSE values are exchanged as part of the auto-negotiation process. As a workaround, apply the
new settings, execute shut followed by no shut on the interface, and then check the running-config of the port.
flowcontrol rx [off | on] tx [off | on] [threshold INTERFACE Control how the system responds to and
{<1-2047> <1-2013> <1-2013>}] generates 802.3x pause frames on 1 and 10Gig
line cards.
Defaults:
C-Series: rx off tx off
E-Series: rx on tx on
S-Series: rx off tx off
Parameters:
rx on: Enter the keywords rx on to process the received flow control frames
on this port.
rx off: Enter the keywords rx off to ignore the received flow control frames
on this port.
tx on: Enter the keywords tx on to send control frames from this port to the
connected device when a higher rate of traffic is received.
tx off: Enter the keywords tx off so that flow control frames are not sent
from this port to the connected device when a higher rate of traffic is received.
threshold (C-Series and S-Series only): When tx on is configured,
the user can set the threshold values for:
Number of flow-control packet pointers: 1-2047 (default = 75)
Flow-control buffer threshold in KB: 1-2013 (default = 49KB)
Flow-control discard threshold in KB: 1-2013 (default= 75KB)
Pause control is triggered when either the flow control buffer threshold
or flow control packet pointer threshold is reached.
452 | Interfaces
Configure MTU Size on an Interface
If a packet includes a Layer 2 header, the difference in bytes between the link MTU and IP MTU must be
large enough to include the Layer 2 header. For example, for VLAN packets, if the IP MTU is 1400 bytes,
the Link MTU must 1422 bytes or greater to accommodate the 22-byte VLAN header:
1400-byte IP MTU + 22-byte VLAN Tag = 1422-byte link MTU
On the E-Series and C-Series, you configure the Link MTU size on an interface by entering the mtu
command.
On the E-Series, you must manually configure the IP MTU size on an interface by entering the ip mtu
command. On the C-Series and S-Series, the IP MTU size is automatically configured on an interface by
taking into account the Layer 2 overheads and difference in the number of bytes as shown in Table 20-9.
Link MTU and IP MTU considerations for port channels and VLANs are as follows.
Port Channels:
• All members must have the same link MTU value and the same IP MTU value.
• The port channel link MTU and IP MTU must be less than or equal to the link MTU and IP MTU
values configured on the channel members.
Example: If the members have a link MTU of 2100 and an IP MTU 2000, the port channel’s MTU values
cannot be higher than 2100 for link MTU or 2000 bytes for IP MTU.
VLANs:
• All members of a VLAN must have the same IP MTU value.
• Members can have different Link MTU values. Tagged members must have a link MTU 4 bytes higher
than untagged members to account for the packet tag.
• The VLAN link MTU and IP MTU must be less than or equal to the link MTU and IP MTU values
configured on the VLAN members.
Example: The VLAN contains tagged members with Link MTU of 1522 and IP MTU of 1500 and
untagged members with Link MTU of 1518 and IP MTU of 1500. The VLAN’s Link MTU cannot be
higher than 1518 bytes and its IP MTU cannot be higher than 1500 bytes.
Interfaces | 453
Port-pipes
www.dell.com | support.dell.com
A port pipe is a Dell Force10 specific term for the hardware path that packets follow through a system. Port
pipes travel through a collection of circuits (ASICs) built into line cards and RPMs on which various
processing events for the packets occur. One or two port pipes process traffic for a given set of physical
interfaces or a port-set. The E300 only supports one port pipe per slot. On the E1200 and E600 each slot
has two port pipes with following specifications:
• 48 port line rate cards have two port pipes on the line card
• 48 port high density cards have only one port pipe on the line card
Note: All references to the E1200 in this section include the E1200i-AC and E1200i-DC. References to
E600 include the E600i.
For the purposes of diagnostics, the major difference between the E-Series platforms is the number of port
pipes per slot.
• E1200 and E600—Each slot has two port-pipes. Each portpipe has nine 3.125Gbps channels to the
backplane, one to each SFM.
• E300—Each slot has one portpipe. Each port-pipe has eight 3.125Gbps channels to the backplane,
with four channels to each SFM.
454 | Interfaces
Auto-Negotiation on Ethernet Interfaces
By default, auto-negotiation of speed and duplex mode is enabled on 10/100/1000 Base-T Ethernet
interfaces. Only 10GE interfaces do not support auto-negotiation. When using 10GE interfaces, verify that
the settings on the connecting devices are set to no auto-negotiation.
Note: Starting with FTOS 7.8.1.0, when a copper SFP2 module with catalog number GP-SFP2-1T is used
in the S25P model of the S-Series, its speed can be manually set with the speed command. When the
speed is set to 10 or 100 Mbps, the duplex command can also be executed.
The local interface and the directly connected remote interface must have the same setting, and
auto-negotiation is the easiest way to accomplish that, as long as the remote interface is capable of
auto-negotiation.
Note: As a best practice, Dell Force10 recommends keeping auto-negotiation enabled. Auto-negotiation
should only be disabled on switch ports that attach to devices not capable of supporting negotiation or
where connectivity issues arise from interoperability issues.
For 10/100/1000 Ethernet interfaces, the negotiation auto command is tied to the speed command.
Auto-negotiation is always enabled when the speed command is set to 1000 or auto.
To discover whether the remote and local interface require manual speed synchronization, and to manually
synchronize them if necessary, use the following command sequence (see Figure 20-35 on page 456):
1 Determine the local interface status. See show interfaces [interface | linecard EXEC Privilege
Figure 20-34. slot-number] status
2 Determine the remote interface status. [Use the command on the remote system EXEC
that is equivalent to the above command.] EXEC Privilege
5 Set the local port speed. speed {10 | 100 | 1000 | auto} INTERFACE
Interfaces | 455
www.dell.com | support.dell.com
Note: The show interfaces status command displays link status, but not administrative status. For link
and administrative status, use show ip interface [interface | brief | linecard slot-number]
[configuration].
In the example, above, several ports display “Auto” in the Speed field, including port 0/1. In Figure 20-35,
the speed of port 0/1 is set to 100Mb and then its auto-negotiation is disabled.
The negotiation auto command provides a mode option for configuring an individual port to forced
master/forced slave once auto-negotiation is enabled.
Caution: Ensure that only one end of the node is configured as forced-master and the other is configured as
forced-slave. If both are configured the same (that is both as forced-master or both as forced-slave), the show
interface command will flap between an auto-neg-error and forced-master/slave states.
456 | Interfaces
Figure 20-36. Setting Auto-Negotiation Options
FTOS(conf)# int gi 0/0
FTOS(conf-if)#neg auto
FTOS(conf-if-autoneg)# ?
For details on the speed, duplex, and negotiation auto commands, see the Interfaces chapter of the FTOS
Command Reference.
Use the keepalive command to change the time interval between keepalive messages on the interfaces. The
interface sends keepalive messages to itself to test network connectivity on the interface.
To change the default time interval between keepalive messages, use the following command:
To view the new setting, use the show config command in the INTERFACE mode.
Figure 20-37 lists the possible show commands that have the configured keyword available:
Interfaces | 457
Figure 20-37. show Commands with configured Keyword Examples
www.dell.com | support.dell.com
In EXEC mode, the show interfaces switchport command displays only interfaces in Layer 2 mode and
their relevant configuration information. The show interfaces switchport command (Figure 20-38)
displays the interface, whether the interface supports IEEE 802.1Q tagging or not, and the VLANs to
which the interface belongs.
Figure 20-38. show interfaces switchport Command Example
FTOS#show interfaces switchport
Name: GigabitEthernet 13/0
802.1QTagged: True
Vlan membership:
Vlan 2
Although any value between 30 and 299 seconds (the default) can be entered, software polling is done
once every 15 seconds. So, for example, if you enter “19”, you will actually get a sample of the past 15
seconds.
All LAG members inherit the rate interval configuration from the LAG.
Figure 20-39 shows how to configure rate interval when changing the default value:
458 | Interfaces
Figure 20-39. Configuring Rate Interval Example
FTOS#show interfaces
TenGigabitEthernet 10/0 is down, line protocol is down
Hardware is Force10Eth, address is 00:01:e8:01:9e:d9
Internet address is not set
MTU 1554 bytes, IP MTU 1500 bytes
LineSpeed 10000 Mbit
ARP type: ARPA, ARP Timeout 04:00:00
Last clearing of "show interface" counters 1d23h44m
Queueing strategy: fifo
0 packets input, 0 bytes
Input 0 IP Packets, 0 Vlans 0 MPLS
0 64-byte pkts, 0 over 64-byte pkts, 0 over 127-byte pkts
0 over 255-byte pkts, 0 over 511-byte pkts, 0 over 1023-byte pkts
Received 0 input symbol errors, 0 runts, 0 giants, 0 throttles
0 CRC, 0 IP Checksum, 0 overrun, 0 discarded
0 packets output, 0 bytes, 0 underruns
Output 0 Multicasts, 0 Broadcasts, 0 Unicasts
0 IP Packets, 0 Vlans, 0 MPLS
0 throttles, 0 discarded Default value of
Rate info (interval 299 seconds):
Input 00.00 Mbits/sec, 0 packets/sec, 0.00% of line-rate
299 seconds
Output 00.00 Mbits/sec, 0 packets/sec, 0.00% of line-rate
Time since last interface status change: 1d23h40m
Interfaces | 459
Dynamic Counters
www.dell.com | support.dell.com
For remaining applications, FTOS automatically turns on counting when the application is enabled, and is
turned off when the application is disabled. Please note that if more than four counter-dependent
applications are enabled on a port pipe, there is an impact on line rate performance.
460 | Interfaces
Clear interface counters
The counters in the show interfaces command are reset by the clear counters command. This command
does not clear the counters captured by any SNMP program.
To clear the counters, use the following command in the EXEC Privilege mode:
clear counters [interface] EXEC Privilege Clear the counters used in the show interface commands for all VRRP
[vrrp [{[ipv6] vrid | vrf groups, VLANs, and physical interfaces or selected ones.
instance}] | learning-limit] Without an interface specified, the command clears all interface counters.
(OPTIONAL) To clear counters on a specified interface, enter one of the
following keywords and slot/port or number:
• For a 1-Gigabit Ethernet interface, enter the keyword
GigabitEthernet followed by the slot/port information.
• For a Loopback interface, enter the keyword loopback followed by
a number from 0 to 16383.
• For a Port Channel interface, enter the keyword port-channel
followed by a number from 1 to 255 for TeraScale and ExaScale, 1 to
32 for EtherScale.
• For the management interface on the RPM, enter the keyword
ManagementEthernet followed by slot/port information. The slot
range is 0-1, and the port range is 0.
• For a SONET interface, enter the keyword sonet followed by the
slot/port information.
• For a 10-Gigabit Ethernet interface, enter the keyword
TenGigabitEthernet followed by the slot/port information.
• For a VLAN, enter the keyword vlan followed by a number from 1 to
4094
E-Series ExaScale platforms support 4094 VLANs with FTOS
version 8.2.1.0 and later. Earlier ExaScale supports 2094
VLANS.
(OPTIONAL) Enter the keyword vrrp to clear the counters of all VRRP
groups. To clear the counters of VRRP groups on all IPv6 interfaces,
enter vrrp ipv6. To clear the counters of a specified VRRP group, enter a
vrid number from 1 to 255.
E-Series only: To clear the counters of VRRP groups in a specified VRF
instance, enter vrrp vrf instance (32 characters maximum).
(OPTIONAL) Enter the keyword learning-limit to clear unknown
source address (SA) drop counters when MAC learning limit is
configured on the interface.
When you enter this command, you must confirm that you want FTOS to clear the interface counters for
that interface (Figure 20-40).
Interfaces | 461
www.dell.com | support.dell.com
462
|
Interfaces
21
IPv4 Addressing
IPv4 Addressing is supported on platforms ces
IPv4 addressing is supported on the E-Series ExaScale platform with FTOS 8.1.1.0 and later.
FTOS supports various IP addressing features. This chapter explains the basics of Domain Name Service
(DNS), Address Resolution Protocol (ARP), and routing principles and their implementation in FTOS.
Table 21-1 lists the defaults for the IP addressing features described in this chapter.
IP Feature Default
DNS Disabled
Directed Broadcast Disabled
Proxy ARP Enabled
ICMP Unreachable Disabled
ICMP Redirect Disabled
IP Addresses
FTOS supports IP version 4, as described in RFC 791. It also supports classful routing and Variable Length
Subnet Masks (VLSM). With VLSM one network can be can configured with different masks.
Supernetting, which increases the number of subnets, is also supported. Subnetting is when a mask is
added to the IP address to separate the network and host portions of the IP address.
00001010110101100101011110000011
is represented as 10.214.87.131
Implementation Information
In FTOS, you can configure any IP address as a static route except IP addresses already assigned to
interfaces.
Note: FTOS versions 7.7.1.0 and later support 31-bit subnet masks (/31, or 255.255.255.254) as defined by
RFC 3021. This feature allows you to save two more IP addresses on point-to-point links than 30-bit masks.
FTOS supports RFC 3021 with ARP.
For a complete listing of all commands related to IP addressing, refer to FTOS Command Line Interface
Reference.
1 interface interface CONFIGURATION Enter the keyword interface followed by the type of
interface and slot/port information:
• For a 1-Gigabit Ethernet interface, enter the keyword
GigabitEthernet followed by the slot/port information.
• For a Loopback interface, enter the keyword loopback
followed by a number from 0 to 16383.
• For the Management interface on the RPM, enter the
keyword ManagementEthernet followed by the slot/
port information. The slot range is 0-1 and the port range
is 0.
• For a port channel interface, enter the keyword
port-channel followed by a number from 1 to 255 for
TeraScale and ExaScale, 1 to 32 for EtherScale.
• For a SONET interface, enter the keyword sonet
followed by the slot/port information.
• For a 10-Gigabit Ethernet interface, enter the keyword
TenGigabitEthernet followed by the slot/port
information.
• For a VLAN interface, enter the keyword vlan followed
by a number from 1 to 4094.
E-Series ExaScale platforms support 4094 VLANs
with FTOS version 8.2.1.0 and later. Earlier
ExaScale supports 2094 VLANS.
3 ip address ip-address INTERFACE Configure a primary IP address and mask on the interface.
mask [secondary] • ip-address mask: IP address must be in dotted decimal
format (A.B.C.D) and the mask must be in slash
prefix-length format (/24).
Add the keyword secondary if the IP address is the
interface’s backup IP address. You can configure up to eight
secondary IP addresses.
To view the configuration, use the show config command (Figure 246) in the INTERFACE mode or show
ip interface in the EXEC privilege mode (Figure 247).
Figure 21-1. show config Command Example in the INTERFACE Mode
FTOS(conf-if)#show conf
!
interface GigabitEthernet 0/0
ip address 10.11.1.1/24
no shutdown
!
FTOS(conf-if)#
FTOS#
A static route is an IP address that is manually configured and not learned by a routing protocol, such as
OSPF. Often static routes are used as backup routes in case other dynamically learned routes are
unreachable.
To configure a static route, use the following command in the CONFIGURATION mode:
ip route ip-address mask {ip-address | CONFIGURATION Configure a static IP address. Use the following
interface [ip-address]} [distance] required and optional parameters:
[permanent] [tag tag-value] • ip-address: Enter an address in dotted decimal
format (A.B.C.D).
• mask: Enter a mask in slash prefix-length
format (/X).
• interface: Enter an interface type followed by
slot/port information.
• distance range: 1 to 255 (optional).
• permanent: Keep the static route in the
routing table (if interface option is used) even if
the interface with the route is disabled.
(optional)
• tag tag-value range: 1 to 4294967295.
(optional)
To view the configured routes, use the show ip route static command.
FTOS installs a next hop that is on the directly connected subnet of current IP address on the interface (for
example, if interface gig 0/0 is on 172.31.5.0 subnet, FTOS installs the static route).
FTOS also installs a next hop that is not on the directly connected subnet but which recursively resolves to
a next hop on the interface's configured subnet. For example, if gig 0/0 has ip address on subnet 2.2.2.0 and
if 172.31.5.43 recursively resolves to 2.2.2.0, FTOS installs the static route.
When an IP address used by a protocol and a static management route exists for the same prefix, the
protocol route takes precedence over the static management route.
To configure a static route for the management port, use the following command in the
CONFIGURATION mode:
management route ip-address mask CONFIGURATION Assign a static route to point to the management
{forwarding-router-address | interface or forwarding router.
ManagementEthernet slot/port}
FTOS>show ip management-route
FTOS>
Directed Broadcast
By default, FTOS drops directed broadcast packets destined for an interface. This default setting provides
some protection against Denial of Service (DOS) attacks.
To enable FTOS to receive directed broadcasts, use the following command in the INTERFACE mode:
To view the configuration, use the show config command in the INTERFACE mode.
Dynamic resolution of host names is disabled by default. Unless the feature is enabled, the system resolves
only host names entered into the host table with the ip host or ipv6 host command.
ip name-server ipv4-address CONFIGURATION Specify up to 6 IPv4 or IPv6 name servers. The order you
[ipv4-address2 ... ipv4-address6] entered the servers determines the order of their use. You
may have IPv4 and IPv6 name servers configured at the
ipv6 name-server ipv6-address same time.
[ipv6-address2 ... ipv6-address6]
FTOS>show host
Default domain is force10networks.com
Name/address lookup uses domain service
Name servers are not set
Host Flags TTL Type Address
-------- ----- ---- ---- -------
ks (perm, OK) - IP 2.2.2.2
patch1 (perm, OK) - IP 192.68.69.2
tomm-3 (perm, OK) - IP 192.68.99.2
gxr (perm, OK) - IP 192.71.18.2
f00-3 (perm, OK) - IP 192.71.23.1
FTOS>
To view the current configuration, use the show running-config resolve command.
If you enter a partial domain, FTOS can search different domains to finish or fully qualify that partial
domain. A fully qualified domain name (FQDN) is any name that is terminated with a period/dot. FTOS
searches the host table first to resolve the partial domain. The host table contains both statically configured
and dynamically learnt host and IP addresses. If FTOS cannot resolve the domain, it tries the domain name
assigned to the local system. If that does not resolve the partial domain, FTOS searches the list of domains
configured
To configure a domain name, use the following command in the CONFIGURATION mode:
ip domain-name name CONFIGURATION Configure one domain name for the E-Series
To configure a list of domain names, use the following command in the CONFIGURATION mode:
To configure your switch to perform DNS with traceroute, follow the steps below in the
CONFIGURATION mode.
ip name-server ipv4-address CONFIGURATION Specify up to 6 IPv4 or IPv6 name servers. The order you
[ipv4-address2 ... ipv4-address6] entered the servers determines the order of their use. You
may have IPv4 and IPv6 name servers configured at the
ipv6 name-server ipv6-address same time.
[ipv6-address2 ... ipv6-address6]
traceroute [host | ipv4-address | CONFIGURATION When you enter the traceroute command without
ipv6-address] specifying an IP address (Extended Traceroute), you are
prompted for a target and source IP address, timeout in
seconds (default is 5), a probe count (default is 3),
minimum TTL (default is 1), maximum TTL (default is
30), and port number (default is 33434). To keep the
default setting for those parameters, press the ENTER key.
------------------------------------------------------------------------------------------
Tracing the route to www.force10networks.com (10.11.84.18), 30 hops max, 40 byte packets
------------------------------------------------------------------------------------------
Address Resolution Protocol (ARP) runs over Ethernet and enables endstations to learn the MAC
addresses of neighbors on an IP network. Over time, FTOS creates a forwarding table mapping the MAC
addresses to their corresponding IP address. This table is called the ARP Cache and dynamically learned
addresses are removed after a defined period of time.
For more information on ARP, see RFC 826, An Ethernet Address Resolution Protocol.
In FTOS, Proxy ARP enables hosts with knowledge of the network to accept and forward packets from
hosts that contain no knowledge of the network. Proxy ARP makes it possible for hosts to be ignorant of
the network, including subnetting.
For more information on Proxy ARP, refer to RFC 925, Multi-LAN Address Resolution, and RFC 1027, Using
ARP to Implement Transparent Subnet Gateways.
For a complete listing of all ARP-related commands, refer to the FTOS Command Line Reference Guide.
ARP dynamically maps the MAC and IP addresses, and while most network host support dynamic
mapping, you can configure an ARP entry (called a static ARP) for the ARP cache.
To configure a static ARP entry, use the following command in the CONFIGURATION mode:
arp ip-address mac-address interface CONFIGURATION Configure an IP address and MAC address mapping
for an interface.
• ip-address: IP address in dotted decimal format
(A.B.C.D).
• mac-address: MAC address in nnnn.nnnn.nnnn
format
• interface: enter the interface type slot/port
information.
These entries do not age and can only be removed manually. To remove a static ARP entry, use the no arp
ip-address command syntax.
To view the static entries in the ARP cache, use the show arp static command (Figure 253) in the EXEC
privilege mode.
Figure 21-7. show arp static Command Example
FTOS#show arp
By default, Proxy ARP is enabled. To disable Proxy ARP, use no proxy-arp command in the interface
mode.
To re-enable Proxy ARP, use the following command in the INTERFACE mode:
To view if Proxy ARP is enabled on the interface, use the show config command in the INTERFACE
mode. If it is not listed in the show config command output, it is enabled. Only nondefault information is
displayed in the show config command output.
To clear the ARP cache of dynamically learnt ARP information, use the following command in the EXEC
privilege mode:
clear arp-cache [interface | ip EXEC privilege Clear the ARP caches for all interfaces or for a specific
ip-address] [no-refresh] interface by entering the following information:
• For a 1-Gigabit Ethernet interface, enter the keyword
GigabitEthernet followed by the slot/port information.
• For a port channel interface, enter the keyword
port-channel followed by a number from 1 to 255 for
TeraScale and ExaScale, 1 to 32 for EtherScale.
• For a SONET interface, enter the keyword sonet
followed by the slot/port information.
• For a 10-Gigabit Ethernet interface, enter the keyword
TenGigabitEthernet followed by the slot/port
information.
• For a VLAN interface, enter the keyword vlan followed
by a number between 1 and 4094.
E-Series ExaScale platforms support 4094 VLANs
with FTOS version 8.2.1.0 and later. Earlier
ExaScale supports 2094 VLANS.
ip ip-address (OPTIONAL) Enter the keyword ip followed by
the IP address of the ARP entry you wish to clear.
no-refresh (OPTIONAL) Enter the keyword no-refresh to
delete the ARP entry from CAM. Or use this option with interface
or ip ip-address to specify which dynamic ARP entries you
want to delete.
Note: Transit traffic may not be forwarded during the period
when deleted ARP entries are resolved again and re-installed
in CAM. Use this option with extreme caution.
In the request, the host uses its own IP address in the Sender Protocol Address and Target Protocol Address
fields.
In FTOS versions prior to 8.3.1.0, if a gratuitous ARP is received some time after an ARP request is sent,
only RP2 installs the ARP information. For example:
CPUs.
If the Target IP does not match the incoming interface, then the packet is dropped. If there is an existing
entry for the requesting host, it is updated.
ARP Request
X
Target IP: 1.1.1.3
Beginning with FTOS version 8.3.1.0, when ARP Learning via Gratuitous ARP is enabled, the system
installs a new ARP entry, or updates an existing entry for all received ARP requests.
ARP Request
X
Target IP: 1.1.1.3
Whether ARP Learning via Gratuitous ARP is is enabled or disabled, the system does not look up the
Target IP. It only updates the ARP entry for the Layer 3 interface with the source IP of the request.
Display all ARP entries learned via gratuitous ARP. show arp retries EXEC Privilege
FTOS Behavior: Due to ARP Pruning, the total number of ARP requests sent might exceed, but is
never less than, the configured number of ARP retries. This occurs when the ARP Pruning timer
expires while ARP retry is in progress.
ARP Pruning is a mechanism that clears stale entries every 1 minute. A stale entry is an IP address for which
either the ARP expiry timer—which by default is set to 4 hours—expires, or ARP cannot resolve an IP address.
When there is a coincidence between an ARP Pruning timer expiry and the ARP retry mechanism FTOS sends
more than the configured number of ARP requests. To illustrate why this occurs, take a time T1=0 seconds, at
which point the pruning timer starts. At time T2=55 seconds, when the pruning timer is 55 seconds, suppose the
ARP retry for an unresolved address begins, with ARP retry configured for 20 retries. By time T3=60 seconds,
the total number of ARP requests sent is 5. However, at T3, the pruning timer expires and clears all stale entries,
including the entry for which ARP retry is in progress. In this case, ARP retry starts over and sends another 20
ARP request over 20 seconds. As a result, the total number of ARP requests sent is 25, not the configured 20.
ICMP
For diagnostics, Internet Control Message Protocol (ICMP) provide routing information to end stations by
choosing the best route (ICMP redirect messages) or determining if a router is reachable (ICMP Echo or
Echo Reply). ICMP Error messages inform the router of problems in a particular packet. These messages
are sent only on unicast traffic
See the FTOS Command Line Reference Guide for a complete listing of all commands related to ICMP.
By default, ICMP unreachable messages are disabled. When enabled ICMP unreachable messages are
created and sent out all interfaces. To disable ICMP unreachable messages, use the no ip unreachable
command.
To reenable the creation of ICMP unreachable messages on the interface, use the following command in
the INTERFACE mode:
To view if ICMP unreachable messages are sent on the interface, use the show config command in the
INTERFACE mode. If it is not listed in the show config command output, it is enabled. Only nondefault
information is displayed in the show config command output.
To reenable the creation of ICMP redirect messages on the interface, use the following command in the
INTERFACE mode:
ip redirect INTERFACE Set FTOS to create and send ICMP redirect messages on
the interface.
To view if ICMP redirect messages are sent on the interface, use the show config command in the
INTERFACE mode. If it is not listed in the show config command output, it is enabled. Only nondefault
information is displayed in the show config command output.
UDP Helper
UDP helper allows you to direct the forwarding IP/UDP broadcast traffic by creating special broadcast
addresses and rewriting the destination IP address of packets to match those addresses. Configurations
using this feature are described in the section Configurations Using UDP Helper on page 478.
1. Enable UDP helper and specify the UDP ports for which traffic is forwarded. See Enabling UDP
Helper on page 477.
2. Configure a broadcast address on interfaces that will receive UDP broadcast traffic. See Configuring a
Broadcast Address on page 478.
View the interfaces and ports on which UDP helper is enabled using the command show ip udp-helper from
EXEC Privilege mode, as shown in Figure 21-11.
View the configured broadcast address for an interface using the command show interfaces, as shown in
Figure 21-13.
In Figure 21-14:
Packet 2, sent from a host on VLAN 101 has a broadcast MAC address and IP address. In this case:
1. It is flooded on VLAN 101 without changing the destination address because the forwarding process is
Layer 2.
2. If UDP helper is enabled, the system changes the destination IP address to the configured broadcast
address 1.1.255.255 and forwards the packet to VLAN 100.
3. Packet 2 is also forwarded to the ingress interface with an unchanged destination address because it
does not have broadcast address configured.
Figure 21-14. UDP helper with All Broadcast Addresses
VLAN 100
IP address: 1.1.0.1/24
Packet 1 Subnet broadcast address: 1.1.0.255
Configured broadcast address: 1.1.255.255
Destination Address: Hosts on VLAN 100: 1.1.0.2, 1.1.0.3, 1.1.0.4
255.255.255.255
1/1 1/2
Ingress interface
1/3
IP Address: 2.1.1.1/24
UDP helper enabled
VLAN 101
IP address: 1.11.1/24
Subnet broadcast address: 1.1.1.255
Packet 2 Configured broadcast address: 1.1.255.255
Switched Packet Hosts on VLAN 100: 1.1.1.2, 1.1.1.3, 1.1.1.4
address of VLAN 101. If UDP helper is configured and the packet matches the specified UDP port, then
the system changes the address to the configured IP broadcast address and floods the packet on VLAN
101.
Packet 2 is sent from host on VLAN 101. It has a broadcast MAC address and a destination IP address of
1.1.1.255. In this case, it is flooded on VLAN 101 in its original condition as the forwarding process is
Layer 2.
Preamble Start Frame Destination MAC Source MAC Ethernet Type LLDPDU Padding FCS
Delimiter (01:80:C2:00:00:0E) (0x88CC)
TLV 1 TLV 2 TLV 3 TLV 4 TLV 5 TLV 6 TLV 7 TLV 127 TLV 0
Chassis ID Port ID Port Description System Name System Description System Capabilities Management Addr Organizationally Specific End of LLDPDU
In Figure 21-16, Packet 1 has a destination IP address that matches the configured broadcast address of
VLAN 100 and 101. If UDP helper is enabled and the UDP port number matches, the packet is flooded on
both VLANs with an unchanged destination address.
Packet 2 is sent from a host on VLAN 101. It has broadcast MAC address and a destination IP address that
matches the configured broadcast address on VLAN 101. In this case, Packet 2 is flooded on VLAN 101
with the destination address unchanged because the forwarding process is Layer 2. If UDP helper is
enabled, the packet is flooded on VLAN 100 as well.
1/1 1/2
Ingress interface
1/3
IP Address: 2.1.1.1/24
UDP helper enabled
VLAN 101
IP address: 1.11.1/24
Subnet broadcast address: 1.1.1.255
Packet 2 Configured broadcast address: 1.1.255.255
Switched Packet Hosts on VLAN 100: 1.1.1.2, 1.1.1.3, 1.1.1.4
Destination Address:
1.1.255.255 fnC0048mp
Use the command debug ip dhcp when using the IP helper and UDP helper on the same interface, as shown
in Figure 21-18.
482
|
IPv4 Addressing
22
IPv6 Addressing
IPv6 Addressing is supported on platforms: ces
Note: The basic IPv6 commands are supported on all platforms. However, not all IPv6-based features are
supported on all platforms and on all releases. Refer to Table 22-2 to see which FTOS version supports
an IPv6 feature on each platform.
IPv6 (Internet Protocol Version 6) is the successor to IPv4. Due to the extremely rapid growth in internet
users, and IP addresses, IPv4 is reaching its maximum usage. IPv6 will eventually replace IPv4 usage to
allow for the constant expansion.
This chapter provides a brief discussion of the differences between IPv4 and IPv6, and the Dell Force10
support of IPv6. This chapter discusses the following, but is not intended to be a comprehensive discussion
of IPv6.
Protocol Overview
IPv6 is an evolution of IPv4. IPv6 is generally installed as an upgrade in devices and operating systems.
Most new devices and operating systems support both IPv4 and IPv6.
Stateless Autoconfiguration
When a booting device comes up in IPv6 and asks for its network prefix, the device can get the prefix (or
prefixes) from an IPv6 router on its link. It can then autoconfigure one or more global IP addresses by
using either the MAC address or a private random number to build its unique IP address.
• Prefix Advertisement - Routers use "Router Advertisement" messages to announce the Network
Prefix. Hosts then use their interface-identifier MAC address to generate their own valid IPv6 address.
• Duplicate Address Detection (DAD) - Before configuring its IPv6 address, an IPv6 host node device
checks whether that address is used anywhere on the network using this mechanism.
• Prefix Renumbering - Useful in transparent renumbering of hosts in the network when an organization
changes its service provider.
Note: As an alternative to stateless auto-configuration, network hosts can obtain their IPv6
addresses using Dynamic Host Control Protocol (DHCP) servers via stateful auto-configuration.
Note: FTOS provides the flexibility to add prefixes to advertise responses to RS messages. By
default the RA response messages are not sent when an RS message is received. Enable the RA
response messages with the ipv6 nd prefix default command in INTERFACE mode.
FTOS manipulation of IPv6 stateless auto-configuration supports the router side only. Neighbor Discovery
(ND) messages are advertised so the neighbor can use this information to auto-configure its address.
However, received Neighbor Discovery (ND) messages are not used to create an IPv6 address.
The router redistribution functionality in Neighbor Discovery Protocol (NDP) is similar to IPv4 router
redirect messages. Neighbor Discovery Protocol (NDP) uses ICMPv6 redirect messages (Type 137) to
inform nodes that a better router exists on the link.
• Version (4 bits)
• Traffic Class (8 bits)
• Flow Label (20 bits)
• Payload Length (16 bits)
• Next Header (8 bits)
• Hop Limit (8 bits)
• Source Address (128 bits)
• Destination Address (128 bits)
IPv6 provides for Extension Headers. Extension Headers are used only if necessary. There can be no
extension headers, one extension header or more than one extension header in an IPv6 packet. Extension
Headers are defined in the Next Header field of the preceding IPv6 header. IPv6 header fields
The 40 bytes of the IPv6 header are ordered as show in Figure 22-1.
192
Destination Address
320
Version (4 bits)
The Version field always contains the number 6, referring to the packet’s IP version.
The Traffic Class field deals with any data that needs special handling. These bits define the packet priority
and are defined by the packet Source. Sending and forwarding routers use this field to identify different
IPv6 classes and priorities. Routers understand the priority settings and handle them appropriately during
conditions of congestion.
The Flow Label field identifies packets requiring special treatment in order to manage real-time data
traffic. The sending router can label sequences of IPv6 packets so that forwarding routers can process
packets within the same flow without needing to reprocess each packet’s head separately.
Note: All packets in the flow must have the same source and destination addresses.
The Payload Length field specifies the packet payload. This is the length of the data following the IPv6
header. IPv6 Payload Length only includes the data following the header, not the header itself.
The Payload Length limit of 2 bytes requires that the maximum packet payload be 64 KB. However, the
Jumbogram option type Extension header supports larger packet sizes when required.
The Next Header field identifies the next header’s type. If an Extension header is used, this field contains
the type of Extension header (Table 22-1). If the next header is a TCP or UDP header, the value in this field
is the same as for IPv4. The Extension header is located between the IP header and the TCP or UDP
header.
Value Description
0 Hop-by Hop option header following
4 IPv4
6 TCP
8 Exterior Gateway Protocol (EGP)
41 IPv6
43 Routing header
44 Fragmentation header
50 Encrypted Security
51 Authentication header
Value Description
59 No Next Header
60 Destinations option header
Note: This is not a comprehensive table of Next Header field values. Refer to the Internet
Assigned Numbers Authority (IANA) web page http://www.iana.org/assignments/protocol-numbers
for a complete and current listing.
The Hop Limit field shows the number of hops remaining for packet processing. In IPv4, this is known as
the Time to Live (TTL) field and uses seconds rather than hops.
Each time the packet moves through a forwarding router, this field decrements by 1. If a router receives a
packet with a Hop Limit of 1, it decrements it to 0 (zero). The router discards the packet and sends an
ICMPv6 message back to the sending router indicating that the Hop Limit was exceeded in transit.
The Source Address field contains the IP address for the packet originator.
The Destination Address field contains the intended recipient’s IP address. This can be either the ultimate
destination or the address of the next hop router.
Each extension header is identified by the Next Header field in the IPv6 header that precedes it. Extension
headers are viewed only by the destination router identified in the Destination Address field. If the
Destination Address is a multicast address, the Extension headers are examined by all the routers in that
multicast group.
However, if the Destination Address is a Hop-by-Hop options header, the Extension header is examined
bye every forwarding router along the packet’s route. The Hop-by-Hop options header must immediately
follow the IPv6 header, and is noted by the value 0 (zero) in the Next Header field (Table 22-1).
Extension headers are processed in the order in which they appear in the packet header.
The Hop-by-Hop options header contains information that is examined by every router along the packet’s
path. It follows the IPv6 header and is designated by the Next Header value 0 (zero) (Table 22-1).
When a Hop-by-Hop Options header is not included, the router knows that it does not have to process any
router specific information and immediately processes the packet to its final destination.
When a Hop-by-Hop Options header is present, the router only needs this extension header and does not
need to take the time to view further into the packet.
Addressing
IPv6 addresses are normally written as eight groups of four hexadecimal digits, where each group is
separated by a colon (:). For example, 2001:0db8:0000:0000:0000:0000:1428:57ab is a valid IPv6 address.
If one or more four-digit group(s) is 0000, the zeros may be omitted and replaced with two colons(::). For
example, 2001:0db8:0000:0000:0000:0000:1428:57ab can be shortened to 2001:0db8::1428:57ab. Only
one set of double colons is supported in a single address. Any number of consecutive 0000 groups may be
reduced to two colons, as long as there is only one double colon used in an address. Leading zeros in a group
can also be omitted (as in ::1 for localhost).
All the addresses in the following list are all valid and equivalent.
IPv6 networks are written using Classless Inter-Domain Routing (CIDR) notation. An IPv6 network (or
subnet) is a contiguous group of IPv6 addresses the size of which must be a power of two; the initial bits of
addresses, which are identical for all hosts in the network, are called the network's prefix.
A network is denoted by the first address in the network and the size in bits of the prefix (in decimal),
separated with a slash. Since a single host is seen as a network with a 128-bit prefix, host addresses may be
written with a following /128.
Link-local Addresses
Link-local addresses, starting with fe80:, are assigned only in the local link area. The addresses are
generated usually automatically by the operating system's IP layer for each network interface. This
provides instant automatic network connectivity for any IPv6 host and means that if several hosts connect
to a common hub or switch, they have an instant communication path via their link-local IPv6 address. .
Static IP addresses are manually assigned to a computer by an administrator. Dynamic IP addresses are
assigned either randomly or by a server using Dynamic Host Configuration Protocol (DHCP). Even though
IP addresses assigned using DHCP may stay the same for long periods of time, they can change. In some
cases, a network administrator may implement dynamically assigned static IP addresses. In this case, a
DHCP server is used, but it is specifically configured to always assign the same IP address to a particular
computer, and never to assign that IP address to another computer. This allows static IP addresses to be
configured in one place, without having to specifically configure each computer on the network in a
different way.
In IPv6, every interface, whether using static or dynamic address assignments, also receives a local-link
address automatically in the fe80::/64 subnet.
FTOS supports both IPv4 and IPv6, and both may be used simultaneously in your system.
Note: Dell Force10 recommends that you use FTOS version 7.6.1.0 or later when implementing
IPv6 functionality on an E-Series system.
Table 22-2 lists the FTOS Version in which an IPv6 feature became available for each platform. The
sections following the table give some greater detail about the feature. Specific platform support for each
feature or functionality is designated by the c e s symbols.
Note: When both E-Series TeraScale and ExaScale are supported, only the e symbol is shown. If a
feature is supported by one or the other chassis, the specific symbols are shown: e tfor E-Series
TeraScale or ex for E-Series ExaScale.
Feature and/or
Functionality FTOS Release Introduction Documentation and Chapter Location
E-Series E-Series
TeraScale ExaScale C-Series S-Series
Basic IPv6 Commands 7.4.1 8.2.1 7.8.1 7.8.1 IPv6 Basic Commands in the FTOS Command
Line Interface Reference Guide
IPv6 Basic Addressing
IPv6 address types: 7.4.1 8.2.1 7.8.1 7.8.1 Extended Address Space in this chapter
Unicast
IPv6 neighbor discovery 7.4.1 8.2.1 7.8.1 7.8.1 IPv6 Neighbor Discovery in this chapter
IPv6 stateless 7.4.1 8.2.1 7.8.1 7.8.1 Stateless Autoconfiguration in this chapter
autoconfiguration
IPv6 MTU path 7.4.1 8.2.1 7.8.1 7.8.1 Path MTU Discovery in this chapter
discovery
IPv6 ICMPv6 7.4.1 8.2.1 7.8.1 7.8.1 ICMPv6 in this chapter
IPv6 ping 7.4.1 8.2.1 7.8.1 7.8.1 ICMPv6 in this chapter
IPv6 traceroute 7.4.1 8.2.1 7.8.1 7.8.1 ICMPv6 in this chapter
IPv6 Routing
Static routing 7.4.1 8.2.1 7.8.1 7.8.1 Assign a Static IPv6 Route in this chapter
Route redistribution 7.4.1 8.2.1 7.8.1 8.4.2 OSPF, IS-IS, and IPv6 BGP chapters in the
FTOS Command Line Reference Guide
Multiprotocol BGP 7.4.1 8.2.1 7.8.1 8.4.2 IPv6 BGP in the FTOS Command Line
extensions for IPv6 Reference Guide
IPv6 BGP MD5 8.2.1.0 8.2.1.0 8.2.1.0 8.4.2 IPv6 BGP in the FTOS Command Line
Authentication Reference Guide
IS-IS for IPv6 7.5.1 8.2.1 8.4.2 8.4.2 Chapter 23, “Intermediate System to
Intermediate System,” on page 507 in the
FTOS Configuration Guide
PIM-SSM for IPv6 7.5.1 8.2.1 8.4.2 8.4.2 IPv6 Multicast in this chapter
ICMPv6
ICMPv6 is supported on platforms ces
ICMP for IPv6 combines the roles of ICMP, IGMP and ARP in IPv4. Like IPv4, it provides functions for
reporting delivery and forwarding errors, and provides a simple echo service for troubleshooting. The
FTOS implementation of ICMPv6 is based on RFC 2463.
• Error reporting messages indicate when the forwarding or delivery of the packet failed at the
destination or intermediate node. These messages include Destination Unreachable, Packet Too Big,
Time Exceeded and Parameter Problem messages.
• Informational messages provide diagnostic functions and additional host functions, such as Neighbor
Discovery and Multicast Listener Discovery. These messages also include Echo Request and Echo
Reply messages.
The FTOS ping and traceroute commands extend to support IPv6 addresses. These commands use ICMPv6
Type-2 messages.
The recommended MTU for IPv6 is 1280. Greater MTU settings increase processing efficiency because
each packet carries more data while protocol overheads (headers, for example) or underlying per-packet
delays remain fixed.
Router A Router B
ICMPv6 (Type 2)
Use MTU = 1400
ICMPv6 (Type 2)
Use MTU = 1200
Packet Received
With ARP, each node broadcasts ARP requests on the entire link. This approach causes unnecessary
processing by uninterested nodes. With NDP, each node sends a request only to the intended destination
via a multicast address with the unicast address used as the last 24 bits. Other hosts on the link do not
participate in the process, greatly increasing network bandwidth efficiency.
Router C
Network 2001:db8::1428:57ab
Send a Packet to
Network 2001:db8::1428:57ab
Router A
Router B
Local Link
Refer to Chapter 41, Quality of Service for details. Refer also to the Honor DSCP values on ingress
packets in the QoS chapter for information relating to the trust diffserv command.
IPv6 Multicast
IPv6 Multicast is supported on platforms: ces
FTOS supports the following protocols to implement IPv6 multicast routing:
• Multicast Listener Discovery Protocol (MLD). MLD on a multicast router sends out periodic general
MLD queries that the switch forwards through all ports in the VLAN. There are two versions of MLD:
MLD version 1 is based on version 2 of the Internet Group Management Protocol (IGMP) for IPv4,
and MLD version 2 is based on version 3 of the IGMP for IPv4. IPv6 multicast for FTOS supports
versions 1 and 2
• PIM-SM. Protocol-Independent Multicast-Sparse Mode (PIM-SM) is a multicast protocol in which
multicast receivers explicitly join to receive multicast traffic. The protocol uses a router as the root or
Rendezvous Point (RP) of the share tree distribution tree to distribute multicast traffic to a multicast
group. Messages to join the multicast group (Join messages) are sent towards the RP and data is sent
from senders to the RP so receivers can discover who are the senders and begin receiving traffic
destined to the multicast group.
• PIM in Source Specific Multicast (PIM-SSM). PIM-SSM protocol is based on the source specific
model for forwarding Multicast traffic across multiple domains on the Internet. It is restricted to
shortest path trees (SPTs) to specific sources described by hosts using MLD. PIM-SSM is essentially a
subset of PIM-SM protocol, which has the capability to join SPTs. The only difference being register
states and shared tree states for Multicast groups in SSM range are not maintained. End-hosts use
MLD to register their interest in a particular source-group (S,G) pair. PIM-SSM protocol interacts with
MLD to construct the multicast forwarding tree rooted at the source S.
Refer to FTOS Command Line Interface Reference document chapters Multicast IPv6, and Protocol
Independent Multicast (IPv6) for configuration details.
Refer to the Security Commands chapter in the FTOS Command Line Interface Reference document for SSH
configuration details.
cam-profile ipv6-extacl EXEC Privileged Enable the CAM profile with IPv6 extended ACLs
microcode ipv6-extacl chassis on the entire chassis or on a specific linecard
| linecard slot chassis changes the CAM profile for all linecards
in the chassis
linecard slot/port changes the CAM profile only
for the specified slot
Figure 22-4 displays the IPv6 CAM profile summary for a chassis that already has IPv6 CAM profile
configured. Figure 22-5 shows the full IPv6 CAM profiles. Refer to Chapter 11, Content Addressable
Memory, on page 281 for complete information regarding CAM configuration.
-- Line card 1 --
: Current Settings : Next Boot
Profile Name : IPV6-ExtACL : IPV6-ExtACL
MicroCode Name : IPv6-ExtACL : IPv6-ExtACL
FTOS#
CamSize : 18-Meg
: Current Settings : Next Boot
Profile Name : IPV6-ExtACL : IPV6-ExtACL
L2FIB : 32K entries : 32K entries
L2ACL : 1K entries : 1K entries
IPv4FIB : 192K entries : 192K entries
IPv4ACL : 12K entries : 12K entries
IPv4Flow : 8K entries : 8K entries
EgL2ACL : 1K entries : 1K entries
EgIPv4ACL : 1K entries : 1K entries
Reserved : 2K entries : 2K entries
IPv6FIB : 6K entries : 6K entries
IPv6ACL : 3K entries : 3K entries
IPv6Flow : 4K entries : 4K entries
EgIPv6ACL : 1K entries : 1K entries
MicroCode Name : IPv6-ExtACL : IPv6-ExtACL
-- Line card 1 --
CamSize : 18-Meg
: Current Settings : Next Boot
--More--
The CAM space is allotted in FP blocks. The total space allocated must equal 13 FP blocks. Note that there
are 16 FP blocks, but the System Flow requires 3 blocks that cannot be reallocated.
The ipv6acl allocation must be entered as a factor of 2 (2, 4, 6, 8, 10). All other profile allocations can use
either even or odd numbered ranges.
• L3 ACL (ipv4acl): 6
• L2 ACL(l2acl) : 5
• IPv6 L3 ACL (ipv6acl): 0
• L3 QoS (ipv4qos): 1
• L2 QoS (l2qos): 1
cam-acl {default | l2acl CONFIGURATION Allocate space for IPV6 ACLs. Enter the CAM
number ipv4acl number profile name followed by the amount to be allotted.
ipv6acl number, ipv4qos
number l2qos number, l2pt When not selecting the default option, you must enter all
number ipmacacl number of the profiles listed and a range for each.
ecfmacl number [vman-qos |
vman-dual-qos number} The total space allocated must equal 13.
The ipv6acl range must be a factor of 2.
ipv6 address ipv6 address/ CONFIG-INTERFACE Enter the IPv6 Address for the device.
mask ipv6 address : x:x:x:x::x
mask : prefix length 0-128
ipv6 route prefix type {slot/ CONFIGURATION Set up IPv6 static routes
port} forwarding router tag prefix: IPv6 route prefix
type {slot/port}: interface type and slot/port
forwarding router: forwarding router’s address
tag: route tag
telnet ipv6 address EXEC or Enter the IPv6 Address for the device.
EXEC Privileged ipv6 address : x:x:x:x::x
mask : prefix length 0-128
IPv6 addresses are normally written as eight groups of four hexadecimal digits,
where each group is separated by a colon (:). Omitting zeros is accepted as
described in Addressing earlier in this chapter.
• snmp-server host
• snmp-server user ipv6
• snmp-server community ipv6
• snmp-server community access-list-name ipv6
• snmp-server group ipv6
• snmp-server group access-list-name ipv6
FTOS#show ipv6 ?
accounting IPv6 accounting information
cam linecard IPv6 CAM Entries for Line Card
fib linecard IPv6 FIB Entries for Line Card
interface IPv6 interface information
mbgproutes MBGP routing table
mld MLD information
mroute IPv6 multicast-routing table
neighbors IPv6 neighbor information
ospf OSPF information
pim PIM V6 information
prefix-list List IPv6 prefix lists
route IPv6 routing information
rpf RPF table
FTOS#
show ipv6 interface type {slot/ EXEC Show the currently running configuration for the
port} specified interface
Enter the keyword interface followed by the type of
interface and slot/port information:
• For all brief summary of IPv6 status and
configuration , enter the keyword brief.
• For all IPv6 configured interfaces, enter the
keyword configured.
• For a 10/100/1000 Ethernet interface, enter the
keyword GigabitEthernet followed by the slot/
port information.
• For a Gigabit Ethernet interface, enter the
keyword GigabitEthernet followed by the slot/
port information.
• For a 10 Gigabit Ethernet interface, enter the
keyword TenGigabitEthernet followed by the
slot/port information.
• For a loopback interface, enter the keyword
loopback followed by the loopback number
• For a linecard interface, enter the keyword
linecard followed by the slot number
• For a port-channel interface, enter the keyword
port-channel followed by the port-channel
number
• For a VLAN interface, enter the keyword vlan
followed by the VLAN ID
show ipv6 route type EXEC Show IPv6 routing information for the specified
route type.
Enter the keyword:
• To display information about a network, enter
the ipv6 address (X:X:X:X::X).
• To display information about a host, enter the
hostname.
• To display information about all IPv6 routes
(including non-active routes), enter all.
• To display information about all connected IPv6
routes, enter connected.
• To display information about brief summary of
all IPv6 routes, enter summary.
• To display information about Border Gateway
Protocol (BGP) routes, enter bgp.
• To display information about ISO IS-IS routes,
enter isis.
• To display information about Open Shortest Path
First (OSPF) routes, enter ospf.
• To display information about Routing
Information Protocol (RIP), enter rip.
• To display information about static
IPv6 routes, enter static.
• To display information about an IPv6 Prefix
lists, enter list and the prefix-list name.
Figure 22-8 illustrates the show ipv6 route summary command output.
Figure 22-9 illustrates the show ipv6 route static command output.
View the configuration for any interface with the following command.
show running-config EXEC Show the currently running configuration for the
interface type {slot/port} specified interface
Enter the keyword interface followed by the type of
interface and slot/port information:
• For a 10/100/1000 Ethernet interface, enter the
keyword GigabitEthernet followed by the slot/
port information.
• For a Gigabit Ethernet interface, enter the
keyword GigabitEthernet followed by the slot/
port information.
• For the Management interface on the RPM, enter
the keyword ManagementEthernet followed by
the slot/port information.
• For a 10 Gigabit Ethernet interface, enter the
keyword TenGigabitEthernet followed by the
slot/port information.
Figure 22-10 illustrates the show running-config command output. Note the IPv6 address listed.
clear ipv6 route {* | ipv6 address EXEC Clear (refresh) all or a specific routes from the IPv6
prefix-length} routing table.
* : all routes
ipv6 address : x:x:x:x::x
mask : prefix length 0-128
506
|
IPv6 Addressing
23
Intermediate System to Intermediate System
Intermediate System to Intermediate System is supported on platform: e
Intermediate System to Intermediate System (IS-IS) protocol is an interior gateway protocol (IGP) that
uses a shortest-path-first algorithm. Dell Force10 supports both IPv4 and IPv6 versions of IS-IS, as
described in this chapter.
IS-IS protocol standards are listed in the Appendix 63, Standards Compliance chapter.
Protocol Overview
The intermediate-system-to-intermediate-system (IS-IS) protocol, developed by the International
Organization for Standardization (ISO), is an interior gateway protocol (IGP) that uses a shortest-path-first
algorithm.
Note: This protocol supports routers passing both IP and OSI traffic, though the Dell Force10
implementation supports only IP traffic.
IS-IS is organized hierarchally into routing domains, and each router or system resides in at least one area.
In IS-IS, routers are designated as Level 1, Level 2 or Level 1-2 systems. Level 1 routers only route traffic
within an area, while Level 2 routers route traffic between areas. At its most basic, Level 1 systems route
traffic within the area and any traffic destined for outside the area is sent to a Level 1-2 system. Level 2
systems manage destination paths for external routers. Only Level 2 routers can exchange data packets or
systems manage both inter-area and intra-area traffic by maintaining two separate link databases; one for
Level 1 routes and one for Level 2 routes. A Level 1-2 router does not advertise Level 2 routes to a Level 1
router.
To establish adjacencies, each IS-IS router sends different Protocol Data Units (PDU). For IP traffic, the IP
addressing information is included in the IS-IS hello PDUs and the Link State PDUs (LSPs).
This brief overview is not intended to provide a complete understanding of IS-IS; for that, consult the
documents listed in Multi-Topology IS-IS on page 509.
IS-IS Addressing
IS-IS PDUs require ISO-style addressing called Network Entity Title (NET). For those familiar with
NSAP addresses, the composition of the NET is identical to an NSAP address, except the last byte is
always 0. The NET is composed of IS-IS area address, system ID, and the N-selector. The last byte is the
N-selector. All routers within an area have the same area portion. Level 1 routers route based on the system
address portion of the address, while the Level 2 routers route based on the area address.
The NET length is variable, with a maximum of 20 bytes and a minimum of 8 bytes. It is composed of the
following:
• area address. Within your routing domain or area, each area must have a unique area value. The first
byte is called the authority and format indicator (AFI).
• system address. This is usually the router’s MAC address.
• N-selector. This is always 0.
Figure 23-1 is an example of the ISO-style address to illustrate the address format used by IS-IS. In this
example, the first five bytes (47.0005.0001) are the area address. The system portion is 000c.000a.4321
and the last byte is always 0.
Figure 23-1. ISO Address Format
47.0005.0001.000c.000a.4321.00
E-Series ExaScale platform ex supports Multi-Topology IS-IS with FTOS 8.2.1.0 and later.
Multi-Topology IS-IS (MT IS-IS) allows you to create multiple IS-IS topologies on a single router with
separate databases. This feature is used to place a virtual physical topology into logical routing domains,
which can each support different routing and security policies.
All routers on a LAN or point-to-point must have at least one common supported topology when operating
in Multi-Topology IS-IS mode. If IPv4 is the common supported topology between those two routers,
adjacency can be formed. All topologies must share the same set of L1-L2 boundaries.
You must implement a wide metric-style globally on the Autonomous System to run Multi-Topology IS-IS
for IPv6 because the TLVs used to advertise IPv6 information in link-state packets (LSPs) are defined to
use only extended metrics.
The Multi-Topology ID is shown in the first octet of the IS-IS packet. Certain MT topologies are assigned
to serve predetermined purposes:
Transition Mode
All routers in the area or domain must use the same type of IPv6 support, either single-topology or
multi-topology. A router operating in multi-topology mode will not recognize the ability of the
single-topology mode router to support IPv6 traffic, which will lead to holes in the IPv6 topology.
While in transition mode, both types of TLVs (single-topology and multi-topology) are sent in LSPs for all
configured IPv6 addresses, but the router continues to operate in single-topology mode (that is, the
topological restrictions of the single-topology mode remain in effect). Transition mode stops after all
routers in the area or domain have been upgraded to support multi-topology IPv6. Once all routers in the
area or domain are operating in multi-topology IPv6 mode, the topological restrictions of single-topology
mode are no longer in effect.
Interface support
MT IS-IS is supported on physical Ethernet interfaces, physical Sonet interfaces, port-channel interfaces
(static & dynamic using LACP), and VLAN interfaces.
Adjacencies on point-to-point interfaces are formed as usual, where IS-IS routers do not implement
Multi-Topology (MT) extensions. If a local router does not participate in certain MTs, it will not advertise
those MT IDs in its IIHs and so will not include that neighbor within its LSPs. If an MT ID is not detected
in the remote side's IIHs, the local router does not include that neighbor within its LSPs. The local router
will not form an adjacency if both routers don't have at least one common MT over the interface.
Graceful Restart
Graceful Restart is supported on e platforms for both Helper and Restart modes.
Graceful Restart is a protocol-based mechanism that preserves the forwarding table of the restarting router
and its neighbors for a specified period to minimize the loss of packets. A graceful-restart router does not
immediately assume that a neighbor is permanently down and so does not trigger a topology change.
Normally, when an IS-IS router is restarted, temporary disruption of routing occurs due to events in both
the restarting router and the neighbors of the restarting router. When a router goes down without a Graceful
Restart, there is a potential to lose access to parts of the network due to the necessity of network topology
changes.
IS-IS Graceful Restart recognizes the fact that in a modern router, the control plane and data plane are
functionality separate. Restarting the control plane functionality (such as the failover of the active RPM to
the backup in a redundant configuration) should not necessarily interrupt data packet forwarding. This
behavior is supported because the forwarding tables previously computed by an active RPM have been
downloaded into the Forwarding Information Base on the line cards (the data plane) and are still resident.
For packets that have existing FIB/CAM entries, forwarding between ingress and egress ports can continue
uninterrupted while the control plane IS-IS process comes back to full functionality and rebuilds its routing
tables.
A new TLV (the Restart TLV) is introduced in the IIH PDUs, indicating that the router supports Graceful
Restart.
Timers
Three timers are used to support IS-IS Graceful Restart functionality. Once Graceful Restart is enabled,
these timers manage the the Graceful Restart process.
• The T1 timer specifies the wait time before unacknowledged restart requests are generated. This is the
interval before the system sends a Restart Request (an IIH with RR bit set in Restart TLV) until the
CSNP is received from the helping router. The duration can be set to a specific amount of time
(seconds) or a number of attempts.
• The T2 timer is the maximum time that the system will wait for LSP database synchronization. This
timer applies to the database type (level-1, level-2 or both).
Implementation Information
IS-IS implementation supports one instance of IS-IS and six areas. The system can be configured as a
Level 1 router, a Level 2 router, or a Level 1-2 router. For IPv6, the IPv4 implementation has been
expanded to include two new type-length-values (TLV) in the protocol data unit (PDU) that carry
information required for IPv6 routing. The new TLVs are IPv6 Reachability and IPv6 Interface Address.
Also, a new IPv6 protocol identifier has also been included in the supported TLVs. The new TLVs use the
extended metrics and up/down bit semantics.
• The Multi-Topology TLV contains one or more Multi-Topology IDs in which the router participates.
This TLV is included in IIH and the first fragment of an LSP.
• The MT Intermediate Systems TLV appears for every topology a node supports. An MT ID is added to
the extended IS reachability TLV type 22.
• The Multi-Topology Reachable IPv4 Prefixes TLV appears for each IPv4 announced by an IS for a
given MT ID. Its structure is aligned with the extended IS Reachability TLV Type 236 and it adds an
MT ID.
• The Multi-Topology Reachable IPv6 Prefixes TLV appears for each IPv6 announced by an IS for a
given MT ID. Its structure is aligned with the extended IS Reachability TLV Type 236 and add a MT
ID.
By default, FTOS supports dynamic hostname exchange to assist with troubleshooting and configuration.
By assigning a name to an IS-IS NET address, you can track IS-IS information on that address easier.
FTOS does not support ISO CLNS routing; however, the ISO NET format is supported for addressing.
To support IPv6, the Dell Force10 implementation of IS-IS performs the following tasks:
Configuration Information
To use IS-IS, you must configure and enable IS-IS in two or three modes: CONFIGURATION ROUTER
ISIS, CONFIGURATION INTERFACE, and ( when configuring for IPv6) ADDRESS-FAMILY mode.
Commands in ROUTER ISIS mode configure IS-IS globally, while commands executed in INTERFACE
mode enable and configure IS-IS features on that interface only. Commands in the ADDRESS-FAMILY
mode are specific to IPv6.
Note that by using the IS-IS routing protocol to exchange IPv6 routing information and to determine
destination reachability, you can route IPv6 along with IPv4 while using a single intra-domain routing
protocol. The configuration commands allow you to enable and disable IPv6 routing and to configure or
remove IPv6 prefixes on links.
Except where identified, the commands discussed in this chapter apply to both IPv4 and IPv6 versions of
IS-IS.
Enable IS-IS
The system supports one instance of IS-IS. To enable IS-IS globally, create an IS-IS routing process and
assign a NET address. To exchange protocol information with neighbors, enable IS-IS on an interface,
instead of on a network as with other routing protocols.
In IS-IS, neighbors form adjacencies only when they are same IS type. For example, a Level 1 router never
forms an adjacency with a Level 2 router. A Level 1-2 router will form Level 1 adjacencies with a
neighboring Level 1 router and will form Level 2 adjacencies with a neighboring Level 2 router.
Note: Even though you enable IS-IS globally, you must enable the IS-IS process on an interface for the
IS-IS process to exchange protocol information and form adjacencies.
2 Configure an IS-IS network entity title (NET) for a routing net ROUTER ISIS
process. network-entity-title
Specify the area address and system ID for an IS-IS routing
process. The last byte must be 00.
Refer to IS-IS Addressing for more information on
configuring a NET.
3 Enter the interface configuration mode. Enter the keyword interface interface CONFIGURATION
interface followed by the type of interface and slot/port
information:
• For a 1-Gigabit Ethernet interface, enter the keyword
GigabitEthernet followed by the slot/port information.
• For the Loopback interface on the RPM, enter the
keyword loopback followed by a number from 0 to
16383.
• For a port channel, enter the keyword port-channel
followed by a number from 1 to 255 for TeraScale and
ExaScale, 1 to 32 for EtherScale.
• For a SONET interface, enter the keyword sonet
followed by slot/port information.
• For a 10-Gigabit Ethernet interface, enter the keyword
TenGigabitEthernet followed by the slot/port
information.
• For a VLAN, enter the keyword vlan followed by a
number from 1 to 4094.
E-Series ExaScale platforms support 4094 VLANs
with FTOS version 8.2.1.0 and later. Earlier
ExaScale supports 2094 VLANS.
6 Enable IS-IS on the interface. If you configure a tag {ip | ipv6} router INTERFACE
variable, it must be the same as the tag variable assigned in isis [tag]
step 1.
The default IS type is level-1-2. To change the IS type to Level 1 only or Level 2 only, use the is-type
command in ROUTER ISIS mode.
Enter the show isis protocol command in EXEC Privilege mode or the show config command in
ROUTER ISIS mode to view the IS-IS configuration.
Use the show isis traffic command in EXEC Privilege mode to view IS-IS protocol statistics.
Figure 23-3. Command Example: show isis traffic
FTOS#show isis traffic
IS-IS: Level-1 Hellos (sent/rcvd) : 4272/1538
IS-IS: Level-2 Hellos (sent/rcvd) : 4272/1538
IS-IS: PTP Hellos (sent/rcvd) : 0/0
IS-IS: Level-1 LSPs sourced (new/refresh) : 0/0
IS-IS: Level-2 LSPs sourced (new/refresh) : 0/0
IS-IS: Level-1 LSPs flooded (sent/rcvd) : 32/19
IS-IS: Level-2 LSPs flooded (sent/rcvd) : 32/17
IS-IS: Level-1 LSPs CSNPs (sent/rcvd) : 1538/0
IS-IS: Level-2 LSPs CSNPs (sent/rcvd) : 1534/0
IS-IS: Level-1 LSPs PSNPs (sent/rcvd) : 0/0
IS-IS: Level-2 LSPs PSNPs (sent/rcvd) : 0/0
IS-IS: Level-1 DR Elections : 2
IS-IS: Level-2 DR Elections : 2
IS-IS: Level-1 SPF Calculations : 29
IS-IS: Level-2 SPF Calculations : 29
IS-IS: LSP checksum errors received : 0
IS-IS: LSP authentication failures : 0
FTOS#
You can assign additional NET addresses, but the System ID portion of the NET address must remain the
same. FTOS supports up to six area addresses.
• In order to be neighbors, Level 1 routers must be configured with at least one common area address.
• A Level 2 router becomes a neighbor with another Level 2 router regardless of the area address
configured. However, if the area addresses are different, the link between the Level 2 routers is only at
Level 2.
3 Set the minimum interval between spf-interval [level-l | level-2 | interval] ROUTER ISIS AF IPV6
SPF calculations. [initial_wait_interval
[second_wait_interval]]
This command is used for IPv6 route computation only when multi-topology is enabled. If using single-topology
mode, use the spf-interval command in CONFIG ROUTER ISIS mode to apply to both IPv4 and IPv6 route
computations.
4 Implement a wide metric-style isis ipv6 metric metric-value [level-1 | ROUTER ISIS AF IPV6
globally. level-2 | level-1-2]
3 Set the minimum interval between spf-interval [level-l | level-2 | interval] ROUTER ISIS AF IPV6
SPF calculations. [initial_wait_interval
[second_wait_interval]]
This command is used for IPv6 route computation only when multi-topology is enabled. If using single-topology
mode, use the spf-interval command in CONFIG ROUTER ISIS mode to apply to both IPv4 and IPv6 route
computations.
4 Implement a wide metric-style isis ipv6 metric metric-value [level-1 | ROUTER ISIS AF IPV6
globally. level-2 | level-1-2]
To enable IS-IS Graceful Restart globally, use the following command in ROUTER-ISIS mode.
Additional, optional commands can be implemented to enable the Graceful Restart settings.
graceful-restart interval minutes ROUTER-ISIS Configure the period of time during which the Graceful
Restart attempt will be prevented.
Range: 1-120 minutes
Default: 5 minutes
graceful-restart restart- wait seconds ROUTER-ISIS Enable the Graceful Restart maximum wait time before
a restarting peer comes up.
Be sure to set the t3 timer to adjacency on the restarting
router when implementing this command.
Range: 5-120 seconds
Default: 30 seconds
graceful-restart t1 {interval seconds | ROUTER-ISIS Configure the time that the Graceful Restart timer T1
retry-times value} defines for a restarting router to use for each interface,
as an interval before regenerating Restart Request (an
IIH with RR bit set in Restart TLV) after waiting for an
acknowledgement.
Use the show isis interface command in EXEC Privilege mode to view all interfaces configured with
IS-IS routing along with the defaults.
IS-IS routers flood Link state PDUs (LSPs) to exchange routing information. LSP attributes include the
generation interval, maximum transmission unit (MTU) or size, and the refresh interval. You can modify
the LSP attribute defaults, but it is not necessary.
To change the defaults, use any or all of the following commands in ROUTER ISIS mode:
lsp-gen-interval [level-1 | level-2] ROUTER ISIS Set interval between LSP generation.
seconds • seconds range: 0 to 120
Default is 5 seconds.
Default level is Level 1.
max-lsp-lifetime seconds ROUTER ISIS Set the maximum time LSPs lifetime.
• seconds range: 1 to 65535
Default is 1200 seconds.
To view the configuration, use the show config command in ROUTER ISIS mode or the show
running-config isis command in EXEC Privilege mode (Figure 475).
All IS-IS links or interfaces are associated with a cost that is used in the SPF calculations. The possible
cost varies depending on the metric style supported. If you configure narrow, transition or narrow
transition metric style, the cost can be a number between 0 and 63. If you configure wide or wide transition
metric style, the cost can be a number between 0 and 16,777,215. FTOS supports five different metric
styles: narrow, wide, transition, narrow transition, and wide transition.
By default, FTOS generates and receives narrow metric values. Metrics or costs higher than 63 are not
supported. To accept or generate routes with a higher metric, you must change the metric style of the IS-IS
process. For example, if metric is configured as narrow, and an LSP with wide metrics is received, the
route is not installed.
Use the following command in ROUTER ISIS mode to change the IS-IS metric style of the IS-IS process.
metric-style {narrow [transition] | ROUTER ISIS Set the metric style for the IS-IS process.
transition | wide [transition]} [level-1 Default: narrow
| level-2] Default: Level 1 and Level 2 (level-1-2)
Use the show isis protocol command (Figure 476) in EXEC Privilege mode to view which metric types
are generated and received.
When you change from one IS-IS metric style to another, the IS-IS metric value could be affected. For each
interface with IS-IS enabled, you can assign a cost or metric that is used in the link state calculation.
Use the following command in INTERFACE mode to change the metric or cost of the interface.
isis ipv6 metric default-metric [level-1 | INTERFACE Assign a metric for an IPv6 link or interface.
level-2] • default-metric range: 0 to 63 for narrow and
transition metric styles; 0 to 16777215 for wide
metric styles.
Default is 10.
Default level is level-1.
Refer to Configure IS-IS metric style and cost for more
information on this command.
Use the show config command in INTERFACE mode or the show isis interface command in EXEC
Privilege mode to view the interface’s current metric.
Table 23-3. Correct Value Range for the isis metric command
wide 0 to 16777215
narrow 0 to 63
wide transition 0 to 16777215
narrow transition 0 to 63
transition 0 to 63
• Level 1 router
• Level 1-2 router
• Level 2 router
Use the following command in ROUTER ISIS mode to change the IS-type for the router, u
is-type {level-1 | level-1-2 | ROUTER ISIS Configure IS-IS operating level for a router.
level-2-only} Default is level-1-2.
is-type {level-1 | level-1-2 | level-2} ROUTER ISIS Change the IS-type for the IS-IS process.
Use the show isis protocol command in EXEC Privilege mode (Figure 476) to view which IS-type is
configured. The show config command in ROUTER ISIS mode displays only non-default information, so
if you do not change the IS-type, the default value (level-1-2) is not displayed.
The default is Level 1-2 router. When the IS-type is Level 1-2, the software maintains two Link State
databases, one for each level. Use the show isis database command to view the Link State databases
(Figure 477).
FTOS#
Use the following commands in ROUTER ISIS mode to control the source of IS-IS route information.
passive-interface interface ROUTER ISIS Disable a specific interface from sending or receiving
IS-IS routing information.
Enter the type of interface and slot/port information:
• For a 1-Gigabit Ethernet interface, enter the keyword
GigabitEthernet followed by the slot/port
information.
• For the Loopback interface on the RPM, enter the
keyword loopback followed by a number from 0 to
16383.
• For a port channel, enter the keyword port-channel
followed by a number from 1 to 255 for TeraScale
and ExaScale, 1 to 32 for EtherScale.
• For a SONET interface, enter the keyword sonet
followed by slot/port information.
• For a 10-Gigabit Ethernet interface, enter the
keyword TenGigabitEthernet followed by the slot/
port information.
• For a VLAN, enter the keyword vlan followed by a
number from 1 to 4094.
E-Series ExaScale platforms support 4094
VLANs with FTOS version 8.2.1.0 and later.
Earlier ExaScale supports 2094 VLANS.
Another method of controlling routing information is to filter the information through a prefix list. Prefix
lists are applied to incoming or outgoing routes and routes must meet the conditions of the prefix lists or
FTOS does not install the route in the routing table. The prefix lists are globally applied on all interfaces
running IS-IS.
Configure the prefix list in the PREFIX LIST mode prior to assigning it to the IS-IS process. For
configuration information on prefix lists, see Chapter 8, IP Access Control Lists (ACL), Prefix Lists, and
Route-maps.
IPv4 routes
Use the following commands in ROUTER ISIS mode to apply prefix lists to incoming or outgoing IPv4
routes.
Note: These commands apply to IPv4 IS-IS only. Use the ADDRESS-FAMILY IPV6 mode shown later to
apply prefix lists to IPv6 routes
distribute-list prefix-list-name in [interface] ROUTER ISIS Apply a configured prefix list to all incoming
IPv4 IS-IS routes.
Enter the type of interface and slot/port
information:
• For a 1-Gigabit Ethernet interface, enter
the keyword GigabitEthernet followed
by the slot/port information.
• For the Loopback interface on the RPM,
enter the keyword loopback followed by
a number from 0 to 16383.
• For a port channel, enter the keyword
port-channel followed by a number from
1 to 255 for TeraScale and ExaScale, 1 to
32 for EtherScale.
• For a SONET interface, enter the keyword
sonet followed by slot/port information.
• For a 10-Gigabit Ethernet interface, enter
the keyword TenGigabitEthernet
followed by the slot/port information.
• For a VLAN, enter the keyword vlan
followed by a number from 1 to 4094.
E-Series ExaScale platforms support
4094 VLANs with FTOS version
8.2.1.0 and later. Earlier ExaScale
supports 2094 VLANS.
distribute-list prefix-list-name out [bgp ROUTER ISIS Apply a configured prefix list to all outgoing
as-number | connected | ospf process-id | rip | IPv4 IS-IS routes. You can configure one of
static] the optional parameters:
• connected: for directly connected routes.
• ospf process-id: for OSPF routes only.
• rip: for RIP routes only.
• static: for user-configured routes.
• bgp: for BGP routes only
distribute-list redistributed-override in ROUTER ISIS Deny RTM download for pre-existing
redistributed IPv4 routes
IPv6 routes
Use these commands in ADDRESS-FAMILY IPV6 mode to apply prefix lists to incoming or outgoing
IPv6 routes. =
Note: These commands apply to IPv6 IS-IS only. Use the ROUTER ISIS mode previously shown to apply
prefix lists to IPv4 routes.
distribute-list prefix-list-name in [interface] ROUTER ISIS-AF Apply a configured prefix list to all incoming
IPV6 IPv6 IS-IS routes.
Enter the type of interface and slot/port
information:
• For a 1-Gigabit Ethernet interface, enter
the keyword GigabitEthernet followed
by the slot/port information.
• For the Loopback interface on the RPM,
enter the keyword loopback followed by
a number from 0 to 16383.
• For a port channel, enter the keyword
port-channel followed by a number from
1 to 255 for TeraScale, 1 to 32 for
EtherScale.
• For a SONET interface, enter the keyword
sonet followed by slot/port information.
• For a 10-Gigabit Ethernet interface, enter
the keyword TenGigabitEthernet
followed by the slot/port information.
• For a VLAN, enter the keyword vlan
followed by a number from 1 to 4094.
E-Series ExaScale platforms support
4094 VLANs with FTOS version
8.2.1.0 and later. Earlier ExaScale
supports 2094 VLANS.
distribute-list prefix-list-name out [bgp ROUTER ISIS-AF Apply a configured prefix list to all outgoing
as-number | connected | ospf process-id | rip | IPV6 IPv6 IS-IS routes. You can configure one of
static] the optional parameters:
• connected: for directly connected routes.
• ospf process-id: for OSPF routes only.
• rip: for RIP routes only.
• static: for user-configured routes.
• bgp: for BGP routes only
distribute-list redistributed-override in ROUTER ISIS-AF Deny RTM download for pre-existing
IPV6 redistributed IPv6 routes
Redistribute routes
In addition to filtering routes, you can add routes from other routing instances or protocols to the IS-IS
process. With the redistribute command syntax, you can include BGP, OSPF, RIP, static, or directly
connected routes in the IS-IS process.
Note: Do not route iBGP routes to IS-IS unless there are route-maps associated with the IS-IS
redistribution.
IPv4 routes
Use any of the following commands in ROUTER ISIS mode to add routes from other routing instances or
protocols.
Note: These commands apply to IPv4 IS-IS only. Use the ADDRESS-FAMILY IPV6 mode shown later to
apply prefix lists to IPv6 routes.
redistribute {bgp as-number | connected | rip | ROUTER ISIS Include BGP, directly connected, RIP, or
static} [level-1 level-1-2 | level-2] [metric user-configured (static) routes in IS-IS.
metric-value] [metric-type {external | internal}] Configure the following parameters:
[route-map map-name] • level-1, level-1-2, or level-2: Assign
all redistributed routes to a level.
Default is level-2.
• metric range: 0 to 16777215. Default is
0.
• metric-type: choose either external
or internal. Default is internal.
• map-name: name of a configured route
map.
redistribute ospf process-id [level-1| level-1-2 | ROUTER ISIS Include specific OSPF routes in IS-IS.
level-2] [metric value] [match external {1 | 2} | Configure the following parameters:
match internal] [metric-type {external | • process-id range: 1 to 65535
internal}] [route-map map-name] • level-1, level-1-2, or level-2: Assign
all redistributed routes to a level.
Default is level-2.
• metric range: 0 to 16777215. Default is
0.
• match external range: 1 or 2
• match internal
• metric-type: external or internal.
• map-name: name of a configured route
map.
IPv6 routes
Use any of the these commands in ROUTER ISIS ADDRESS-FAMILY IPV6 mode to add routes from
other routing instances or protocols.
Note: These commands apply to IPv6 IS-IS only. Use the ROUTER ISIS mode previously shown to apply
prefix lists to IPv4 routes.
redistribute {bgp as-number | connected | rip | ROUTER ISIS Include BGP, directly connected, RIP, or
static} [level-1 level-1-2 | level-2] [metric user-configured (static) routes in IS-IS.
metric-value] [metric-type {external | internal}] Configure the following parameters:
[route-map map-name] • level-1, level-1-2, or level-2: Assign
all redistributed routes to a level.
Default is level-2.
• metric range: 0 to 16777215. Default is
0.
• metric-type: choose either external
or internal. Default is internal.
• map-name: name of a configured route
map.
redistribute ospf process-id [level-1| level-1-2 | ROUTER ISIS Include specific OSPF routes in IS-IS.
level-2] [metric value] [match external {1 | 2} | Configure the following parameters:
match internal] [metric-type {external | • process-id range: 1 to 65535
internal}] [route-map map-name] • level-1, level-1-2, or level-2: Assign
all redistributed routes to a level.
Default is level-2.
• metric range: 0 to 16777215. Default is
0.
• match external range: 1 or 2
• match internal
• metric-type: external or internal.
• map-name: name of a configured route
map.
You can assign an authentication password for routers in Level 1 and for routers in Level 2. Since Level 1
and Level 2 routers do not communicate with each other, you can assign different passwords for Level 1
routers and for Level 2 routers. If you want the routers in the level to communicate with each other, though,
they must be configured with the same password.
Use either or both of the commands in ROUTER ISIS mode to configure a simple text password.
area-password [hmac-md5] ROUTER ISIS Configure authentication password for an area. FTOS
password supports HMAC-MD5 authentication.
This password is inserted in Level 1 LSPs, Complete
SNPs, and Partial SNPs.
domain-password [encryption-type ROUTER ISIS Set the authentication password for a routing domain.
| hmac-md5] password FTOS supports both DES and HMAC-MD5
authentication methods. This password is inserted in
Level 2 LSPs, Complete SNPs, and Partial SNPs.
Use the show config command in ROUTER ISIS mode or the show running-config isis command in
EXEC Privilege mode to view the passwords.
Use this command the following command in ROUTER ISIS mode to set the overload bit manually.
set-overload-bit ROUTER ISIS Set the overload bit in LSPs. This prevents other routers from
using it as an intermediate hop in their shortest path first (SPF)
calculations.
Figure 23-9, the overload bit is set in both the Level-1 and Level-2 database because the IS type for the
router is Level-1-2
Figure 23-9. Command Example: show isis database
Debug IS-IS
Enter the debug isis command in EXEC Privilege mode to debug all IS-IS processes.
debug isis adj-packets [interface] EXEC Privilege View information on all adjacency-related activity
(for example, hello packets that are sent and
received).
To view specific information, enter one of the
following optional parameters:
• interface: Enter the type of interface and slot/port
information to view IS-IS information on that
interface only.
debug isis local-updates [interface] EXEC Privilege View information about IS-IS local update packets.
To view specific information, enter one of the
following optional parameters:
• interface: Enter the type of interface and slot/port
information to view IS-IS information on that
interface only.
debug isis snp-packets [interface] EXEC Privilege View IS-IS SNP packets, include CSNPs and
PSNPs.
To view specific information, enter one of the
following optional parameters:
• interface: Enter the type of interface and slot/port
information to view IS-IS information on that
interface only.
debug isis spf-triggers EXEC Privilege View the events that triggered IS-IS shortest path
first (SPF) events for debugging purposes.
debug isis update-packets [interface] EXEC Privilege View sent and received LSPs.
To view specific information, enter one of the
following optional parameters:
• interface: Enter the type of interface and slot/port
information to view IS-IS information on that
interface only.
FTOS displays debug messages on the console. Use the show debugging command in EXEC Privilege
mode to view which debugging commands are enabled.
Enter the keyword no followed by the debug command to disable a specific debug command. For example,
to disable debugging of IS-IS updates, enter no debug isis updates-packets.
For any level (Level-1, Level-2, or Level-1-2), the value range possible in the isis metric command in
INTERFACE mode changes depending on the metric style.
Table 23-4. Correct Value Range for the isis metric Command
Metric Style Correct Value Range for the isis metric Command
wide 0 to 16777215
narrow 0 to 63
wide transition 0 to 16777215
narrow transition 0 to 63
transition 0 to 63
In the following scenarios, the IS-type is either Level-1 or Level-2 or Level-1-2 and the metric style
changes.
Beginning metric style Final metric style Resulting IS-IS metric value
wide narrow default value (10) if the original value is greater than
63.
A message is sent to the console.
wide transition truncated value1 (the truncated value appears in the
LSP only.)
The original isis metric value is displayed in the
show config and show running-config
commands and is used if you change back to
transition metric style.
Beginning metric style Final metric style Resulting IS-IS metric value
wide narrow transition default value (10) if the original value is greater than
63.
A message is sent to the console.
wide wide transition original value
narrow wide original value
narrow transition original value
narrow narrow transition original value
narrow wide transition original value
transition wide original value
transition narrow original value
transition narrow transition original value
transition wide transition original value
narrow transition wide original value
narrow transition narrow original value
narrow transition wide transition original value
narrow transition transition original value
wide transition wide original value
wide transition narrow default value (10) if the original value is greater than
63.
A message is sent to the console.
wide transition narrow transition default value (10) if the original value is greater than
63.
A message is sent to the console.
wide transition transition truncated value (the truncated value appears in the
LSP only.)
The original isis metric value is displayed in the
show config and show running-config
commands and is used if you change back to
transition metric style.
1 a truncated value is a value that is higher than 63, but set back to 63 because the higher value is not supported.
Moving to transition and then to another metric style produces different results (Table 23-6).
Table 23-6. Metric Value when Metric Style Changes Multiple Times
Table 23-7. Metric Value with Different Levels Configured with Different Metric Styles
Level-1 metric style Level-2 metric style Resulting isis metric value
narrow wide original value
narrow wide transition original value
narrow narrow transition original value
narrow transition original value
wide narrow truncated value
wide narrow transition truncated value
wide wide transition original value
wide transition truncated value
narrow transition wide original value
narrow transition narrow original value
narrow transition wide transition original value
narrow transition transition original value
transition wide original value
transition narrow original value
transition wide transition original value
transition narrow transition original value
wide transition wide original value
wide transition narrow truncated value
wide transition narrow transition truncated value
wide transition transition truncated value
Note: Only one IS-IS process can run on the router, even if both IPv4 and IPv6 routing is
S
being used.
You can copy and paste from these examples to your CLI. Be sure you make the necessary changes to
support your own IP Addresses, Interfaces, Names, etc.
Note: Whenever ISIS configuration changes are made, the IS-IS process must be cleared
S
(re-started) using clear isis. The command clear isis must include the tag for the ISIS
process. The example below shows the response from the router:
FTOS#clear isis *
% ISIS not enabled.
FTOS#clear isis 9999 *
Figure 23-10 is a sample configuration for enabling IPv6 IS-IS. Figure 23-13 illustrates the topology
created with that CLI configuration.
Router 1
R1(conf)#interface Loopback 0
R1(conf-if-lo-0)#ip address 192.168.1.1/24
R1(conf-if-lo-0)#ipv6 address 2001:db8:9999:1::/48
R1(conf-if-lo-0)#ip router isis 9999
R1(conf-if-lo-0)#no shutdown
R1#show ip route
Codes: C - connected, S - static, R - RIP,
B - BGP, IN - internal BGP, EX - external BGP,LO - Locally Originated,
O - OSPF, IA - OSPF inter area, N1 - OSPF NSSA external type 1,
N2 - OSPF NSSA external type 2, E1 - OSPF external type 1,
E2 - OSPF external type 2, i - IS-IS, L1 - IS-IS level-1,
L2 - IS-IS level-2, IA - IS-IS inter area, * - candidate default,
> - non-active route, + - summary route
R2#show ip route
Codes: C - connected, S - static, R - RIP,
B - BGP, IN - internal BGP, EX - external BGP,LO - Locally Originated,
O - OSPF, IA - OSPF inter area, N1 - OSPF NSSA external type 1,
N2 - OSPF NSSA external type 2, E1 - OSPF external type 1,
E2 - OSPF external type 2, i - IS-IS, L1 - IS-IS level-1,
L2 - IS-IS level-2, IA - IS-IS inter area, * - candidate default,
> - non-active route, + - summary route
Router 3
R3(conf)#interface Loopback 0
R3(conf-if-lo-0)#ip address 192.168.1.3/24
R3(conf-if-lo-0)#ipv6 address 2001:db8:9999:3::/48
R3(conf-if-lo-0)#ip router isis 9999
R3(conf-if-lo-0)#no shutdown
R3(conf-if-lo-0)#router isis 9999
R3(conf-router_isis)#net FF.F101.0002.0C00.1133.00
R3(conf-router_isis)#ipv6 route 2001:db8:9999:1::/128 2001:db8:1022:1::
R3(conf)#ipv6 route 2001:db8:9999:2::/128 2001:db8:1023:2::
R3(conf)#ip route 192.168.1.1/32 10.0.13.1
R3#show ip route
Codes: C - connected, S - static, R - RIP,
B - BGP, IN - internal BGP, EX - external BGP,LO - Locally Originated,
O - OSPF, IA - OSPF inter area, N1 - OSPF NSSA external type 1,
N2 - OSPF NSSA external type 2, E1 - OSPF external type 1,
E2 - OSPF external type 2, i - IS-IS, L1 - IS-IS level-1,
L2 - IS-IS level-2, IA - IS-IS inter area, * - candidate default,
> - non-active route, + - summary route
Gateway of last resort is not set
Destination Gateway Dist/Metric Last Change
----------- ------- ----------- -----------
C 10.0.13.0/24 Direct, Gi 3/14 0/0 00:00:10
C 10.0.23.0/24 Direct, Gi 3/21 0/0 00:00:03
C 192.168.1.0/24 Direct, Lo 0 0/0 00:00:32
S 192.168.1.1/32 via 10.0.13.1, Gi 3/14 1/0 00:00:10
S 192.168.1.2/32 via 10.0.23.2, Gi 3/21 1/0 00:00:03
Loopback 0
2001:0db8:9999:2:: /48
(192.168.1.2 /24)
GigE 2/11 GigE 2/31
2001:0db8:1021:2:: /48 2001:0db8:1023:2:: /48
(10.0.12.2 /24) (10.0.23.2 /24)
R2
GigE 1/21
2001:0db8:1021:1:: /48 GigE 3/21
2001:0db8:1023:3:: /48
(10.0.12.1 /24)
(10.0.23.3 /24)
Loopback 0
2001:0db8:9999:1:: /48 R1 Loopback 0
R3
(192.168.1.1 /24) GigE 1/34 2001:0db8:9999:3:: /48
2001:0db8:1022:1:: /48 (192.168.1.3 /24)
(10.0.13.1 /24)
AREA A
Full Mesh
The unique benefit of a dynamic LAG is that its ports can toggle between participating in the LAG or
acting as dedicated ports, whereas ports in a static LAG must be specifically removed from the LAG in
order to act alone.
FTOS uses LACP to create dynamic LAGs. LACP provides a standardized means of exchanging
information between two systems (also called Partner Systems) and automatically establishes the LAG
between the systems. LACP permits the exchange of messages on a link to allow their LACP instances to:
• Reach agreement on the identity of the LAG to which the link belongs.
• Move the link to that LAG.
• Enable the transmission and reception functions in an orderly manner.
The FTOS implementation of LACP is based on the standards specified in the IEEE 802.3: “Carrier sense
multiple access with collision detection (CSMA/CD) access method and physical layer specifications.”
packets are only exchanged between ports that are configured as LACP capable.
% Error: This port property does not match with other LAG member.
[no] port-channel-protocol lacp INTERFACE Enable or disable LACP on any LAN port:
• Default is “LACP disabled”
• This command creates a new context.
Create a LAG
To create a dynamic port channel (LAG), define the LAG and then the LAG interfaces. Use the interface
port-channel and switchport commands, as shown in Figure 24-1, which uses the example of LAG 32:
FTOS(conf)#interface port-channel 32
FTOS(conf-if-po-32)#no shutdown
FTOS(conf-if-po-32)#switchport
The LAG is in the default VLAN. To place the LAG into a non-default VLAN, use the tagged command
on the LAG (Figure 24-2):
Figure 24-2. Placing a LAG into a Non-default VLAN
FTOS(conf)#interface vlan 10
FTOS(conf-if-vl-10)#tagged port-channel 32
After creating a LAG, configure the dynamic LAG interfaces. Figure 24-3 shows ports 3/15, 3/16, 4/15,
and 4/16 added to LAG 32 in LACP mode with the command port-channel-protocol lacp.
The port-channel 32 mode active command shown above may be successfully issued as long as there is
no existing static channel-member configuration in LAG 32.
PDUs are exchanged between port channel (LAG) interfaces to maintain LACP sessions. PDUs are
transmitted at either a slow or fast transmission rate, depending upon the LACP timeout value. The timeout
value is the amount of time that a LAG interface waits for a PDU from the remote system before bringing
the LACP session down. The default timeout value is 1 second; it can be configured to be 30 seconds.
Invoking the longer timeout might prevent the LAG from flapping if the remote system is up but
temporarily unable to transmit PDUs due to a system interruption.
Note: The 30-second timeout is available for dynamic LAG interfaces only. The lacp long-timeout
command can be entered for static LAGs, but it has no effect.
Note: View PDU exchanges and the timeout value using the command debug lacp. See Monitor and
Debugging LACP on page 546.
[no] debug lacp [config | events | pdu EXEC Debug LACP, including configuration and events.
[in | out | [interface [in | out]]]]
In Figure 24-5, line-rate traffic from R1 destined for R4 follows the lowest-cost route via R2, as shown.
Traffic is equally distributed between LAGs 1 and 2. If LAG 1 fails, all traffic from R1 to R4 flows across
LAG 2 only. This condition over-subscribes the link, and packets are dropped.
1
Po
2
Po
R1 Po 2 over-subscribed
R2 R3
fnC0049mp
To avoid packet loss, traffic must be re-directed through the next lowest-cost link (R3 to R4). FTOS has the
ability to bring LAG 2 down in the event that LAG 1 fails, so that traffic can be re-directed, as described.
This is what is meant by Shared LAG State Tracking. To achieve this functionality, you must group LAG 1
and LAG 2 into a single entity, called a failover group.
2 Create a failover group and specify the group number port-channel CONFIG-PO-FAILOVER-GRP
two port-channels that will be members number port-channel number
of the group.
In Figure 24-6, LAGs 1 and 2 have been placed into to the same failover group.
Figure 24-6. Configuring Shared LAG State Tracking
R2#config
R2(conf)#port-channel failover-group
R2(conf-po-failover-grp)#group 1 port-channel 1 port-channel 2
View the failover group configuration using the show running-configuration po-failover-group
command, as shown in Figure 24-7.
upon the failure. This effect is logged by Message 2, in which a console message declares both LAGs
down at the same time.
1
Po
2
Po
R1
R2 R3
fnC0049mp
View the status of a failover group member using the command show interface port-channel, as shown in
Figure 24-9.
Note: The set of console messages shown in Message 2 appear only if Shared LAG State Tracking is
configured on that router (the feature can be configured on one or both sides of a link). For example, in
Figure 24-8, if Shared LAG State Tracking is configured on R2 only, then no messages appear on R4
regarding the state of LAGs in a failover group.
Configure LACP to be hitless using the command redundancy protocol lacp from CONFIGURATION
mode, as shown in Figure 24-10.
Port Channel 10
ALPHA
BRAVO
Gig 2/31 Gig 3/21
Alpha#sho lacp 10
Port-channel 10 admin up, oper up, mode lacp Shows LAG status
Actor System ID: Priority 32768, Address 0001.e806.953e
Partner System ID: Priority 32768, Address 0001.e809.c24a
Actor Admin Key 10, Oper Key 10, Partner Oper Key 10
LACP LAG 10 is an aggregatable link
Port Gi 2/32 is enabled, LACP is enabled and mode is lacp Interfaces participating in the LAG
Actor Admin: State ACEHJLMP Key 10 Priority 32768 are included here.
Oper: State ACEGIKNP Key 10 Priority 32768
Partner Admin: State BDFHJLMP Key 0 Priority 0
Oper: State ACEGIKNP Key 10 Priority 32768
!
interface GigabitEthernet 2/31
no ip address
!
port-channel-protocol LACP
port-channel 10 mode active
no shutdown
!
Alpha(conf-if-gi-2/31)#
interface Port-channel 10
no ip address
switchport
no shutdown
!
interface GigabitEthernet 3/21
no ip address
!
port-channel-protocol LACP
port-channel 10 mode active
no shutdown
Bravo(conf-if-gi-3/21)#end
int port-channel 10
no ip address
switchport
no shutdown
show config
Force10#
Force10#show lacp 10
Port-channel 10 admin up, oper up, mode lacp Shows LAG status
Actor System ID: Priority 32768, Address 0001.e809.c24a
Partner System ID: Priority 32768, Address 0001.e806.953e
Actor Admin Key 10, Oper Key 10, Partner Oper Key 10
LACP LAG 10 is an aggregatable link
Port Gi 3/22 is enabled, LACP is enabled and mode is lacp Interfaces participating in the LAG
Actor Admin: State ACEHJLMP Key 10 Priority 32768 are included here.
Oper: State ACEGIKNP Key 10 Priority 32768
Partner Admin: State BDFHJLMP Key 0 Priority 0
Oper: State ACEGIKNP Key 10 Priority 32768
PPP is a connection-oriented protocol that enables layer two links over a variety of different physical layer
connections. It is supported on both synchronous and asynchronous lines, and can operate in half-duplex or
full-duplex mode. It was designed to carry IP traffic but is general enough to allow any type of network
layer datagram to be sent over a PPP connection. As its name implies, it is for point-to-point connections
between exactly two devices, and assumes that frames are sent and received in the same order.
Layer 2 | 559
Clear the MAC Address Table
www.dell.com | support.dell.com
Disable MAC address aging for all dynamic mac-address-table aging-time 0 CONFIGURATION
entries.
FTOS Behavior: The time elapsed before the configured MAC aging time expires is not precisely as
configured. For example, the VLAN configuration mac-address-table aging-time 1, does not remove
dynamic entries from the CAM after precisely 1 second. The actual minimum aging time for entries is
approximately 5 seconds because this is the default MAC address table scanning interval. Therefore,
MAC aging configurations of less than 5 seconds, as in this example, might be ineffective. Configuring
mac-address-table station-move time-interval 500, solves this limitation. Reducing the scanning interval
to the minimum, 500 milliseconds, increases the detection speed, which results in FTOS clearing
entries closer to the actual desired aging time.
560 | Layer 2
Configure a Static MAC Address
A static entry is one that is not subject to aging. Static entries must be entered manually:
Create a static MAC address entry in the MAC address table. mac-address-table static CONFIGURATION
Display the contents of the MAC address table. show mac-address-table [address | EXEC Privilege
• address displays the specified entry. aging-time [vlan vlan-id]| count |
• aging-time displays the configured aging-time. dynamic | interface | static | vlan]
• count displays the number of dynamic and static entries
for all VLANs, and the total number of entries.
• dynamic displays only dynamic entries
• interface displays only entries for the specified
interface.
• static displays only static entries.
• vlan displays only entries for the specified VLAN.
Layer 2 | 561
MAC Learning Limit
www.dell.com | support.dell.com
MAC Address Learning Limit is a method of port security on Layer 2 physical, port-channel, and VLAN
interfaces. It enables you to set an upper limit on the number of MAC addresses learned on an interface/
VLAN. After the limit is reached, the system drops all traffic from a device with an unlearned MAC
address.
FTOS Behavior: When configuring MAC Learning Limit on a port or VLAN the configuration is
accepted (becomes part of running-config and show mac learning-limit interface) before the system
verifies that sufficient CAM space exists. If the CAM check fails, the a message is displayed:
%E90MH:5 %ACL_AGENT-2-ACL_AGENT_LIST_ERROR: Unable to apply access-list
Mac-Limit on GigabitEthernet 5/84
In this case, the configuration is still present in the running-config and show output. Remove the configuration
before re-applying a MAC learning limit with lower value. Also, ensure that Syslog messages can be viewed on
your session.
Note: The CAM-check failure message beginning in FTOS version 8.3.1.0 is different from versions
8.2.1.1 and earlier, which read:
% Error: ACL returned error
% Error: Remove existing limit configuration if it was configured before
Specify the number of MAC addresses that the system mac learning-limit address_limit INTERFACE
can learn off a Layer 2 interface.
Three options are available with the mac learning-limit command: dynamic, no-station-move, and
station-move,
Note: An SNMP trap is available for mac learning-limit station-move. No other SNMP traps are available
for MAC Learning Limit, including limit violations.
562 | Layer 2
mac learning-limit dynamic
After you enable a MAC learning limit, MAC addresses learned on the port and entered in the MAC
address table are static by default. If you configure the MAC learning dynamic option, learned MAC
addresses are stored in the dynamic region of the table and are subject to aging. Entries created before this
option is set are not affected.
On the C-Series and S-Series, the MAC address table is stored in the Layer 2 FIB region of CAM. The
Layer 2 FIB region allocates space for static MAC address entries and dynamic MAC address entries.
On the E-Series, the MAC address table is stored in the Layer 2 ACL region. All MAC address entries on
the E-Series are dynamic.
FTOS Behavior: If you do not configure the dynamic option, the C-Series and S-Series do not detect
station moves in which a MAC address learned off of a MAC-limited port is learned on another port on
same line card. Therefore, FTOS does not take any configured station-move violation action. When a
MAC address is relearned on any other linecard (any line card except the one to which the original
MAC-limited port belongs), the station-move is detected, and the system takes the configured the
violation action.
Layer 2 | 563
mac learning-limit no-station-move
www.dell.com | support.dell.com
Note: Sticky MAC is not supported on the S25 or S50 in FTOS release 8.4.2.6.
The no-station-move option, also known as “sticky MAC,” provides additional port security by
preventing a station move. When this option is configured, the first entry in the table is maintained instead
of creating a new entry on the new interface. no-station-move is the default behavior. Entries created before
this option is set are not affected.
FTOS Behavior: The C-Series and S-Series do not generate a station-move violation log entry for
physical interfaces or port-channels when you configure mac learning-limit or when you configure mac
learning-limit station-move-violation log. FTOS detects a station-move violation only when you
configure mac learning-limit dynamic, and logs the violation only when you configure the mac
learning-limit station-move-violation log, as shown below:
FTOS(conf-if-gi-1/1)#show config
!
interface GigabitEthernet 1/1
no ip address
switchport
mac learning-limit 1 dynamic no-station-move
mac learning-limit station-move-violation log
no shutdown
You can provide security for the dynamically-learned MAC addresses of trusted devices that are allowed to
access a port by configuring the sticky option. This MAC learning option allows a switch to maintain the
association of a trusted MAC address with a port and prevents a device from accessing the switch on
another interface until the option is disabled.
Trusted MAC addresses are added to the running configuration and “stick” to the port on which they are
learned even if an interface goes down and comes back up. If you save sticky MAC addresses to the
start-up configuration file by entering the write config command, the addresses are deleted from the
running-configuration, do not have to be dynamically relearned, and do not change when the switch
reboots. Any sticky MAC addresses learned after the write config is performed are not saved after a reboot.
The sticky MAC address option is supported on physical port and port-channel interfaces; it is not
supported on VLAN interfaces.
Static MAC addresses have a higher preference than sticky MAC addresses and are therefore not converted
with sticky-MAC learning.
564 | Layer 2
FTOS Behavior: The following conditions apply when you enable the sticky-MAC address option for
MAC learning on an interface:
• When you enable the sticky MAC learning option, all dynamically-learned MAC addresses that
you save to the start-up configuration are converted to statically-configured MAC addresses
when you reboot the switch.
• When the switch reboots, the interface deletes all previously learned dynamic MAC addresses
and regenerates the list of sticky MAC addresses in the running-configuration with
statically-configured and newly learned dynamic MAC addresses. During the new session,
MAC addresses that are dynamically-learned are automatically converted to sticky MAC
addresses until the configured limit is reached.
• The aging out of dynamically-learned MAC addresses on the interface is disabled and restarts
only when you disable the sticky option.
• A “station move” is not supported and a trusted MAC address in the table cannot be learned off
another interface.
• The list of sticky MAC addresses is converted back to their former dynamic addresses.
• New dynamically-learned MAC addresses are no longer converted to sticky MAC
addresses.
• After a line card reset, a port or port-channel interface enabled for sticky-MAC learning
dynamically learns the MAC addresses of devices attached to ports on other line cards only if
the attached devices are transmitting continuous traffic on default VLAN 1.
Note: A Sticky MAC configuration limits the number of MAC addresses that can be learned on a port/
port-channel interface. Because a trunk port receives trusted MAC addresses not from a single user or
VLAN but from multiple users and VLANs, it is difficult to specify the exact MAC address limit on a trunk
port. As a result, traffic from MAC addresses that exceed the limit may be dropped.
It is recommended that you configure the sticky MAC option only on an access port, which is directly
connected to a host and on which you want to limit the number of learned MAC addresses.
It is not recommended that you configure sticky MAC learning on inter-bridge ports. If there is a topology
change, traffic may be blocked because a sticky MAC address cannot be moved across the ports.
To enable and display sticky MAC address learning on a Layer 2 physical port or port-channel interface,
enter the following commands:
Display the MAC addresses with sticky MAC address show mac-address-table EXEC
learning. EXEC Privilege
Layer 2 | 565
Displaying MAC Learning-Limited Interfaces
www.dell.com | support.dell.com
Display a list of all interfaces with a MAC learning show mac learning-limit EXEC Privilege
limit.
Generate a system log message when the MAC learning learn-limit-violation log
INTERFACE
limit is exceeded.
Shut down the interface and generate a system log learn-limit-violation shutdown
INTERFACE
message when the MAC learning limit is exceeded.
no-station-move is the default behavior (see mac learning-limit no-station-move on page 564). You can
configure the system to take an action if a station move occurs using one the following options with the
mac learning-limit command:.
Shut down both the first and second port station-move-violation shutdown-both
INTERFACE
to learn the MAC address.
566 | Layer 2
To display a list of interfaces configured with MAC learning limit or station move violation actions:
Display a list of all of the interfaces show mac learning-limit violate-action CONFIGURATION
configured with MAC learning limit or
station move violation.
Note: You can also reset an interface by shutting it down with the shutdown command, and then
reenabling it with the no shutdown command.
One application of Per-VLAN MAC Learning Limit is on access ports. In Figure 25-1, an Internet
Exchange Point (IXP) connects multiple Internet Service Provider (ISP). An IXP can provide several types
of services to its customers including public an private peering. Public peering means that all customers are
connected to one VLAN, and if one ISP wants to peer with another ISP, it establishes a BGP peering
session over this VLAN. Private Peering means that the IXP sets up a separate VLAN between two
customers that want to peer privately; only the ports of these two ISPs would belong to this VLAN, and
they would peer via BGP. In Figure 25-1, Per-VLAN MAC Learning Limit is used on the access ports for
the ISPs that have subscribed to private and public peering since these access ports are members of
multiple VLANs.
Layer 2 | 567
Figure 25-1. Per-VLAN MAC Learning Limit
www.dell.com | support.dell.com
802.1QTagged
interface GigabitEthernet 1/1
...
mac learning-limit 1 vlan 10
mac learning-limit 1 vlan 20
ISP A
ISP B
ISP C
Configure a MAC learning limit on a mac learning-limit limit vlan vlan-id INTERFACE
VLAN.
Display the MAC learning limit show mac learning-limit [interface slot/port [vlan EXEC Privilege
counters for a VLAN. vlan-id]]
568 | Layer 2
NIC Teaming
NIC teaming is a feature that allows multiple network interface cards in a server to be represented by one
MAC address and one IP address in order to provide transparent redundancy, balancing, and to fully utilize
network adapter resources.
Figure 25-2 shows a topology where two NICs have been teamed together. In this case, if the primary NIC
fails, traffic switches to the secondary NIC, since they are represented by the same set of addresses.
X Port 0/1
MAC: A:B:C:D
A:B
IP: 1.1.1.1
k
Active Lin
Port 0/5
fnC0025mp
When NIC teaming is employed, consider that the server MAC address is originally learned on Port 0/1 of
the switch (Figure 25-3). When the NIC fails, the same MAC address is learned on Port 0/5 of the switch.
The MAC address must be disassociated with the one port and re-associated with another in the ARP table;
in other words, the ARP entry must be “moved”. To ensure that this happens, you must configure the
command mac-address-table station-move refresh-arp on the Dell Force10 switch at the time that NIC
teaming is being configured on the server.
Note: If this command is not configured, traffic continues to be forwarded to the failed NIC until the ARP
entry on the switch times out.
Layer 2 | 569
Figure 25-3. Configuring mac-address-table station-move refresh-arp Command
www.dell.com | support.dell.com
X Port 0/1
Move MAC
MAC: A:B:C:D
A:B address
IP: 1.1.1.1
k
Active Lin
Port 0/5
fnC0026mp
threshold is the number of times a station move must be detected in a single interval in order to trigger a
system log message. For example, if you configure mac-address-table station-move threshold 2
time-interval 5000, and 4 station moves occur in 5000ms, then two log messages are generated.
Microsoft Clustering
Microsoft Clustering is supported only on platform: e
Microsoft Clustering allows multiple servers using Microsoft Windows to be represented by one MAC
address and IP address in order to provide transparent failover or balancing. FTOS does not recognize
server clusters by default; it must be configured to do so.
Default Behavior
When an ARP request is sent to a server cluster, either the active server or all of the servers send a reply,
depending on the cluster configuration. If the active server sends a reply, the Dell Force10 switch learns the
active server’s MAC address. If all servers reply, the switch registers only the last received ARP reply, and
the switch learns one server’s actual MAC address (Figure 25-4); the virtual MAC address is never
learned.
570 | Layer 2
Since the virtual MAC address is never learned, traffic is forwarded to only one server rather than the
entire cluster, and failover and balancing are not preserved (Figure 25-5).
IPS1
Server1: Ethernet Frame Header ARP Reply
MACS1
La VLAN 1 Client
st A
RP
Re
ply
Server2: IPS2
MACS2
Microsoft Server Cluster: IPCluster
MACCluster
IPS3
Server3:
MACS3
IPS4
Server4:
MACS4
fnC0027mp
VLAN 1 Client
Server2: IPS2
MACS2
Microsoft Server Cluster: IPCluster
MACCluster
IPS3 Data
Server3:
MACS3
IPS4
Server4:
MACS4
fnC0028mp
As shown in Figure 25-6, the server MAC address is given in the Ethernet frame header of the ARP reply,
while the virtual MAC address representing the cluster is given in the payload. The ip vlan-flooding
command directs the system to discover that there are different MAC addresses in an ARP reply and
associate the virtual MAC address with the VLAN connected to the cluster. Then, all traffic destined for
the cluster is flooded out of all member ports. Since all of the servers in the cluster receive traffic, failover
and balancing are preserved.
Layer 2 | 571
Figure 25-6. Server Cluster: Failover and Balancing Preserved with the vlan-flooding Command
www.dell.com | support.dell.com
IPS1
Server1: Ethernet Frame Header ARP Reply
MACS1
VLAN 1 Client
Server2: IPS2
MACS2
Microsoft Server Cluster: IPCluster
MACCluster
IPS3 Data
Server3:
MACS3
IPS4
Server4:
MACS4
fnC0029mp
vlan-flooding configured
The ARP entries exist in the secondary RPM CAM, so failover has no effect on the feature.
572 | Layer 2
Configuring Redundant Pairs
Configuring Redundant Pairs is supported:
• On physical interfaces on platforms ces
• On static and dynamic port-channel interfaces on platforms ces
The Redundant Pairs feature allows you to provide redundancy for Layer 2 links without using Spanning
Tree (STP). You create redundant links by configuring pairs of Layer 2 (physical or port-channel)
interfaces so that only one interface is up and carries user traffic at any time. Interfaces on either side of a
link provide backup for the primary link. Redundant pairs are useful in service-provider and enterprise
networks in which you do not run STP on switches—for example, networks with Digital Subscriber Line
Access Mutiplexers (DSLAM)—to avoid creating switching loops (see Figure 25-7).
Note: For details on STP, see Chapter 52, “Spanning Tree Protocol,” on page 1049.
R3 R4
3/41 4/31
Backup Link
3/42 4/32
fnC0067mp
Force10(conf-if-gi-3/42)#switchport Force10(conf-if-gi-4/32)#switchport
Force10(conf-if-gi-3/42)#no shutdown Force10(conf-if-gi-4/32)#no shutdown
You configure a redundant pair by assigning a backup interface to a primary interface with the switchport
backup interface command. Initially, the primary interface is active and transmits traffic and the backup
interface remains down. If the primary fails for any reason, the backup transitions to an active UP state. If
the primary interface fails and later comes back up, it remains as the backup interface for the redundant
pair.
FTOS supports only Gigabit and 10-Gigabit ports and port channels as primary/backup interfaces in
redundant pairs. (A port channel is also referred to as a Link Aggregation Group (LAG). See Port Channel
Interfaces on page 428 for more information.)
In a redundant pair, any combination of physical and port-channel interfaces is supported as the two
interfaces in a redundant pair. For example, you can configure a static (without LACP) or dynamic (with
LACP) port-channel interface as either the primary or backup link in a redundant pair with a Gigabit
interface.
Layer 2 | 573
To ensure that existing network applications see no difference when a primary interface in a redundant pair
www.dell.com | support.dell.com
transitions to the backup interface, be sure to apply identical configurations of other traffic parameters to
each interface.
If you remove an interface in a redundant link (remove the line card of a physical interface or delete a port
channel with the no interface port-channel command), the redundant pair configuration is also removed.
574 | Layer 2
In Figure 25-8, interface 3/41 is a backup interface for 3/42, and 3/42 is DOWN as shown in message
Message 1. If 3/41 fails, 3/42 transitions to the UP state, which makes the backup link active. A message
similar to Message 1 appears whenever you configure a backup port.
02:28:04: %RPM0-P:CP %IFMGR-5-L2BKUP_WARN: Do not run any Layer2 protocols on Gi 3/41 and Gi
3/42
02:28:04: %RPM0-P:CP %IFMGR-5-OSTATE_DN: Changed interface state to down: Gi 3/42
02:28:04: %RPM0-P:CP %IFMGR-5-STATE_ACT_STBY: Changed interface state to standby: Gi 3/42
Figure 25-8. CLI for Configuring Redundant Layer 2 Pairs without Spanning Tree
FTOS(conf-if-range-gi-3/41-42)#switchport backup interface GigabitEthernet 3/42
FTOS(conf-if-range-gi-3/41-42)#show config
!
interface GigabitEthernet 3/41
no ip address
switchport
switchport backup interface GigabitEthernet 3/42
no shutdown
!
interface GigabitEthernet 3/42
no ip address
switchport
no shutdown
FTOS(conf-if-range-gi-3/41-42)#
FTOS(conf-if-range-gi-3/41-42)#do show ip int brief | find 3/41
GigabitEthernet 3/41 unassigned YES Manual up up
GigabitEthernet 3/42 unassigned NO Manual up down
[output omitted]
FTOS(conf-if-range-gi-3/41-42)#interface gig 3/41
FTOS(conf-if-gi-3/41)#shutdown
00:24:53: %RPM0-P:CP %IFMGR-5-ASTATE_DN: Changed interface Admin state to down: Gi 3/41
FTOS(conf-if-gi-3/41)#00:24:55: %RPM0-P:CP %IFMGR-5-OSTATE_DN: Changed interface state to
down: Gi 3/41
00:24:55: %RPM0-P:CP %IFMGR-5-INACTIVE: Changed Vlan interface state to inactive: Vl 1
00:24:55: %RPM0-P:CP %IFMGR-5-OSTATE_UP: Changed interface state to up: Gi 3/42
00:24:55: %RPM0-P:CP %IFMGR-5-ACTIVE: Changed Vlan interface state to active: Vl 1
00:24:55: %RPM0-P:CP %IFMGR-5-STATE_STBY_ACT: Changed interface state from standby to active:
Gi 3/42
Layer 2 | 575
Restricting Layer 2 Flooding
www.dell.com | support.dell.com
For example, if a VLAN that has an (auto-negotiated) 100M port and a 1G port on the same port-pipe, and
you enable Restricted Layer 2 Flooding with a minimum speed of 1G, multicast traffic is only flooded on
the 1G port.
Enable Restricted Layer 2 Flooding using the command restrict-flooding from INTERFACE VLAN mode.
In combination with restrict-flooding, you can use the command mac-flood-list from CONFIGURATION
mode, without the min-speed option, to allow some specific multicast traffic (identified using a MAC
address range you specify) to be flooded on all ports regardless of the restrict-flooding configuration.
Conversely, if you want all multicast traffic to be flooded on all ports, but some specific traffic to be
restricted, use mac-flood-list with the min-speed option, but without restrict-flooding configured. This
configuration restricts flooding only for traffic with destination multicast MAC addresses within the
multicast MAC address range you specify.
In Figure 25-9, flooding of unknown multicast traffic is restricted to 1G ports on VLAN100 using the
command restrict-flooding. However, the command mac-flood-list allows traffic with MAC addresses
01:01:e8:00:00:00 to 01:01:e8:ff:ff:ff to be flooded on all ports regardless of link speed.
Figure 25-9. Restricting Layer 2 Multicast Flooding over Low Speed Ports
576 | Layer 2
Far-end Failure Detection
Far-end Failure Detection is supported only on platform: e
Far-end Failure Detection (FEFD) is a protocol that senses remote data link errors in a network. It responds
by sending a unidirectional report that triggers an echoed response after a specified time interval.
Interval
R1 R2
Echo
Layer2 001
The report consists of several packets in SNAP format that are sent to the nearest known MAC address.
In the event of a far-end failure, the device stops receiving frames, and after the specified time interval
assumes that the far-end is not available. The connecting line protocol is brought down so that upper layer
protocols can detect the neighbor unavailability faster.
Layer 2 | 577
5. If the FEFD system has been set to Aggressive mode and neighboring echoes are not received after
www.dell.com | support.dell.com
three intervals, the state changes to Err-disabled. All interfaces in the Err-disabled state must be
manually reset using the fefd reset [interface] command in EXEC privilege mode (it can be done
globally or one interface at a time) before the FEFD enabled system can become operational again.
Configuring FEFD
You can configure FEFD for all interfaces from CONFIGURATION mode, or on individual interfaces
from INTERFACE mode.
To enable FEFD globally on all interfaces enter the command fefd-global in CONFIGURATION mode.
Report interval frequency and mode adjustments can be made by supplementing this command as well.
578 | Layer 2
Step Task Command Syntax Command Mode
Entering the show fefd command in EXEC privilege mode displays information about the state of each
interface.
FTOS#show fefd
FEFD is globally 'ON', interval is 3 seconds, mode is 'Normal'.
Entering the command fefd in INTERFACE mode enables FEFD on a per interface basis. To change the
FEFD mode, supplement the fefd command in INTERFACE mode by entering the command fefd [mode
{aggressive | normal}].
To disable FEFD protocol on one interface, enter the command fefd disable in INTERFACE mode.
Disabling an interface will shut down all protocols working on that interface’s connected line, and will not
delete your previous FEFD configuration which can be enabled again at any time.
Layer 2 | 579
Figure 25-12. FEFD enabled interface configuration
www.dell.com | support.dell.com
FTOS(conf-if-gi-1/0)#show config
!
interface GigabitEthernet 1/0
no ip address
switchport
fefd mode normal
no shutdown
Debugging FEFD
By entering the command debug fefd events in EXEC privilege mode, output is displayed whenever events
occur that initiate or disrupt an FEFD enabled connection.
Entering the command debug fefd packets in EXEC privilege mode will provide output for each packet
transmission over the FEFD enabled connection.
580 | Layer 2
During an RPM Failover
In the event that an RPM failover occurs, FEFD will become operationally down on all enabled ports for
approximately 8-10 seconds before automatically becoming operational again.
Layer 2 | 581
www.dell.com | support.dell.com
582
|
Layer 2
26
Link Layer Discovery Protocol
Link Layer Discovery Protocol is supported only on platforms: ces
LLDP is supported on the E-Series ExaScale platform with FTOS 8.1.1.0 and later.
TLV Header
fnC0057mp
1 octet 1- 255 octets
TLVs are encapsulated in a frame called an LLDP Data Unit (LLDPDU) (Figure 26-2), which is
transmitted from one LLDP-enabled device to its LLDP-enabled neighbors. LLDP is a one-way protocol.
LLDP-enabled devices (LLDP agents) can transmit and/or receive advertisements, but they cannot solicit
and do not respond to advertisements.
There are five types of TLVs. All types are mandatory in the construction of an LLDPDU except Optional
TLVs. The inclusion of individual Optional TLVs is user configurable.
Preamble Start Frame Destination MAC Source MAC Ethernet Type LLDPDU Padding FCS
Delimiter (01:80:C2:00:00:0E) (0x88CC)
TLV 1 TLV 2 TLV 3 TLV 4 TLV 5 TLV 6 TLV 7 TLV 127 TLV 0
Chassis ID Port ID Port Description System Name System Description System Capabilities Management Addr Organizationally Specific End of LLDPDU
fnC0047mp
• Management TLVs
• IEEE 802.1 and 802.3 Organizationally Specific TLVs
• TIA-1057 Organizationally Specific TLVs
Management TLVs
A Management TLV is an Optional TLVs sub-type. This kind of TLV contains essential management
information about the sender. The five types are described in Table 26-2.
Organizationally specific TLVs can be defined by a professional organization or a vendor. They have two
mandatory fields (Figure 26-3) in addition to the basic TLV fields (Figure 26-1):
• Organizationally Unique Identifier (OUI)—a unique number assigned by the IEEE to an organization
or vendor.
• OUI Sub-type—These sub-types indicate the kind of information in the following data field. The
sub-types are determined by the owner of the OUI.
Figure 26-3. Organizationally Specific TLV
Organizationally
TLV Type TLV Length Organizationally Organizationally Specific
Unique ID
(127) Defined Sub-type Data
(OUI)
fnC0052mp
7 bits 9 bits 3 octets 1 octet 0 - 507 octets
Optional TLVs
4 Port description A user-defined alphanumeric string that describes the port. FTOS does not
currently support this TLV.
5 System name A user-defined alphanumeric string that identifies the system.
6 System description A user-defined alphanumeric string that describes the system
The LLDP-MED Capabilities TLV communicates the types of TLVs that the endpoint device and the
network connectivity device support. LLDP-MED network connectivity devices must transmit the
Network Policies TLV.
• The value of the LLDP-MED Capabilities field in the TLV is a 2 octet bitmap (Figure 26-4), each bit
represents an LLDP-MED capability (Table 26-4).
• The possible values of the LLDP-MED Device Type is listed in Table 26-5. The Dell Force10 system
is a Network Connectivity device, which is Type 4.
When you enable LLDP-MED in FTOS (using the command advertise med) the system begins
transmitting this TLV.
A network policy in the context of LLDP-MED is a device’s VLAN configuration and associated Layer 2
and Layer 3 configurations, specifically:
• VLAN ID
• VLAN tagged or untagged status
• Layer 2 priority
• DSCP value
The application type is a represented by an integer (the Type integer in Table 26-6), which indicates a
device function for which a unique network policy is defined. An individual LLDP-MED Network Policy
TLV is generated for each application type that you specify with the FTOS CLI (Advertising TLVs on
page 592).
Note: With regard to Table 26-6, signaling is a series of control packets that are exchanged between an
endpoint device and a network connectivity device to establish and maintain a connection. These signal
packets might require a different network policy than the media packets for which a connection is made. In
this case, configure the signaling application.
The Extended Power via MDI TLV enables advanced PoE management between LLDP-MED endpoints
and network connectivity devices. Advertise the Extended Power via MDI on all ports that are connected
to an 802.3af powered, LLDP-MED endpoint device.
• Power Type—there are two possible power types: Power Sourcing Entity (PSE) or Power Device
(PD). The Dell Force10 system is a PSE, which corresponds to a value of 0, based on the TIA-1057
specification.
• Power Source—there are two possible power sources: Primary and Backup. The Dell Force10 system
is a Primary Power Source, which corresponds to a value of 1, based on the TIA-1057 specification.
• Power Priority—there are three possible priorities: Low, High, and Critical. On Dell Force10
systems, the default power priority is “High,” which corresponds to a value of 2 based on the
TIA-1057 specification. You can configure a different power priority through the CLI, Dell Force10
also honors the power priority value sent by the powered device. However, the CLI configuration takes
precedence.
• Power Value—Dell Force10 advertises the maximum amount of power that can be supplied on the
port. By default it is 15.4W, which corresponds to a Power Value of 130, based on the TIA-1057
specification. You can advertise a different Power Value using the max-milliwatts option with the power
inline auto | static command. Dell Force10 also honors the power value (power requirement) sent by
the powered device when the port is configured for power inline auto.
Figure 26-6. Extended Power via MDI TLV
LLDP Compatibility
• Spanning Tree and Force10 Ring Protocol “blocked” ports allow LLDPDUs.
• 802.1X controlled ports do not allow LLDPDUs until the connected device is authenticated.
R1(conf)#protocol lldp
R1(conf-lldp)#?
advertise Advertise TLVs
disable Disable LLDP protocol globally
end Exit from configuration mode
exit Exit from LLDP configuration mode
hello LLDP hello configuration
mode LLDP mode configuration (default = rx and tx)
multiplier LLDP multiplier configuration
no Negate a command or set its defaults
show Show LLDP configuration
R1(conf-lldp)#exit
R1(conf)#interface gigabitethernet 1/31
R1(conf-if-gi-1/31)#protocol lldp
R1(conf-if-gi-1/31-lldp)#?
advertise Advertise TLVs
disable Disable LLDP protocol on this interface
end Exit from configuration mode
exit Exit from LLDP configuration mode
hello LLDP hello configuration
mode LLDP mode configuration (default = rx and tx)
multiplier LLDP multiplier configuration
no Negate a command or set its defaults
show Show LLDP configuration
R1(conf-if-gi-1/31-lldp)#
Enabling LLDP
LLDP is disabled by default. LLDP can be enabled and disabled globally or per interface. If LLDP is
enabled globally, all up interfaces send periodic LLDPDUs. To enable LLDP:
Advertising TLVs
You can configure the system to advertise TLVs out of all interfaces or out of specific interfaces.
• If you configure the system globally, all interfaces will send LLDPDUs with the specified TLVs.
If LLDP is configured both globally and at interface level, the interface level configuration overrides the
global configuration. To advertise TLVs:
Command
Step Task Command Mode
2 Advertise one or more TLVs. Include the keyword for advertise {management-tlv | PROTOCOL
each TLV you want to advertise. dot1-tlv | dot3-tlv | med} LLDP
• For management TLVs: system-capabilities,
system-description
• For 802.1 TLVs: port-protocol-vlan-id,
port-vlan-id, vlan-name
• For 802.3 TLVs: max-frame-size
• For TIA-1057 TLVs:
•guest-voice
•guest-voice-signaling
•location-identification
•power-via-mdi
•softphone-voice
•streaming-video
•video-conferencing
•video-signaling
•voice
•voice-signaling
In Figure 26-8, LLDP is enabled globally. R1 and R2 are transmitting periodic LLDPDUs that contain
management, 802.1, and 802.3 TLVs.
R2 R1
2/11 1/21
LLDPDU
fnC0074mp
Display the LLDP configuration using the command show config in either CONFIGURATION or
INTERFACE mode, as shown in Figure 26-9 and Figure 26-10, respectively
========================================================================
R1(conf)#protocol lldp
R1(conf-lldp)#show config
!
protocol lldp
advertise dot1-tlv port-protocol-vlan-id port-vlan-id
advertise dot3-tlv max-frame-size
advertise management-tlv system-capabilities system-description
no disable
R1(conf-lldp)#mode ?
rx Rx only
tx Tx only
R1(conf-lldp)#mode tx
R1(conf-lldp)#show config
!
protocol lldp
advertise dot1-tlv port-protocol-vlan-id port-vlan-id
advertise dot3-tlv max-frame-size
advertise management-tlv system-capabilities system-description
mode tx
no disable
R1(conf-lldp)#no mode
R1(conf-lldp)#show config
!
protocol lldp
advertise dot1-tlv port-protocol-vlan-id port-vlan-id
advertise dot3-tlv max-frame-size
advertise management-tlv system-capabilities system-description
no disable
R1(conf-lldp)#
R1(conf-lldp)#show config
!
protocol lldp
advertise dot1-tlv port-protocol-vlan-id port-vlan-id
advertise dot3-tlv max-frame-size
advertise management-tlv system-capabilities system-description
no disable
R1(conf-lldp)#multiplier ?
<2-10> Multiplier (default=4)
R1(conf-lldp)#multiplier 5
R1(conf-lldp)#show config
!
protocol lldp
advertise dot1-tlv port-protocol-vlan-id port-vlan-id
advertise dot3-tlv max-frame-size
advertise management-tlv system-capabilities system-description
multiplier 5
no disable
R1(conf-lldp)#no multiplier
R1(conf-lldp)#show config
!
protocol lldp
advertise dot1-tlv port-protocol-vlan-id port-vlan-id
advertise dot3-tlv max-frame-size
advertise management-tlv system-capabilities system-description
no disable
R1(conf-lldp)#
Debugging LLDP
The command debug lldp enables you to view the TLVs that your system is sending and receiving.
• Use the debug lldp brief command to view a readable version of the TLVs.
• Use the debug lldp detail command to view a readable version of the TLVs plus a hexadecimal version
of the entire LLDPDU.
• Table lists the objects associated with received and transmitted TLVs.
• Table 26-8 lists the objects associated with the LLDP configuration on the local agent.
• Table 26-9 lists the objects associated with IEEE 802.1AB Organizationally Specific TLVs.
• Table 26-10 lists the objects associated with received and transmitted LLDP-MED TLVs.
TLV Type TLV Name TLV Variable System LLDP MIB Object
1 Chassis ID chassis ID subtype Local lldpLocChassisIdSubtype
Remote lldpRemChassisIdSubtype
chassid ID Local lldpLocChassisId
Remote lldpRemChassisId
2 Port ID port subtype Local lldpLocPortIdSubtype
Remote lldpRemPortIdSubtype
port ID Local lldpLocPortId
Remote lldpRemPortId
4 Port Description port description Local lldpLocPortDesc
Remote lldpRemPortDesc
5 System Name system name Local lldpLocSysName
Remote lldpRemSysName
6 System Description system description Local lldpLocSysDesc
Remote lldpRemSysDesc
7 System Capabilities system capabilities Local lldpLocSysCapSupported
Remote lldpRemSysCapSupported
8 Management Address enabled capabilities Local lldpLocSysCapEnabled
Remote lldpRemSysCapEnabled
management address length Local lldpLocManAddrLen
Remote lldpRemManAddrLen
management address subtype Local lldpLocManAddrSubtype
Remote lldpRemManAddrSubtype
management address Local lldpLocManAddr
Remote lldpRemManAddr
interface numbering subtype Local lldpLocManAddrIfSubtype
Remote lldpRemManAddrIfSubtype
interface number Local lldpLocManAddrIfId
Remote lldpRemManAddrIfId
OID Local lldpLocManAddrOID
Remote lldpRemManAddrOID
TLV Type TLV Name TLV Variable System LLDP MIB Object
127 Port-VLAN ID PVID Local lldpXdot1LocPortVlanId
Remote lldpXdot1RemPortVlanId
127 Port and Protocol port and protocol VLAN supported Local lldpXdot1LocProtoVlanSupported
VLAN ID Remote lldpXdot1RemProtoVlanSupported
port and protocol VLAN enabled Local lldpXdot1LocProtoVlanEnabled
Remote lldpXdot1RemProtoVlanEnabled
PPVID Local lldpXdot1LocProtoVlanId
Remote lldpXdot1RemProtoVlanId
127 VLAN Name VID Local lldpXdot1LocVlanId
Remote lldpXdot1RemVlanId
VLAN name length Local lldpXdot1LocVlanName
Remote lldpXdot1RemVlanName
VLAN name Local lldpXdot1LocVlanName
Remote lldpXdot1RemVlanName
TLV Sub-Type TLV Name TLV Variable System LLDP-MED MIB Object
1 LLDP-MED LLDP-MED Capabilities Local lldpXMedPortCapSupported
Capabilities lldpXMedPortConfigTLVsTx
Enable
Remote lldpXMedRemCapSupported,
lldpXMedRemConfigTLVsTx
Enable
LLDP-MED Class Type Local lldpXMedLocDeviceClass
Remote lldpXMedRemDeviceClass
2 Network Policy Application Type Local lldpXMedLocMediaPolicyApp
Type
Remote lldpXMedRemMediaPolicyAp
pType
Unknown Policy Flag Local lldpXMedLocMediaPolicyUnk
nown
Remote lldpXMedLocMediaPolicyUnk
nown
Tagged Flag Local lldpXMedLocMediaPolicyTag
ged
Remote lldpXMedLocMediaPolicyTag
ged
VLAN ID Local lldpXMedLocMediaPolicyVla
nID
Remote lldpXMedRemMediaPolicyVl
anID
L2 Priority Local lldpXMedLocMediaPolicyPrio
rity
Remote lldpXMedRemMediaPolicyPri
ority
DSCP Value Local lldpXMedLocMediaPolicyDsc
p
Remote lldpXMedRemMediaPolicyDs
cp
3 Location Identifier Location Data Format Local lldpXMedLocLocationSubtype
Remote lldpXMedRemLocationSubtyp
e
Location ID Data Local lldpXMedLocLocationInfo
Remote lldpXMedRemLocationInfo
TLV Sub-Type TLV Name TLV Variable System LLDP-MED MIB Object
4 Extended Power via Power Device Type Local lldpXMedLocXPoEDeviceTyp
MDI e
Remote lldpXMedRemXPoEDeviceTy
pe
Power Source Local lldpXMedLocXPoEPSEPower
Source,
lldpXMedLocXPoEPDPowerS
ource
Remote lldpXMedRemXPoEPSEPowe
rSource,
lldpXMedRemXPoEPDPower
Source
Power Priority Local lldpXMedLocXPoEPDPowerP
riority,
lldpXMedLocXPoEPSEPortP
DPriority
Remote lldpXMedRemXPoEPSEPowe
rPriority,
lldpXMedRemXPoEPDPower
Priority
Power Value Local lldpXMedLocXPoEPSEPortPo
werAv,
lldpXMedLocXPoEPDPower
Req
Remote lldpXMedRemXPoEPSEPowe
rAv,
lldpXMedRemXPoEPDPower
Req
Protocol Overview
MLD version 1 is analogous to IGMP version 2. MLD version 3 adds the ability to include and exclude
sources and is analogous to IGMP version 3.
MLD Version 1
Routers use MLD to learn which multicast addresses have listeners on each of their attached links. For
each link, the router keeps a list of which multicast addresses have listeners and a timer associated with
each of those addresses.
• Multicast Listener Query — a message sent by the Queerer to learn which multicast groups have
listeners.
• General Query — a query to which all listeners should respond.
• Multicast-Address-Specific Query — a query to which only listeners for the specified group
should respond.
• Multicast Listener Report — a message sent by listeners declaring their multicast group
subscriptions.
• Multicast Listener Done — a message sent by a listener declaring that it is leaving a multicast group.
response to a General or Multicast-Address-Specific Query. The value is zero in reports and Done
messages.
• Multicast Address — set to zero in General Queries, and set to the relevant multicast address in
multicast-address-specific queries and done messages.
Figure 27-1. MLD version 1 Packet Structure
Preamble Start Frame Destination MAC Source MAC Ethernet Type IPv6 Packet Padding FCS
Delimiter
Version Traffic Class Flow Label Payload Length Next Header Hop Limit Next Header Header Extension Options
Length (Router Alert) ICMPv6 Packet
(6) (0) (1) (58)
(0)
A host does not have to wait for a General Query to join a group. If a host wants to become a member of a
group for which the router is not currently forwarding traffic, it should send an unsolicited report.
When a router receives a report for a group, it either creates a new entry in the group membership table, or
it updates an existing entry by adding the interface on which the report arrived to the outgoing interface list
for the group.
When a Querier receives a Done message, it sends a Multicast-Address-Specific Query addressed to the
relevant multicast group. Hosts still interested in receiving traffic for that group (according to the
suppression mechanism) so that the group table entry is maintained. If no reports are received in response
to the query, the group membership entry is cleared and the router stops forwarding traffic for that group.
MLD version 2
MLD version 2 (MLDv2) adds source-filtering capability. A node can report interest in multicast traffic
only from specific source addresses or from all sources except for specific source addresses. MLDv2 is
backwards compatible with MLD version 1.
• Multicast Listener Query — a message sent by the Querier to discover multicast listeners
(Figure 27-2).
• General Query — a query to which all listeners should respond.
• Multicast-Address-Specific Query — a query to which listeners for the specified group should
respond to affirm their membership.
• Multicast-Address-and-Source-Specific Query — a query to determine if there are any listeners
interested in a group and source pair.
• Version 2 Multicast Listener Report — a response to a query indicating listening state or state
changes (Figure 27-3).
Figure 27-2. MLDv2 Multicast Listener Query
Preamble Start Frame Destination MAC Source MAC Ethernet Type IPv6 Packet Padding FCS
Delimiter
Version Traffic Class Flow Label Payload Length Next Header Hop Limit Next Header Header Extension Options
Length (Router Alert) ICMPv6 Packet
(6) (0) (1) (58)
(0)
Type Code Checksum Max. Response Reserved Multicast Address Reserved S Querier Robustness Querier's Query N Source Addresses
(0) Delay Variable Interval Code
Preamble Start Frame Destination MAC Source MAC Ethernet Type IPv6 Packet Padding FCS
Delimiter
Version Traffic Class Flow Label Payload Length Next Header Hop Limit Next Header Header Extension Options
Length (Router Alert) ICMPv6 Packet
(6) (0) (1) (58)
(0)
Code: 1: MODE_IS_INCLUDE
2: MODE_IS EXCLUDE
3: CHANGE_TO_INCLUDE
4: CHANGE_TO_EXCLUDE
5: ALLOW_NEW_SOURCES
6: BLOCK_OLD_SOURCES
Implementation Information
• In FTOS versions prior to 8.3.1.0: when a switch on which MLD snooping is enabled acts as Querier,
queries sent to a specific port (in the event of a port enable, MLD leave, or MLD join), were sent with
an all-zero (::) IPv6 source address. This might unintentionally indicate to another MLD switch that it
is elected the Querier. Beginning with FTOS version 8.3.1.0, all queries are flooded on the VLAN so
that the IPv6 source address is correctly included in all queries.
• MLDv2 Snooping ignores sources specified in exclude reports; all exclude (S,G) reports are treated as
exclude (*,G).
• The following querier commands are available for Layer 3 MLD and MLD Snooping: ipv6 mld
last-member-query-interval, ipv6 mld query-interval, ipv6 mld query-max-resp-time.
Enabling MLD
MLD is enabled automatically when IPv6 PIM is enabled.
The Query Interval is the amount of time between General Queries sent by the Querier.
The Querier sends a Multicast-Address-Specific Query upon receiving a Done message to ascertain
whether there are any remain receivers for a group. The Last Listener Query Interval is the Maximum
Response Delay for a Multicast-Address-Specific Query, and also the amount of time between
Multicast-Address-Specific Query retransmissions. Lowering the Last Listener Query Interval reduces the
time to detect that there are no remaining receivers for a group, and so can reduce the amount of
unnecessarily forwarded traffic.
Explicit Tracking
If the Querier does not receive a response to a Multicast-Address-Specific Query, it sends another. Then,
after no response, it removes the group entry from the group membership table. You can configure the
system to remove specified groups immediately after receiving a Leave message to reduce leave latency.
Display MLD groups. Group information show ipv6 mld {groups | interface} EXEC Privilege
can be filtered, see the FTOS Command Line
Reference for the options available with this
command.
Debug MLD
Task Command Syntax Command Mode
Display FTOS messages about the MLD process. debug ipv6 mld EXEC Privilege
MLD Snooping
Multicast packets are addressed with multicast MAC addresses, which represent a group of devices, rather
than one unique device. Switches forward multicast frames out of all ports in a VLAN by default, even
though there may be only some interested hosts, which is a waste of bandwidth. MLD Snooping enables
switches to use information in MLD packets to generate a forwarding table that associates ports with
multicast groups so that when they receive multicast frames, they can forward them only to interested
receivers.
MLD is automatically enabled when you enable IPv6 PIM, but MLD Snooping must be explicitly enabled.
Configure the switch to be the querier for a Layer 2 VLAN using the command ipv6 mld snooping querier
from INTERFACE VLAN mode. You must configure an IP address for the VLAN.
The source address of the queries is 0 to distinguish these queries from router queries. If the system
receives a query with a non-zero address any VLAN interface, it stops sending queries. When a VLAN
configured with snooping querier comes up, the VLAN interface waits for querier timeout to expire before
becoming querier.
You can configure the switch to only forward unregistered packets to ports on a VLAN that are connected
to a multicast routers using the command no ipv6 mld snooping flood from CONFIGURATION mode.
When flooding is disabled, if there are no such ports in the VLAN connected to a multicast router, the
switch drops the packets.
Configure the system to remove a group ipv6 mld snooping explicit-tracking VLAN INTERFACE
immediately after receiving a Leave message.
Display the MLD explicit-tracking table. show ipv6 mld snooping groups explicit EXEC Privilege
Display the MLD Snooping table. show ipv6 mroute mld EXEC Privilege
Display group information in the table. Group show ipv6 mld snooping groups EXEC Privilege
information can be filtered, see the FTOS
Command Line Reference for the options available
with this command.
MLDv2 Snooping
With MLDv1 Snooping, multicast forwarding tables are formed for a group, G, based on received MLDv1
reports. With MLDv2 Snooping, multicast forwarding tables are formed for a source and group pair, (S,G),
based on received MLDv2 include reports. MLDv2 Snooping is compatible with MLDv1 hosts and selects
a port as dynamic mrouter port when it receives Membership Query on that port.
Snooping Table
MLDv2 IGMP
(*,G) 1 (*,G) 1, 3
VLAN 10
(S,G) 1*, 3
1 2 3 4
exclude (*,G)
include (S,G)
In Figure 27-4, the host on Port 1 sends an exclude—that is, exclude nothing—report to join group G and
receive traffic from all transmitting sources for the group. FTOS creates a (*,G) entry and lists Port 1 in the
outgoing interface list. The host on Port 3 sends an include report to join the same group G, but receive
traffic from only source S. FTOS creates a (S,G) entry and could list Port 3 as the outgoing interface.
However, inbound traffic matches against the most specific entry, in this case, traffic from source S for
group G matches the (S,G) entry. So, this traffic is forwarded out of only Port 3, which means that Port 1,
which requested traffic from all sources, would be denied (S,G) traffic.
To reconcile this behavior, FTOS adds (*,G) ports to (S, G) entries. These inherited ports are marked with
an asterisk to differentiate them from ports that have been snooped. In Figure 27-4, the (S,G) entry inherits
Port 1 from the (*,G) entry. Now, (S,G) traffic is forwarded out Ports 1 and 3, so that Port 1 receives traffic
from all sources, as requested.
Note: IGMPv3 does not inherit ports like MLDv2. Instead, when a VLAN has hosts that want to include
and exclude the same source, S, the group defaults to exclude mode. That is, no (S,G) entry installed,
and the excluding host receives all traffic. Notice, that in Figure 27-4, the MLD snooping table has an
(S,G) entry, while the IGMP snooping does not.
Protocol Overview
Multicast Source Discovery Protocol (MSDP) is a Layer 3 protocol that connects IPv4 PIM-SM domains.
A domain in the context of MSDP is contiguous set of routers operating PIM within a common boundary
defined by an exterior gateway protocol, such as BGP.
Each RP peers with every other RP via TCP. Through this connection, peers advertise the sources in their
domain.
1. When an RP in a PIM-SM domain receives a PIM register message from a source it sends a
Source-Active (SA) message (Figure 28-1) to MSDP peers.
2. Each MSDP peer receives and forwards the message to its peers away from the originating RP.
3. When an MSDP peer receives an SA message, it determines if there are any group members within the
domain interested in any of the advertised sources. If there are, the receiving RP sends a join message
to the originating RP, creating an SPT to the source.
AS X PC 2 P 3
MPC
IG Receiver
Area 0 Source +
M
AS Y
PI
+
4/1 R4 Area 0
PF
OS
MP
IG
+ 4/31
M
PI
2/1
+
BGP
PF
OS
R2
2/11 3/21
3/41
R3
ip RP
ersh
1/21 P Pe
MSD
1/2
R1
1/1
RP1
PC 1
Receiver
RPs advertise each (S,G) in its domain in Type, Length, Value (TLV) format. The total number of TLVs
contained in the SA is indicated in the “Entry Count” field. SA messages are transmitted every 60 seconds,
and immediately when a new source is detected.
Type Length Entry Count RP Address Reserved Sprefix Length Group Address Source Address
(/32)
Implementation Information
• The FTOS implementation of MSDP is in accordance with RFC 3618 and Anycast RP is in accordance
with RFC 3446.
1. Enable an exterior gateway protocol (EGP) with at least two routing domains.
Figure 28-5 and MSDP Sample Configurations on page 638 show the OSPF-BGP configuration used
in this chapter for MSDP. Otherwise, see Chapter 32, Open Shortest Path First (OSPFv2 and
OSPFv3), on page 691 and Chapter 10, Border Gateway Protocol IPv4 (BGPv4), on page 205.
2. Configure PIM-SM within each EGP routing domain.
Figure 28-5 and MSDP Sample Configurations on page 638 show the PIM-SM configuration in this
chapter for MSDP. Otherwise, see Chapter 34, PIM Sparse-Mode, on page 755.
3. Enable MSDP. See page 622.
4. Peer the RPs in each routing domain with each other. See page 622.
618
|
Figure 28-3.
AS 100
PC 2 PC 3
Area 0
router ospf 1
network 192.168.0.1/32 area 0
AS 200
network 10.11.1.0/24 area 0 4/1
PF
R4 Area 0
network 10.11.4.0/24 area 0
OS
redistribute static
redistribute connected 4/31 router ospf 1
redistribute bgp 100 network 10.11.5.0/24 area 0
2/1
R2_E300(conf)#do show run bgp BGP network 10.11.6.0/24 area 0
PF
! network 192.168.0.4/32 area 0
OS
2/31
router bgp 100 R2
redistribute ospf 1
neighbor 192.168.0.3 remote-as 200
2/11 3/21
neighbor 192.168.0.3 ebgp-multihop 255 3/41
neighbor 192.168.0.3 update-source Loopback 0
neighbor 192.168.0.3 no shutdown R3
Configuring OSPF and BGP for MSDP
1/21
1/2
620
|
Figure 28-5.
P
AS 100 GM
PC 2 M
+ I PC 3
Source: 239.0.0.1 PI Receiver: 239.0.0.1
2/1
2/31
ip multicast routing R2
!
ip pim rp-address 192.168.0.1 group-address 224.0.0.0/4
2/11 3/21
3/41
R3
RP2
Configuring PIM in Multiple Routing Domains
1/21
1/2
R1 ip multicast-routing ip multicast-routing
1/1
RP1 ! !
ip pim rp-address 192.168.0.1 group-address 224.0.0.0/4 ip pim rp-address 192.168.0.3 group-address 224.0.0.0/4
PC 2
Receiver: 239.0.0.1
Figure 28-6.
BG
Configuring MSDP
AS 200
+
4/1
PF
P R4 Area 0
GM
+I
OS
M
PI
+ 4/31
R1_E600(conf)#do show run msdp P R4_C300(conf)#do show ip pim tib
BG
!
+
2/1
ip multicast-msdp PIM Multicast Routing Table
PF
ip msdp peer 192.168.0.3 connect-source Loopback 0 Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned,
OS
2/31
R1_E600(conf)#do show ip pim tib R2 R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT,
M - MSDP created entry, A - Candidate for MSDP Advertisement
PIM Multicast Routing Table K - Ack-Pending State
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned, 2/11 3/21 Timers: Uptime/Expires
3/41
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, Interface state: Interface, next-Hop, State/Mode
M - MSDP created entry, A - Candidate for MSDP Advertisement R3
K - Ack-Pending State (*, 239.0.0.1), uptime 21:07:44, expires 00:00:00, RP 192.168.0.3, flags: SCJ
Timers: Uptime/Expires Incoming interface: GigabitEthernet 4/31, RPF neighbor 10.11.6.34
Interface state: Interface, next-Hop, State/Mode RP2 Outgoing interface list:
ip
ersh GigabitEthernet 4/1 Forward/Sparse 21:07:44/Never
1/21 P Pe
(*, 239.0.0.1), uptime 22:26:37, expires 00:00:00, RP 192.168.0.1, flags: SCJ MSD
1/2
Incoming interface: Null, RPF neighbor 0.0.0.0 (10.11.4.2, 239.0.0.1), uptime 16:48:40, expires 00:03:16, flags: CT
R3_E600(conf)#do show run msdp
Outgoing interface list: Incoming interface: GigabitEthernet 4/31, RPF neighbor 10.11.6.34
R1 !
GigabitEthernet 1/1 Forward/Sparse 22:26:37/Never RP1 Outgoing interface list:
ip multicast-msdp
1/1 GigabitEthernet 4/1 Forward/Sparse 21:07:44/Never
ip msdp peer 192.168.0.1 connect-source Loopback 0
(10.11.4.2, 239.0.0.1), uptime 1d16h, expires 00:03:12, flags: CTA
R3_E600(conf)#do show ip pim tib
Incoming interface: GigabitEthernet 1/21, RPF neighbor 10.11.1.21
Outgoing interface list:
PIM Multicast Routing Table
GigabitEthernet 1/1 Forward/Sparse 22:26:37/Never
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned,
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT,
R1_E600(conf)#do show ip msdp sa-cache
M - MSDP created entry, A - Candidate for MSDP Advertisement
MSDP Source-Active Cache - 1 entries
K - Ack-Pending State
GroupAddr SourceAddr RPAddr LearnedFrom Expire UpTime
PC 1 Timers: Uptime/Expires
239.0.0.1 10.11.4.2 192.168.0.1 local 95 16:49:25
Receiver: 239.0.0.1 Interface state: Interface, next-Hop, State/Mode
R3_E600(conf)#ip multicast-msdp
R3_E600(conf)#ip msdp peer 192.168.0.1 connect-source Loopback 0
R3_E600(conf)#do show ip msdp summary
View details about about a peer. show ip msdp peer EXEC Privilege
Multicast sources in remote domains are stored on the RP in the Source-active cache (SA cache). The
system does not create entries in the multicast routing table until there is a local receiver for the
corresponding multicast group.
Limit the number of sources that can be stored in the SA show ip msdp sa-limit EXEC Privilege
cache.
If the total number of active sources is already larger than the limit when limiting is applied, the sources
that are already in FTOS are not discarded. To enforce the limit in such a situation, use the command clear
ip msdp sa-cache to clear all existing entries.
Clear the SA cache of all, local, or rejected entries, or clear ip msdp sa-cache CONFIGURATION
entries for a specific group. [group-address | local | rejected-sa]
MSDP Peership
(S2, G2) (S3, G3) (S2, G2) (S3, G3)
Pe
RP2 RP3 RP2 er RP3
sh
ip
Fa
il
Interface A Interface B Interface A Interface B
RP1 RP1
Scenario 3 Scenario 4
RP2 sh RP3
Fa
il
ip
Fa
il
RP1
ip msdp default-peer Router 3 access-list list123
RP1 ip access-list list123
permit RP4
ip msdp default-peer Router 3
Deny RP5
Specify the forwarding-peer and originating-RP from ip msdp default-peer ip-address list CONFIGURATION
which all active sources are accepted without regard for
the the RPF check. If you do not specify an access list,
the peer accepts all sources advertised by that peer. All
sources from RPs denied by the ACL are subjected to
the normal RPF check.
OPTIONAL: Store sources that are received after the ip msdp cache-rejected-sa CONFIGURATION
limit is reached in the rejected SA cache.
Set the upper limit for the number of sources allowed ip msdp peer peer-address sa-limit CONFIGURATION
from an MSDP peer. The default limit is 100K.
If the total number of sources received from the peer is already larger than the limit when this
configuration is applied, those sources are not discarded. To enforce the limit in such a situation, first clear
the SA cache.
OPTIONAL: Cache sources that are denied by the ip msdp cache-rejected-sa CONFIGURATION
redistribute list in the rejected SA cache.
Prevent the system from caching local SA entries based ip msdp redistribute list CONFIGURATION
on source and group using an extended ACL.
When you apply this filter, the SA cache is not affected immediately. When sources which are denied by
the ACL time out, they are not refreshed. Until they time out, they continue to reside in the cache. To apply
the redistribute filter to entries already present in the SA cache, first clear the SA cache. You may
optionally store denied sources in the rejected SA cache.
OPTIONAL: Cache sources that are denied by the ip msdp cache-rejected-sa CONFIGURATION
SA filter in the rejected SA cache.
Prevent the system from caching remote sources ip msdp sa-filter list out peer list ext-acl CONFIGURATION
learned from a specific peer based on source and
group.
In Figure 28-14, R1 is advertising source 10.11.4.2. It is already in the SA cache of R3 when an ingress SA
filter is applied to R3. The entry remains in the SA cache until it expires; it is not stored in the rejected SA
cache.
[Router 3]
R3_E600(conf)#do show run msdp
!
ip multicast-msdp
ip msdp peer 192.168.0.1 connect-source Loopback 0
ip msdp sa-filter in 192.168.0.1 list myremotefilter
R3_E600(conf)#do show run acl
!
ip access-list extended myremotefilter
seq 5 deny ip host 239.0.0.1 host 10.11.4.2
R3_E600(conf)#do show ip msdp sa-cache
MSDP Source-Active Cache - 1 entries
GroupAddr SourceAddr RPAddr LearnedFrom Expire UpTime
239.0.0.1 10.11.4.2 192.168.0.1 192.168.0.1 1 00:03:59
R3_E600(conf)#do show ip msdp sa-cache
R3_E600(conf)#
R3_E600(conf)#do show ip msdp peer
Prevent an RP from advertising a source in the SA ip msdp sa-filter list in peer list ext-acl CONFIGURATION
cache.
In Figure 28-14, R1 stops advertising source 10.11.4.2. Since it is already in the SA cache of R3, the entry
remains there until it expires.
[Router 1]
R1_E600(conf)#do show run msdp
!
ip multicast-msdp
ip msdp peer 192.168.0.3 connect-source Loopback 0
ip msdp sa-filter out 192.168.0.3 list mylocalfilter
R1_E600(conf)#do show run acl
!
ip access-list extended mylocalfilter
seq 5 deny ip host 239.0.0.1 host 10.11.4.2
seq 10 deny ip any any
R1_E600(conf)#do show ip msdp sa-cache
MSDP Source-Active Cache - 1 entries
GroupAddr SourceAddr RPAddr LearnedFrom Expire UpTime
239.0.0.1 10.11.4.2 192.168.0.1 local 70 00:27:20
R3_E600(conf)#do show ip msdp sa-cache
MSDP Source-Active Cache - 1 entries
GroupAddr SourceAddr RPAddr LearnedFrom Expire UpTime
239.0.0.1 10.11.4.2 192.168.0.1 192.168.0.1 1 00:10:29
[Router 3]
R3_E600(conf)#do show ip msdp sa-cache
R3_E600(conf)#
Display the configured SA filters for a peer using the command show ip msdp peer from EXEC Privilege
mode (see Figure 28-14).
Terminate a Peership
MSDP uses TCP as its transport protocol. In a peering relationship, the peer with the lower IP address
initiates the TCP session, while the peer with the higher IP address listens on port 639.
Once the relationship is terminated, the peering state of the terminator is SHUTDOWN, while the peering
state of the peer is INACTIVE.
[Router 3]
R3_E600(conf)#ip msdp shutdown 192.168.0.1
R3_E600(conf)#do show ip msdp peer
Reset the TCP connection to the peer and clear all peer clear ip msdp peer peer-address CONFIGURATION
statistics.
PIM-SM allows only active group to RP mapping, which has several implications:
• traffic concentration: PIM-SM allows only one active group to RP mapping which means that all
traffic for the group must, at least initially, travel over the same part of the network. You can load
balance source registration between multiple RPs by strategically mapping groups to RPs, but this
technique is less effective as traffic increases because preemptive load balancing requires prior
knowledge of traffic distributions.
• lack of scalable register decasulation: With only a single RP per group, all joins are sent to that RP
regardless of the topological distance between the RP, sources, and receivers, and data is transmitted to
the RP until the SPT switch threshold is reached.
• slow convergence when an active RP fails: When multiple RPs are configured, there can be
considerable convergence delay involved in switching to the backup RP.
Anycast RP relieves these limitations by allowing multiple RPs per group, which can be distributed in a
topologically significant manner according to the locations of the sources and receivers.
1. All the RPs serving a given group are configured with an identical anycast address.
2. Sources then register with the topologically closest RP.
3. RPs use MSDP to peer with each other using a unique address.
M
AS Y
PI
+
4/1 R4 Area 0
PF
OS
MP (*, 239.0.0.1), uptime 00:00:23, expires 00:00:00, RP 192.168.0.3, flags: SCJ
IG
+ 4/31 Incoming interface: GigabitEthernet 4/31, RPF neighbor 10.11.6.34
Outgoing interface list:
M
PI
BGP
PF
R3
ip RP3
ersh
1/21 P Pe
MSD (*, 239.0.0.1), uptime 00:00:14, expires 00:03:16, RP 192.168.0.3, flags: S
1/2 Incoming interface: Null, RPF neighbor 0.0.0.0
Outgoing interface list:
GigabitEthernet 3/41 Forward/Sparse 00:00:14/00:03:16
R1
1/1
RP1 (10.11.4.2, 239.0.0.1), uptime 00:00:14, expires 00:03:17, flags: TM
(*, 239.0.0.1), uptime 00:00:09, expires 00:00:00, RP 192.168.0.1, flags: SCJ Incoming interface: GigabitEthernet 3/21, RPF neighbor 10.11.0.23
Incoming interface: Null, RPF neighbor 0.0.0.0 Outgoing interface list:
Outgoing interface list: GigabitEthernet 3/41 Forward/Sparse 00:00:14/00:03:16
GigabitEthernet 1/1 Forward/Sparse 00:00:09/Never
1 In each routing domain that will have multiple RPs serving a interface loopback CONFIGURATION
group, create a loopback interface on each RP serving the
group with the same IP address.
2 Make this address the RP for the group. ip pim rp-address CONFIGURATION
3 In each routing domain that will have multiple RPs serving a interface loopback CONFIGURATION
group, create another loopback interface on each RP serving
the group with a unique IP address.
4 Peer each RP with every other RP using MSDP, specifying the ip msdp peer CONFIGURATION
unique loopback address as the connect-source.
5 Advertise the network of each of the unique loopback network ROUTER OSPF
addresses throughout the network.
RPs flood source-active messages to all of their peers away from the RP. When multiple RPs exist within a
domain, the RPs forward received active source information back to the originating RP, which violates the
RFP rule. You can prevent this unnecessary flooding by creating a mesh-group. A mesh in this context is a
topology in which each RP in a set of RPs has a peership with all other RPs in the set. When an RP is a
member of the mesh group, it forwards active source information only to its peers outside of the group.
Use the address of another interface as the originator-id ip msdp originator-id CONFIGURATION
instead of the RP address.
ip multicast-routing
!
interface GigabitEthernet 2/1
ip pim sparse-mode
ip address 10.11.4.1/24
no shutdown
!
interface GigabitEthernet 2/11
ip pim sparse-mode
ip address 10.11.1.21/24
no shutdown
!
interface GigabitEthernet 2/31
ip pim sparse-mode
ip address 10.11.0.23/24
no shutdown
!
interface Loopback 0
ip pim sparse-mode
ip address 192.168.0.1/32
no shutdown
!
interface Loopback 1
ip address 192.168.0.22/32
no shutdown
!
router ospf 1
network 10.11.1.0/24 area 0
network 10.11.4.0/24 area 0
network 192.168.0.22/32 area 0
redistribute static
redistribute connected
redistribute bgp 100
!
router bgp 100
redistribute ospf 1
neighbor 192.168.0.3 remote-as 200
neighbor 192.168.0.3 ebgp-multihop 255
neighbor 192.168.0.3 no shutdown
!
ip multicast-msdp
ip msdp peer 192.168.0.3 connect-source Loopback 1
ip msdp peer 192.168.0.11 connect-source Loopback 1
ip msdp mesh-group AS100 192.168.0.11
ip msdp originator-id Loopback 1
!
ip route 192.168.0.3/32 10.11.0.32
!
ip pim rp-address 192.168.0.1 group-address 224.0.0.0/4
The following figures show the running-configurations for the routers shown in figures Figure 28-5,
Figure 28-4, Figure 28-5, Figure 28-6.
ip multicast-routing
!
interface GigabitEthernet 3/21
ip pim sparse-mode
ip address 10.11.0.32/24
no shutdown
!
interface GigabitEthernet 3/41
ip pim sparse-mode
ip address 10.11.6.34/24
no shutdown
!
interface ManagementEthernet 0/0
ip address 10.11.80.3/24
no shutdown
!
interface Loopback 0
ip pim sparse-mode
ip address 192.168.0.3/32
no shutdown
!
router ospf 1
network 10.11.6.0/24 area 0
network 192.168.0.3/32 area 0
redistribute static
redistribute connected
redistribute bgp 200
!
router bgp 200
redistribute ospf 1
neighbor 192.168.0.2 remote-as 100
neighbor 192.168.0.2 ebgp-multihop 255
neighbor 192.168.0.2 update-source Loopback 0
neighbor 192.168.0.2 no shutdown
!
ip multicast-msdp
ip msdp peer 192.168.0.1 connect-source Loopback 0
!
ip route 192.168.0.2/32 10.11.0.23
Protocol Overview
Multiple Spanning Tree Protocol (MSTP)—specified in IEEE 802.1Q-2003—is an RSTP-based spanning
tree variation that improves on PVST+. MSTP allows multiple spanning tree instances and allows you to
map many VLANs to one spanning tree instance to reduce the total number of required instances.
In contrast, PVST+ allows a spanning tree instance for each VLAN. This 1:1 approach is not suitable if
you have many VLANs, because each spanning tree instance costs bandwidth and processing resources.
In Figure 29-1, three VLANs are mapped to two Multiple Spanning Tree instances (MSTI). VLAN 100
traffic takes a different path than VLAN 200 and 300 traffic. The behavior in Figure 29-1 demonstrates
how you can use MSTP to achieve load balancing.
Figure 29-1. MSTP with Three VLANs Mapped to Two Spanning Tree Instances
1/31 2/31
Forwarding
Blocking
3/11
3/21
R3
MSTI 2 root
Implementation Information
• The FTOS MSTP implementation is based on IEEE 802.1Q-2003, and interoperates only with bridges
that also use this standard implementation.
• MSTP is compatible with STP and RSTP.
• FTOS supports only one MSTP region.
• When you enable MSTP, all ports in Layer 2 mode participate in MSTP.
• On the C-Series and S-Series, you can configure 64 MSTIs including the default instance 0 (CIST).
Verify that MSTP is enabled using the show config command from PROTOCOL MSTP mode, as shown in
Figure 29-2.
Figure 29-2. Verifying MSTP is Enabled
FTOS(conf)#protocol spanning-tree mstp
FTOS(config-mstp)#show config
!
protocol spanning-tree mstp
no disable
FTOS#
When you enable MSTP, all physical, VLAN, and port-channel interfaces that are enabled and in Layer 2
mode are automatically part of the MSTI 0.
• Within an MSTI, only one path from any bridge to any other bridge is enabled.
• Bridges block a redundant path by disabling one of the link ports.
Create an MSTI using the command msti from PROTOCOL MSTP mode. Specify the keyword vlan
followed by the VLANs that you want to participate in the MSTI, as shown in Figure 29-3.
All bridges in the MSTP region must have the same VLAN-to-instance mapping. View to which instance a
VLAN is mapped using the command show spanning-tree mst vlan from EXEC Privilege mode, as shown
in Figure 29-6.
View the forwarding/discarding state of the ports participating in an MSTI using the command show
spanning-tree msti from EXEC Privilege mode, as shown in Figure 29-4.
Assign a number as the bridge priority. A lower number msti instance bridge-priority PROTOCOL MSTP
increases the probability that the bridge becomes the root priority
bridge.
Range: 0-61440, in increments of 4096
Default: 32768
The simple configuration Figure 29-1 by default yields the same forwarding path for both MSTIs.
Figure 29-5, shows how R3 is assigned bridge priority 0 for MSTI 2, which elects a different root bridge
than MSTI 2. View the bridge priority using the command show config from PROTOCOL MSTP mode,
also shown in Figure 29-5.
R3(conf-mstp)#show config
!
protocol spanning-tree mstp
no disable
MSTI 1 VLAN 100
MSTI 2 VLAN 200,300
MSTI 2 bridge-priority 0
For a bridge to be in the same MSTP region as another, all three of these qualities must match exactly. The
default values for name and revision will match on all Dell Force10 FTOS equipment. If you have
non-FTOS equipment that will participate in MSTP, ensure these values to match on all the equipment.
Note: Some non-FTOS equipment may implement a non-null default region name. SFTOS, for example,
uses the Bridge ID, while others may use a MAC address.
View the current region name and revision using the command show spanning-tree mst configuration from
EXEC Privilege mode, as shown in Figure 29-6.
• Forward-delay is the amount of time an interface waits in the Listening State and the Learning State
before it transitions to the Forwarding State.
• Hello-time is the time interval in which the bridge sends MSTP Bridge Protocol Data Units (BPDUs).
• Max-age is the length of time the bridge maintains configuration information before it refreshes that
information by recomputing the MST topology.
• Max-hops is the maximum number of hops a BPDU can travel before a receiving switch discards it.
Note: Dell Force10 recommends that only experienced network administrators change MSTP parameters.
Poorly planned modification of MSTP parameters can negatively impact network performance.
To change MSTP parameters, use the following commands on the root bridge:
View the current values for MSTP parameters using the show running-config spanning-tree mstp
command from EXEC privilege mode.
You can adjust two interface parameters to increase or decrease the probability that a port becomes a
forwarding port:
• Port cost is a value that is based on the interface type. The greater the port cost, the less likely the port
will be selected to be a forwarding port.
• Port priority influences the likelihood that a port will be selected to be a forwarding port in case that
several ports have the same port cost.
Table 29-2 lists the default values for port cost by interface.
Change the port cost of an interface. spanning-tree msti number cost cost INTERFACE
Range: 0 to 200000
Default: see Table 29-2.
Change the port priority of an interface. spanning-tree msti number priority priority INTERFACE
Range: 0 to 240, in increments of 16
Default: 128
View the current values for these interface parameters using the command show config from INTERFACE
mode. See Figure 29-8.
Caution: Configure EdgePort only on links connecting to an end station. EdgePort can cause loops if it is enabled
on an interface connected to a network.
Verify that EdgePort is enabled on a port using the command show config from the INTERFACE mode, as
shown in Figure 29-8.
Use the Root Guard feature in a Layer 2 MSTP network to avoid bridging loops.
FTOS Behavior: The following conditions apply to a port enabled with root guard:
• Root guard is supported on any MSTP-enabled port or port-channel interface except when used as a
stacking port.
• Root guard is supported on a port in any Spanning Tree mode:
• Spanning Tree Protocol (STP)
• Rapid Spanning Tree Protocol (RSTP)
• Multiple Spanning Tree Protocol (MSTP)
• Per-VLAN Spanning Tree Plus (PVST+)
• When enabled on a port, root guard applies to all VLANs configured on the port.
• Root guard and loop guard cannot be enabled at the same time on an MSTP port. For example, if you
configure loop guard on a port on which root guard is already configured, the following error message is
displayed:
% Error: RootGuard is configured. Cannot configure LoopGuard.
• When used in an MSTP network, if root guard blocks a boundary port in the CIST, the port is also blocked
in all other MST instances.
To enable a root guard on an MSTP-enabled port or port-channel interface, enter the spanning-tree mstp
rootguard command. Refer to STP Root Guard on page 1060 for more information on how to use the root
guard feature.
Enable root guard on a port or port-channel interface. spanning-tree mstp rootguard INTERFACE
INTERFACE
PORT-CHANNEL
To disable MSTP root guard on a port or port-channel interface, enter the no spanning-tree mstp rootguard
command in an interface configuration mode.
To verify the MSTP root guard configuration on a port or port-channel interface, enter the show
spanning-tree msti [instance-number] guard commandin global configuration mode.
FTOS Behavior: The following conditions apply to a port enabled with loop guard:
• Loop guard is supported on any MSTP-enabled port or port-channel interface.
• Loop guard is supported on a port or port-channel in any Spanning Tree mode:
• Spanning Tree Protocol (STP)
• Rapid Spanning Tree Protocol (RSTP)
• Multiple Spanning Tree Protocol (MSTP)
• Per-VLAN Spanning Tree Plus (PVST+)
• Root guard and loop guard cannot be enabled at the same time on an MSTP port. For example, if you
configure root guard on a port on which loop guard is already configured, the following error message is
displayed:
% Error: LoopGuard is configured. Cannot configure RootGuard.
• Enabling Portfast BPDU guard and loop guard at the same time on a port results in a port that remains in a
blocking state and prevents traffic from flowing through it. For example, when Portfast BPDU guard and
loop guard are both configured:
- If a BPDU is received from a remote device, BPDU guard places the port in an err-disabled
blocking state and no traffic is forwarded on the port.
- If no BPDU is received from a remote device, loop guard places the port in a loop-inconsistent
blocking state and no traffic is forwarded on the port.
To enable a loop guard on an MSTP-enabled port or port-channel interface, enter the spanning-tree mstp
loopguard command. Refer to STP Loop Guard on page 1064 for more information on how to use the loop
guard feature.
Enable loop guard on an MSTP-enabled port or port-channel spanning-tree mstp loopguard INTERFACE
interface.
INTERFACE
PORT-CHANNEL
To disable MSTP loop guard on a port or port-channel interface, enter the no spanning-tree mstp loopguard
command in an INTERFACE configuration mode.
To verify the MSTP loop guard configuration on a port or port-channel interface, enter the show
spanning-tree msti [instance-number] guard command in global configuration mode.
FTOS has an optimized MAC address flush mechanism for RSTP, MSTP, and PVST+ that flushes
addresses only when necessary, which allows for faster convergence during topology changes. However,
you may activate the flushing mechanism defined by 802.1Q-2003 using the command tc-flush-standard,
which flushes MAC addresses upon every topology change notification. View the enable status of this
feature using the command show running-config spanning-tree mstp from EXEC Privilege mode.
Figure 29-10. MSTP with Three VLANs Mapped to Two Spanning Tree Instances
root
R1 R2
1/2 Forwarding 2/1
1/3 2/3
Blocking
3/1 3/2
R3
interface 1/0/31
no shutdown
spanning-tree port mode enable
switchport protected 0
exit Assign Layer-2 interfaces
to MSTP topology
interface 1/0/32
no shutdown
spanning-tree port mode enable
switchport protected 0
exit
Display BPDUs using the command debug spanning-tree mstp bpdu from EXEC Privilege mode. Display
MSTP-triggered topology change messages debug spanning-tree mstp events.
1w1d17h : MSTP: TC flag set in the incoming BPDU on port Gi 1/31 for instance 0
1w1d17h : MSTP: TC flag set in the incoming BPDU on port Gi 1/31 for instance 0
Examine your individual routers to ensure all the necessary parameters match.
1. Region Name
2. Region Version
3. VLAN to Instance mapping
The show spanning-tree mst commands will show various portions of the MSTP configuration. To view the
overall MSTP configuration on the router, use the show running-configuration spanning-tree mstp in the
EXEC Privilege mode (output sample shown in Figure 29-16).
Use the debug spanning-tree mstp bpdu command to monitor and verify that the MSTP configuration is
connected and communicating as desired (output sample shown in Figure 29-17).
Key items to look for in the debug report:
• MSTP flags indicate communication received from the same region.
• In Figure 29-17, the output shows that the MSTP routers are located in the same region.
• Does the debug log indicate that packets are coming from a “Different Region” (Figure 29-18)? If
so, one of the key parameters is not matching.
• MSTP Region Name and Revision
• The configured name and revisions must be identical among all the routers.
• Is the Region name blank? That may mean that a name was configured on one router and but was
not configured or was configured differently on another router (spelling and capitalization counts).
• MSTP Instances.
• Use the show commands to verify the VLAN to MSTP Instance mapping.
• Are there “extra” MSTP Instances in the Sending or Received logs? That may mean that an
additional MSTP Instance was configured on one router but not the others.
Figure 29-17. Displaying BPDUs and Events - Debug Log of Successful MSTP Configuration
FTOS#debug spanning-tree mstp bpdu
MSTP debug bpdu is ON
FTOS#
4w0d4h : MSTP: Sending BPDU on Gi 2/21 :
ProtId: 0, Ver: 3, Bpdu Type: MSTP, Flags 0x6e
CIST Root Bridge Id: 32768:0001.e806.953e, Ext Path Cost: 0
Regional Bridge Id: 32768:0001.e806.953e, CIST Port Id: 128:470
Msg Age: 0, Max Age: 20, Hello: 2, Fwd Delay: 15, Ver1 Len: 0, Ver3 Len: 96
Name: Tahiti, Rev: 123, Int Root Path Cost: 0
Rem Hops: 20, Bridge Id: 32768:0001.e806.953e
4w0d4h : INST 1: Flags: 0x6e, Reg Root: 32768:0001.e806.953e, Int Root Cost: 0
Brg/Port Prio: 32768/128, Rem Hops: 20
INST 2: Flags: 0x6e, Reg Root: 32768:0001.e806.953e, Int Root Cost: 0
Brg/Port Prio: 32768/128, Rem Hops: 20
MSTP Instance
Figure 29-18. Displaying BPDUs and Events - Debug Log of Unsuccessful MSTP Configuration
4w0d4h : MSTP: Received BPDU on Gi 2/21 :
ProtId: 0, Ver: 3, Bpdu Type: MSTP, Flags 0x78Different Region
CIST Root Bridge Id: 32768:0001.e806.953e, Ext Path Cost: 0
Regional Bridge Id: 32768:0001.e806.953e, CIST Port Id: 128:470
Msg Age: 0, Max Age: 20, Hello: 2, Fwd Delay: 15, Ver1 Len: 0, Ver
Name: Tahiti, Rev: 123, Int Root Path Cost: 0
Rem Hops: 20, Bridge Id: 32768:0001.e8d5.cbbd
4w0d4h : INST 1: Flags: 0x70, Reg Root: 32768:0001.e8d5.cbbd, Int
Brg/Port Prio: 32768/128, Rem Hops: 20
INST 2: Flags: 0x70, Reg Root: 32768:0001.e8d5.cbbd, Int Root Cost Indicates MSTP
Brg/Port Prio: 32768/128, Rem Hops: 20 routers are in
different regions and
are not communicating
with each other
Implementation Information
• Multicast is not supported on secondary IP addresses.
Enable IP Multicast
Enable IP Multicast is supported on platforms ces
In Figure 30-1, the receiver joins three groups. The last-hop DR initially has two equal-cost routes to the
RP with no streams, so it non-deterministically selects Route 1 for the Group 1 IGMP Join message. Route
1 then has one stream associated with it, so the last-hop DR sends the Group 2 Join by Route 2. It then
non-deterministically selects Route 2 for the Group 3 Join since both routes already have one multicast
stream.
P Joi
IG M P J
n: G3
Gig X Gig
Gig B Gig A
RP
Gig W
G1
Gig Y
Join:
IGMP
Source Receiver
Group 2 GigabitEthernet X
Group 3 GigabitEthernet X Group 3 GigabitEthernet A
Multicast Policies
FTOS offers parallel Multicast features for IPv4 and IPv6.
Limit the total number of multicast routes on the system. ip multicast-limit CONFIGURATION
Range: 1-50000
Default: 15000
When the limit is reached, FTOS does not process any IGMP or MLD joins to PIM—though it still
processes leave messages—until the number of entries decreases below 95% of the limit. When the limit
falls below 95% after hitting the maximum, the system begins relearning route entries through IGMP,
MLD, and MSDP.
• If the limit is increased after it is reached, join subsequent join requests are accepted. In this case, you
must increase the limit by at least 10% for IGMP and MLD to resume.
• If the limit is decreased after it is reached, FTOS does not clear the existing sessions. Entries are
cleared upon a timeout (you may also clear entries using clear ip mroute).
Note: FTOS waits at least 30 seconds between stopping and starting IGMP join processing. You may
experience this delay when manipulating the limit after it is reached.
3w1d13h: %RPM0-P:RP2 %PIM-3-PIM_TIB_LIMIT: PIM TIB limit reached. No new routes will be
learnt until TIB level falls below low watermark.
3w1d13h: %RPM0-P:RP2 %PIM-3-PIM_TIB_LIMIT: PIM TIB below low watermark. Route learning will
begin.
Note: The IN-L3-McastFib CAM partition is used to store multicast routes and is a separate hardware limit
that is exists per port-pipe. Any software-configured limit might be superseded by this hardware space
limitation. The opposite is also true, the CAM partition might not be exhausted at the time the system-wide
route limit set by the ip multicast-limit is reached.
You can prevent a host from joining a particular group by blocking specific IGMP reports. Create an
extended access list containing the permissible source-group pairs. Use the command ip igmp access-group
access-list-name from INTERFACE mode to apply the access list.
Note: For rules in IGMP access lists, source is the multicast source, not the source of the IGMP packet.
For IGMPv2, use the keyword any for source (as shown in Figure 30-2), since IGMPv2 hosts do not know
in advance who the source is for the group in which they are interested.
FTOS Behavior: Do not enter the command ip igmp access-group before creating the access-list. If
you do, upon entering your first deny rule, FTOS clears multicast routing table and re-learns all groups,
even those not covered by the rules in the access-list, because there is an implicit deny all rule at the
end of all access-lists. Therefore, configuring an IGMP join request filter in this order might result in
data loss. If you must enter the command ip igmp access-group before creating the access-list, prevent
FTOS from clearing the routing table by entering a permit any rule with high sequence number before
you enter any other rules.
In Figure 30-2, VLAN 400 is configured with an access list to permit only IGMP reports for group
239.0.0.1. Though Receiver 2 sends a membership report for groups 239.0.0.1 and 239.0.0.2, a multicast
routing table entry is created only for group 239.0.0.1. VLAN 300 has no access list limiting Receiver 1, so
both IGMP reports are accepted, and two corresponding entries are created in the routing table.
668
|
Figure 30-2.
Multicast Features
ip address 10.11.23.2/24
no shutdown
interface GigabitEthernet 2/31
ip pim sparse-mode Source 1
Source 2 ip address 10.11.23.1/24 10.11.5.2
10.11.1.2 no shutdown
interface GigabitEthernet 3/1
interface GigabitEthernet 2/1
ip pim sparse-mode
ip pim sparse-mode
ip address 10.11.5.1/24
ip address 10.11.1.1/24
no shutdown
no shutdown
239.0.0.2
R2
3/1 239.0.0.1
2/1 2/31 3/21
R3
interface GigabitEthernet 2/11
ip pim sparse-mode RP interface GigabitEthernet 3/11
ip address 10.11.12.2/24
2/11 ip multicast-routing 3/11 ip pim sparse-mode
no shutdown ip pim rp-address 10.11.12.2 group-address 224.0.0.0/4 ip address 10.11.13.2/24
interface GigabitEthernet 1/21 router rip no shutdown
ip pim sparse-mode network 10.0.0.0
ip address 10.11.12.1/24
no shutdown
R1(conf-if-vl-400)# do show ip pim tib
1/21 R1(conf )#do show run acl
!
Preventing a Host from Joining a Group
(*, 239.0.0.1), uptime 00:00:06, expires 00:00:00, RP 10.11.12.2, flags: SCJ PIM Multicast Routing Table
Incoming interface: GigabitEthernet 1/21, RPF neighbor 10.11.12.2 Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned,
Outgoing interface list: interface Vlan 300 R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT,
Vlan 400 Forward/Sparse 00:00:06/Never ip pim sparse-mode M - MSDP created entry, A - Candidate for MSDP Advertisement
ip address 10.11.3.1/24 K - Ack-Pending State
interface Vlan 400 untagged GigabitEthernet 1/1 Timers: Uptime/Expires
ip pim sparse-mode no shutdown Interface state: Interface, next-Hop, State/Mode
ip address 10.11.4.1/24
untagged GigabitEthernet 1/2 (*, 239.0.0.1), uptime 00:00:07, expires 00:00:00, RP 10.11.12.2, flags: SCJ
ip igmp access-group igmpjoinfilR2G2
Receiver 1 Incoming interface: GigabitEthernet 1/21, RPF neighbor 10.11.12.2
no shutdown 10.11.3.2 Outgoing interface list:
Vlan 300 Forward/Sparse 00:00:07/Never
ip igmp snooping enable
Group: 239.0.0.1, 239.0.0.2
(*, 239.0.0.2), uptime 00:01:10, expires 00:00:00, RP 10.11.12.2, flags: SCJ
Incoming interface: GigabitEthernet 1/21, RPF neighbor 10.11.12.2
Outgoing interface list:
Vlan 300 Forward/Sparse 00:01:10/Never
Receiver 2
10.11.4.2
Group: 239.0.0.1, 239.0.0.2
Rate Limit IGMP Join Requests
If you expect a burst of IGMP Joins, protect the IGMP process from overload by limiting that rate at which
new groups can be joined using the command ip igmp group-join-limit from INTERFACE mode. Hosts
whose IGMP requests are denied will use the retry mechanism built-in to IGMP so that they’re
membership is delayed rather than permanently denied.
View the enable status of this feature using the command show ip igmp interface from EXEC Privilege
mode.
To prevent a router from participating in Protocol Independent Multicast (PIM) (for example, to configure
stub multicast routing), use the ip pim neighbor-filter command from INTERFACE mode.
Use the command ip pim register-filter from CONFIGURATION mode to prevent a source from
transmitting to a particular group. This command prevents the PIM source DR from sending register
packets to RP for the specified multicast source and group; if the source DR never sends register packets to
the RP, no hosts can ever discover the source and create an SPT to it.
In Figure 30-3, Source 1 and Source 2 are both transmitting packets for groups 239.0.0.1 and 239.0.0.2. R3
has a PIM register filter that only permits packets destined for group 239.0.0.2. An entry is created for
group 239.0.0.1 in the routing table, but no outgoing interfaces are listed. R2 has no filter, so it is allowed
to forward both groups. As a result, Receiver 1 receives only one transmission, while Receiver 2 receives
duplicate transmissions.
670
|
or group.
interface GigabitEthernet 3/21
Multicast Features
Figure 30-3.
R2(conf )#do show ip pim tib ip pim sparse-mode R3(conf )#do show ip pim tib
ip address 10.11.23.2/24
PIM Multicast Routing Table no shutdown PIM Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned, interface GigabitEthernet 2/31 Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned,
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, ip pim sparse-mode Source 1 R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT,
M - MSDP created entry, A - Candidate for MSDP Advertisement
Source 2 ip address 10.11.23.1/24 10.11.5.2 M - MSDP created entry, A - Candidate for MSDP Advertisement
K - Ack-Pending State 10.11.1.2 no shutdown K - Ack-Pending State
Timers: Uptime/Expires interface GigabitEthernet 3/1 Timers: Uptime/Expires
Interface state: Interface, next-Hop, State/Mode interface GigabitEthernet 2/1 Interface state: Interface, next-Hop, State/Mode
ip pim sparse-mode
ip pim sparse-mode
ip address 10.11.5.1/24
(*, 239.0.0.1), uptime 00:03:00, expires 00:02:32, RP 10.11.12.2, flags: SF ip address 10.11.1.1/24 (10.11.5.2, 239.0.0.1), uptime 00:05:21, expires 00:02:46, flags: FT
no shutdown
Incoming interface: Null, RPF neighbor 0.0.0.0 no shutdown Incoming interface: GigabitEthernet 3/1, RPF neighbor 0.0.0.0
Outgoing interface list: Outgoing interface list:
GigabitEthernet 2/11 Forward/Sparse 00:03:00/00:02:32 GigabitEthernet 3/11 Forward/Sparse 00:00:18/00:03:12
239.0.0.2
R2
(10.11.1.2, 239.0.0.1), uptime 00:00:44, expires 00:02:56, flags: FT 3/1 239.0.0.1 (10.11.5.2, 239.0.0.2), uptime 00:05:08, expires 00:03:26, flags: FT
Incoming interface: GigabitEthernet 2/1, RPF neighbor 0.0.0.0 2/1 2/31 3/21 Incoming interface: GigabitEthernet 3/1, RPF neighbor 0.0.0.0
Outgoing interface list: Outgoing interface list:
GigabitEthernet 2/11 Forward/Sparse 00:00:13/00:03:17 R3
interface GigabitEthernet 2/11
(10.11.5.2, 239.0.0.1), uptime 00:00:26, expires 00:03:06, flags: P ip pim sparse-mode interface GigabitEthernet 3/11
ip address 10.11.12.2/24
2/11 ip multicast-routing 3/11 ip pim sparse-mode
Incoming interface: GigabitEthernet 2/31, RPF neighbor 10.11.23.2
Outgoing interface list: no shutdown ip pim rp-address 10.11.12.2 group-address 224.0.0.0/4 ip address 10.11.13.2/24
interface GigabitEthernet 1/21 router rip no shutdown
ip pim sparse-mode network 10.0.0.0 R3(conf )#do show run acl
(*, 239.0.0.2), uptime 00:00:21, expires 00:03:09, RP 10.11.12.2, flags: SF !
ip address 10.11.12.1/24
Incoming interface: Null, RPF neighbor 0.0.0.0 ip access-list extended regfilS1G2
no shutdown
Outgoing interface list: 1/21 seq 5 permit ip host 10.11.5.2 host 239.0.0.1
GigabitEthernet 2/11 Forward/Sparse 00:00:21/00:03:09 R3(conf )#do show run pim
R1 !
(10.11.1.2, 239.0.0.2), uptime 00:00:02, expires 00:03:28, flags: FT 1/31 interface GigabitEthernet 1/31
ip pim rp-address 10.11.12.2 group-address 224.0.0.0/4
Incoming interface: GigabitEthernet 2/1, RPF neighbor 0.0.0.0 RP ip pim sparse-mode
ip pim register-filter regfilS1G2
Outgoing interface list: ip address 10.11.13.1/24
GigabitEthernet 2/11 Forward/Sparse 00:00:21/00:03:09 no shutdown
Permit or deny PIM Join/Prune messages on an interface using an extended IP access list. Use the
command ip pim join-filter to prevent the PIM SM router from creating state based on multicast source and/
Using a Static Multicast MAC Address
To enable a router to switch multicast traffic in a Layer 2 VLAN only to the ports associated with a static
multicast MAC address, you must:
Note: Enabling Layer 2 multicast switching automatically disables default Layer 3 multicast routing on the router.
Note: You can add individual or a range of ports to the VLAN used for Layer 2 multicast forwarding as follows:
range-output single-interface specifies one of the following port types:
- 1-Gigabit Ethernet: Enter gigabitethernet slot/port.
- 10-Gigabit Ethernet: Enter tengigabitethernet slot/port.
- Port channel: Enter port-channel {1-128}.
range-output interface-list specifies multiple ports separated by a space, comma and space; for example:
tengigabitethernet 0/1 , gigabitethernet 0/3 , ...
range-output interface-range specifies a port range in the format:
interface-type slot/first_port - last_port; for example: tengigabitethernet 0/1 - 3
To return to the default Layer 3 multicast forwarding on the router, enter the no ip multicast-mode l2
command after you remove the static multicast MAC address with the no mac-address-table static multicast
vlan output-range command.
mac-address-table static multicast [vlan vlan-id | multicast-mac-address [vlan vlan-id]] command in EXEC
mode. Static MAC addresses configured for Layer 2 multicast forwarding with an associated VLAN and
assigned output ports are displayed as shown in Figure 30-4.
Figure 30-4. show mac-address-table static multicast Command Output
FTOS# show mac-address-table static multicast
To display the number of static multicast MAC addresses in use for all VLANs on a router, enter the show
mac-address-table static multicast count [vlan vlan-id] command in EXEC mode.
Figure 30-7. show mac-address-table static multicast count vlan Command Example
FTOS#show mac-address-table static multicast count vlan 10
You can limit the total number of IPv6 multicast routes on the system. The maximum number of multicast
entries allowed on each line card is determined by the CAM profile. Multicast routes are stored in the
IN-V6-McastFib CAM region, which has a fixed number of entries. Any limit configured via the CLI is
superseded by this hardware limit. The opposite is also true; the CAM might not be exhausted at the time
the CLI-configured route limit is reached.
Limit the total number of IPv6 multicast routes on the ipv6 multicast-limit CONFIGURATION
system.
Range: 1-50000
Default: 15000
Prevent a router from participating in PIM. ipv6 pim neighbor-filter access-list CONFIGURATION
Configured on the source DR, prevent the ipv6 pim register-filter access-list CONFIGURATION
source DR from sending register packets to the
RP for specific sources and groups.
Permit or deny PIM Join/Prune messages on an ipv6 pim join-filteraccess-list [in | out] INTERFACE
interface using an access list. This command
prevents the PIM-SM router from creating state
based on multicast source and/or group.
Multicast Traceroute
Multicast Traceroute is supported only on platform: e
MTRACE is an IGMP-based tool that prints that network path that a multicast packet takes from a source
to a destination, for a particular group. FTOS has mtrace client and mtrace transmit functionality.
• MTRACE Client—an mtrace client transmits mtrace queries and prints out the details received
responses.
Print the network path that a multicast mtrace multicast-source-address EXEC Privilege
packet takes from a multicast source to multicast-receiver-address multicast-group-address
receiver, for a particular group.
You may do one or more for the following to optimize the E-Series for your multicast application:
FTOS provides the ability to adjust the scheduling weight for multicast traffic. For example, if the majority
of your traffic is multicast, the default configuration might yield greater latency. In this case, allocate more
backplane bandwidth for multicast using the command queue multicast bandwidth-percent from
CONFIGURATION mode. View your configuration using the command show queue backplane multicast
bandwidth-percentage.
Object tracking allows FTOS client processes, such as VRRP, to monitor tracked objects (for example,
interface or link status) and take appropriate action when the state of an object changes.
In future releases, environmental alarms and available free memory will be supported. You can configure
client applications, such VRRP, to receive a notification when the state of a tracked object changes.
For example, Figure 31-1 shows how object tracking is performed. Router A and Router B are both
connected to the Internet via interfaces running OSPF. Both routers belong to a VRRP group with a virtual
router at 10.0.0.1 on the LAN side. Neither Router A nor Router B is the owner of the group. Although
Router A and Router B use the same default VRRP priority (100), Router B would normally become the
master for the VRRP group because it has a higher IP address.
default route as a tracked object, you can configure the VRRP group to track the state of the route. In this
way, the VRRP priority of the router with the better metric as determined by OSPF automatically becomes
master of the VRRP group. Later, if network conditions change and the cost of the default route in each
router changes, the mastership of the VRRP group is automatically reassigned to the router with the better
metric.
When you configure a tracked object, such as an IPv4/IPv6 a route or interface, you specify an object
number to identify the object. Optionally, you can also specify:
When the link-level status goes down, the tracked resource status is considered to be DOWN; if the
link-level status goes up, the tracked resource status is considered to be UP. For logical interfaces, such as
port-channels or VLANs, the link-protocol status is considered to be UP if any physical interface under the
logical interface is UP.
• The Layer 3 status of an interface is UP only if the Layer 2 status of the interface is UP and the
interface has a valid IP address.
• The Layer 3 status of an interface goes DOWN when its Layer 2 status goes down or the IP address is
removed from the routing table.
A tracked route matches a route in the routing table only if the exact address and prefix length match an
entry in the routing table. For example, when configured as a tracked route, 10.0.0.0/24 does not match the
routing table entry 10.0.0.0/8. If no route-table entry has the exact address and prefix length, the tracked
route is considered to be DOWN.
In addition to the entry of a route in the routing table, you can configure how the status of a route is tracked
in either the following ways:
If you configure the reachability of an IP route entry as a tracked object, the UP/DOWN state of the route
is determined by the entry of the next-hop address in the ARP cache. A tracked route is considered to be
reachable if there is an ARP cache entry for the route's next-hop address. If the next-hop address in the
ARP cache ages out for a route tracked for its reachability, an attempt is made to regenerate the ARP cache
entry to see if the next-hop address appears before considering the route DOWN.
If you configure a metric threshold to track a route, the UP/DOWN state of the tracked route is determined
by the current metric for the route entered in the routing table.
To provide a common tracking interface for different clients, route metrics are scaled in the range 0 to 255,
where 0 is connected and 255 is inaccessible. The scaled metric value communicated to a client always
considers a lower value to have priority over a higher value. The resulting scaled value is compared against
the threshold values to determine the state of a tracked route as follows:
• If the scaled metric for a route entry is less than or equal to the UP threshold, the state of a route is UP.
The UP and DOWN thresholds are user-configurable for each tracked route. The default UP threshold is
254; the default DOWN threshold is 255. The notification of a change in the state of a tracked object is sent
when a metric value crosses a configured threshold.
The tracking process uses a protocol-specific resolution value to convert the actual metric in the routing
table to a scaled metric in the range 0 to 255. The resolution value is user-configurable and calculates the
scaled metric by dividing a route's cost by the resolution value set for the route type:
• For ISIS, you can set the resolution in the range 1 to 1000, where the default is 10.
• For OSPF, you can set the resolution in the range 1 to 1592, where the default is 1.
• The resolution value used to map static routes is not configurable. By default, FTOS assigns a metric
of 0 to static routes.
• The resolution value used to map RIP routes is not configurable. The RIP hop-count is automatically
multiplied by 16 to scale it; a RIP metric of 16 (unreachable) scales to 256, which considers the route
to be DOWN. For example, to configure object tracking for a RIP route to be considered UP only if the
RIP hop count is less than or equal to 4, you would configure the UP threshold to be 64 (4 x 16) and
the DOWN threshold to be 65.
If the state of an object changes back to its former UP/DOWN state before the timer expires, the timer is
cancelled and the client is not notified. If the timer expires and an object’s state has changed, a notification
is sent to the client. For example, if the DOWN timer is running when an interface goes down and comes
back up, the DOWN timer is cancelled and the client is not notified of the event.
If no delay is configured, a notification is sent immediately as soon as a change in the state of a tracked
object is detected. The time delay in communicating a state change is specified in seconds.
Note: In VRRP object tracking, the sum of the priority costs for all tracked objects and interfaces cannot
equal or exceed the priority of the VRRP group.
For a complete listing of all commands related to object tracking, refer to the FTOS Command Line Interface.
• 1-Gigabit Ethernet: Enter gigabitethernet slot/port in the track interface interface command (see Step 1
below).
• 10-Gigabit Ethernet: Enter tengigabitethernet slot/port.
• Port channel: Enter port-channel number, where valid port-channel numbers are:
• For the C-Series and S-Series, 1 to 128
• For the E-Series, 1 to 32 (EtherScale) and 1 to 255 (TeraScale and ExaScale)
• SONET: Enter sonet slot/port.
• VLAN: Enter vlan vlan-id, where valid VLAN IDs are from 1 to 4094.
A line-protocol object only tracks the link-level (UP/DOWN) status of a specified interface. When the
link-level status goes down, the tracked object status is considered to be DOWN; if the link-level status is
up, the tracked object status is considered to be UP.
2 (Optional) Configure the time delay used delay {[up seconds] [down OBJECT TRACKING
before communicating a change in the seconds]}
status of a tracked interface. Valid delay times are from 0 to 180
seconds. Default: 0.
Track 100
Interface GigabitEthernet 7/1 line-protocol
Description: San Jose data center
Line protocol is Up
2 changes, last change 00:03:05
Tracked by:
For an IPv6 interface, a routing object only tracks the UP/DOWN status of the specified IPv6 interface
(track interface ipv6-routing command).
• The status of an IPv6 interface is UP only if the Layer 2 status of the interface is UP and the interface
has a valid IPv6 address.
• The Layer 3 status of an IPv6 interface goes DOWN when its Layer 2 status goes down (for a Layer 3
VLAN, all VLAN ports must be down) or the IPv6 address is removed from the routing table.
To configure object tracking on the routing status of a Layer 3 interface, use the following commands. To
remove object tracking on a Layer 3 IPv4/IPv6 interface, enter the no track object-id command.
1 Configure object tracking on the routing track object-id interface interface {ip CONFIGURATION
status of an IPv4 or IPv6 interface. routing | ipv6 routing}
Valid object IDs are from 1 to 65535.
2 (Optional) Configure the time delay used delay {[up seconds] [down OBJECT TRACKING
before communicating a change in the seconds]}
status of a tracked interface. Valid delay times are from 0 to 180
seconds. Default: 0.
Track 101
Interface GigabitEthernet 7/2 ip routing
Description: NYC metro
IP routing is Down (shutdown)
2 changes, last change 00:03:23
Tracked by:
Track 103
Interface GigabitEthernet 7/11 ipv6 routing
Description: Austin access point
IPv6 routing is Down (shutdown)
2 changes, last change 00:03:25
Tracked by:
In order for an route’s reachability or metric to be tracked, the route must appear as an entry in the routing
table. A tracked route is considered to match an entry in the routing table only if the exact IPv4 or IPv6
address and prefix length match an entry in the table. For example, when configured as a tracked route,
10.0.0.0/24 does not match the routing table entry 10.0.0.0/8. Similarly, for an IPv6 address,
3333:100:200:300:400::/80 does not match routing table entry 3333:100:200:300::/64. If no route-table
entry has the exact IPv4/IPv6 address and prefix length, the tracked route is considered to be DOWN.
In addition to the entry of a route in the routing table, you can configure the UP/DOWN state of a tracked
route to be determined in the following ways:
• By the reachability of the route's next-hop router
The UP/DOWN state of the route is determined by the entry of the next-hop address in the ARP cache.
A tracked route is considered to be reachable if there is an ARP cache entry for the route's next-hop
address. If the next-hop address in the ARP cache ages out for a route tracked for its reachability, an
attempt is made to regenerate the ARP cache entry to see if the next-hop address appears before con-
sidering the route DOWN.
• By comparing the threshold for a route’s metric with current entries in the route table
The UP/DOWN state of the tracked route is determined by the threshold for the current value of the
route metric in the routing table.
To provide a common tracking interface for different clients, route metrics are scaled in the range 0 to
255, where 0 is connected and 255 is inaccessible. The scaled metric value communicated to a client
always considers a lower value to have priority over a higher value. The resulting scaled value is com-
pared against the configured threshold values to determine the state of a tracked route as follows:
• If the scaled metric for a route entry is less than or equal to the UP threshold, the state of a route is
UP.
• If the scaled metric for a route is greater than or equal to the DOWN threshold or the route is not
entered in the routing table, the state of a route is DOWN.
The UP and DOWN thresholds are user-configurable for each tracked route. The default UP threshold
is 254; the default DOWN threshold is 255. The notification of a change in the state of a tracked object
is sent when a metric value crosses a configured threshold.
To configure object tracking on the reachability of an IPv4 or IPv6 route, use the following commands. To
remove object tracking, enter the no track object-id command.
2 (Optional) Configure the time delay delay {[up seconds] [down seconds]} OBJECT TRACKING
used before communicating a change Valid delay times are from 0 to 180
in the status of a tracked route. seconds. Default: 0.
Track 104
IP route 10.0.0.0/8 reachability
Reachability is Down (route not in route table)
2 changes, last change 00:02:49
Tracked by:
FTOS#configure
FTOS(conf)#track 4 ip route 3.1.1.0/24 reachability vrf vrf1
Track 105
IPv6 route 1234::/64 reachability
Description: Headquarters
Reachability is Down (route not in route table)
2 changes, last change 00:03:03
Tracked by:
To configure object tracking on the metric threshold of an IPv4 or IPv6 route, use the following
commands. To remove object tracking, enter the no track object-id command.
1 (Optional) Reconfigure the track resolution {ip route | ipv6 route} CONFIGURATION
default resolution value used by {isis resolution-value | ospf resolution-value}
the specified protocol to scale the Range of resolution values:
metric for IPv4 or IPv6 routes. ISIS routes - 1 to 1000. Default: 1.
OSPF routes - 1 to 1592. Default: 1.
3 (Optional) Configure the time delay {[up seconds] [down seconds]} OBJECT
delay used before communicating Valid delay times are from 0 to 180 seconds. Default: TRACKING
a change in the UP and/or 0.
DOWN status of a tracked route.
5 (Optional) Configure the metric threshold metric {[up number] [down number]} OBJECT
threshold for the UP and/or Default UP threshold: 254. The routing state is UP if TRACKING
DOWN routing status to be the scaled route metric is less than or equal to the UP
tracked for the specified route. threshold.
Default DOWN threshold: 255. The routing state is
DOWN if the scaled route metric is greater than or
equal to the DOWN threshold.
You can display the currently configured objects used to track Layer 2 and Layer 3 interfaces, and IPv4
and IPv6 routes, by entering the following show commands:
• show track [object-id [brief] | interface [brief] [vrf vrf-name] | ip route [brief] [vrf vrf-name] | resolution |
vrf vrf-name [brief] | brief]
Use the show track command to display the configuration and status of currently tracked Layer 2 or
Layer 3 interfaces, IPv4 or IPv6 routes, or a VRF instance. You can also display the currently config-
ured per-protocol resolution values used to scale route metrics when tracking metric thresholds.
Figure 31-9. Command Example: show track
FTOS#show track
Track 1
IP route 23.0.0.0/8 reachability
Reachability is Down (route not in route table)
2 changes, last change 00:16:08
Tracked by:
Track 2
IPv6 route 2040::/64 metric threshold
Metric threshold is Up (STATIC/0/0)
5 changes, last change 00:02:16
Metric threshold down 255 up 254
First-hop interface is GigabitEthernet 13/2
Tracked by:
VRRP GigabitEthernet 7/30 IPv6 VRID 1
Track 3
IPv6 route 2050::/64 reachability
Reachability is Up (STATIC)
5 changes, last change 00:02:16
First-hop interface is GigabitEthernet 13/2
Tracked by:
VRRP GigabitEthernet 7/30 IPv6 VRID 1
Track 4
Interface GigabitEthernet 13/4 ip routing
IP routing is Up
3 changes, last change 00:03:30
Tracked by:
Track 5
IP route 192.168.0.0/24 reachability, Vrf: red
Reachability is Up (CONNECTED)
3 changes, last change 00:02:55
First-hop interface is GigabitEthernet 13/4
Tracked by:
IP Route Resolution
ISIS 1
OSPF 1
Track 5
IP route 192.168.0.0/24 reachability, Vrf: red
Reachability is Up (CONNECTED)
3 changes, last change 00:02:39
First-hop interface is GigabitEthernet 13/4
Tracked by:
690
|
Object Tracking
32
Open Shortest Path First (OSPFv2 and OSPFv3)
Open Shortest Path First version 2 (OSPF for IPv4) is supported on platforms ces
Open Shortest Path First version 3 (OSPF for IPv6) is supported on platforms c e
OSPF for IPv4 is supported on the E-Series ExaScale platform with FTOS 8.1.1.0; OSPF for IPv6 is
supported on E-Series ExaScale with FTOS version 8.2.1.0 and later.
This chapter is intended to provide a general description of OSPFv2 (OSPF for IPv4) and OSPFv3 (OSPF
for IPv6) as supported in the Force 10 Operating System (FTOS). It is not intended to provide a complete
Note: The fundamental mechanisms of OSPF (flooding, DR election, area support, SPF calculations,
etc.) are the same between OSPFv2 and OSPFv3. Where there are differences between the two
versions, they are identified and clarified. Except where identified, the information in this chapter applies
to both protocol versions.
• Protocol Overview
• Implementing OSPF with FTOS
• Graceful Restart
• Fast Convergence (OSPFv2, IPv4 only)
• Multi-Process OSPF (OSPFv2, IPv4 only)
• RFC-2328 Compliant OSPF Flooding
• OSPF ACK Packing
• OSPF Adjacency with Cisco Routers
• Configuration Requirements
• Configuration Task List for OSPFv2 (OSPF for IPv4)
• Configuration Task List for OSPFv3 (OSPF for IPv6)
• Sample Configurations for OSPFv2
Open Shortest Path First (OSPF) routing is a link-state routing protocol that calls for the sending of
Link-State Advertisements (LSAs) to all other routers within the same Autonomous System (AS) Areas.
Information on attached interfaces, metrics used, and other variables is included in OSPF LSAs. As OSPF
routers accumulate link-state information, they use the SPF algorithm (Shortest Path First algorithm) to
calculate the shortest path to each node.
OSPF routers initially exchange HELLO messages to set up adjacencies with neighbor routers. The
HELLO process is used to establish adjacencies between routers of the AS. It is not required that every
router within the Autonomous System areas establish adjacencies. If two routers on the same subnet agree
to become neighbors through the HELLO process, they begin to exchange network topology information
in the form of Link State Advertisements (LSAs).
OSPFv3 runs on a per-link basis instead of on a per-IP-subnet basis. All neighbors on all link types are
identified by Router ID (RID). In OSPFv2 neighbors on broadcast and NBMA links are identified
by their interface addresses, while neighbors on other types of links are identified by RID.
OSPFv3 removes this inconsistency, and all neighbors on all link types are identified by RID.
Note: OSPFv3 is not backward-compatible with OSPFv2; they can co-exist. To use OSPF
with both IPv4 and IPv6, you must run both OSPFv2 and OSPFv3.
An AS can be divided into a number of areas, which are groups of contiguous networks and
attached hosts. Routers with multiple interfaces can participate in multiple areas. These routers,
Area Border Routers (ABRs), maintain separate databases for each area. Areas are a logical
grouping of OSPF routers identified by an integer or dotted-decimal number.
Areas allow you to further organize your routers within in the AS. One or more areas are required within
the AS. Areas are valuable in that they allow sub-networks to "hide" within the AS, thus minimizing the
size of the routing tables on all routers. An area within the AS may not see the details of another Area's
topology. AS areas are known by their area number or the router’s IP address.
Router M
Router K
Router F
Router E
Router L
Area 0
Router B Router H
Router A
Router I
Router J
Area 300
Area Types
The Backbone of the network is Area 0. It is also called Area 0.0.0.0 and is the core of any Autonomous
System (AS). All other areas must connect to Area 0. Areas can be defined in such a way that the
backbone is not contiguous. In this case, backbone connectivity must be restored through virtual
links. Virtual links are configured between any backbone routers that share a link to a
non-backbone area and function as if they were direct links.
An OSPF backbone is responsible for distributing routing information between areas. It consists of all
Area Border Routers, networks not wholly contained in any area, and their attached routers.
The Backbone is the only area with an default area number. All other areas can have their Area ID assigned
in the configuration.
receive information from inter-area (IA) routes. Note that all routers within an assigned Stub area must be
configured as stubby, and no generate LSAs that do not apply. For example, a Type 5 LSA is intended for
external areas and the Stubby area routers may not generate external LSAs. Stubby areas cannot be
traversed by a virtual link.
A Not-So-Stubby Area (NSSA) can import AS external route information and send it to the Backbone. It
cannot received external AS information from the Backbone or other areas. It can be traversed by a virtual
link.
Routers that share a link become neighbors on that segment. OSPF uses the hello protocol as a neighbor
discovery and keep alive mechanism. After two routers are neighbors, they may proceed to exchange and
synchronize their databases, which creates an adjacency.
Note: You can log adjacency state changes for OSPFv2 and v3 with the command log-adjacency-changes
from ROUTER OSPF mode.
Router Types
Router types are attributes of the OSPF process. A given physical router may be a part of one or more
OSPF processes. For example, a router connected to more than one area, receiving routing from a BGP
process connected to another AS acts as both an Area Border Router and an Autonomous System Router.
Each router has a unique ID, written in decimal format (A.B.C.D). The router ID does not have to be
associated with a valid IP address. However, Force 10 recommends that the router ID and the router’s IP
address reflect each other, to make troubleshooting easier.
Router M
Interior Router
Router K
Router E Router F
Interior Router
Router L
Stub Area
Router D Area 200
Router C
Not So Stubby Area Router G
Area 100
Backbone Area
Area 0
Router B Router H
Backbone Router Area Border Router
Router A Router I
Interior Router
Interior Router
Router J
Autonomous System
Boundary Router
Router 8000
Router 82 Router 81
Interior Router
OSPF AS 8888
A Backbone Router (BR) is part of the OSPF Backbone, Area 0. This includes all Area Border Routers
(ABRs). It can also include any routers that connect only to the Backbone and another ABR, but are only
part of Area 0, such as Router I in Figure 32-2 above.
Within an AS, an Area Border (ABR) connects one or more areas to the Backbone. The ABR keeps a copy
of the link-state database for every area it connects to, so it may keep multiple copies of the link state
database. An Area Border Router (ABR) takes information it has learned on one of its attached areas and
can summarize it before sending it out on other areas it is connected to.
An ABR can connect to many areas in an AS, and is considered a member of each area it connects to.
The Autonomous System Border Area Router (ASBR) connects to more than one AS, and exchanges
information with the routers in other ASs. Generally the ASBR connects to a non-Interior Gate Protocol
(IGP) such as BGP or uses static routes.
The Internal Router (IR) has adjacencies with ONLY routers in the same area, as Router E, M and I are
shown in Figure 32-2.
• The Designated Router (DR) maintains a complete topology table of the network and sends the
updates to the other routers via multicast. All routers in an area form a slave/master relationship with
the DR. Every time a router sends an update, it sends it to the Designated Router (DR) and Backup
Designated Router (BDR). The DR sends the update out to all other routers in the area.
• The Backup Designated Router (BDR) is the router that takes over if the DR fails.
Each router exchanges information with the DR and BDR. The DR and BDR relay the information to the
other routers. On broadcast network segments the number of OSPF packets is further reduced by the DR
and BDR sending such OSPF updates to a multicast IP address that all OSPF routers on the network
segment are listening on.
These router designations are not the same ad the router IDs discussed earlier. The Designated and Backup
Designated Routers are configurable in FTOS. If no DR or BDR is defined in FTOS, the system assigns
them. OSPF looks at the priority of the routers on the segment to determine which routers are the DR and
BDR. The router with the highest priority is elected the DR. If there is a tie, then the router with the higher
Router ID takes precedence. After the DR is elected, the BDR is elected the same way. A router with a
router priority set to zero is cannot become the DR or BDR.
• OSPFv3 can treat LSAs as having link-local flooding scope, or store and flood them as if they are
understood, while ignoring them in their own SPF algorithms.
• OSPFv2 always discards unknown LSA types.
Each router link is defined as one of four types: type 1, 2, 3, or 4. The LSA includes a link ID field that
identifies, by the network number and mask, the object this link connects to.
Virtual Links
In the case in which an area cannot be directly connected to Area 0, you must configure a virtual link
between that area and Area 0. The two endpoints of a virtual link are ABRs, and the virtual link must be
configured in both routers. The common non-backbone area to which the two routers belong is called a
transit area. A virtual link specifies the transit area and the router ID of the other virtual endpoint (the other
ABR).
Priority is a numbered rating 0-255. The higher the number, the higher the priority.
Cost is a numbered rating 1-65535. The higher the number, the greater the cost. The cost assigned reflects
the cost should the router fail. When a router fails and the cost is assessed, a new priority number results.
Router 1
Priority 200
Cost 21
Router 4
Priority 150
Cost 20
FTOS version 7.8.1.0 and later support multiple OSPF processes (OSPF MP).
Prior to 7.8.1.0, FTOS supports 1 OSPFv2 and 1 OSPFv3 process ID per system. Recall that OSPFv2 and
OSPFv3 can coexist but must be configured individually.
FTOS supports Stub areas, Totally Stub (No Summary) and Not So Stubby Areas (NSSAs) and supports
the following LSAs, as discussed earlier in this document.
• Router (type 1)
• Network (type 2)
• Network Summary (type 3)
• AS Boundary (type 4)
• AS External (type 5)
Graceful Restart
Graceful Restart for OSPFv2 is supported on c e and s platforms in Helper and Restart modes.
Graceful Restart for OSPFv3 is supported only on et platforms in Helper and Restart modes.
When a router goes down without a Graceful Restart, there is a possibility for loss of access to parts of the
network due to ongoing network topology changes. Additionally, LSA flooding and reconvergence can
cause substantial delays. It is, therefore, desirable that the network maintain a stable topology if it is
possible for data flow to continue uninterrupted.
OSPF Graceful Restart recognizes the fact that in a modern router, the control plane and data plane
functionality are separate, restarting the control plane functionality (such as the failover of the active RPM
to the backup in a redundant configuration), does not necessarily have to interrupt the forwarding of data
packets. This behavior is supported because the forwarding tables previously computed by an active RPM
have been downloaded into the Forwarding Information Base on the line cards (the data plane), and are
still resident. For packets that have existing FIB/CAM entries, forwarding between ingress and egress
ports/VLANs etc., can continue uninterrupted while the control plane OSPF process comes back to full
functionality and rebuilds its routing tables.
When a router is attempting to restart gracefully, it originates the following link-local Grace LSAs to notify
its helper neighbors that the restart process is beginning:
Type 9 and 11 LSAs include a grace period, which is the time period an OSPF router advertises to adjacent
neighbor routers as the time to wait for it to return to full control plane functionality. During the grace
period, neighbor OSPFv2 /v3 interfaces save the LSAs from the restarting OSPF interface. Helper
neighbor routers continue to announce the restarting router as fully adjacent, as long as the network
topology remains unchanged. When the restarting router completes its restart, it flushes the Type 9 and 11
LSAs, thereby notifying its neighbors that the restart is complete. This should happen before the grace
period expires.
Dell Force10 routers support the following OSPF graceful restart functionality:
• Restarting role in which a router is enabled to perform its own graceful restart.
• Helper role in which the router's graceful restart function is to help a restarting neighbor router in its
graceful restarts.
• Helper-reject role in which OSPF does not participate in the graceful restart of a neighbor.
OSPFv2 supports “helper-only” and “restarting-only” roles. By default, both helper and restarting
roles are enabled. OSPFv2 supports the helper-reject role globally on a router.
OSPFv3 supports “helper-only” and “restarting-only” roles. The “helper-only” role is enabled by
default. To enable the restarting role in addition to the “helper-only” role, you must configure a grace
To display the configuration values for OSPF graceful restart, enter the following commands:
• For OSPFv2: show run ospf
• For OSPFv3: show run ospf and show ipv6 ospf database database-summary
Note that the faster the convergence, the more frequent the route calculations and updates. This will impact
CPU utilization and may impact adjacency stability in larger topologies.
Multi-Process OSPF allows multiple OSPFv2 processes on a single router. Multiple OSPFv2 processes
allow for isolating routing domains, supporting multiple route policies and priorities in different domains,
and creating smaller domains for easier management.
equal number of interfaces must be in Layer-3 mode for the number of processes created. For example, if 5
OSPFv2 processes are created on a system, there must be at least 5 interfaces assigned in Layer-3 mode.
Each OSPFv2 process is independent. If one process loses adjancency, the other processes continue to
function/
By default, FTOS implements an enhanced flooding procedure which dynamically and intelligently detects
when to optimize flooding. Wherever possible, the OSPF task attempts to reduce flooding overhead by
selectively flooding on a subset of the interfaces between two routers.
If RFC 2328 flooding behavior is required, enable it by using the command flood-2328 in ROUTER OSPF
mode. When enabled, this command configures FTOS to flood LSAs on all interfaces.
Confirm RFC 2328 flooding behavior by using the command debug ip ospf packet and look for output
similar to the following:
In FTOS Version, 7.5.1.0 use show ip ospf to confirm that RFC-2328 compliant OSPF flooding is enabled,
as shown below.
match the Cisco configuration. Use the command “ip ospf dead-interval <x>” in interface mode:
Configuration Requirements
The interfaces must be in Layer-3 mode (assigned an IP address) and enabled so that they can send and
receive traffic. The OSPF process must know about these interfaces. To make the OSPF process aware of
these interfaces, they must be assigned to OSPF areas.
OSPF features and functions are assigned to each router using the CONFIG-INTERFACE commands for
each interface.
The following configuration steps include two mandatory steps and several optional ones:
• Enable OSPFv2 (mandatory)
• Enable Multi-Process OSPF
• Assign an OSPFv2 area (mandatory)
• Enable OSPFv2 on interfaces
• Configure stub areas
• Configure OSPF Stub-Router Advertisement
• Enable passive interfaces
• Enable fast-convergence
• Change OSPFv2 parameters on interfaces
• Enable OSPFv2 authentication
• Enable OSPFv2 graceful restart
• Configure virtual links
• Redistribute routes
• Troubleshooting OSPFv2
For a complete listing of all commands related to OSPFv2, refer to the OSPF section in the FTOS
Command Line Interface document.
Enable OSPFv2
Assign an IP address to an interface (physical or Loopback) to enable Layer 3 routing. By default OSPF,
like all routing protocols, is disabled.
You must configure at least one interface for Layer 3 before enabling OSPFv2 globally.
If implementing, Multi-Process OSPF, you must create an equal number of Layer 3 enabled interfaces and
OSPF Process IDs. For example, if you create 4 OSPFv2 process IDs, you must have 4 interfaces with
Layer 3 enabled.
number assigned to the OSPF process, and the Router ID is the IP address associated with the OSPF
process. .
router ospf process-id [vrf {vrf name}] CONFIGURATION Enable the OSPFv2 process globally.
Range: 0-65535
vrf name: Enter the VRF key word and
instance name to tie the OSPF instance to the
VRF. All network commands under this OSPF
instance are subsequently tied to the VRF
instance.
Once the OSPF process and the VRF are tied together, the OSPF Process ID cannot be used again in the
system.
If you try to enter an OSPF Process ID, or if you try to enable more OSPF processes than available Layer 3
interfaces, prior to assigning an IP address to an interface and setting the no shutdown command, you will
see the following message.
Message 1
C300(conf)#router ospf 1
% Error: No router ID available.
In CONFIGURATION ROUTER OSPF mode, assign the Router ID. The Router ID is not required to be
the router’s IP address. Dell Force10 recommends using the IP address as the Router ID for easier
management and troubleshooting.
Use the no router ospf process-id command syntax in the CONFIGURATION mode to disable OSPF.
Use the clear ip ospf process-id command syntax in EXEC Privilege mode to reset the OSPFv2 process.
Use the show ip ospf process-id command in EXEC mode (Figure 408) to view the current OSPFv2 status.
Figure 32-8. Command Example: show ip ospf process-id
FTOS#show ip ospf 55555
Routing Process ospf 55555 with ID 10.10.10.10
Supports only single TOS (TOS0) routes
SPF schedule delay 5 secs, Hold time between two SPFs 10 secs
Number of area in this router is 0, normal 0 stub 0 nssa 0
FTOS#
Follow the same steps as above, when configuring a single OSPF process. Repeat them as often as
necessary for the desired number of processes. Once the process is created, all other configurations apply
as usual,
Return to CONFIGURATION mode to enable the OSPF process. The OSPF Process ID is the identifying
number assigned to the OSPF process, and the Router ID is the IP address associated with the OSPF
process. .
router ospf process-id [vrf {vrf name}] CONFIGURATION Enable the OSPFv2 process globally.
Range: 0-65535
vrf name: Enter the VRF key word and
instance name to tie the OSPF instance to the
VRF. All network commands under this OSPF
instance are subsequently tied to the VRF
instance.
Once the OSPF process and the VRF are tied together, the OSPF Process ID cannot be used again in the
system.
If you try to enable more OSPF processes than available Layer 3 interfaces you will see the following
message.
Message 2
C300(conf)#router ospf 1
% Error: No router ID available.
the router’s IP address. Dell Force10 recommends using the IP address as the Router ID for easier
management and troubleshooting.
Use the no router ospf process-id command syntax in the CONFIGURATION mode to disable OSPF.
Use the clear ip ospf process-id command syntax in EXEC Privilege mode to reset the OSPFv2 process.
You must have at least one AS area: Area 0. This is the Backbone Area. If your OSPF network contains
more than one area, you must also configure a backbone area (Area ID 0.0.0.0). Any area besides Area 0
can have any number ID assigned to it.
The OSPFv2 process evaluates the network commands in the order they are configured. Assign the
network address that is most explicit first to include all subnets of that address. For example, if you assign
the network address 10.0.0.0 /8, you cannot assign the network address 10.1.0.0 /16 since it is already
included in the first network address.
When configuring the network command, you must configure a network address and mask that is a
superset of the IP subnet configured on the Layer-3 interface to be used for OSPFv2.
Use this command in CONFIGURATION ROUTER OSPF mode to set up each neighbor and OSPF area.
The Area can be assigned by a number or with an IP interface address.
network ip-address mask area area-id CONFIG-ROUTER-OSPF-id Enable OSPFv2 on an interface and
assign an network address range to a
specific OSPF area.
IP Address Format: A.B.C.D/M
Area ID Range: 0-65535 or A.B.C.D/M
OSPF functions and features, such as MD5 Authentication, Grace Period, Authentication Wait Time, etc,
are assigned on a per interface basis.
Note: If using features like MD5 Authentication, ensure all the neighboring routers are also
configured for MD5.
Figure 32-9 presents an example of assigning an IP address to an interface and then assigning an OSPFv2
area that includes that Layer-3 interface’s IP address.
Figure 32-9. Configuring an OSPF Area Example
FTOS#(conf)#int gi 4/44
FTOS(conf-if-gi-4/44)#ip address 10.10.10.10/24 Assign Layer-3 interface
FTOS(conf-if-gi-4/44)#no shutdown with IP Address and
FTOS(conf-if-gi-4/44)#ex no shutdown
FTOS(conf)#router ospf 1
FTOS(conf-router_ospf-1)#network 1.2.3.4/24 area 0
FTOS(conf-router_ospf-1)#network 10.10.10.10/24 area 1 Assign interface’s
FTOS(conf-router_ospf-1)#network 20.20.20.20/24 area 2 IP Address to an Area
FTOS(conf-router_ospf-1)#
FTOS#
Force 10 recommends that the OSPFv2 Router ID be the interface IP addresses for easier management and
troubleshooting.
Use the show config command in CONFIGURATION ROUTER OSPF mode to view the configuration.
OSPF, by default, sends hello packets out to all physical interfaces assigned an IP address that are a subset
of a network on which OSPF is enabled. Use the show ip ospf interface command (Figure 410) to view
the interfaces currently active and the areas assigned to the interfaces.
Loopback interfaces also assist in the OSPF process. OSPF will pick the highest interface address as the
router-id and a loopback interface address has a higher precedence than other interface addresses.
Figure 32-11 gives an example of the show ip ospf process-id interface command with a Loopback
interface.
Figure 32-11. Command Example: show ip ospf process-id interface
FTOS#show ip ospf 1 int
To ensure connectivity in your OSPFv2 network, never configure the backbone area as a stub area.
Use these commands in the following sequence, starting in EXEC Privilege mode to configure a stub area.
1 show ip ospf process-id [vrf EXEC Privilege Review all areas after they were configured to
vrf name] database determine which areas are NOT receiving type 5
database-summary LSAs.
3 router ospf process-id [vrf {vrf CONFIGURATION Enter the ROUTER OSPF mode.
name}] Process ID is the ID assigned when configuring
OSPFv2 globally (page 58).
vrf name: Enter the VRF key word and instance name to
tie the OSPF instance to the VRF. All network commands
under this OSPF instance are subsequently tied to the
VRF instance.
4 area area-id stub CONFIG-ROUTER-O Configure the area as a stub area. Use the
[no-summary] SPF-id no-summary keywords to prevent transmission in
to the area of summary ASBR LSAs.
Area ID is the number or IP address assigned when
creating the Area (page 60).
Use the show ip ospf database process-id database-summary command syntax (Figure 413) in the
EXEC Privilege mode To view which LSAs are transmitted.
Figure 32-12. Command Example: show ip ospf process-id database database-summary
FTOS#show ip ospf 34 database database-summary
To view information on areas, use the show ip ospf process-id command in the EXEC Privilege mode.
By using the max-metric router-lsa command, you force the link cost of all OSPF non-stub links to the
maximum link cost (65535) for a specified time. The advertisement of this maximum metric causes other
routers to assign a cost to the new router that is higher than the cost of using an alternate path. Because of
the high cost assigned to paths that pass through the new router, other routers will not use a path through
the new router as a transit path to forward traffic to other networks.
Use the max-metric router-lsa command to gracefully shut down or reload a router without dropping
packets destined for other networks.
max-metric router-lsa ROUTER OSPF E-Series ExaScale only: Configure the maximum cost of
[on-startup {announce-time | 65535 on a new router so that it always functions as a stub
wait-for-bgp [wait-time]}] router in the network and OSPF traffic destined to other
networks is not routed on paths which pass through the
router.
on-startup announce-time specifies the time (in
seconds) following boot-up during which the
maximum cost (65535) for transmitting OSPF traffic
on router interfaces is announced in LSAs and the
router functions as a stub router.
Range: 5 to 86400 seconds.
on-startup wait-for-bgp [wait-time] enables the router
to announce the maximum metric in OSPF LSAs until
the BGP routing table converges with updated
routes. Default: 600 seconds.
You can also specify the time (in seconds) that the
router waits for the BGP routing table to converge
before it stops advertising the maximum cost in LSAs
and advertises the router’s currently configured
OSPF cost. Range: 5 to 86400 seconds.
Note: If you enter the max-metric router-lsa command without an option (on-startup announce-time or
on-startup wait-for-bgp [wait-time]), the maximum metric of 65535 is always announced in LSAs sent by the
router.
Use the following command in the ROUTER OSPF mode to suppress the interface’s participation on an
OSPF interface. This command stops the router from sending updates on that interface.
passive-interface {default | CONFIG-ROUTER- Specify whether all or some of the interfaces will be passive.
interface} OSPF-id Default enabled passive interfaces on ALL interfaces in the
OSPF process.
Entering the physical interface type, slot, and number enable
passive interface on only the identified interface.
• For a Gigabit Ethernet interface, enter the keyword
GigabitEthernet followed by the slot/port information
(e.g. passive-interface gi 2/1).
• For a port channel, enter the keyword port-channel
followed by a number from 1 to 255 for TeraScale and
ExaScale, 1 to 32 for EtherScale (e.g. passive-interface
po 100)
• For a SONET interface, enter the keyword sonet
followed by the slot/port information (e.g.
passive-interface so 2/2).
• For a 10-Gigabit Ethernet interface, enter the keyword
TenGigabitEthernet followed by the slot/port
information (e.g. passive-interface ten 2/3).
• For a VLAN, enter the keyword vlan followed by a
number from 1 to 4094 (e.g. passive-interface vlan
2222).
E-Series ExaScale platforms support 4094 VLANs
with FTOS version 8.2.1.0 and later. Earlier
ExaScale supports 2094 VLANS.
The default keyword sets all interfaces on this OSPF process as passive. The passive
interface can be removed from select interfaces using the no passive-interface
interface command while passive interface default is configured.
To enable both receiving and sending routing updates, enter the no passive-interface interface command.
When you configure a passive interface, the show ip ospf process-id interface command (Figure 413)
adds the words “passive interface” to indicate that hello packets are not transmitted on that
interface.
Enable fast-convergence
The fast-convergence CLI sets the minimum origination and arrival LSA parameters to zero (0), allowing
rapid route calculation. When fast-convergence is disabled, origination and arrival LSA parameters are set
to 5 seconds and 1 second, respectively.
Setting the convergence parameter (1-4) indicates the actual convergence level. Each convergence setting
adjusts the LSA parameters to zero, but the fast-convergence parameter setting allows for even finer tuning
of the convergence speed. The higher the number, the faster the convergence. Use the following command
in the ROUTER OSPF mode to enable or disable fast-convergence.
fast-convergence {number} CONFIG-ROUTER- Enable OSPF fast-convergence and specify the convergence
OSPF-id level.
Parameter: 1-4
The higher the number, the faster the convergence.
When disabled, the parameter is set at 0 (Figure 32-15).
ip ospf cost CONFIG-INTERFACE Change the cost associated with OSPF traffic on
the interface.
Cost: 1 to 65535 (default depends on the
interface speed).
ip ospf dead-interval seconds CONFIG-INTERFACE Change the time interval the router waits before
declaring a neighbor dead. Configure Seconds
range: 1 to 65535 (default is 40 seconds).
The hello interval must be the same on all routers in the OSPF network.
ip ospf message-digest-key keyid CONFIG-INTERFACE Use the MD5 algorithm to produce a message
md5 key digest or key, which is sent instead of the key.
Keyid range: 1 to 255
Key: a character string
Be sure to write down or otherwise record the Key. You cannot learn the key
once it is configured.
You must be careful when changing this key.
ip ospf priority number CONFIG-INTERFACE Change the priority of the interface, which is
used to determine the Designated Router for the
OSPF broadcast network.
Number range: 0 to 255 (the default is 1).
The retransmit interval must be the same on all routers in the OSPF network.
ip ospf transmit-delay seconds CONFIG-INTERFACE Change the wait period between link state
update packets sent out the interface. Seconds
range: from 1 to 65535 (default is 1 second).
The transmit delay must be the same on all routers in the OSPF network.
Use the show config command in CONFIGURATION INTERFACE mode (Figure 32-16) to view interface
configurations. Use the show ip ospf interface command in EXEC mode to view interface status in the
OSPF process.
ip ospf authentication-key key CONFIG-INTERFACE Set clear text authentication scheme on the
interface. Configure a key that is a text string no
longer than eight characters.
All neighboring routers must share the same
password to exchange OSPF information.
ip ospf auth-change-wait-time CONFIG-INTERFACE Set the authentication change wait time in
seconds seconds between 0 and 300 for the interface.
This is the amount of time OSPF has available to
change its interface authentication type. During
the auth-change-wait-time, OSPF sends out
packets with both the new and old authentication
schemes. This transmission stops when the
period ends. The default is 0 seconds.
The Dell Force10 implementation of OSPFv2 graceful restart enables you to specify:
• grace period—the length of time the graceful restart process can last before OSPF terminates it.
configured router.
• mode—the situation or situations that trigger a graceful restart.
• role—the role or roles the configured router can perform.
graceful-restart CONFIG-ROUTER- Enable OSPFv2 graceful-restart globally and set the grace period.
grace-period seconds OSPF-id Seconds range: between 40 and 3000
This is the period of time that an OSPFv2 router’s neighbors will advertise it as fully
adjacent, regardless of the synchronization state, during a graceful restart.
OSPFv2 terminates this process when the grace period ends.
graceful-restart CONFIG-ROUTER- Enter the Router ID of the OSPFv2 helper router from which the
helper-reject router-id OSPF-id router does not accept graceful restart assistance.
This applies to the specified router only.
IP Address: A.B.C.D
graceful-restart mode CONFIG-ROUTER- Specify the operating mode in which graceful-restart functions.
[planned-only | OSPF-id FTOS supports the following options:
unplanned-only] • Planned-only. The OSPFv2 router supports graceful-restart for
planned restarts only. A planned restart is when the user
manually enters a fail-over command to force the primary
RPM over to the secondary RPM. During a planned restart,
OSPF sends out a Grace LSA before the system switches over
to the secondary RPM. OSPF also is notified that a planned
restart is happening.
• Unplanned-only. The OSPFv2 router supports graceful-restart
for only unplanned restarts. During an unplanned restart, OSPF
sends out a Grace LSA once the secondary RPM comes online.
By default, OSPFv2 supports both planned and unplanned restarts. Selecting one or the
other mode restricts OSPFv2 to the single selected mode.
graceful-restart role CONFIG-ROUTER- Configure the graceful restart role or roles that this OSPFv2 router
[helper-only | restart-only] OSPF-id performs. FTOS supports the following options:
• Helper-only. The OSPFv2 router supports graceful-restart only
as a helper router.
• Restart-only. The OSPFv2 router supports graceful-restart only
during unplanned restarts.
By default, OSPFv2 supports both restarting and helper roles. Selecting one or the other role
restricts OSPFv2 to the single selected role.
When you configure a graceful restart on an OSPFv2 router, the show run ospf command (Figure 32-17)
displays information similar to the following.
Use the following command to disable OSPFv2 graceful-restart after you have enabled it.
For more information on OSPF graceful restart, refer to the FTOS Command Line Interface Reference.
area area-id virtual-link router-id [hello-interval CONFIG-ROUTER- Configure the optional parameters of a
seconds | retransmit-interval seconds | transmit-delay OSPF-id virtual link:
seconds | dead-interval seconds | authentication-key • Area ID: assigned earlier (0-65535 or
key | message-digest-key keyid md5 key] A.B.C.D)
• Router ID: IP address associated with
the virtual link neighbor
• Hello Interval Seconds: 1-8192
(default 10)
• Retransmit Interval Seconds: 1-3600
(default 5)
• Transmit Delay Seconds: 1-3600
(default 1)
• Dead Interval Seconds: 1-8192
(default 40)
• Authentication Key: 8 characters
• Message Digest Key: 1-255
• MD5 Key: 16 characters
Use the show ip ospf process-id virtual-links command (Figure 32-18) in the EXEC mode to view the
virtual link.
Figure 32-18. Command Example: show ip ospf process-id virtual-links
FTOS#show ip ospf 1 virtual-links
Filter routes
To filter routes, use prefix lists. OSPF applies prefix lists to incoming or outgoing routes. Incoming routes
must meet the conditions of the prefix lists, and if they do not, OSPF does not add the route to the routing
table. Configure the prefix list in CONFIGURATION PREFIX LIST mode prior to assigning it to the
OSPF process.
seq sequence-number {deny |permit} ip-prefix CONFIG- PREFIX Create a prefix list with a sequence.
[ge min-prefix-length] [le max-prefix-length] LIST number and a deny or permit action. The
optional parameters are:
ge min-prefix-length: is the minimum
prefix length to be matched (0 to 32).
le max-prefix-length: is the maximum prefix
length to be matched (0 to 32).
For configuration information on prefix lists, refer to IP Access Control Lists, Prefix Lists, and Route-maps
chapter in the FTOS Configuration Guide.
Use the following commands in CONFIGURATION-ROUTER OSPF mode to apply prefix lists to
incoming or outgoing OSPF routes
distribute-list prefix-list-name out [connected | CONFIG-ROUTER- Assign a configured prefix list to outgoing
isis | rip | static] OSPF-id OSPF routes.
Redistribute routes
You can add routes from other routing instances or protocols to the OSPF process. With the redistribute
command syntax, you can include RIP, static, or directly connected routes in the OSPF process.
Note: Do not route iBGP routes to OSPF unless there are route-maps associated with the OSPF
redistribution.
redistribute {bgp | connected | isis | CONFIG-ROUTER- Specify which routes will be redistributed into OSPF
rip | static} [metric metric-value | OSPF-id process. Configure the following required and
metric-type type-value] [route-map optional parameters:
map-name] [tag tag-value] • bgp, connected, isis, rip, or static: enter one
of the keyword to redistribute those routes. rip is
supported only on E-Series.
• metric metric-value range: 0 to 4294967295.
• metric-type metric-type: 1 for OSPF external
route type 1 or 2 for OSPF external route type 2.
• route-map map-name: enter a name of a
configured route map.
• tag tag-value range: 0 to 4294967295.
Troubleshooting OSPFv2
FTOS has several tools to make troubleshooting easier. Be sure to check the following, as these are typical
issues that interrupt an OSPFv2 process. Note that this is not a comprehensive list, just some examples of
typical troubleshooting checks.
• show interfaces
• show protocols
• debug IP OSPF events and/or packets
• show neighbors
• show virtual links
• show routes
Note: If you are using Multi-Process OSPF, you must enter the Process ID to view information regarding a
specific OSPF process. If you do not enter the Process ID, only the first configured process is listed.
show running-config ospf EXEC Privilege View the summary of all OSPF process IDs enables on the
router.
Use the following commands in EXEC Privilege mode to get general route and links status information.
show ip route summary EXEC Privilege View the summary information of the IP routes
show ip ospf database EXEC Privilege View the summary information for the OSPF database
Use the following command in EXEC Privilege mode to view the OSPFv2 configuration for a neighboring
router:
show ip ospf neighbor EXEC Privilege View the configuration of OSPF neighbors.
process:
To display a summary of the information stored in the OSPFv2 database of the router, enter the show ip
ospf database database-summary command. Note that the number of Type-9 Grace LSAs received from
restarting neighbor OSPFv2 routers are also displayed.
Command Syntax Command Mode Usage
show ip ospf database EXEC Privilege View a summary of OSPFv2 database information.
database-summary
Area ID Router Net S-Net S-ASBR Type7 Type9 Type10 Total ChSum
0 4 3 3000 0 0 1 0 3008 0x5e69164
You can copy and paste from these examples to your CLI. Be sure you make the necessary changes to
support your own IP Addresses, Interfaces, Names, etc.
OSPF AREA 0
GI 1/1 GI 2/1
GI 2/2
GI 1/2
GI 3/1 GI 3/2
Open Shortest Path First version 3 (OSPF for IPv6) is supported on platforms ce
The configuration options of OSPFv3 are the same as those for OSPFv2, but may be configured with
differently labeled commands. Process IDs and areas need to be specified. Interfaces and addresses need to
be included in the process. Areas can be defined as stub or totally stubby.
The interfaces must be in IPv6 Layer-3 mode (assigned an IPv6 IP address) and enabled so that they can
send and receive traffic. The OSPF process must know about these interfaces. To make the OSPF process
aware of these interfaces, they must be assigned to OSPF areas.
TheOSPFv3 ipv6 ospf area command enables OSPFv3 on the interface and places the interface in an area.
With OSPFv2, two commands are required to accomplish the same tasks: the router ospf command to
create the OSPF process, then the network area command to enable OSPF on an interface. Note that the
OSPFv2 network area command can enable OSPF on multiple interfaces with the single command, while
the OSPFv3 ipv6 ospf area command must be configured on each interface that will be running OSPFv3.
All IPv6 addresses on an interface are included in the OSPFv3 process that is created on the interface.
OSPFv3 for IPv6 is enabled by specifying an OSPF Process ID and an Area in the INTERFACE mode. If
an OSPFv3 process has not yet been created, it is created automatically. All IPv6 addresses configured on
the interface are included in the specified OSPF process.
Note: IPv6 and OSPFv3 do not support Multi-Process OSPF. Only a single OSPFv3 process is can be
enabled.
ipv6 address ipv6 address CONF-INT-type slot/port Assign IPv6 address to the interface.
IPv6 addresses are normally written as
eight groups of four hexadecimal digits,
where each group is separated by a colon
(:).
FORMAT: A:B:C::F/128
no shutdown CONF-INT-type slot/port Bring the interface up.
ipv6 ospf process-id area area-id CONF-INT-type slot/port Assign the OSPFv3 process and an
OSPFv3 area to this interface.
process-id: The Process ID number
assigned above.
area-id: the area ID for this interface.
The ipv6 ospf area command enables OSPFv3 on an interface and places the interface in the specified
area. Additionally, it creates the OSPFv3 process with ID on the router. OSPFv2 required two commands
are required to accomplish the same tasks: the router ospf command to create the OSPF process, then the
network area command to enable OSPFv2 on an interface. Note that the OSPFv2 network area command
can enable OSPFv2 on multiple interfaces with the single command, whereas the OSPFv3 ipv6 ospf area
command must be configured on each interface that will be running OSPFv3.
ipv6 router ospf {process ID} CONFIGURATION Enable the OSPFv3 process globally and
enter OSPFv3 mode.
Range: 0-65535
area area-id stub CONF-IPV6-ROUTER-OSPF Configure the area as a stub area. Use the
[no-summary] no-summary keywords to prevent transmission in
to the area of summary ASBR LSAs.
Area ID is a number or IP address assigned when
creating the Area.
The Area ID can be represented as a number
between 0 – 65536 if a dotted decimal format is
assigned, rather than an IP address.
passive-interface CONF-IPV6-ROUTER-OSPF Specify whether some or all some of the interfaces will be
{type slot/port} passive.
Interface identifies the specific interface that will be
passive.
• For a Gigabit Ethernet interface, enter the keyword
GigabitEthernet followed by the slot/port information
(e.g. passive-interface gi 2/1).
• For a port channel, enter the keyword port-channel
followed by a number from 1 to 255 for TeraScale and
ExaScale, 1 to 32 for EtherScale (e.g. passive-interface
po 100)
• For a 10-Gigabit Ethernet interface, enter the keyword
TenGigabitEthernet followed by the slot/port
information ( e.g. passive-interface ten 2/3).
• For a VLAN, enter the keyword vlan followed by a
number from 1 to 4094 (e.g. passive-interface vlan
2222).
E-Series ExaScale platforms support 4094 VLANs
with FTOS version 8.2.1.0 and later. Earlier
ExaScale supports 2094 VLANS.
To enable both receiving and sending routing updates, enter the no passive-interface interface command.
When you configure a passive interface, the show ipv6 ospf interface command adds the words
“passive interface” to indicate that hello packets are not transmitted on that interface.
You can add routes from other routing instances or protocols to the OSPFv3 process. With the redistribute
command syntax, you can include RIP, static, or directly connected routes in the OSPF process.
default-information originate CONF-IPV6-ROUTER-OSPF Specify the information for the default route.
[always [metric metric-value] Configure the following required and
[metric-type type-value]] optional parameters:
[route-map map-name] • always: indicate that default route
information must always be advertised
• metric metric-value range: 0 to
4294967295.
• metric-type metric-type: 1 for OSPFv3
external route type 1 OR 2 for OSPFv3
external route type 2.
• route-map map-name: enter a name of
a configured route map.
By default, OSPFv3 graceful restart is disabled and functions only in a helper role to help restarting
neighbor routers in their graceful restarts when it receives a Grace LSA.
To enable OSPFv3 graceful restart, you must enter the ipv6 router ospf process-id command to enter
OSPFv3 configuration mode and then configure a grace period using the graceful-restart grace-period
command. The grace period is the length of time that OSPFv3 neighbors continue to advertise the
restarting router as though it is fully adjacent. When graceful restart is enabled (restarting role), an OSPFv3
restarting expects its OSPFv3 neighbors to help when it restarts by not advertising the broken link.
When you enable the helper-reject role on an interface with the ipv6 ospf graceful-restart helper-reject
command, you reconfigure OSPFv3 graceful restart to function in a “restarting-only” role. OSPFv3 does
not participate in the graceful restart of a neighbor. (Note that you enter the ipv6 ospf graceful-restart
helper-reject command in Interface configuration mode.)
graceful-restart CONF-IPV6-ROUTE Enable OSPFv3 graceful restart globally by setting the grace
grace-period seconds R-OSPF period (in seconds). Valid values are from 40 to 1800 seconds.
ipv6 ospf graceful-restart INTERFACE Configure an OSPFv3 interface to not act upon the Grace LSAs
helper-reject that it receives from a restarting OSPFv3 neighbor.
graceful-restart mode CONF-IPV6-ROUTE Specify the operating mode and type of events that trigger a
[planned-only | R-OSPF graceful restart:
unplanned-only] • Planned-only. The OSPFv3 router supports graceful restart
only for planned restarts. A planned restart is when you
manually enter a redundancy force-failover rpm command to
force the primary RPM over to the secondary RPM. During a
planned restart, OSPFv3 sends out a Grace LSA before the
system switches over to the secondary RPM. OSPFv3 is
notified that a planned restart is happening.
• Unplanned-only. The OSPFv3 router supports graceful-restart
only for unplanned restarts. During an unplanned restart,
OSPFv3 sends out a Grace LSA once the secondary RPM
comes online.
Default: Both planned and unplanned restarts trigger an OSPFv3
graceful restart. Selecting one or the other mode restricts OSPFv3
to the single selected mode.
To disable OSPFv3 graceful restart when it is enabled, enter the following command:
commands:
Command Syntax Command Mode Usage
show run ospf EXEC Privilege Display the graceful-restart configuration for OSPFv2 and
OSPFv3 (Figure 32-23).
show ipv6 ospf database EXEC Privilege Display the Type-11 Grace LSAs sent and received on an
grace-lsa OSPFv3 router (Figure 32-24).
show ipv6 ospf database EXEC Privilege Display the currently configured OSPFv3 parameters for
database-summary graceful restart (Figure 32-25).
LS Age : 10
Link State ID : 6.16.192.66
Advertising Router : 100.1.1.1
LS Seq Number : 0x80000001
Checksum : 0x1DF1
Length : 36
Associated Interface : Gi 5/3
Restart Interval : 180
Restart Reason : Switch to Redundant Processor
IPsec is a set of protocols developed by the IETF to support secure exchange of packets at the IP layer.
IPsec supports two encryption modes: Transport and Tunnel. Transport mode encrypts only the data
portion (payload) of each packet, but leaves the header untouched. The more secure Tunnel mode encrypts
both the header and the payload. On the receiving side, an IPsec-compliant device decrypts each packet.
Note: FTOS supports only transport encryption mode in OSPFv3 authentication with IPsec.
With IPsec-based authentication, crypto images are used to include the IPsec secure socket application
programming interface (API) required for use with OSPFv3.
To ensure integrity, data origin authentication, detection and rejection of replays, and confidentiality of the
packet, RFC 4302 and RFC 4303 propose using two security protocols - AH (authentication header) and
ESP (encapsulating security payload). For OSPFv3, these two IPsec protocols provide interoperable,
high-quality cryptographically-based security.
• The IPsec authentication header is used in packet authentication to verify that data is not altered during
transmission and ensures that users are communicating with the intended individual or organization.
The authentication header is inserted after the IP header with a value of 51. AH provides integrity and
validation of data origin by authenticating every OSPFv3 packet. For detailed information on the IP
AH protocol, refer to RFC 4302.
• The encapsulating security payload encapsulates data, enabling the protection of data that follows in
the datagram. ESP provides authentication and confidentiality of every packet. The ESP extension
header is designed to provide a combination of security services for both IPv4 and IPv6. The ESP
header is inserted after the IP header and before the next layer protocol header in transport mode. It is
possible that the ESP header is inserted between the next layer protocol header and encapsulated IP
header in tunnel mode. The tunnel mode is not supported in FTOS. For detailed information on the IP
ESP protocol, refer to RFC 4303.
In OSPFv3 communication, IPsec provides security services between a pair of communicating hosts or
security gateways using either AH or ESP. In an authentication policy on an interface or in an OSPF area,
AH and ESP are used alone; in an encryption policy, AH and ESP may be used together. The difference
between the two mechanisms is the extent of the coverage. ESP only protects IP header fields if they are
encapsulated by ESP.
The set of IPsec protocols that are employed for authentication and encryption and the ways in which they
are employed is user-dependent. When IPsec is correctly implemented and deployed, it does not adversely
affect users or hosts. AH and ESP are designed to be cryptographic algorithm-independent.
OSPFv3 authentication using IPsec is implemented according to the specifications in RFC 4552,
including:
• To use IPsec, you configure an authentication (using AH) or encryption (using ESP) security policy on
an interface or in an OSPFv3 area. Each security policy consists of a security policy index (SPI) and
the key used to validate OSPFv3 packets. After IPsec is configured for OSPFv3, IPsec operation is
invisible to the user.
• Only one security protocol (AH or ESP) can be enabled at a time on an interface or for an area.
IPsec AH is enabled with the ipv6 ospf authentication command; IPsec ESP is enabled with the
ipv6 ospf encryption command.
• The security policy configured for an area is inherited by default on all interfaces in the area.
• The security policy configured on an interface overrides any area-level configured security for the
area to which the interface is assigned.
• The configured authentication or encryption policy is applied to all OSPFv3 packets transmitted
on the interface or in the area. The IPsec security associations (SAs) are the same on inbound and
outbound traffic on an OSPFv3 interface.
• There is no maximum AH or ESP header length because the headers have fields with variable
lengths.
• Manual key configuration is supported in an authentication or encryption policy (dynamic key
configuration using the Internet Key Exchange (IKE) protocol is not supported).
• In an OSPFv3 authentication policy:
• AH is used to authenticate OSPFv3 headers and certain fields in IPv6 headers and extension
headers.
• MD5 and SHA1 authentication types are supported; encrypted and unencrypted keys are
supported.
• In an OSPFv3 encryption policy:
• Both encryption and authentication are used.
• IPsec security associations (SAs) are supported only in transport mode (tunnel mode is not
supported).
• ESP with null encryption is supported for authenticating only OSPFv3 protocol headers.
• ESP with non-null encryption is supported for full confidentiality.
• 3DES, DES, AES-CBC, and NULL encryption algorithms are supported; encrypted and
unencrypted keys are supported.
Note: You may encrypt all keys on a router by using the service password-encryption command in
global configuration mode. However, this command does not provide a high level of network security. To
enable key encryption in an IPsec security policy at an interface or area level, specify 7 for
[key-encryption-type] when you enter the ipv6 ospf authentication ipsec or ipv6 ospf encryption ipsec
command.
• To configure an IPsec security policy for authenticating or encrypting OSPFv3 packets on a physical,
port-channel, or VLAN interface or OSPFv3 area, perform any of the following tasks:
• Configuring IPsec Authentication on an Interface
• Configuring IPsec Encryption on an Interface
Prerequisite: Before you enable IPsec authentication on an OSPFv3 interface, you must first enable IPv6
unicast routing globally, configure an IPv6 address and enable OSPFv3 on the interface, and assign it to an
area (see Configuration Task List for OSPFv3 (OSPF for IPv6) on page 726).
ipv6 ospf authentication {null | INTERFACE Enable IPsec authentication for OSPFv3 packets on an
ipsec spi number {MD5 | SHA1} IPv6-based interface, where:
[key-encryption-type ] key} null causes an authentication policy configured
for the area to not be inherited on the interface.
ipsec spi number is the Security Policy index (SPI)
value. Range: 256 to 4294967295.
MD5 | SHA1 specifies the authentication type:
Message Digest 5 (MD5) or Secure Hash
Algorithm 1 (SHA-1).
key-encryption-type (optional) specifies if the key
is encrypted. Valid values: 0 (key is not
encrypted) or 7 (key is encrypted).
key specifies the text string used in authentication.
All neighboring OSPFv3 routers must share the same
key to exchange information.
For MD5 authentication, the key must be 32 hex digits
(non-encrypted) or 64 hex digits (encrypted).
For SHA-1 authentication, the key must be 40 hex digits
(non-encrypted) or 80 hex digits (encrypted).
An SPI value must be unique to one IPsec security policy (authentication or encryption) on the router. You
must configure the same authentication policy (same SPI and key) on each OSPFv3 interface in a link.
To remove an IPsec authentication policy from an interface, enter the no ipv6 ospf authentication ipsec
spi number command. To remove null authentication on an interface to allow the interface to inherit the
authentication policy configured for the OSPFv3 area, enter the no ipv6 ospf authentication null
command.
To display the configuration of IPsec authentication policies on the router, enter the show crypto ipsec
policy command. To display the security associations set up for OSPFv3 interfaces in authentication
policies, enter the show crypto ipsec sa ipv6 command.
Prerequisite: Before you enable IPsec encryption on an OSPFv3 interface, you must first enable IPv6
unicast routing globally, configure an IPv6 address and enable OSPFv3 on the interface, and assign it to an
area (see Configuration Task List for OSPFv3 (OSPF for IPv6) on page 726).
Command
Command Syntax Mode Usage
ipv6 ospf encryption {null | ipsec INTERFACE Enable IPsec encryption for OSPFv3 packets on an
spi number esp encryption-algorithm IPv6-based interface, where:
[key-encryption-type] key null causes an encryption policy configured for
authentication-algorithm the area to not be inherited on the interface.
[key-authentication-type] key } ipsec spi number is the Security Policy index
(SPI) value. Range: 256 to 4294967295.
esp encryption-algorithm specifies the
encryption algorithm used with ESP. Valid
values are: 3DES, DES, AES-CBC, and NULL.
For AES-CBC, only the AES-128 and AES-192
ciphers are supported.
key specifies the text string used in the encryption.
All neighboring OSPFv3 routers must share the same
key to decrypt information. Required lengths of a
non-encrypted or encrypted key are: 3DES - 48 or 96
hex digits; DES - 16 or 32 hex digits; AES-CBC - 32 or
64 hex digits for AES-128 and 48 or 96 hex digits for
AES-192.
key-encryption-type (optional) specifies if the
key is encrypted. Valid values: 0 (key is not
encrypted) or 7 (key is encrypted).
authentication-algorithm specifies the encryption
authentication algorithm to use. Valid values
are MD5 or SHA1.
key specifies the text string used in used in
authentication. All neighboring OSPFv3 routers must
share the same key to exchange information. For MD5
authentication, the key must be 32 hex digits
(non-encrypted) or 64 hex digits (encrypted). For
SHA-1 authentication, the key must be 40 hex digits
(non-encrypted) or 80 hex digits (encrypted).
key-authentication-type (optional) specifies if the
authentication key is encrypted. Valid values: 0
or 7.
Note that when you configure encryption with the ipv6 ospf encryption ipsec command, you enable both
IPsec encryption and authentication. However, when you enable authentication on an interface with the
ipv6 ospf authentication ipsec command, you do not enable encryption at the same time.
An SPI value must be unique to one IPsec security policy (authentication or encryption) on the router. You
must configure the same authentication policy (same SPI and key) on each OSPFv3 interface in a link.
number command. To remove null encryption on an interface to allow the interface to inherit the
encryption policy configured for the OSPFv3 area, enter the no ipv6 ospf encryption null command.
To display the configuration of IPsec encryption policies on the router, enter the show crypto ipsec policy
command. To display the security associations set up for OSPFv3 interfaces in encryption policies, enter
the show crypto ipsec sa ipv6 command.
Prerequisite: Before you enable IPsec authentication on an OSPFv3 area, you must first enable OSPFv3
globally on the router (see Configuration Task List for OSPFv3 (OSPF for IPv6) on page 726).
To configure IPsec authentication for an OSPFv3 area, enter the following command in global
configuration mode:
area-id authentication ipsec CONF-IPV6- Enable IPsec authentication for OSPFv3 packets in an
spi number {MD5 | SHA1} ROUTER-OSPF area, where:
[key-encryption-type] key area area-id specifies the area for which OSPFv3
traffic is to be authenticated. For area-id, you can
enter a number or an IPv6 prefix.
spi number is the Security Policy index (SPI)
value. Range: 256 to 4294967295.
MD5 | SHA1 specifies the authentication type:
message digest 5 (MD5) or Secure Hash
Algorithm 1 (SHA-1).
key-encryption-type (optional) specifies if the
key is encrypted. Valid values: 0 (key is not
encrypted) or 7 (key is encrypted).
key specifies the text string used in
authentication. All neighboring OSPFv3 routers must
share the same key to exchange information.
For MD5 authentication, the key must be 32 hex digits
(non-encrypted) or 64 hex digits (encrypted).
For SHA-1 authentication, the key must be 40 hex
digits (non-encrypted) or 80 hex digits (encrypted).
An SPI value must be unique to one IPsec security policy (authentication or encryption) on the router. You
must configure the same authentication policy (same SPI and key) on each interface in an OPSFv3 link.
If you have enabled IPsec encryption in an OSPFv3 area with the area encryption command, you cannot
use the area authentication command in the area at the same time.
The configuration of IPsec authentication on an interface-level takes precedence over an area-level
configuration. If you remove an interface configuration, an area authentication policy that has been
configured is applied to the interface.
To remove an IPsec authentication policy from an OSPFv3 area, enter the no area area-id authentication
ipsec spi number command.
Prerequisite: Before you enable IPsec encryption in an OSPFv3 area, you must first enable OSPFv3
globally on the router (see Configuration Task List for OSPFv3 (OSPF for IPv6) on page 726).
To configure IPsec encryption in an OSPFv3 area, enter the following command in global configuration
mode:
area area-id encryption ipsec CONF-IPV6- Enable IPsec encryption for OSPFv3 packets in an area,
spi number ROUTER-OSPF where:
esp encryption-algorithm area area-id specifies the area for which OSPFv3
[key-encryption-type] key traffic is to be encrypted. For area-id, you can enter
authentication-algorithm a number or an IPv6 prefix.
[key-authentication-type] key spi number is the Security Policy index (SPI) value.
Range: 256 to 4294967295.
esp encryption-algorithm specifies the encryption
algorithm used with ESP. Valid values are: 3DES,
DES, AES-CBC, and NULL. For AES-CBC, only the
AES-128 and AES-192 ciphers are supported.
key specifies the text string used in the encryption.
All neighboring OSPFv3 routers must share the same key
to decrypt information. Required lengths of a
non-encrypted or encrypted key are:
3DES - 48 or 96 hex digits; DES - 16 or 32 hex digits;
AES-CBC - 32 or 64 hex digits for AES-128 and 48 or 96
hex digits for AES-192.
key-encryption-type (optional) specifies if the key
is encrypted. Valid values: 0 (key is not encrypted)
or 7 (key is encrypted).
authentication-algorithm specifies the
authentication algorithm to use for encryption.
Valid values are MD5 or SHA1.
key specifies the text string used in authentication.
All neighboring OSPFv3 routers must share the same key
to exchange information.
For MD5 authentication, the key must be 32 hex digits
(non-encrypted) or 64 hex digits (encrypted). For SHA-1
authentication, the key must be 40 hex digits
(non-encrypted) or 80 hex digits (encrypted).
key-authentication-type (optional) specifies if the
authentication key is encrypted. Valid values: 0 or
7.
An SPI value must be unique to one IPsec security policy (authentication or encryption) on the router. You
must configure the same encryption policy (same SPI and keys) on each interface in an OPSFv3 link.
encryption and authentication. However, when you enable authentication on an area with the area
authentication command, you do not enable encryption at the same time.
If you have enabled IPsec authentication in an OSPFv3 area with the area authentication command, you
cannot use the area encryption command in the area at the same time.
To remove an IPsec encryption policy from an OSPFv3 area, enter the no area area-id encryption ipsec
spi number command.
To display the configuration of IPsec encryption policies on the router, enter the show crypto ipsec policy
command.
To display the configuration of IPsec authentication and encryption policies, enter the following command:
show crypto ipsec policy EXEC Privilege Display the AH and ESP parameters configured in IPsec
[name name] security policies, including the SPI number, key, and
algorithms used.
name displays configuration details about a
specified policy.
Crypto IPSec client security policy data In this authentication policy, the
keys are encrypted.
Policy name : OSPFv3-1-500
Policy refcount : 2
Inbound AH SPI : 500 (0x1F4)
Outbound AH SPI : 500 (0x1F4)
Inbound AH Key : bbdd96e6eb4828e2e27bc3f9ff541e43faa759c9ef5706ba8ed8bb5efe91e97e
Outbound AH Key : bbdd96e6eb4828e2e27bc3f9ff541e43faa759c9ef5706ba8ed8bb5efe91e97e
Transform set : ah-md5-hmac
show crypto ipsec sa ipv6 EXEC Privilege Displays security associations set up for OSPFv3 links in IPsec
[interface interface] authentication and encryption policies on the router.
To display information on the SAs used on a specific interface,
enter interface interface, where interface is one of the
following values:
For a 1-Gigabit Ethernet interface, enter
GigabitEthernet slot/port.
For a Port Channel interface, enter port-channel number. Valid
port-channel numbers (on an E-Series TeraScale):
1 to 255.
For a 10-Gigabit Ethernet interface, enter TenGigabitEthernet
slot/port.
For a VLAN interface, enter vlan vlan-id.
Valid VLAN IDs: 1 to 4094
inbound ah sas
spi : 500 (0x1f4)
transform : ah-md5-hmac
in use settings : {Transport, }
replay detection support : N
STATUS : ACTIVE
outbound ah sas
spi : 500 (0x1f4)
transform : ah-md5-hmac
in use settings : {Transport, }
replay detection support : N
STATUS : ACTIVE
inbound ah sas
outbound ah sas
FTOS has several tools to make troubleshooting easier. Be sure to check the following, as these are typical
issues that interrupt the OSPFv3 process. Note that this is not a comprehensive list, just some examples of
typical troubleshooting checks.
Use the following commands in EXEC Privilege mode to get general route and links status information.
show ipv6 route summary EXEC Privilege View the summary information of the IPv6 routes
show ipv6 ospf database EXEC Privilege View the summary information for the OSPFv3 database
Use the following command in EXEC Privilege mode to view the OSPF configuration for a neighboring
router:
show ipv6 ospf neighbor EXEC Privilege View the configuration of OSPFv3 neighbors.
debug ipv6 ospf [event | EXEC Privilege View debug messages for all OSPFv3 interfaces.
packet] {type slot/port} • event: View OSPF event messages.
• packet: View OSPF packets.
• For a Gigabit Ethernet interface, enter the keyword
GigabitEthernet followed by the slot/port information
(e.g. passive-interface gi 2/1).
• For a port channel, enter the keyword port-channel
followed by a number from 1 to 255 for TeraScale and
ExaScale, 1 to 32 for EtherScale (e.g. passive-interface po
100)
• For a 10-Gigabit Ethernet interface, enter the keyword
TenGigabitEthernet followed by the slot/port
information ( e.g. passive-interface ten 2/3).
• For a VLAN, enter the keyword vlan followed by a
number from 1 to 4094 (e.g. passive-interface vlan 2222).
E-Series ExaScale platforms support 4094 VLANs
with FTOS version 8.2.1.0 and later. Earlier ExaScale
supports 2094 VLANS.
Implementation Information
• E-Series supports a maximum of 511 PIM interfaces and 50K multicast entries including (*,G), (S,G),
and (S,G,rpt) entries. There is no limit on the number of PIM neighbors E-Series can have.
• FTOS reduces the number of control messages sent between multicast routers by bundling Join and
Prune requests in the same message.
• FTOS supports PIM-DM on physical, VLAN, and port-channel interfaces.
Protocol Overview
PIM-DM routers form adjacencies with their neighbors by sending periodic hello messages to the
all-PIM-routers address 224.0.0.13 out of all PIM-DM-enabled interfaces. By default, PIM-DM routers
assume that every subnet has at least one receiver. When a router receives traffic from a particular source
and for a particular group, it creates a (S,G) entry and lists all interfaces directly connected to a PIM-DM
neighbor as an outgoing interface, thus recreating a unique distribution tree called a shortest path tree
(SPT) to the source that includes all subnets.
Source
Group Address: 239.192.0.1
Hello
R1 R2
Adjacency
Receiver
PIM-DM 001
R4
R3
Any router that receives multicast traffic on a port that does not lead back to the source (via the PIM-DM
selected path) also generates a prune message.
In Figure 33-1, R3 receives multicast traffic by two paths. In Figure 33-2, PIM-DM selects only one path
for the reverse path forwarding (RFP) check and generates a prune message so that routers upstream stop
sending traffic for the group. R2 then has no PIM-DM neighbors downstream and so sends a prune
message to R1.
Prune
R1 R2
e
un
Pr
Receiver
PIM-DM 002
R4
R3
R2
Graft
R1 Receiver
Receiver
PIM-DM 003
R4
R3
1. Enable multicast routing using the command ip multicast-routing from CONFIGURATION mode.
2. Enable PIM-DM on an interface. See page 750.
Enable PIM-DM
To enable PIM-DM:
2 Enable PIM-Dense Mode on each interface that will ip pim dense-mode INTERFACE
participate in PIM-DM, as shown in Figure 33-4.
Display which interfaces are enabled with PIM-DM using the command show ip pim interface from EXEC
Privilege mode, as shown in Figure 33-5.
Display PIM neighbors for each interface using the command show ip pim neighbor from EXEC Privilege
mode, as shown in Figure 33-6.
Display the PIM routing table using the command show ip pim tib from EXEC privilege mode, as shown in
Figure 33-7.
754
|
PIM Dense-Mode
34
PIM Sparse-Mode
PIM Sparse-Mode is supported on platforms: ces
PIM-SM is supported on the E-Series ExaScale platform with FTOS 8.1.1.0 and later.
PIM-Sparse Mode (PIM-SM) is a multicast protocol that forwards multicast traffic to a subnet only upon
request using a PIM Join message; this behavior is the opposite of PIM-Dense Mode, which forwards
multicast traffic to all subnets until it receives a request to stop.
Implementation Information
• The Dell Force10 implementation of PIM-SM is based on the IETF Internet Draft
draft-ietf-pim-sm-v2-new-05.
• C-Series supports a maximum of 31 PIM interfaces and 4K multicast entries including (*,G), and
(S,G) entries. There is no limit on the number of PIM neighbors C-Series can have.
• S-Series supports a maximum of 31 PIM interfaces and 2K multicast entries including (*,G), and (S,G)
entries. There is no limit on the number of PIM neighbors S-Series can have.
• E-Series supports a maximum of 511 PIM interfaces and 50K multicast entries including (*,G), (S,G),
and (S,G,rpt) entries. There is no limit on the number of PIM neighbors E-Series can have.
• The SPT-Threshold is zero, which means that the last-hop designated router (DR) joins the shortest
path tree (SPT) to the source upon receiving the first multicast packet.
• FTOS reduces the number of control messages sent between multicast routers by bundling Join and
Prune requests in the same message.
• FTOS supports PIM-SM on physical, VLAN, and port-channel interfaces.
• FTOS supports 2000 IPv6 multicast forwarding entries, with up to 128 PIM-SSM neighbors/interfaces.
• On VLAN interfaces, PIM-SM is supported on C-Series, E-Series, and S-Series platforms.
• IPv6 Multicast is not supported on SONET interfaces.
To distribute the same traffic to multiple receivers, PIM-SM creates a tree extending from a root, called the
Rendezvous Point (RP), down branches that extend to the nodes which have requested the traffic. Nodes
requesting the same traffic belong to the same multicast group.
Initially, a single PIM-SM tree called a shared tree to distribute traffic. It is called shared because all traffic
for the group, regardless of the source, or the location of the source, must pass through the RP. The shared
tree is unidirectional; that is, all multicast traffic flows only from the RP to the receivers. Once a receiver
receives traffic from the RP, PM-SM switches to shortest path trees (SPT) to forward multicast traffic,
which connects the receiver directly to the source. Each multicast group has an RP and a unidirectional
shared tree (group-specific shared tree).
1. Upon receiving an IGMP Join message, the receiver gateway router (last-hop DR) creates a (*,G) entry
in its multicast routing table for the requested group. The interface on which the join message was
received becomes the outgoing interface associated with the (*,G) entry.
2. The last-hop DR sends a PIM Join message to the RP. All routers along the way, including the RP,
create an (*,G) entry in their multicast routing table, and the interface on which the message was
received becomes the outgoing interface associated with the (*,G) entry. This process constructs an
RPT branch to the RP.
3. If a host on the same subnet as another multicast receiver sends an IGMP report for the same multicast
group, the gateway takes no action. If a router between the host and the RP receives a PIM Join
message for which it already has a (*,G) entry, the interface on which the message was received is
added to the outgoing interface list associated with the (*,G) entry, and the message is not (and does
not need to be) forwarded towards the RP.
1. Upon receiving an IGMP Leave message, the gateway removes the interface on which it is received
from the outgoing interface list of the (*,G) entry. If the (*,G) entry has no remaining outgoing
interfaces, multicast traffic for that group is no longer forwarded to that subnet.
2. If the (*,G) entry has no remaining outgoing interfaces, the last-hop DR sends a PIM Prune message to
towards the RP. All routers along the way remove the interface on which the message was received
from the outgoing interface list of the (*,G) entry. If on any router there is at least one outgoing
interface listed for that (*,G) entry, the Prune message is not forwarded.
1. The source gateway router (first-hop DR) receives the multicast packets and creates an (S,G) entry in
its multicast routing table. The first-hop DR encapsulates the initial multicast packets in PIM Register
packets and unicasts them to the RP.
2. The RP decapsulates the PIM Register packets and forwards them if there are any receivers for that
group. The RP sends a PIM Join message towards the source. All routers between the RP and the
source, including the RP, create an (S,G) entry and list the interface on which the message was
received as an outgoing interface, thus recreating a SPT to the source.
3. Once the RP starts receiving multicast traffic via the (S,G) it unicasts a Register-Stop message to the
first-hop DR so that multicast packets are no longer encapsulated in PIM Register packets and unicast.
Upon receiving the first multicast packet from a particular source, the last-hop DR sends a PIM Join
message to the source to create an SPT to it.
4. There are two paths, then, between the receiver and the source, a direct SPT and an RPT. One router
will receive a multicast packet on two interfaces from the same source in this case; this router prunes
the shared tree by sending a PIM Prune message to the RP that tells all routers between the source and
the RP to remove the outgoing interface from the (*,G) entry, and tells the RP to prune its SPT to the
source with a Prune message.
FTOS Behavior: When the router creates an SPT to the source, there are then two paths between the
receiver and the source, the SPT and the RPT. Until the router can prune itself from the RPT, the
receiver receives duplicate multicast packets which may cause disruption. Therefore, the router must
prune itself from the RPT as soon as possible. FTOS optimizes the shared to shortest-path tree
switchover latency by copying and forwarding the first (S,G) packet received on the SPT to the PIM
task immediately upon arrival. The arrival of the (S,G) packet confirms for PIM that the SPT is created,
and that it can prune itself from the shared tree.
Configure PIM-SM
Configuring PIM-SM is a two-step process:
1. Enable IPv4 or IPv6 multicast routing using the command [ip | ipv6] multicast-routing from
CONFIGURATION mode.
2. Select a Rendezvous Point, or let PIM elect an RP. See page 760.
Enable PIM-SM
You must enable PIM-SM on each participating interface:
Display which interfaces are enabled with PIM-SM using the command show [ip | ipv6] pim interface from
EXEC Privilege mode, as shown in Figure 34-1.
Note: You can influence the selection of the Rendezvous Point by enabling PIM-Sparse Mode on a
loopback interface and assigning a low IP address.
Display PIM neighbors for each interface using the command show [ip | ipv6] pim neighbor from EXEC
Privilege mode, as shown in Figure 34-2.
Display the PIM routing table using the command show [ip | ipv6] pim tib from EXEC privilege mode, as
shown in Figure 34-3.
Figure 34-3. Viewing the PIM Multicast Routing Table
FTOS#show ip pim tib
When an expiry time created, deleted, or updated, the changes are applied when the keep alive timer
refreshes.
3 Set the expiry time for a ip pim sparse-mode sg-expiry-timer seconds CONFIGURATION
specific (S,G) entry sg-list access-list-name
(Figure 34-4).
Range 211-86400 seconds
Default: 210
Note: The expiry time configuration is nullified, and the default global expiry time is used if:
• an ACL is specified for an in the ip pim sparse-mode sg-expiry-timer command, but the ACL has not been
created or is a standard ACL.
• if the expiry time is specified for an (S,G) entry in a deny rule.
Display the expiry time configuration using the show running-configuration [acl | pim] command from
EXEC Privilege mode.
Identify an RP by the IP address of a PIM-enabled or loopback interface using the command ip pim
rp-address, as shown in Figure 34-5.
If you have configured a static RP for a group, use the option override with the command [ip | ipv6] pim
rp-address to override bootstrap router updates with your static RP configuration. If you do not use this
option, the RPs advertised in the BSR updates take precedence over any statically configured RPs.
Display the assigned RP for a group using the command show [ip | ipv6] pim rp from EXEC privilege
mode, as shown in Figure 34-6.
Display the assigned RP for a group range (group-to-RP mapping) using the command show ip pim rp
mapping command in EXEC privilege mode
Figure 34-7. Display the Rendezvous Point for a Multicast Group Range
FTOS#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s): 224.0.0.0/4, Static
RP: 165.87.50.5, v2
IPv4 Display the assigned RP for a group. show ip pim rp EXEC Privilege
IPv4 Display the assigned RP for a group range show ip pim rp mapping EXEC Privilege
(group-to-RP mapping).
IPv6 Override bootstrap router RP election results ipv6 pim rp-address CONFIGURATION
with your static RP configuration.
IPv6 Display the assigned RP for a group. show ipv6 pim rp EXEC Privilege
IPv6 Display the assigned RP for a group range show ipv6 pim rp mapping EXEC Privilege
(group-to-RP mapping).
Some routers within the domain are configured to be C-RPs. Other routers are configured to be Bootstrap
Router candidates (C-BSRs); one router is elected the BSR for the domain and is responsible for
forwarding Bootstrap messages (BSM) containing the results of the RP election to the other routers in the
domain.
1. C-BSRs flood their candidacy throughout the domain in a BSM. Each message contains a BSR priority
value, and the C-BSR with the highest priority value becomes the BSR.
2. Each C-RP unicasts periodic Candidate-RP-Advertisements to the BSR. Each message contains an RP
priority value and the group ranges for which it is a C-RP.
3. The BSR determines the most efficient and stable group-to-RP mappings, which is called the RP-Set.
4. The BSR floods the RP-Set throughout the domain periodically in case new C-RPs are announced, or
an RP failure occurs.
IPv6 Make a PIM router a BSR candidate. ipv6 pim bsr-candidate CONFIGURATION
Display Bootstrap Router information. show ipv6 pim bsr-router EXEC Privilege
The DR is elected using hello messages. Each PIM router learns about its neighbors by periodically
sending a hello message out of each PIM-enabled interface. Hello messages contain the IP address of the
interface out of which it is sent and a DR priority value. The router with the greatest priority value is the
DR. If the priority value is the same for two routers, then the router with the greatest IP address is the DR.
By default the DR priority value is 192, so the IP address determines the DR.
IPv4 Change the interval at which a router sends ip pim query-interval seconds INTERFACE
hello messages.
IPv4 Display the current value of DR parameters. show ip pim interface EXEC Privilege
IPv6 Change the interval at which a router sends ipv6 pim query-interval seconds INTERFACE
hello messages.
IPv6 Display the current value of DR parameters. show ipv6 pim interface EXEC Privilege
Create multicast boundaries and domains by filtering inbound and outbound Bootstrap Router (BSR)
messages per interface, using the [ip | ipv6] pim bsr-border command. This command is applied to the
subsequent inbound and outbound updates. Already existing BSR advertisements are removed by timeout.
Remove candidate RP advertisements using the clear [ip | ipv6] pim rp-mapping command.
IPv4 Filter inbound and outbound Bootstrap Router ip pim bsr-border INTERFACE
messages per interface.
Remove candidate RP advertisements. clear ip pim rp-mapping EXEC PRIVILEGE
IPv6 Filter inbound and outbound Bootstrap Router ipv6 pim bsr-border INTERFACE
messages per interface.
Remove candidate RP advertisements. clear ip pim rp-mapping EXEC PRIVILEGE
You can configure PIM to switch over to the SPT when the router receives multicast packets at or beyond a
specified rate.
IPv4 Configure PIM to switch over to the ip pim spt-threshold {value | infinity} CONFIGURATION
SPT when the multicast packet rate is Default: 10 kbps
at or beyond a specified rate. The
keyword infinity directs PIM to never
switch to the SPT.
IPv6 Configure PIM to switch over to the ip pim spt-threshold {value | infinity} CONFIGURATION
SPT when the multicast packet rate is Default: 10 kbps
at or beyond a specified rate. The
keyword infinity directs PIM to never
switch to the SPT.
When a PIM neighbor restarts and the liveliness timer for that neighbor expires, the join/prune states
received from the neighbor expire, and the corresponding interfaces are removed from the outgoing list of
multicast entries. The effect of this is that active multicast sessions are brought down.
FTOS supports graceful restart based on the GenID. A Dell Force10 PIM router announces its graceful
restart capability to its neighbors up front as an option in its hello messages.
If a graceful-restart capable router recognizes that a graceful-restart capable neighbor has restarted, it
preserves the state from the neighbor and continues forwarding multicast traffic while the neighbor
restarts.
• The router holds on to the entries learned from the neighbor for the graceful restart interval. If it does
not receive a hello from the neighbor within this time, it purges all state associated with the neighbor.
• If the neighbor restarts and sends a hello with a new GenID before this interval expires, the router
sends a join message towards the neighbor for the relevant entries.
If a graceful-restart capable router restarts, the router preserves all multicast entries in hardware until it
receives and consolidates joins from its graceful-restart capable neighbors. The router is not taken off the
forwarding path during restart.
Enable PIM-SM graceful restart (non-stop forwarding capability) using the command ip pim
graceful-restart nsf from CONFIGURATION mode. There are two options with this command:
• restart-time is the time required by the Dell Force10 system to restart. The default value is 180 seconds.
• stale-entry-timeis the maximum amount of time that the Dell Force10 system preserves entries from a
restarting neighbor. The default value is 60 seconds.
In helper-only mode, the system preserves the PIM states of a neighboring router while the neighbor
gracefully restarts, but the Dell Force10 system allows itself to be taken off the forwarding path if it
restarts. Enable this mode using the command ip pim graceful-restart helper-only. This mode takes
precedence over any graceful restart configuration.
1. These packets can be soft (slow path) forwarded to receivers at a maximum rate of 70 packets/second.
Incoming packets beyond this rate are dropped.
2. When the system is both the source-DR and the RP, in some cases, packet loss, packet reordering, or
duplicate packets might occur.
entries via the CLI. When you create this mapping, (*,G) entries are programmed in hardware. Packets are
then fast forwarded starting with the first packet, and the potential for these delivery errors is avoided.
Monitoring PIM
The PIM MIB is supported only on platform e
FTOS fully supports the PIM MIB as specified in RFC 5060 with some exceptions.
• The following tables are not supported:
• pimBidirDFElectionTable
• pimAnycastRPSetTable
• The OIDs related to InvalidRegisterMsgs reflect the last received invalid register message. Similarly,
the OIDs related to InvalidJoinPruneMsgs reflect the last received invalid Join or Prune message.
• OIDs which refer to any timer show the time that the timer started; it is 0 otherwise.
When you enable PIM-SM and IGMP snooping at the same time:
• The IGMP report is forwarded on the port that connects to the PIM DR.
• The port that connects to the PIM DR port and ports on which IGMP queries are received are chosen as
IGMP router ports. It is recommended that you configure the both the IGMP querier and the PIM DR
in the same router to avoid unnecessary flooding.
Table 34-1. Egress Ports Used for Multicast Traffic with PIM-SM and IGMP Snooping
For information on how to enable PIM-SM snooping and disable PIM DR flooding, refer to PIM-SM
Snooping on page 767.
PIM-SM Snooping
PIM-SM Snooping is supported on VLAN interfaces on platform: ex
In a Layer 2 VLAN, a switch normally floods multicast traffic to all member ports in the VLAN. PIM-SM
snooping is designed to restrict multicast traffic to only the PIM-SM-enabled routers and IGMP hosts that
should receive the traffic. When PIM-SM snooping is enabled, the switch learns the multicast ports on
which receivers are listening through PIM hello and PIM-SM join/prune messages, and forwards multicast
traffic only to the VLAN ports connected to valid receivers.
PIM-SM snooping functions in a Layer 2 network in which multiple routers are interconnected by a
switch, such as an IXP where Internet service providers (ISPs) exchange Internet traffic between their
networks. By default, the switch floods multicast traffic to all VLAN member ports, regardless of whether
there are multicast receivers downstream that are joined to a multicast group.
When you enable PIM-SM snooping, the switch receives PIM hello and PIM-SM join/prune messages, and
determines which multicast ports are connected to receivers to which multicast packets should be
forwarded. Multicast data is forwarded only to VLAN member ports on which there are valid downstream
receivers.
• Using PIM hello messages, the switch learns about PIM neighbors and builds a database for the VLAN
and port on which the packets are received. The PIM Snooping neighbor database is the same one used
for PIM-SM.
Each neighbor entry stores the physical or port-channel port on which a hello message from a neighbor
is received. PIM hello messages are flooded to all VLAN member ports, except the port on which the
message was received. The PIM designated router on the VLAN is learned from the snooped PIM
hello packets.
• A PIM-SM snooping-enabled switch will proxy the join/prune messages it receives to minimize the
messages it sends upstream. The switch consumes the join/prune messages received from downstream
neighbors and initiates join/prune messages towards upstream neighbors.
All other PIM protocol messages are flooded to VLAN member ports. PIM join/prune messages to
non-existent upstream neighbors are silently dropped.
PIM-SM join/prune messages towards an upstream neighbor are sent only to the port corresponding to
the upstream router in the join message.
PIM (S,G,Rpt) prune and (S,G,Rpt) join messages are snooped and managed according to the PIM-SM
RFC.
• The switch creates and maintains a tree topology with the state of PIM neighbors in the tree
information base (TIB). Each PIM snooping-enabled VLAN has its own neighbor tree in the TIB.
The PIM (*,G) TIB state maintains the list of multiple upstream neighbors for joins initiated by down-
stream routers towards the rendezvous point (RP). The PIM (*,G,) TIB adds all other upstream neigh-
bor ports to its Outgoing Interface list, except the port to which the join was forwarded, to trigger
assert conditions.
The PIM (S,G) TIB state maintains the list of multiple upstream neighbors for joins initiated by down-
stream routers towards the source.
• If the PIM designated-router (DR) flood is not disabled (default setting; see Disable PIM
Designated-Router Flooding on page 772):
• Multicast traffic is transmitted on the egress port towards the PIM DR if the port is not the
incoming interface.
• Multicast traffic for an unknown group is sent on the port towards the PIM DR. When DR flooding
is disabled, multicast traffic for an unknown group is dropped.
• Multicast traffic for known multicast group addresses, such as Local Network Control Block and
Internetwork Control Block (as defined in RFC 5771), is flooded to all VLAN member ports.
Figure 34-8 shows an example with PIM-SM snooping enabled. When Router A sends a join message to
Router B, the switches forward the join message only to Router B without flooding the message to other
connected routers, such as Routers C and D.
Layer 2 Network
with PIM Snooping
Router D
Router B
RP Source
Data Router C
Layer 2 Network
with PIM Snooping
G Traffic
Router D
Router A
You can enable PIM-SM snooping globally on a switch or on individual VLANs. PIM-SM snooping is not
enabled by default and does not require an IP address, PIM-DM, or PIM-SM.
PIM-SM snooping and PIM multicast routing are mutually exclusive: PIM-SM snooping cannot be
enabled on a switch/router if PIM-SM or PIM-DM is enabled.
If enabled at the global level, PIM-SM snooping is automatically enabled on all VLANs on the switch
unless the no ip pim snooping command has been entered on a VLAN interface.
If enabled at the VLAN level, PIM-SM snooping requires that you also enter the no shutdown command to
enable the interface.
To enable PIM-SM snooping on all VLAN interfaces on a switch, enter the following command.
When designated-router flooding is disabled, PIM-SM snooping only forwards multicast traffic, which
belongs to a multicast group for which the switch receives a join request, on the port connected towards the
designated router.
To disable designated-router flooding for PIM-SM snooping, enter the no ip pim snooping dr-flood
command:
To display information about PIM-SM snooping operation, enter one of the following show commands:
Display information about PIM neighbors show ip pim snooping neighbor [vlan EXEC Privilege
discovered by PIM-SM snooping. vlan-id]
Figure 34-10
Display information about PIM group members show ip pim snooping tib [vlan vlan-id] EXEC Privilege
and states stored in the tree information base [group-address [source-address]]
(TIB) that was discovered by PIM-SM snooping. Figure 34-11
Display information about the VLAN interfaces show ip pim snooping interface [vlan EXEC Privilege
on which PIM-SM snooping is configured. vlan-id]
Figure 34-12
Display information about the current operation show ip pim summary EXEC Privilege
of PIM-SM snooping globally on the switch or Figure 34-13 VLAN INTERFACE
on a specified VLAN.
Display information on the multicast routes show ip mroute snooping [vlan vlan-id] EXEC Privilege
discovered on VLANs configured for PIM-SM [group-address [source-address]]
snooping. Figure 34-14
Display information about the current show running-config pim EXEC Privilege
configuration of PIM-SM snooping on the Figure 34-15
switch.
To clear tree information learned through PIM-SM snooping from the PIM TIB, enter the clear ip pim
snooping tib command.
To clear information on the multicast routes learned through PIM-SM snooping from the IPv4 multicast
snooping table, enter the clear ip mroute snooping command.
The following examples show the PIM-SM snooping output displayed for these show commands.
Active Modes :
PIM-SNOOPING
Interface summary:
1 active PIM interface
0 passive PIM interfaces
3 active PIM neighbors
TIB summary:
1/1 (*,G) entries in PIM-TIB/MFC
1/1 (S,G) entries in PIM-TIB/MFC
0/0 (S,G,Rpt) entries in PIM-TIB/MFC
0 PIM nexthops
0 RPs
0 sources
0 Register states
Message summary:
2582/2583 Joins sent/received
5/0 Prunes sent/received
0/0 Candidate-RP advertisements sent/received
0/0 BSR messages sent/received
0/0 State-Refresh messages sent/received
0/0 MSDP updates sent/received
0/0 Null Register messages sent/received
0/0 Register-stop messages sent/received
Memory usage:
TIB : 3768 bytes
Nexthop cache : 0 bytes
Interface table : 992 bytes
Neighbor table : 528 bytes
RP Mapping : 0 bytes
PIM-Source-Specific Mode (PIM-SSM) is a multicast protocol that forwards multicast traffic from a single
source to a subnet. In the other versions of Protocol Independent Multicast (PIM), a receiver subscribes to
a group only. The receiver receives traffic not just from the source in which it is interested but from all
sources sending to that group. PIM-SSM requires that receivers specify the sources in which they are
interested using IGMPv3 include messages to avoid receiving unwanted traffic.
PIM-SSM is more efficient than PIM-SM because it immediately creates shortest path trees (SPT) to the
source rather than first using shared trees. PIM-SM requires a shared tree rooted at the RP because
IGMPv2 receivers do not know about the source sending multicast data. Multicast traffic passes from the
source to the receiver through the RP, until the receiver learns the source address, at which point it switches
to the SPT. PIM-SSM uses IGMPv3. Since receivers subscribe to a source and group, the RP and shared
tree is unnecessary, so only SPTs are used. On Dell Force10 systems, it is possible to use PIM-SM with
IGMPv3 to achieve the same result, but PIM-SSM eliminates the unnecessary protocol overhead.
PIM-SSM also solves the multicast address allocation problem. Applications should use unique multicast
addresses because if multiple applications use the same address, receivers receive unwanted traffic.
However, global multicast address space is limited. Currently GLOP/EGLOP is used to statically assign
Internet-routable multicast addresses, but each autonomous system number yields only 255 multicast
addresses. For short-term applications, an address could be leased, but no global dynamic multicast
address allocation scheme has been accepted yet. PIM-SSM eliminates the need for unique multicast
addresses because routing decisions for (S1, G1) are independent from (S2, G1). As a result, subnets do not
receive unwanted traffic when multiple applications use the same address.
In Figure 35-1, Receiver 1 is an IGMPv2 host. The packets for group 239.0.0.2 travel to it first via the RP,
then by the SPT. Receiver 2 is an IGMPv3 host. The packets for group 239.0.0.1 travel only via the STP.
778
|
Figure 35-1.
ip address 10.11.3.1/24
Outgoing interface list: interface Vlan 400 untagged GigabitEthernet 1/1
Vlan 300 Forward/Sparse 00:02:12/Never ip pim sparse-mode no shutdown
ip address 10.11.4.1/24
(10.11.5.2, 239.0.0.2), uptime 00:00:36, expires 00:03:14, flags: CT untagged GigabitEthernet 1/2
Incoming interface: GigabitEthernet 1/31, RPF neighbor 10.11.13.2 ip igmp version 3
Receiver 1
Outgoing interface list: no shutdown 10.11.3.2
Vlan 300 Forward/Sparse 00:02:12/Never
ip igmp snooping enable
Group: 239.0.0.2
Receiver 2
10.11.4.2
Group: 239.0.0.1
Source: 10.11.5.2
Implementation Information
• The Dell Force10 implementation of PIM-SSM is based on RFC 3569.
• C-Series supports a maximum of 31 PIM interfaces and 4K multicast entries including (*,G), and
(S,G) entries. There is no limit on the number of PIM neighbors C-Series can have.
• S-Series supports a maximum of 31 PIM interfaces and 2K multicast entries including (*,G), and (S,G)
entries. There is no limit on the number of PIM neighbors S-Series can have.
• E-Series supports a maximum of 511 PIM interfaces and 50K multicast entries including (*,G), (S,G),
and (S,G,rpt) entries. There is no limit on the number of PIM neighbors E-Series can have.
• FTOS reduces the number of control messages sent between multicast routers by bundling Join and
Prune requests in the same message.
Configure PIM-SM
Configuring PIM-SSM is a one-step process:
To enable PIM-SSM:
1 Create an ACL that uses permit rules to specify what range of [ip | ipv6] access-list CONFIGURATION
addresses should use SSM. You must at least include one standard name
rule, permit 232.0.0.0/8, which is the default range for
PIM-SSM.
2 Enter the command ip pim ssm-range and specify the ACL [ip | ipv6] pim CONFIGURATION
you created. ssm-range acl-name
Display address ranges in the PIM-SSM range using the command show [ip | ipv6] pim ssm-range from
EXEC Privilege mode.
Translate (*,G) entries to (S,G) entries using the command ip igmp ssm-map acl source from
CONFIGURATION mode. In a standard access list, specify the groups or the group ranges that you want
to map to a source. Then, specify the multicast source.
• When a SSM map is in place and FTOS cannot find any matching access lists for a group, it continues
to create (*,G) entries because there is an implicit deny for unspecified groups in the ACL.
• When you remove the mapping configuration, FTOS removes the corresponding (S,G) states that it
created and reestablishes the original (*,G) states.
• You may enter multiple ssm-map commands for different access lists. You may also enter multiple
ssm-map commands for the same access list, as long as they use different source addresses.
Display the source to which a group is mapped using the command show ip igmp ssm-map [group], as
shown in Figure 35-4 on page 783. If use the group option, the command displays the group-to-source
mapping even if the group is not currently in the IGMP group table. If you do not specify the group option,
then the display is a list of groups currently in the IGMP group table that have a group-to-source mapping.
Display the list of sources mapped to a group currently in the IGMP group table using the command show
ip igmp groups group detail, as shown in Figure 35-4 on page 783.
782
|
R2(conf )#do show ip pim tib
R3(conf )#do show ip pim tib
PIM Multicast Routing Table
Figure 35-3.
no shutdown 10.11.3.2
ip igmp snooping enable
Group: 239.0.0.2
Source: 10.11.5.2
Receiver 2
10.11.4.2
Group: 239.0.0.1
Figure 35-4. Configuring PIM-SSM with IGMPv2
R1(conf)#do show run pim
!
ip pim rp-address 10.11.12.2 group-address 224.0.0.0/4
ip pim ssm-range ssm
R1(conf)#do show run acl
!
ip access-list standard map
seq 5 permit host 239.0.0.2
!
ip access-list standard ssm
seq 5 permit host 239.0.0.2
R1(conf)#ip igmp ssm-map map 10.11.5.2
R1(conf)#do show ip igmp groups
Total Number of Groups: 2
IGMP Connected Group Membership
Group Address Interface Mode Uptime Expires Last Reporter
239.0.0.2 Vlan 300 IGMPv2-Compat 00:00:07 Never 10.11.3.2
Member Ports: Gi 1/1
239.0.0.1 Vlan 400 INCLUDE 00:00:10 Never 10.11.4.2
R1(conf)#do show ip igmp ssm-map
IGMP Connected Group Membership
Group Address Interface Mode Uptime Expires Last Reporter
239.0.0.2 Vlan 300 IGMPv2-Compat 00:00:36 Never 10.11.3.2
Member Ports: Gi 1/1
R1(conf)#do show ip igmp ssm-map 239.0.0.2
SSM Map Information
Group : 239.0.0.2
Source(s) : 10.11.5.2
R1(conf)#do show ip igmp groups detail
784
|
PIM Source-Specific Mode
36
Power over Ethernet
Power over Ethernet (PoE) is supported only on platforms: cs
This chapter contains the following major sections:
• Configuring Power over Ethernet on page 786
• Power Additional PoE Ports on the S-Series on page 794
• Deploying VOIP on page 795
FTOS supports Power over Ethernet (PoE), as described by IEEE 802.3af . IEEE 802.3af specifies that a
maximum of 15.4 Watts can be transmitted to Ethernet devices over the signal pairs of an unshielded
twisted pair (UTP) cable. PoE is useful in networks with IP phones and wireless access points because
separate power supplies for powered devices (PD) are not needed.
Table 36-2 describes the classes of powered devices defined by IEEE 802.3af:
Classification
Power Range Current
Class (Watts) (mA)
0 0.44 to 12.95 < 5.0
1 0.44 to 3.84 10.5
2 3.84 to 6.49 18.5
3 6.49 to 12.95 28
4 Reserved 40
Note: FTOS treats Class 0, Class 3, and Class 4 powered devices the same. Class 4 is meant for
IEEE802.3at compliant devices which require >12.95 Watts. Currently FTOS treats Class 4 devices as
Class 3.
FTOS supports PoE on all copper ports on the C-Series and on the S25V and S50V models of the S-Series.
The C-Series and S-Series transmit power to connected IEEE 802.3af-compliant powered devices through
ports that have been configured to supply PoE. Those platforms also support the protocols LLDP and
LLDP-MED, which help optimize power distribution to PoE devices. See Chapter 46, Link Layer
Discovery Protocol, on page 861.
PoE can be enabled, and some PSUs are reserved for PoE redundancy, as described in Table 36-2.
Note: The C-Series can provide PoE only through its AC power supplies.
Table 36-2. PoE Ports per Power Supply Unit in the C-Series*
FTOS Behavior: Table 36-2 provides the maximum number of PoE ports per PSU, based on the
assumption that each port deliver 15.4W. In many cases, the PD requires <15.4W. Typical IP Phones
require only 3-10 Watts. So, if the ports are configured optimally, more PDs can be powered with fewer
PSUs.
On the C-Series, though each PSU used for PoE (units 4-7 on the C300, and 3-4 on the C150) provides
1200 Watts of power, each actually makes available 1478.40 Watts for PoE. This is possible because each
unit, once installed, borrows 278.40 Watts from the system redundancy power supply. If a power supply
used for PoE is removed, PoE ports are shut down so that the system redundancy PSU retains is capability.
Note: The S25V and S50V models contain AC power supplies in order to support PoE. You can also add
the external Dell Force10 470W Redundant Power Supply to power more PoE devices. For details, see
Power Additional PoE Ports on the S-Series on page 794 and see the power budget command in the
Power Over Ethernet (PoE) chapter of the FTOS Command Reference for the S-Series.
• The power inline auto command allows the port to determine the amount of power that a connected
Class 1–4 powered device requires, and supply it. See Table 36-1 on page 785.
• The power inline static command without the qualifier guarantees 15.4W to the powered device.
• You can limit the maximum amount of power (in milliwatts) available to a powered device with the
command power inline auto max_milliwatts or with power inline static max_milliwatts
• Disable PoE on a port using the no power inline command.
Ports configured with power inline auto have a lower priority for access to power than those configured
with power inline static. As a second layer of priority setting, use the [no] power inline priority command.
Use the power inline static max_milliwatts command to avoid allocating more power than necessary to a
port because allocated power is made unavailable to other ports regardless of whether it is consumed.
Typical IP phones use 3-10 Watts.
1/1
0/1 1/0
privilege mode.
Figure 36-2. PoE Allocation Displayed with show power inline Command
Table 36-3 describes the fields that the show power inline command displays:
View the total power consumption of the chassis using the show power detail command from EXEC
privilege mode.
Figure 36-3. PoE Consumed, Allocated, and Available with show power detail Command
FTOS(conf-if-range-gi-0/1-48)#do show power detail
Unit Total Logic Inline Inline Inline Inline
Power Power Power Power Power Power
Available Consumed Available Allocated Consumed Remaining
(Watts) (Watts) (Watts) (Watts) (Watts) (Watts)
-------------------------------------------------------------------------------
0 470.00 150 320.00 308.00 190.00 12.00
FTOS uses the following four parameters, in order, for defining the power priority for a port:
FTOS maintains a sorted list of PoE ports based these four parameters. Static ports have a higher weight
than auto mode ports, so all static ports always stay on top of all auto ports regardless of the other 3
parameters. Within the set of static ports, FTOS attempts to order them based on the second parameter
power-inline priority, the default of which is “Low”. If FTOS finds multiple ports with the same
PD, which like power-inline priority could be “Critical,” “High,” or “Low”. After this, if FTOS still finds a
tie, priority is based on the fourth parameter which is the ports position in the chassis; there cannot be a tie
based on this parameter.
FTOS always uses this sorted list of ports for allocation. When an additional PSU is added, additional ports
are powered based on this list, and PSU is removed, this same list is used to remove power from the lowest
priority ports.
power-inline mode
FTOS allows ports to be configured in one of two modes: auto and static.
auto: Ports configured for auto mode manage the power allocation by themselves. There is no prior
reservation of power made on these ports. When no PD is connected on this port, the power allocated is
zero. Once a PD is connected, FTOS detects its PoE class dynamically and the maximum power for its
class is allocated to the port. The PD then boots using this allocated power. After bootup, if the PD is
LLDP-MED capable, it might send in Extended Power via MDI TLV to the system. In this case, the Dell
Force10 switch revises the power allocation to the value that the PD requests via LLDP-MED. The
advertised Power Requirement from the PD could be less than or greater than the currently allocated value.
Ports configured for auto mode with the max_milliwatts option allocate power the same way, but the
allocation never exceeds the specified maximum. If max_milliwatts is greater than the PoE class maximum
the system allocates only the class maximum. Note that if a PD has class maximum that is greater than
max_milliwatts, the system allocates no power, and the PD does not power up.
static: Ports configured in static mode reserve a fixed power allocation whether a device is connected or
not. By default 15.4W is allocated, but this is user-configurable with the max_milliwatts option. No dynamic
PoE class detection is performed on static ports, and Extended Power via MDI TLVs have no effect.
The PD sends three pieces of information in the LLDP-MED Extended Power-via-MDI TLV:
1. Power Requirement: FTOS honors this and uses it for power allocation.
2. Power Priority—Critical, High, or Low: FTOS honors this information and uses it for power priority
calculation.
3. External Power Source: FTOS does not use this information.
1. When you configure a port with power inline auto without the max_milliwatts power limit option, power
is only allocated after you connect a device to the port.
• When you connect a device, the maximum power for the device class is allocated if there is
sufficient power in the budget. See Table 36-1 on page 785.
• If there is not enough power in the budget, the configuration is maintained and the port waits for
power to become available.
• If the device advertises its power requirement through LLDP-MED, then FTOS allocates the
required amount and returns the remaining amount to the budget.
Note: LLDP-MED TLVs are only honored if the port is configured with power inline auto (with or without
the max_milliwatts option).
2. When you configure a port with power inline auto with the power limit option max_milliwatts, power is
only allocated after you connect a device to the port.
• If the maximum power for the device class is less than the power limit you specified, FTOS
allocates the required amount and returns the remaining amount to the budget.
• If there is not enough power in the budget, the configuration is maintained and the port waits for
power to become available.
• If the maximum power for the device class is more than than the power limit you specified, FTOS
does not allocate any power.
Note: When a port is configured with power inline auto (with or without the max_milliwatts option) and the
PoE device is disconnected, the allocated power is returned to the power budget.
3. When you configure a port with power inline static without the power limit option (max_milliwatts),
FTOS allocates 15.4W (subject to availability and priority) to the port whether or not a device is
connected.
4. When you configure a port with power inline static with the power limit option (max_milliwatts), FTOS
allocates the specified number of Watts.
• If there is not enough power in the budget, the configuration is maintained and port waits for
power to become available.
• If the maximum power for the device class is more than than the power limit you specified, FTOS
does not allocate any power.
The power budget is the amount of power available from the installed PSUs minus the power required to
operate the chassis. Use the show power inline (Figure 36-2 on page 788) and show power detail
(Figure 36-3 on page 788) commands to help you determine if power is available for additional PoE ports
(1478.40 Watts are supplied per C-Series PSU; max of 790W on S-Series with load-sharing external DC
PSU).
Enabling PoE on more ports than is supported by the power budget produces one of these results:
• If the newly PoE-enabled port has a lower priority, then the command is accepted, but power is not
allocated to the port. In this case, the following message is displayed.
%Warning: Insufficient power to enable. POE oper-status set to OFF for port <linecard/
portnumber>
• If the newly PoE-enabled port has a higher priority, then the CLI is accepted, and power is terminated
on the lowest priority port in the chassis. If another power supply is added to the system at a later time,
both ports receive power.
• If all of the lower priority ports combined cannot meet the power requirements of the newly enabled
port, then the CLI is accepted, but power on the lower priority ports is not terminated, and no power is
supplied to the port.
The second result in this scenario is true even if a powered device is not connected to the port. Power can
be allocated to a port, thus subtracting it from the power budget and making it unavailable to other ports,
but that power does not have to be consumed.
Note: For S-Series, where Table 36-5 refers to “line cards with the lowest slot number”, substitute
“S-Series stack members with the lowest unit ID”.)
For C-Series, use the show power supply command to display PSU status (Figure 36-4).
For S-Series, see the Power over Ethernet (PoE) chapter in the FTOS Command Reference for the S-Series
for an example of the output of the show power inline output and its field descriptions.
Figure 36-4. show power supply Command Example
R1#show power supply
Power Model
Supply Number Type Status
------------------------------------------------
PS0 -- -- Absent
PS1 CC-C300-PWR-AC AC Active
PS2 CC-C300-PWR-AC AC Fail
PS3 CC-C300-PWR-AC AC Remote Off
PS4 -- -- Absent
PS5 -- -- Absent
PS6 -- -- Absent
PS7 -- -- Absent
If power must be terminated for some ports, the order in which ports are affected is based on priority. Ports
with the lowest priority are terminated first (see Manage Power Priorities on page 792).
0
Term
1 i nate
PoE
2
When a failed PSU is replaced and there is sufficient power for PoE, power is automatically re-supplied for
previously configured PoE ports, and power is supplied first to ports with the highest priority.
0
Re-s
upp
1 ly
2
Message 28 appears if you attempt to use the power budget command when an external power supply is
not connected.
% Error: External power supply not found or incompatible external power supply.
Figure 36-7 shows a basic configuration for a deployment in which the end workstation plugs into an IP
phone for its Ethernet connection.
On both the C-Series or S-Series, if you know traffic originating from the phone is tagged with the DSCP
value of 46 (EF), you might make the associated queue a strict priority queue, as shown in Figure 36-10;
on the C-Series and S-Series, FTOS maps DSCP 46 to queue 2 (see Table 41-5 on page 865 in the QoS
chapter.)
On the C-Series, if you know traffic originating from the phone is tagged with a dot1p value of 5, you
might make the associated queue a strict priority queue, as shown in Figure 36-11; on the C-Series, FTOS
maps dot1p priority 5 to queue 2.
Avoid congestion and give precedence to voice and signaling traffic by classifying traffic based on subnet
and using strict priority and bandwidth weights on egress, as outlined in the steps below.
Figure 36-12 depicts the topology and shows the configuration for a C-Series. The steps are the same on an
S-Series. Figure 36-13 on page 799 is a screenshot showing some of the steps and the resulting
running-config.
Figure 36-12. Classifying VOIP Traffic and Applying QoS Policies for an Office VOIP Deployment
Force10#sh run int gi 6/10
!
interface GigabitEthernet 6/10 Force10#sh run int gi 6/2
description "IP Phone X” !
no ip address interface GigabitEthernet 6/2
portmode hybrid description "Uplink to E1200"
switchport no ip address
service-policy input phone-pc switchport
power inline auto service-policy output BW
no shutdown no shutdown
1 Create three standard or extended access-lists, one each for ip access-list CONFIGURATION
voice, voice signaling, and PC data, and place each in its
own match-any class-map. class-map match-any CLASS-MAP
3 Create two input QoS policies, one each for PC data and qos-policy-out CONFIGURATION
voice signaling. Assign a different bandwidth weight to each
policy. bandwidth-weight QOS-POLICY-IN
4 Create an output policy map containing both QoS policies, policy-map-out CONFIGURATION
and assign them to different service queues.
service-queue POLICY-MAP-OUT
6 Apply the input policy map you created in Step 2 to the service-policy INTERFACE
interface connected to the phone, and apply the output
policy map you created in Step 4 to the interface connected
your desired next-hop router.
Figure 36-13 on page 799 is a screenshot showing some of the steps, above, and the resulting
running-config.
800
|
Power over Ethernet
37
Policy-based Routing
Policy-based Routing is supported on platforms: ces
PBR is supported on the E-Series ExaScale platform with FTOS 8.1.1.0 and later.
PBR is supported on the E-Series TeraScale, C-Series, and S-Series platforms in FTOS 8.4.2.0 and later.
• Overview
• Implementing Policy-based Routing with FTOS on page 803
• Configuration Task List for Policy-based Routing on page 804
• Create a Redirect List on page 804
• Create a Rule for a Redirect-list on page 805
• Apply a Redirect-list to an Interface using a Redirect-group on page 808
• PBR Exceptions (Permit) on page 807
• Sample Configuration on page 810
Overview
Policy-based Routing (PBR) enables you to make routing decisions based on policies applied to a specific
interface. When a router receives a packet it normally decides where to forward it based on the destination
address in the packet, which is used to look up an entry in a routing table. However, in some cases, there
may be a need to forward the packet based on other criteria: size, source, protocol type, destination, etc.
For example, a network administrator might want to forward a packet that uses TCP across a
different next-hop than packets using ICMP.
Rules for PBR can also be a combination of things: when the packet comes from this source and wants
to go to that destination then route it to this next-hop or onto that specific interface. This permits
routing over different links or towards different networks even while the destination is the same but
depending on where the packet originates.
Customer
Finance Engineering Marketing Sales Operations
Support
45
ps
10
ps
Mb
Mb
1.5
ps
Mb
Mb
ps
Mb
45
Mb
ps
10
1.5
ps
To enable a PBR, you create a Redirect List. Redirect lists are defined by rules, or routing policies. The
following parameters can be defined in the routing policies or rules:
Once a redirect-list is applied to an interface, all traffic passing through it is subjected to the rules defined
in the redirect-list.
1. Next-hop addresses are verified. If the specified next hop is reachable, then the traffic is forwarded to
the specified next-hop.
FTOS#show ip redirect-list
IP redirect-list rcl0:
Defined as:
seq 5 permit ip 200.200.200.200 200.200.200.200 199.199.199.199 199.199.199.199
seq 10 redirect 1.1.1.2 tcp 234.224.234.234 255.234.234.234 222.222.222.222/24 eq 40 ack, Next-hop reachable
(via Gi 8/1), ARP resolved
Non-Contiguous Bitmasks
Applied interfaces:
Contiguous Bitmasks
Gi 8/0
Hot-Lock PBR
Ingress and egress Hot Lock PBR allow you to add or delete new rules into an existing policy (already
written into CAM) without disruption to traffic flow. Existing entries in CAM are adjusted to
accommodate the new entries. Hot Lock PBR is enabled by default.
ip redirect-list redirect-list-name CONFIGURATION Create a redirect list by entering the list name.
Format: 16 characters
FTOS(conf)#ip redirect-list ?
WORD Redirect-list name (max 16 chars)
FTOS(conf)#ip redirect-list xyz
Command
Command Syntax Mode Purpose
seq {number} redirect CONF- Configure a rule for the redirect list.
{ip-address | sonet} REDIRECT- number is the number in sequence to initiate this
{ip-protocol-number | protocol-type [bit]} LIST rule
{source mask | any | host ip-address} ip-address is the Forwarding router’s address
{destination mask | any | host ip-address} FORMAT: A.B.C.D
sonet is a sonet interface
FORMAT: sonet slot/port
ip-protocol-number or protocol-type is the type of
protocol to be redirected
FORMAT: 0-255 for IP protocol number, or
enter protocol type
source ip-address or any or host ip-address is the
Source’s IP address
FORMAT: A.B.C.D/NN, or ANY or HOST IP
address
destination ip-address or any or host ip-address
is the Destination’s IP address
FORMAT: A.B.C.D/NN, or ANY or HOST IP
address
Figure 37-4 shows a step-by-step example of how to create a rule for a redirect list by configuring:
FTOS(conf-redirect-list)#redirect ?
A.B.C.D Forwarding router's address
IP address of
sonet SONET interface
forwarding router
FTOS(conf-redirect-list)#redirect 3.3.3.3 ?
<0-255> An IP protocol number
icmp Internet Control Message Protocol IP protocol
ip Any Internet Protocol number
tcp Transmission Control Protocol
udp User Datagram Protocol
FTOS(conf-redirect-list)#redirect 3.3.3.3 ip ? Source address and
A.B.C.D Source address mask
any Any source host
host A single source host
FTOS(conf-redirect-list)#redirect 3.3.3.3 ip 222.1.1.1 ?
Destination address
Mask Network mask in slash format (/xx) and mask
FTOS(conf-redirect-list)#redirect 3.3.3.3 ip 222.1.1.1 /32 ?
A.B.C.D Destination address
any Any destination host
host A single destination host
Multiple rules can be applied to a single redirect-list. The rules are applied in ascending order, starting with
the rule that has the lowest sequence number in a redirect-list. Figure 37-5 displays the correct method for
applying multiple rules to one list.
Note: Starting in release 8.4.1.2, FTOS supports the use of multiple recursive routes with the same
source-address and destination-address combination in a redirect policy on an E-Series ExaScale router.
A recursive route is a route for which the immediate next-hop address is learned dynamically through a
routing protocol and acquired through a route lookup in the routing table.You can configure multiple
recursive routes in a redirect list by entering multiple seq redirect statements with the same source and
destination address and specify a different next-hop IP address. In this way, the recursive routes are used
as different forwarding routes for dynamic failover. If the primary path goes down and the recursive route
is removed from the routing table, the seq redirect statement is ignored and the next statement in the list
with a different route is used.
Use the command permit to create an exception to a redirect list. Exceptions are used when a forwarding
decision should be based on the routing table rather than a routing policy.
FTOS assigns the first available sequence number to a rule configured without a sequence number and
inserts the rule into the PBR CAM region next to the existing entries. Since the order of rules is important,
ensure that you configure any necessary sequence numbers.
In Figure 37-6, the permit statement is never applied because the redirect list covers all source and
destination IP addresses.
ip redirect-list rcl0
seq 5 redirect 2.2.2.2 ip any any
seq 10 permit ip host 3.3.3.3 any
To ensure that the permit statement or PBR exception is effective, use a lower sequence number, as shown
in Figure 37-7.
ip redirect-list rcl0
seq 10 permit ip host 3.3.3.3 any
seq 15 redirect 2.2.2.2 ip any any
IP redirect lists are supported on physical interfaces as well as VLAN and port-channel interfaces.
Note: When you apply a redirect-list on a port-channel on the E-Series, when traffic is redirected to the
next hop and the destination port-channel is shut down, the traffic is dropped. However, on the C-Series,
the traffic redirected to the destination port-channel is sometimes switched.
Use the following command in INTERFACE mode to apply a redirect list to an interface. Multiple
redirect-lists can be applied to a redirect-group. It is also possible to create two or more redirect-groups on
one interface for backup purposes.
Delete the redirect list from this interface with the [no] ip redirect-group
command.
In this example, the list “xyz” is applied to the GigabitEthernet 4/0 interface.
show ip redirect-list EXEC View the redirect list configuration and the associated
redirect-list-name interfaces.
show cam pbr EXEC View the redirect list entries programmed in the CAM.
show cam-usage
List the redirect list configuration using the show ip redirect-list redirect-list-name command.
The non-contiguous mask is displayed in dotted format (x.x.x.x). The contiguous mask is displayed in /x
format. Some sample outputs are shown in Figure 37-10, Figure 37-11, and Figure 37-12.
IP redirect-list xyz:
Defined as:
seq 5 redirect 3.3.3.3 ip host 222.1.1.1 host 77.1.1.1
Use the show ip redirect-list (without the list name) to display all the redirect-lists configured on the
device.
FTOS#show ip redirect-list
IP redirect-list rcl0:
Defined as:
seq 5 permit ip 200.200.200.200 200.200.200.200 199.199.199.199 199.199.199.199
seq 10 redirect 1.1.1.2 tcp 234.224.234.234 255.234.234.234 222.222.222.222/24 eq 40 ack, Next-hop reachable
(via Gi 8/1), ARP resolved Non-Contiguous Bitmasks
Applied interfaces:
Gi 8/0 Contiguous Bitmasks
Note: If, the redirect-list is applied to an interface, the output of show ip redirect-list
redirect-list-name command displays reachability and ARP status for the specified next-hop.
TCP Flag: Bit 5 - URG, Bit 4 - ACK, Bit 3 - PSH, Bit 2 - RST, Bit 1 - SYN, Bit 0 - FIN
Cam Port VlanID Proto Tcp Src Dst SrcIp DstIp Next-hop
Index Flag Port Port MAC
-----------------------------------------------------------------------------------------------------------------------
----------
06080 0 N/A IP 0x0 0 0 200.200.200.200 200.200.200.200 199.199.199.199 199.199.199.199 N/A
06081 0 N/A TCP 0x10 0 40 234.234.234.234 Non-Contiguous Bitmasks
255.234.234.234 222.222.222.222/24 00:00:00:00:0
Contiguous Bitmasks
Sample Configuration
The following configuration is an example for setting up a PBR. These are not comprehensive directions.
They are intended to give you a some guidance with typical configurations.
You can copy and paste from these examples to your CLI. Be sure you make the necessary changes to
support your own IP Addresses, Interfaces, Names, etc.
Figure 37-13 is a graphic illustration of the configuration shown in Figure 37-14. The Redirect-List GOLD
defined in this example, creates the following rules:
192.168.1.0 /24
10.0.0.0 /16 192.168.2.0 /24 10.1.0.0 /16
GigE 2/11
EDGE_ROUTER
1.5 Mbps
45 Mbps
10 Mbps
10.44.44.13
10.22.22.100
Internet
EDGE_ROUTER#
IP redirect-list GOLD:
Defined as:
seq 5 redirect 10.99.99.254 ip 192.168.1.0/24 any, Next-hop reachable (via
Gi 3/23), ARP resolved
seq 10 redirect 10.99.99.254 ip 192.168.2.0/24 any, Next-hop reachable (via
Gi 3/23), ARP resolved
seq 15 permit ip any any
Applied interfaces:
Gi 2/11
EDGE_ROUTER#
Port Monitoring is a feature that copies all incoming or outgoing packets on one port and forwards
(mirrors) them to another port. The source port is the monitored port (MD) and the destination port is the
monitoring port (MG). Port Monitoring functionality is different between platforms, but the behavior is the
same, with highlighted exceptions.
displayed if you try to assign a monitored port to more than one monitoring port.
FTOS(conf)#mon ses 1
FTOS(conf-mon-sess-1)#$gig 0/0 destination gig 0/60 direction both
FTOS(conf-mon-sess-1)#do show mon ses
SessionID Source Destination Direction Mode Type
--------- ------ ----------- --------- ---- ----
1 Gi 0/0 Gi 0/60 both interface Port-based
FTOS(conf-mon-sess-1)#mon ses 2
FTOS(conf-mon-sess-2)#source gig 0/0 destination gig 0/61 direction both
% Error: MD port is already being monitored.
• The C-Series and S-Series may only have four destination ports per port-pipe. There is no limitation on
the total number of monitoring sessions.
Table 38-1 lists the maximum number of monitoring sessions per system. For the C-Series and S-Series,
the total number of sessions is derived by consuming a unique destination port in each session, in each
port-pipe.
Note: On the C-Series and S-Series, there is no limit to the number of monitoring sessions per system,
provided that there are only 4 destination ports per port-pipe. If each monitoring session has a unique
destination port, then the maximum number of session is 4 per port-pipe.
• FTOS supports one destination (MG) port per monitoring session. The same destination port (MG) can
be used in another monitoring session.
• One destination (MG) port can monitor up to 28 source (MD) ports.
• A port cannot be defined as both a source (MD) and a destination (MG) port (Message 1).
Message 1 Cannot define source (MD) and destination (MG) on same port
On the E-Series TeraScale, FTOS supports a single source-destination statement in a monitor session
(Message 2). E-Series TeraScale supports only one source and one destination port per port-pipe
(Message 3). Therefore, the E-Series TeraScale supports as many monitoring sessions as there are
port-pipes in the system.
Message 3 One Source/Destination Port per Port-pipe Error Message on E-Series TeraScale
% Error: Some port from this port pipe is already configured as MD.
% Error: Some port from this port pipe is already configured as MG.
Monitor Session 0 MD MG
Monitor Session 1 MD MG
Monitor Session 2 MD
Monitor Session 3 MD
Port Monitoring 002
E-Series ExaScale
FTOS on E-Series ExaScale supports a single destination (MG) port monitoring multiple multiple source
(MD) ports in one monitor session. One monitor session can have only one destination (MG) port. The
same destination (MG) port can be uses with multiple monitoring sessions.
There is no restriction on the number of source (MD) or destination (MG) ports on the chassis because
there is no port-pipe restriction on the E-Series ExaScale system.
There is no restriction to the number of monitoring sessions supported on the E-Series ExaScale system.
The C-Series and S-Series support multiple source-destination statements in a monitor session, but there
may only be one destination port in a monitoring session (Message 4).
Message 4 One Destination Port in a Monitoring Session Error Message on C-Series and S-Series
The number of source ports FTOS allows within a port-pipe is equal to the number of physical ports in the
port-pipe (n). However, n number of ports may only have four different destination ports (Message 5).
In Figure 38-2, ports 0/13, 0/14, 0/15, and 0/16 all belong to the same port-pipe. They are pointing to four
different destinations (0/1, 0/2, 0/3, and 0/37). Now it is not possible for another source port from the same
port-pipe (for example, 0/17) to point to another new destination (for example, 0/4). If you attempt to
configure another destination, Message 5 appears. However, you can configure another monitoring session
that uses one of previously used destination ports, as shown in Figure 38-3.
In Figure 38-4, 0/25 and 0/26 belong to Port-pipe 1. This port-pipe again has the same restriction of only
four destination ports, new or used.
A source port may only be monitored by one destination port (Message 6), but a destination port may
monitor more than one source port. Given these parameters, Figure 38-1 illustrates conceptually the
possible port monitoring configurations on the C-Series and S-Series.
Message 5 One Destination Port in a Monitoring Session Error Message on C-Series and S-Series
Monitor Session 0 MD MG
MD
Monitor Session 1 MD
MD MG
MD MG
Monitor Session 2 MD MG
FTOS Behavior: On the C-Series and S-Series, all monitored frames are tagged if the configured
monitoring direction is transmit (TX), regardless of whether the monitored port (MD) is a Layer 2 or
Layer 3 port. If the MD port is a Layer 2 port, the frames are tagged with the VLAN ID of the VLAN to
which the MD belongs. If the MD port is a Layer 3 port, the frames are tagged with VLAN ID 4095. If
the MD port is in a Layer 3 VLAN, the frames are tagged with the respective Layer 3 VLAN ID. For
example, in the configuration source gig 6/0 destination gig 6/1 direction tx, if the MD port
gigabitethernet 6/0 is an untagged member of any VLAN, all monitored frames that the MG port
gigabitethernet 6/1 receives are tagged with the VLAN ID of the MD port. Similarly, if BPDUs are
transmitted, the MG port receives them tagged with the VLAN ID 4095. This behavior might result in a
difference between the number of egress packets on the MD port and monitored packets on the MG
port.
FTOS Behavior: The C-Series and S-Series continue to mirror outgoing traffic even after an MD
participating in Spanning Tree Protocol transitions from the forwarding to blocking.
1 show interface EXEC Privilege Verify that the intended monitoring port has no
configuration other than no shutdown, as shown in
Figure 38-6.
2 monitor session CONFIGURATION Create a monitoring session using the command monitor
session from CONFIGURATION mode, as shown in
Figure 38-6.
3 source MONITOR SESSION Specify the source and destination port and direction of
traffic, as shown in Figure 38-6.
Display monitor sessions using the command show monitor session from EXEC Privilege mode, as shown
in Figure 38-6.
In Figure 38-7, the host and server are exchanging traffic which passes through interface gigabitethernet 1/
1. Interface gigabitethernet 1/1 is the monitored port and gigabitethernet 1/2 is the monitoring port, which
is configured to only monitor traffic received on gigabitethernet 1/1 (host-originated traffic).
Host Traffic
1/1 1/3
Server Traffic
1/2
Host Server
Force10(conf-if-gi-1/2)#show config
!
interface GigabitEthernet 1/2
no ip address
no shutdown Sniffer
Force10(conf )#monitor session 0
Force10(conf-mon-sess-0)#source gig 1/1 destination gig 1/2 direction rx
Flow-based Monitoring
Flow-based Monitoring is supported only on platform e
Flow-based monitoring conserves bandwidth by monitoring only specified traffic instead all traffic on the
interface. This feature is particularly useful when looking for malicious traffic. It is available for Layer 2
and Layer 3 ingress and egress traffic. You may specify traffic using standard or extended access-lists.
1 flow-based enable MONITOR SESSION Enable flow-based monitoring for a monitoring session.
3 ip access-group INTERFACE Apply the ACL to the monitored port. See Chapter 8, IP
access-list Access Control Lists (ACL), Prefix Lists, and Route-maps.
View an access-list that you applied to an interface using the command show ip accounting access-list from
EXEC Privilege mode, as shown in Figure 38-8.
FTOS(conf)#monitor session 0
FTOS(conf-mon-sess-0)#flow-based enable
FTOS(conf)#ip access-list ext testflow
FTOS(config-ext-nacl)#seq 5 permit icmp any any count bytes monitor
FTOS(config-ext-nacl)#seq 10 permit ip 102.1.1.0/24 any count bytes monitor
FTOS(config-ext-nacl)#seq 15 deny udp any any count bytes
FTOS(config-ext-nacl)#seq 20 deny tcp any any count bytes
FTOS(config-ext-nacl)#exit
FTOS(conf)#interface gig 1/1
FTOS(conf-if-gi-1/1)#ip access-group testflow in
FTOS(conf-if-gi-1/1)#show config
!
interface GigabitEthernet 1/1
ip address 10.11.1.254/24
ip access-group testflow in
shutdown
FTOS(conf-if-gi-1/1)#exit
FTOS(conf)#do show ip accounting access-list testflow
!
Extended Ingress IP access list testflow on GigabitEthernet 1/1
Total cam count 4
seq 5 permit icmp any any monitor count bytes (0 packets 0 bytes)
seq 10 permit ip 102.1.1.0/24 any monitor count bytes (0 packets 0 bytes)
seq 15 deny udp any any count bytes (0 packets 0 bytes)
seq 20 deny tcp any any count bytes (0 packets 0 bytes)
FTOS(conf)#do show monitor session 0
SessionID Source Destination Direction Mode Type
--------- ------ ----------- --------- ---- ----
0 Gi 1/1 Gi 1/2 rx interface Flow-based
In a remote-port mirroring session, monitored traffic is tagged with a VLAN ID and switched on a
user-defined, non-routable L2 VLAN. The VLAN is reserved in the network to carry only mirrored traffic,
which is forwarded on all egress ports of the VLAN. Each intermediate switch that participates in the
transport of mirrored traffic must be configured with the reserved L2 VLAN. Remote port mirroring
supports mirroring sessions in which multiple source and destination ports are distributed across multiple
switches.
The VLAN traffic on monitored links from the access network is tagged and assigned to a dedicated L2
VLAN. Monitored links are configured in two source sessions shown with orange and green circles. Each
source session uses a separate reserved VLAN to transmit mirrored packets (mirrored source-session
traffic is shown with an orange or green circle with a blue border).
The reserved VLANs transport the mirrored traffic in sessions (blue pipes) to the destination analyzers in
the local network. Two destination sessions are shown: one for the reserved VLAN that transports
orange-circle traffic; one for the reserved VLAN that transports green-circle traffic.
Reserved VLAN
Monitored VLANs
Configuration Notes
When you configure remote port mirroring, the following conditions apply:
- You add a port to a VLAN, which has already been configured in a source session, and the
newly added port exceeds the 128-port limit.
- You configure a range of VLANs in a source session and the combined number of ports in
the VLANs exceeds 128.
• You can use ACLs on a source port. In a flow-based source session, packets sent from the RPM are
not monitored.
• Rate-limiting tagged-VLAN egress traffic on a source port is supported.
• In a destination session used for remote port mirroring:
• Maximum number of destination sessions supported on a switch: 64
Maximum number ports supported in a destination session: 64
• You can configure any port as a destination port. A port-channel interface is not supported as a
destination port.
• You can configure additional destination ports in an active session.
• You can tunnel the mirrored traffic from multiple remote-port source sessions to the same
destination port.
• You can configure a destination port to send only tagged or untagged traffic to the analyzer. By
default, the port sends untagged packets so that the reserved VLAN ID is removed and the original
monitored packet is analyzed.
• By default, ingress traffic on a destination port is dropped.
Restrictions
When you configure remote port mirroring, the following restrictions apply:
• You cannot configure the same source port to be used in multiple source sessions.
• You cannot configure a source port channel or source VLAN in a source session if the port channel or
VLAN has a member port that is configured as a destination port in a remote-port mirroring session.
• A destination port for remote port mirroring cannot be used as a source port, including the session in
which the port functions as the destination port.
• A destination port cannot be used in any spanning tree instance.
• The reserved VLAN used to transport mirrored traffic must be a L2 VLAN. L3 VLANs are not
supported.
Configuration Procedure
1 interface vlan vlan-id CONFIGURATION Create a VLAN to transport mirrored traffic in remote
port mirroring.
Valid vlan-id values are 1 to 4094. The default VLAN
ID is not supported.
3 tagged interface VLAN INTERFACE Configure a tagged port to carry mirrored traffic in the
reserved VLAN.
Repeat this command to configure additional tagged
ports for the VLAN.
4 Repeat Steps 1 to 3 on source, intermediate, and destination switches on which mirrored traffic in the reserved L2
VLAN is transmitted (see Figure 38-11 and Figure 38-12).
To remove the remote-port mirroring assignment from a VLAN, enter the no mode
remote-port-mirroring command.
1 monitor session session-id CONFIGURATION Configure a new remote-port mirroring session or add
or delete source ports from an existing session, and
enter Monitor Session configuration mode.
Up to 4 source sessions are supported on a switch.
Refer to Configuration Notes for information on
datapath limitations.
session-id: Session number used to identify the
mirroring session. Range: 0 - 65535.
5 Repeat Steps 1 to 4 on other source switches to configure additional source ports for this session.
To delete one or more source ports or source VLANs from a mirroring session, enter the no source
destination remote-vlan vlan-id command, specifying the ports to be deleted in the command syntax.
To change the reserved L2 VLAN used in a source session, you can delete the session (no monitor
session command) or remove the current VLAN by entering the complete no source command. Then
re-enter the complete source command as described above to configure a new reserved VLAN for the
session.
1 monitor session session-id CONFIGURATION Configure the destination session for remote port
mirroring and enter Monitor Session configuration
mode.
2 source remote-vlan vlan-id MONITOR SESSION Associate the reserved L2 VLAN used to transport
destination {single-interface mirrored traffic with this destination session and
| range {interface-list | configure the destination ports to which an analyzer
interface-range | is a connected.
mixed-interface-list}} single-interface is one of the following values:
gigabitethernet slot/port
tengigabitethernet slot/port
range interface-list specifies multiple interfaces
separated by a comma and space: single-interface,
single-interface, single-interface...
range interface-range specifies one of the
following interface ranges:
gigabitethernet slot/first_port-last_port
tengigabitethernet slot/first_port-last_port
A space is required before and after the dash (-).
range mixed-interface-list specifies single
interfaces and interface ranges in any order:
single-interface, interface-range, single-interface...
3 tagged destination MONITOR SESSION (Optional) Configure destination ports so that the
{single-interface | range reserved VLAN tag is added to the monitored
interface-range} traffic sent to an analyzer.
Default: Destination ports send untagged packets so
that the reserved VLAN ID is removed and the
original monitored packet is analyzed.
single-interface is one of the following values:
gigabitethernet slot/port
tengigabitethernet slot/port
range interface-range specifies one of the
following interface ranges:
gigabitethernet slot/first_port-last_port
tengigabitethernet slot/first_port-last_port
4 Repeat Steps 1 to 3 on other destination switches to configure additional destination ports for this session.
To delete one or more destination ports from a destination session, enter the no source remote-vlan
vlan-id destination command.
To change the reserved L2 VLAN used in the destination session, you must first remove all destination
ports. Then delete the current VLAN by entering the no monitor session session-id source remote-vlan
vlan-id command and re-enter the monitor session session-id source remote-vlan command to
configure the new VLAN ID.
To reconfigure destination ports as untagged ports, enter the untagged destination command.
To display the current configuration of remote port mirroring for a specified session, enter the show config
command in MONITOR SESSION configuration mode.
FTOS(conf-mon-sess-50)# show config
!
monitor session 50
source GigabitEthernet 1/2 destination remote-vlan 50 direction both mode Remote-Port-Mirroring
source vlan 4, vlan 11 - 12, destination remote-vlan 50 direction both mode Remote-Port-Mirroring
no disable
To display the currently configured source and destination sessions for remote port mirroring on a switch,
enter the show monitor session command in EXEC Privilege mode.
FTOS# show monitor session
To display the current configuration of the reserved VLAN, enter the show vlan command.
FTOS(conf-if-gi-1/2)# show vlan
Figure 38-10 shows a sample configuration of remote port mirroring on a source switch. Note that in the
show monitor session output of a source session, the source is a source port/port-channel (for example, Gi
2/2) and the destination is the reserved VLAN (for example, remote-vlan 22).
Figure 38-11 shows a sample configuration of remote port mirroring on an intermediate (transport) switch.
the show monitor session output of a destination session, the source is the reserved VLAN (for example,
remote-vlan 22) and the destination is the destination port (for example, Gi 4/73) to which an analyzer is
attached.
Note: While conceptually, the primary VLAN is divided into secondary VLANs, when configuring PVLAN
in FTOS, you explicitly define the secondary VLANs, and then make them members of the primary VLAN.
The VLAN that is divided into subdomains is called the Primary VLAN; the subdomains are called
secondary VLANs. There are two types of secondary VLANs:
• Community VLAN — a group of ports in which ports may communicate with each other and
promiscuous ports, but not to ports outside of their own secondary VLAN. A service provider can
provide Layer 2 security for customers and use the IP addresses more efficiently, by using a separate
community VLAN per customer, while at the same time using the same IP subnet address space for all
community and isolated VLANs mapped to the same primary VLAN.
• Isolated VLAN — a group of ports in which ports may communicate with promiscuous ports only;
they may not communicate with each other, or to other ports outside of their own secondary VLAN.
An enterprise, such as a hotel, can use an isolated VLAN in a private VLAN to provide Internet access
for its guests, while stopping direct access between the guest ports.
Figure 39-1. PVLAN: Primary and Secondary VLANs
Primary VLAN
Isolated
VLAN
Community
VLAN
Network
• Host Ports—these ports are the ones that Private VLAN aims to isolate. They are connected to
end-stations.
• Promiscuous Ports—these ports are members of the primary VLAN, and function as gateways to the
primary and secondary VLANs.
• Trunk Ports—trunk ports carry tagged traffic between switches. They have promiscuous and trunk
ports as members.
Figure 39-2. PVLAN: Primary and Secondary VLANs
Primary VLAN
Host Port
Isolated
VLAN
Community
VLAN
Server
Promiscuous
Host Port
Port
Trunk Port
Network
Assign a PVLAN port role to a switchport. switchport mode private-vlan {host | INTERFACE
promiscuous | trunk}
Community VLANs:
• Can only have host ports.
• Host ports can communicate with each other and to promiscuous ports.
Isolated VLANs:
• Can only have host ports.
• Host ports cannot communicate with each other; they can only communicate with promiscuous ports.
1 Access the INTERFACE VLAN mode for the interface vlan vlan-id CONFIGURATION
VLAN that you want to make a community
VLAN.
2 Designate the VLAN as a community or isolated private-vlan mode {community | INTERFACE VLAN
VLAN. isolated}
3 Add one or more host ports to the VLAN. {tagged | untagged} interface INTERFACE VLAN
A primary VLAN is a port-based VLAN that is specifically designated as a private VLAN. Doing so
enables the VLAN to be divided into secondary VLANs.
3 Map secondary VLANs to the private-vlan mapping secondary-vlan vlan-list INTERFACE VLAN
primary VLAN.
4 Add promiscuous ports as tagged or {tagged | untagged} interface INTERFACE VLAN
untagged interfaces. Add trunk ports
as tagged.
Display type and status of PVLAN interfaces. show interfaces private-vlan [interface EXEC Privilege
interface]
Display PVLANs and/or interfaces that are part show vlan private-vlan [community | EXEC Privilege
of a PVLAN. interface | isolated | primary | primary_vlan
| interface interface]
Display primary-secondary VLAN mapping. show vlan private-vlan mapping EXEC Privilege
Protocol Overview
Per-VLAN Spanning Tree Plus (PVST+) is a variation of Spanning Tree—developed by a third party—
that allows you to configure a separate Spanning Tree instance for each VLAN. For more information on
Spanning Tree, see Chapter 52, Spanning Tree Protocol.
2/12 3/12
Forwarding
g
kin
oc
Bl
1/22
X
XX
1/32
R1
Implementation Information
• The FTOS implementation of PVST+ is based on IEEE Standard 802.1d.
• The FTOS implementation of PVST+ uses IEEE 802.1s costs as the default costs (Table 40-2). Other
implementations use IEEE 802.1d costs as the default costs if you are using Dell Force10 systems in a
multi-vendor network, verify that the costs are values you intended.
• You must allocate at least the default minimum amount of Layer 2 ACL CAM space when employing
PVST+ on the E-Series. See Configure Ingress Layer 2 ACL Sub-partitions on page 295.
• On the C-Series and S-Series, you can enable PVST+ on 254 VLANs.
Disable PVST+
Display your PVST+ configuration by entering the command show config from PROTOCOL PVST
context, as shown in fig.
2/32 Blocking
3/22
X
2/12 3/12
Forwarding
1/22 X
X
1/32
R1
STI 1 root
vlan 100 bridge-priority 4096
The bridge with the bridge value for bridge priority is elected root. Since all bridges use the default priority
(until configured otherwise), lowest MAC address is used as a tie-breaker. Assign bridges a low
non-default value for bridge priority to increase the likelihood that it will be selected as the STP root.
Display the PVST+ forwarding topology by entering the command show spanning-tree pvst [vlan vlan-id]
from EXEC Privilege mode, as shown in Figure 40-4.
The root bridge sets the values for forward-delay, and hello-time and overwrites the values set on other
PVST+ bridges.
• Forward-delay is the amount of time an interface waits in the Listening State and the Learning State
before it transitions to the Forwarding State.
• Hello-time is the time interval in which the bridge sends Bridge Protocol Data Units (BPDUs).
• Max-age is the length of time the bridge maintains configuration information before it refreshes that
information by recomputing the PVST+ topology.
To change PVST+ parameters, use the following commands on the root bridge:
The values for global PVST+ parameters are given in the output of the command show spanning-tree pvst,
as shown in Figure 40-4.
Note: The FTOS implementation of PVST+ uses IEEE 802.1s costs as the default costs. Other
implementations use IEEE 802.1d costs as the default costs if you are using Dell Force10 systems in a
multi-vendor network, verify that the costs are values you intended.
Change the port cost of an interface. spanning-tree pvst vlan cost INTERFACE
Range: 0 to 200000
Default: see Table 40-2.
Change the port priority of an interface. spanning-tree pvst vlan priority INTERFACE
Range: 0 to 240, in increments of 16
Default: 128
The values for interface PVST+ parameters are given in the output of the command show spanning-tree
pvst,as shown in Figure 40-4.
Configure an EdgePort
The EdgePort feature enables interfaces to begin forwarding traffic approximately 30 seconds sooner. In
this mode an interface forwards frames by default until it receives a BPDU that indicates that it should
behave otherwise; it does not go through the Learning and Listening states. The bpduguard
shutdown-on-violation option causes the interface hardware to be shutdown when it receives a BPDU.
When only bpduguard is implemented, although the interface is placed in an Error Disabled state when
receiving the BPDU, the physical interface remains up and spanning-tree will drop packets in the hardware
after a BPDU violation. BPDUs are dropped in the software after receiving the BPDU violation. This
feature is the same as PortFast mode in Spanning Tree.
Caution: Configure EdgePort only on links connecting to an end station. EdgePort can cause loops if it is enabled
on an interface connected to a network.
The EdgePort status of each interface is given in the output of the command show spanning-tree pvst, as
shown in Figure 40-4.
FTOS Behavior: The following conditions apply to a port enabled with root guard:
• Root guard is supported on any PVST-enabled port or port-channel interface except when used as a
stacking port.
• Root guard is supported on a port in any Spanning Tree mode:
• Spanning Tree Protocol (STP)
• Rapid Spanning Tree Protocol (RSTP)
• Multiple Spanning Tree Protocol (MSTP)
• Per-VLAN Spanning Tree Plus (PVST+)
• When enabled on a port, root guard applies to all VLANs configured on the port.
• Root guard and loop guard cannot be enabled at the same time on a PVST+ port. For example, if you
configure loop guard on a port on which root guard is already configured, the following error message is
displayed:
% Error: RootGuard is configured. Cannot configure LoopGuard.
To enable a root guard on a PVST-enabled port or port-channel interface, enter the spanning-tree pvst
rootguard command. Refer to STP Root Guard on page 1060 for more information on how to use the root
guard feature.
Enable root guard on a port or port-channel interface. spanning-tree pvst rootguard INTERFACE
INTERFACE
PORT-CHANNEL
To disable PVST+ root guard on a port or port-channel interface, enter the no spanning-tree pvst rootguard
command in an interface configuration mode.
To verify the PVST+ root guard configuration on a port or port-channel interface, enter the show
spanning-tree pvst [vlan vlan-id] guard command in global configuration mode.
The Loop Guard feature provides protection against Layer 2 forwarding loops (STP loops) caused by a
hardware failure, such as a cable failure or an interface fault. When a cable or interface fails, a participating
STP link may become unidirectional (STP requires links to be bidirectional) and an STP port does not
receive BPDUs. When an STP blocking port does not receive BPDUs, it transitions to a forwarding state.
This condition can create a loop in the network.
FTOS Behavior: The following conditions apply to a port enabled with loop guard:
• Loop guard is supported on any PVST-enabled port or port-channel interface.
• Loop guard is supported on a port or port-channel in any Spanning Tree mode:
• Spanning Tree Protocol (STP)
• Rapid Spanning Tree Protocol (RSTP)
• Multiple Spanning Tree Protocol (MSTP)
• Per-VLAN Spanning Tree Plus (PVST+)
• Root guard and loop guard cannot be enabled at the same time on a PVST+ port. For example, if you
configure root guard on a port on which loop guard is already configured, the following error message is
displayed:
% Error: LoopGuard is configured. Cannot configure RootGuard.
• Enabling Portfast BPDU guard and loop guard at the same time on a port results in a port that remains in a
blocking state and prevents traffic from flowing through it. For example, when Portfast BPDU guard and
loop guard are both configured:
- If a BPDU is received from a remote device, BPDU guard places the port in an err-disabled
blocking state and no traffic is forwarded on the port.
- If no BPDU is received from a remote device, loop guard places the port in a loop-inconsistent
blocking state and no traffic is forwarded on the port.
• When used in a PVST+ network, loop guard is performed per-port or per-port channel at a VLAN level. If
no BPDUs are received on a VLAN interface, the port or port-channel transitions to a loop-inconsistent
(blocking) state only for this VLAN.
To enable a loop guard on a PVST-enabled port or port-channel interface, enter the spanning-tree mstp
loopguard command. Refer to STP Loop Guard on page 1064 for more information on how to use the loop
guard feature.
Enable loop guard on an PVST-enabled port or port-channel spanning-tree pvst loopguard INTERFACE
interface.
INTERFACE
PORT-CHANNEL
To disable PVST+ loop guard on a port or port-channel interface, enter the no spanning-tree pvst loopguard
command in an INTERFACE configuration mode.
To verify the PVST+ loop guard configuration on a port or port-channel interface, enter the show
spanning-tree pvst [vlan vlan-id] command in global configuration mode.
Dell Force10 systems do not expect PVST+ BPDU (tagged or untagged) on an untagged port. If this
happens, FTOS places the port in error-disable state. This behavior might result in the network not
converging. To prevent FTOS from executing this action, use the command no spanning-tree pvst
err-disable cause invalid-pvst-bpdu. After you configure this command, if the port receives a PVST+
BPDU, the BPDU is dropped, and the port remains operational.
If PVST+ is enabled on the Dell Force10 switch in this network, P1 and P2 receive BPDUs from each
other. Ordinarily, the Bridge ID in the frame matches the Root ID, a loop is detected, and the rules of
convergence require that P2 move to blocking state because it has the lowest port ID.
To keep both ports in forwarding state, use Extend System ID. Extend System ID augments the Bridge ID
with a VLAN ID to differentiate BPDUs on each VLAN so that PVST+ does not detect a loop, and both
ports can remain in forwarding state.
VLAN unaware
Force10 System Hub
P1
untagged in VLAN 10
X P2
untagged in VLAN 20
Augment the Bridge ID with the VLAN ID. extend system-id PROTOCOL PVST
FTOS(conf-pvst)#do show spanning-tree pvst vlan 5 brief
VLAN 5
Executing IEEE compatible Spanning Tree Protocol
Root ID Priority 32773, Address 0001.e832.73f7
Root Bridge hello time 2, max age 20, forward delay 15
Bridge ID Priority 32773 (priority 32768 sys-id-ext 5), Address 0001.e832.73f7
We are the root of Vlan 5
Configured hello time 2, max age 20, forward delay 15
...
The E-Series has eight unicast queues per port and 128 multicast queues per-port pipe. Traffic is queued on
ingress and egress. By default, on ingress, all data traffic is mapped to Queue 0, and all control traffic is
mapped to Queue 7. On egress control traffic is mapped across all eight queues. All queues are serviced
using the Weighted Fair Queuing scheduling algorithm. You can only manage queuing prioritization on
egress.
The C-Series traffic has eight queues per port. Four queues are for data traffic and four are for control
traffic. All queues are serviced using the Deficit Round Robin scheduling algorithm. You can only manage
queuing prioritization on egress.
Table 41-1. FTOS Support for Port-based, Policy-based, and Multicast QoS Features
Switching
Buffers Egress
Traffic
Rate Limiting Class-based Packet
Shaping
Queues Processing
Egress Congestion
Congestion Management Avoidance
(WFQ Scheduling) (WRED)
Implementation Information
Dell Force10 QoS implementation complies with IEEE 802.1p User Priority Bits for QoS Indication. It
also implements these Internet Engineering Task Force (IETF) documents:
• RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 Headers
• RFC 2475, An Architecture for Differentiated Services
• RFC 2597, Assured Forwarding PHB Group
• RFC 2598, An Expedited Forwarding PHB
You cannot configure port-based and policy-based QoS on the same interface, and SONET line cards
support only port-based QoS.
FTOS Behavior: The C-Series and S-Series distribute eight dot1p priorities across four data queues.
This is different from the E-Series, which distributes eight dot1p priorities across eight queues
(Table 41-2).
On the C-Series and S-Series you can configure service-class dynamic dot1p from CONFIGURATION
mode, which applies the configuration to all interfaces. A CONFIGURATION mode service-class dynamic
dot1p entry supersedes any INTERFACE entries. See Mapping dot1p values to service queues on
page 867.
Note: You cannot configure service-policy input and service-class dynamic dot1p on the same interface.
When priority-tagged frames ingress an untagged port or hybrid port the frames are classified to the default
VLAN of the port, and to a queue according to their dot1p priority if service-class dynamic dotp or trust
dot1p are configured. When priority-tagged frames ingress a tagged port, the frames are dropped because
for a tagged port the default VLAN is 0.
FTOS Behavior: Hybrid ports can receive untagged, tagged, and priority tagged frames. The rate
metering calculation might be inaccurate for untagged ports, since an internal assumption is made that
all frames are treated as tagged. Internally the ASIC adds a 4-bytes tag to received untagged frames.
Though these 4-bytes are not part of the untagged frame received on the wire, they are included in the
rate metering calculation resulting in metering inaccuracy.
Rate policing ingress traffic on an interface using the command rate police from INTERACE mode, as
shown in Figure 41-4. If the interface is a member of a VLAN, you may specify the VLAN for which
ingress packets are policed.
FTOS Behavior:
On the C-Series and S-Series, rate shaping is effectively rate limiting because of its smaller buffer size.
On the E-Series:
— 802.1Q-priority tagged frames are sometimes not rate-limited according to the configured rate-limit
value. Only hybrid ports reliably apply the configured rate limit to priority-tagged frames
— Rate-limiting may not be applied according to the configured rate-limit value on an interface on
which the dot.1p priority is changed on incoming traffic using the dot1p-priority command
Rate limit egress traffic on an interface using the command rate limit from INTERFACE mode, as shown
in Figure 41-6. If the interface is a member of a VLAN, you may specify the VLAN for which egress
packets are rate limited.
Display how your rate limiting configuration affects traffic using the keyword rate limit with the command
show interfaces, as shown in Figure 41-7.
Figure 41-7. Displaying How Your Rate Limiting Configuration Affects Traffic
FTOS#show interfaces gigabitEthernet 1/1 rate limit
Rate limit 300 (50) peak 800 (50)
Traffic Monitor 0: normal 300 (50) peak 800 (50)
Out of profile yellow 23386960 red 320605113
Traffic Monitor 1: normal NA peak NA
Out of profile yellow 0 red 0
Traffic Monitor 2: normal NA peak NA
Out of profile yellow 0 red 0
Traffic Monitor 3: normal NA peak NA
Out of profile yellow 0 red 0
Traffic Monitor 4: normal NA peak NA
Out of profile yellow 0 red 0
Traffic Monitor 5: normal NA peak NA
Out of profile yellow 0 red 0
Traffic Monitor 6: normal NA peak NA
Out of profile yellow 0 red 0
Traffic Monitor 7: normal NA peak NA
Out of profile yellow 0 red 0
Total: yellow 23386960 red 320605113
Rate shaping buffers, rather than drops, traffic exceeding the specified rate until the buffer is exhausted. If
any stream exceeds the configured bandwidth on a continuous basis, it can consume all of the buffer space
that is allocated to the port.
Apply rate shaping to outgoing traffic on a port using the command rate shape from INTERFACE mode, as
shown in Figure 41-8.
FTOS Behavior: On ExaScale, when rate shaping is configured on an interface, the “Dropped
Packets” counter in the outputs of show queue statistics egress and show qos statistics wred-profile
does not increment. This is because, while TeraScale systems maintain QoS counters per interface,
ExaScale systems maintain QoS counters per port-pipe. The matched packets counter, however,
increments as expected.
FTOS Behavior: On Exascale 10G line cards, the granularity for rate shaping is 10Mbps so traffic is
not always rate shaped according to the configured value. Specifically, if the configured value is below
5Mbps or a multiple of 5: for values less than 5Mbps, 0Mbps is received at remote end, and for values
greater than or equal to 5Mbps, the remote end receives the next highest increment of 10; 15Mbps, for
example, is rate shaped to 20Mbps.
Interface
0 7 0 7
Classify Traffic
Class maps differentiate traffic so that you can apply separate quality of service policies to each class. For
both class maps, Layer 2 and Layer 3, FTOS matches packets against match criteria in the order that you
configure them.
A Layer 3 class map differentiates ingress packets based on DSCP value or IP precedence, and
characteristics defined in an IP ACL. You may specify more than one DSCP and IP precedence value, but
only one value must match to trigger a positive match for the class map.
1. Create a match-any class map using the command class-map match-any or a match-all class map using
the command class-map match-all from CONFIGURATION mode, as shown in Figure 41-10.
match criteria using the command match ip, as shown in Figure 41-10. Match-any class maps allow up
to five ACLs, and match-all class-maps allow only one ACL.
3. After you specify your match criteria, link the class-map to a queue using the command service-queue
from POLICY MAP mode, as shown in Figure 41-10.
Figure 41-10. Using the Order Keyword in ACLs
FTOS(conf)#ip access-list standard acl1
FTOS(config-std-nacl)#permit 20.0.0.0/8
FTOS(config-std-nacl)#exit
FTOS(conf)#ip access-list standard acl2
FTOS(config-std-nacl)#permit 20.1.1.0/24 order 0
FTOS(config-std-nacl)#exit
FTOS(conf)#class-map match-all cmap1
FTOS(conf-class-map)#match ip access-group acl1
FTOS(conf-class-map)#exit
FTOS(conf)#class-map match-all cmap2
FTOS(conf-class-map)#match ip access-group acl2
FTOS(conf-class-map)#exit
FTOS(conf)#policy-map-input pmap
FTOS(conf-policy-map-in)#service-queue 7 class-map cmap1
FTOS(conf-policy-map-in)#service-queue 4 class-map cmap2
FTOS(conf-policy-map-in)#exit
FTOS(conf)#interface gig 1/0
FTOS(conf-if-gi-1/0)#service-policy input pmap
All class maps are Layer 3 by default; you can create a Layer 2 class map by specifying the option layer2
with the class-map command. A Layer 2 class map differentiates traffic according to 802.1p value and/or
characteristics defined in a MAC ACL.
1. Create a match-any class map using the command class-map match-any or a match-all class map using
the command class-map match-all from CONFIGURATION mode, and enter the keyword layer2.
2. Once you create a class-map, FTOS places you in CLASS MAP mode. From this mode, specify your
match criteria using the command match mac. Match-any class maps allow up to five access-lists, and
match-all class-maps allow only one. You can match against only one VLAN ID.
3. After you specify your match criteria, link the class-map to a queue using the command service-queue
from POLICY MAP mode.
The following configuration maps each queue to a VLAN (you can map 8 VLAN to 8 queues on the
E-Series, and 4 VLANs to 4 queues on the C-Series and S-Series).
Match-any Layer 3 flows may have several match criteria. All flows that match at least one of the match
criteria are mapped to the same queue since they are in the same class map. Setting a DSCP value from
QOS-POLICY-IN mode (see Set a DSCP value for egress packets on page 861) assigns the same DSCP
value to all of the matching flows in the class-map. The Flow-based DSCP Marking feature allows you to
assign different DSCP to each match criteria CLASS-MAP mode using the option set-ip-dscp with the
match command so that matching flows within a class map can have different DSCP values, as shown in
Figure 41-11. The values you set from CLASS-MAP mode override the value you QoS input policy DSCP
value, and packets matching the rule are marked with the specified value.
Figure 41-11. Marking Flows in the Same Queue with Different DSCP Values
FTOS#show run class-map
!
class-map match-any example-flowbased-dscp
match ip access-group test set-ip-dscp 2
match ip access-group test1 set-ip-dscp 4
match ip precedence 7 set-ip-dscp 1
Display all class-maps or a specific class map using the command show qos class-map from EXEC
Privilege mode.
FTOS Behavior: An explicit “deny any" rule in a Layer 3 ACL used in a (match any or match all)
class-map creates a "default to Queue 0" entry in the CAM, which causes unintended traffic
classification. Below, traffic is classified in two Queues, 1 and 2. Class-map ClassAF1 is “match any,”
and ClassAF2 is “match all”.
Above, the ClassAF1 does not classify traffic as intended. Traffic matching the first match criteria is classified to
Queue 1, but all other traffic is classified to Queue 0 as a result of CAM entry 20419.
When the explicit “deny any” rule is removed from all three ACLs, the CAM reflects exactly the desired
classification.
Input QoS policies regulate Layer 3 and Layer 2 ingress traffic. The regulation mechanisms for input QoS
policies are rate policing and setting priority values. There are two types of input QoS policies: Layer 3 and
Layer 2.
• Layer 3 QoS input policies allow you to rate police and set a DSCP or dot1p value.
• Layer 2 QoS input policies allow you to rate police and set a dot1p value.
Output QoS policies regulate Layer 3 egress traffic. The regulation mechanisms for output QoS policies
are rate limiting, rate shaping, and WRED.
Note: When changing a "service-queue" configuration in a QoS policy map, all QoS rules are deleted and
re-added automatically to ensure that the order of the rules is maintained. As a result, the Matched
Packets value shown in the "show qos statistics" command is reset.
1. Create a Layer 3 input QoS policy using the command qos-policy-input from CONFIGURATION
mode. Create a Layer 2 input QoS policy by specifying the keyword layer2 after the command
qos-policy-input.
2. Once you create an input QoS policy, do one or more of the following:
• Configure policy-based rate policing
• Set a DSCP value for egress packets
• Set a dot1p value for egress packets
Rate police ingress traffic using the command rate-police from QOS-POLICY-IN mode.
Set a DSCP value for egress packets based on ingress QoS classification, as shown in Figure 41-2. The 6
bits that are used for DSCP are also used to identify the queue in which traffic is buffered. When you set a
DSCP value, FTOS displays an informational message advising you of the queue to which you should
apply the QoS policy (using the command service-queue from POLICY-MAP-IN mode). If you apply the
QoS policy to a queue other than the one specified in the informational message, FTOS replaces the first 3
bits in the DSCP field with the queue ID you specified.
FTOS#config
FTOS(conf)#qos-policy-input my-input-qos-policy
FTOS(conf-qos-policy-in)#set ip-dscp 34
% Info: To set the specified DSCP value 34 (100-010 b) the QoS policy must be mapped to queue
4 (100 b).
FTOS(conf-qos-policy-in)#show config
!
qos-policy-input my-input-qos-policy
set ip-dscp 34
FTOS(conf-qos-policy-in)#end
FTOS#
Set a dot1p value for egress packets using the command set mac-dot1p from QOS-POLICY-IN mode.
1. Create an output QoS policy using the command qos-policy-output from CONFIGURATION mode.
2. Once you configure an output QoS policy, do one or more of the following
• Configure policy-based rate limiting
• Configure policy-based rate shaping
• Allocate bandwidth to queue
• Specify WRED drop precedence
Rate shape egress traffic using the command rate-shape from QOS-POLICY-OUT mode. Output QoS
policy can be applied to an output policy map with a policy aggregate or to an specific queue. Per queue
rate shaping is supported on C-Series and S-Series only; see Create Output Policy Maps on page 868.
FTOS#conf t
FTOS(conf)#qos-policy-output QosShape
FTOS(conf-qos-policy-out)# rate-shape 4 10
FTOS(conf-qos-policy-out)#show config
!
qos-policy-output
QosShape rate-shape 4 10
FTOS(conf-qos-policy-out)#exit
The E-Series schedules unicast, multicast, and replication traffic for egress based on the Weighted Fair
Queuing algorithm. The C-Series and S-Series schedule packets for egress based on Deficit Round Robin
(DRR). These strategies both offer a guaranteed data rate.
To allocate an amount bandwidth to a queue using the command bandwidth-percentage on the E-Series.
To allocate bandwidth to queues on the C-Series and S-Series, assign each queue a weight ranging from 1
to 1024, in increments of 2n, using the command bandwidth-weight. Table 41-3 shows the default
bandwidth weights for each queue, and their equivalent percentage which is derived by dividing the
bandwidth weight by the sum of all queue weights.
Equivalent
Queue Default Weight Percentage
0 1 6.67%
1 2 13.33%
2 4 26.67%
3 8 53.33%
There are two key differences between allocating bandwidth by weight on the C-Series and S-Series and
allocating bandwidth by percentage on the E-Series:
1. Assigning a weight to one queue affects the amount of bandwidth that is allocated to other queues.
Therefore, whenever you are allocating bandwidth to one queue, Dell Force10 recommends that you
evaluate your bandwidth requirements for all other queues as well.
2. Because you are required to choose a bandwidth weight in increments of 2n you may not be able to
achieve exactly a target bandwidth allocation.
bandwidth allocation.
Table 41-4. Assigning Bandwidth Weights for the C-Series and S-Series
Equivalent Target
Queue Weight Percentage Allocation
0 1 0.44% 1%
1 64 28.44% 25%
2 128 56.89% 60%
3 32 14.22% 14%
1. Create a Layer 3 input policy map using the command policy-map-input from CONFIGURATION
mode. Create a Layer 2 input policy map by specifying the keyword layer2 with the policy-map-input
command.
2. Once you create an input policy map, do one or more of the following:
• Apply a class-map or input QoS policy to a queue
• Apply an input QoS policy to an input policy map
• Honor DSCP values on ingress packets
• Honoring dot1p values on ingress packets
3. Apply the input policy map to an interface. See page 868.
FTOS Behavior: On ExaScale, FTOS cannot classify protocol traffic on a Layer 2 interface using
Layer 3 policy map. The packets always take the default queue, Queue 0, and cannot be rate-policed.
Assign an input QoS policy to a queue using the command service-queue from POLICY-MAP-IN mode.
Apply an input QoS policy to an input policy map using the command policy-aggregate from
POLICY-MAP-IN mode.
FTOS provides the ability to honor DSCP values on ingress packets using Trust DSCP feature. Enable this
feature using the command trust diffserv from POLICY-MAP-IN mode. Table 41-5 lists the standard
DSCP definitions, and indicates to which queues FTOS maps DSCP values. When Trust DSCP is
configured the matched packets and matched bytes counters are not incremented in show qos statistics.
FTOS provides the ability to honor dot1p values on ingress packets with the Trust dot1p feature. Enable
Trust dot1p using the command trust dot1p from POLICY-MAP-IN mode. Table 41-6 specifies the queue
to which the classified traffic is sent based on the dot1p value.
The dot1p value is also honored for frames on the default VLAN; see Priority-tagged Frames on the
Default VLAN.
When class-maps are used, traffic is matched against each class-map sequentially from first to last. The
sequence is based on the priority of the rules, as follows:
By default, if no match occurs, the packet is queued to the default queue, Queue 0.
!
policy-map-input input-policy
service-queue 1 class-map qos-BE1
service-queue 3 class-map qos-AF3
service-queue 4 class-map qos-AF4
!
class-map match-any qos-AF3
match ip dscp 24
match ip access-group qos-AF3-ACL
!
class-map match-any qos-AF4
match ip dscp 32
match ip access-group qos-AF4-ACL
!
class-map match-all qos-BE1
match ip dscp 0
match ip access-group qos-BE1-ACL
1. Match packets against match-any qos-AF4. If a match exists, queue the packet as AF4 in Queue 4, and
if no match exists, go to the next class map.
2. Match packets against match-any qos-AF3. If a match exists, queue the packet as AF3 in Queue 3, and
if no match exists, go to the next class map.
3. Match packets against match-all qos-BE1. If a match exists, queue the packet as BE1, and if no match
exists, queue the packets to the default queue, Queue 0.
You can optionally classify packets using their DSCP marking, instead of placing packets in Queue 0, if no
match occurs. In the above example, if no match occurs against match-all qos-BE1, the classification logic
continues:
4. Queue the packet according to the DSCP marking. The DSCP to Queue mapping will be as per the
Table 41-5.
The behavior is similar for trust dot1p fallback in a Layer2 input policy map; the dot1p-to-queue mapping
is according to Table 41-6.
Classify packets according to their DSCP value as a secondary trust {diffserve | dot1p} POLICY-MAP-IN
option in case no match occurs against the configured class fallback
maps.
dot1p on ingress, then you can create service classes based the queueing strategy in Table 41-6 using the
command service-class dynamic dot1p from INTERFACE mode. You may apply this queuing strategy
globally by entering this command from CONFIGURATION mode.
• All dot1p traffic is mapped to Queue 0 unless service-class dynamic dot1p is enabled on an interface or
globally.
• Layer 2 or Layer 3 service policies supersede dot1p service classes.
Guarantee a minimum bandwidth to queues globally from CONFIGURATION mode with the command
service-class bandwidth-weight. The command is applied in the same way as the bandwidth-weight
command in an output QoS policy (see Allocate bandwidth to queue on page 863). The bandwidth-weight
command in QOS-POLICY-OUT mode supersedes the service-class bandwidth-weight command.
Apply an input policy map to an interface using the command service-policy input from INTERFACE
mode. Specify the keyword layer2 if the policy map you are applying a Layer 2 policy map; in this case, the
INTERFACE must be in switchport mode. You can apply the same policy map to multiple interfaces, and
you can modify a policy map after you apply it.
• You cannot apply a class-map and QoS policies to the same interface.
• You cannot apply an input Layer 2 QoS policy on an interface you also configure with vlan-stack
access.
• If you apply a service policy that contains an ACL to more than one interface, FTOS uses ACL
optimization to conserves CAM space. The ACL Optimization behavior detects when an ACL already
exists in the CAM and rather than writing it to the CAM multiple times.
Apply an output QoS policy to queues using the command service-queue from INTERFACE mode.
Specify an aggregate QoS policy using the command policy-aggregate from POLICY-MAP-OUT mode.
Apply an input policy map to an interface using the command service-policy output from INTERFACE
mode. You can apply the same policy map to multiple interfaces, and you can modify a policy map after
you apply it.
By default, while rate limiting, policing, and shaping, FTOS does not include the Preamble, SFD, or the
IFG fields. These fields are overhead; only the fields from MAC Destination Address to the CRC are used
for forwarding and are included in these rate metering calculations. You can optionally include overhead
fields in rate metering calculations by enabling QoS Rate Adjustment.
QoS Rate Adjustment is disabled by default, and no qos-rate-adjust is listed in the running-configuration.
You can assign strict-priority to one unicast queue, 1-7, using the command strict-priority from
CONFIGURATION mode. Strict-priority means that FTOS dequeues all packets from the assigned queue
before servicing any other queues.
Traffic is a mixture of various kinds of packets. The rate at which some types of packets arrive might be
greater than others. In this case, the space on the BTM (ingress or egress) can be consumed by only one or
a few types of traffic, leaving no space for other types. A WRED profile can be applied to a policy-map so
that specified traffic can be prevented from consuming too much of the BTM resources.
WRED uses a profile to specify minimum and maximum threshold values. The minimum threshold is the
allotted buffer space for specified traffic, for example 1000KB on egress. If the 1000KB is consumed,
packets will be dropped randomly at an exponential rate until the maximum threshold is reached
(Figure 41-13); this is the “early detection” part of WRED. If the maximum threshold—2000KB, for
example—is reached, then all incoming packets are dropped until less than 2000KB of buffer space is
consumed by the specified traffic.
Allotted Space
Early Warning
0 Pckts
fnC0045mp
1. Create a WRED profile using the command wred from CONFIGURATION mode.
2. The command wred places you in WRED mode. From this mode, specify minimum and maximum
threshold values using the command threshold.
FTOS assigns a color (also called drop precedence)—red, yellow, or green—to each packet based on it
DSCP value before queuing it. DSCP is a 6 bit field. Dell Force10 uses the first three bits of this field (DP)
to determine the drop precedence. DP values of 110 and 100 map to yellow, and all other values map to
green. If you do not configure FTOS to honor DSCP values on ingress (Honor DSCP values on ingress
packets on page 865) see all traffic defaults to green drop precedence.
Assign a WRED profile to either yellow or green traffic from QOS-POLICY-OUT mode using the
command wred.
Using the command storm-control broadcast 50 out wred-profile, for example, first the total bandwidth that
broadcast traffic can consume is reduced to 50% of line rate. Even though broadcast traffic is restricted, the
rate of outgoing broadcast traffic might be greater than other traffic, and if so, broadcast packets would
consume too much buffer space. So, the wred-profile option is added to limit the amount of buffer space
that broadcast traffic can consume.
FTOS Behavior: The C-Series fetches the per-queue packet count via class-maps. The count is the
number of packets matching the ACL entries in class-map. Every time the class-map or policy-map is
modified, the ACL entries are re-written to the Forwarding Processor, and the queue statistics are
cleared. This behavior is different from the E-Series. The E-Series fetches the packet count directly
from counters at each queue, which allows queue statistics to persist until explicitly cleared via the CLI.
• If you configure bandwidth-percentage for unicast only, 1/8 of the port bandwidth is reserved for
multicast, and the remaining bandwidth is distributed based on your configuration.
• If you configure multicast bandwidth, after assigning the specified amount of bandwidth to multicast
the remaining bandwidth is distributed according to the WFQ algorithm.
• If you configure bandwidth-percentage for both unicast and multicast, then bandwidth is assigned
based on your configuration for multicast then unicast (based on the remaining available bandwidth),
and the remaining bandwidth is distributed among the other queues.
% to all remaining unicast queues, then first, FTOS assigns 70% bandwidth to multicast, then FTOS
derives the 80% bandwidth for unicast from the remaining 30% of total bandwidth.
The command test cam-usage enables you to verify that there are enough available CAM entries before
applying a policy-map to an interface so that you avoid exceeding the QoS CAM space and partial
configurations. This command measures the size of the specified policy-map and compares it to the
available CAM space in a partition for a specified port-pipe.
Test the policy-map size against the CAM space for a specific port-pipe or all port-pipes using these
commands:
• test cam-usage service-policy input policy-map {linecard | stack-unit } number port-set number
• test cam-usage service-policy input policy-map {linecard | stack-unit } all
Specifically:
• Available CAM is the available number of CAM entries in the specified CAM partition for the
specified line card or stack-unit port-pipe.
• Estimated CAM is the estimated number of CAM entries that the policy will consume when it is
applied to an interface.
Note: The command show cam-usage provides much of the same information as test cam-usage, but
whether or not a policy-map can be successfully applied to an interface cannot be determined without first
measuring how many CAM entries the policy-map would consume; the command test cam-usage is useful
because it provides this measurement.
876
|
Quality of Service
42
Routing Information Protocol
Routing Information Protocol is supported only on platforms: ce s
RIP is supported on the S-Series following the release of FTOS version 7.8.1.0, and on the C-Series with
FTOS versions 7.6.1.0 and after.
RIP is supported on the E-Series ExaScale platform with FTOS 8.1.1.0 and later.
Routing Information Protocol (RIP) is based on a distance-vector algorithm, it tracks distances or hop
counts to nearby routers when establishing network connections.
RIP protocol standards are listed in the Appendix 63, Standards Compliance chapter.
Protocol Overview
RIP is the oldest interior gateway protocol. There are two versions of RIP: RIP version 1 (RIPv1) and RIP
version 2 (RIPv2). These versions are documented in RFCs 1058 and 2453.
RIPv1
RIPv1 learns where nodes in a network are located by automatically constructing a routing data table. The
routing table is established after RIP sends out one or more broadcast signals to all adjacent nodes in a
network. Hop counts of these signals are tracked and entered into the routing table, which defines where
nodes in the network are located.
The information that is used to update the routing table is sent as either a request or response message. In
RIPv1, automatic updates to the routing table are performed as either one-time requests or periodic
responses (every 30 seconds). RIP transports its responses or requests by means of UDP over port 520.
containing a router’s full routing table are transmitted every 30 seconds. If a router does not send an update
within a certain amount of time, the hop count to that route is changed to unreachable (a route hop metric
of 16 hops). Another timer sets the amount of time before the unreachable routes are removed from the
routing table.
This first RIP version does not support VLSM or CIDR and is not widely used.
RIPv2
RIPv2 adds support for subnet fields in the RIP routing updates, thus qualifying it as a classless routing
protocol. The RIPv2 message format includes entries for route tags, subnet masks, and next hop addresses.
Another enhancement included in RIPv2 is multicasting for route updates on IP multicast address
224.0.0.9.
Implementation Information
FTOS supports both versions of RIP and allows you to configure one version globally and the other
version or both versions on the interfaces. The C-Series and E-Series both support 1,000 RIP routes.
Feature Default
Interfaces running RIP Listen to RIPv1 and RIPv2
Transmit RIPv1
RIP timers update timer = 30 seconds
invalid timer = 180 seconds
holddown timer = 180 seconds
flush timer = 240 seconds
Auto summarization Enabled
ECMP paths supported 16
Configuration Information
By default, RIP is disabled in FTOS. To configure RIP, you must use commands in two modes: ROUTER
RIP and INTERFACE. Commands executed in the ROUTER RIP mode configure RIP globally, while
commands executed in the INTERFACE mode configure RIP features on that interface only.
RIP is best suited for small, homogeneous networks. All devices within the RIP network must be
configured to support RIP if they are to participate in the RIP.
For a complete listing of all commands related to RIP, refer to the FTOS Command Reference.
By default, RIP is not enabled in FTOS. To enable RIP, use the following commands in sequence, starting
in the CONFIGURATION mode:
1 router rip CONFIGURATION Enter ROUTER RIP mode and enable the RIP process
on FTOS.
After designating networks with which the system is to exchange RIP information, ensure that all devices
on that network are configured to exchange RIP information.
The FTOS default is to send RIPv1, and to receive RIPv1 and RIPv2. To change the RIP version globally,
use the version command in the ROUTER RIP mode.
When RIP is enabled, you can view the global RIP configuration by using the show running-config
command in the EXEC mode or the show config command (Figure ) in the ROUTER RIP mode.
To disable RIP globally, use the no router rip command in the CONFIGURATION mode.
When you enable RIP globally on the system, interfaces meeting certain conditions start receiving RIP
routes. By default, interfaces that are enabled and configured with an IP address in the same subnet as the
RIP network address receive RIPv1 and RIPv2 routes and send RIPv1 routes.
Assign IP addresses to interfaces that are part of the same subnet as the RIP network identified in the
network command syntax.
By default, RIP broadcasts routing information out all enabled interfaces, but you can configure RIP to
send or to block RIP routing information, either from a specific IP address or a specific interface. To
control which devices or interfaces receive routing updates, you must configure a direct update to one
router and configure interfaces to block RIP updates from other sources.
To control the source of RIP route information, use the following commands, in the ROUTER RIP mode:
neighbor ip-address ROUTER RIP Define a specific router to exchange RIP information
between it and the Dell Force10 system.
You can use this command multiple times to exchange
RIP information with as many RIP networks as you
want.
passive-interface interface ROUTER RIP Disable a specific interface from sending or receiving
RIP routing information.
Another method of controlling RIP (or any routing protocol) routing information is to filter the information
through a prefix list. A prefix lists is applied to incoming or outgoing routes. Those routes must meet the
conditions of the prefix list; if not, FTOS drops the route. Prefix lists are globally applied on all interfaces
running RIP. Configure the prefix list in the PREFIX LIST mode prior to assigning it to the RIP process.
For configuration information on prefix lists, see Chapter 17, IP Access Control Lists, Prefix Lists, and
Route-maps, on page 47.
To apply prefix lists to incoming or outgoing RIP routes, use the following commands in the ROUTER
RIP mode:
distribute-list prefix-list-name in ROUTER RIP Assign a configured prefix list to all incoming
RIP routes.
distribute-list prefix-list-name out ROUTER RIP Assign a configured prefix list to all outgoing
RIP routes.
In addition to filtering routes, you can add routes from other routing instances or protocols to the RIP
process. With the redistribute command syntax, you can include OSPF, static, or directly connected routes
in the RIP process.
redistribute isis [level-1 | level-1-2 | level-2] ROUTER RIP Include IS-IS routes in RIP.
[metric metric-value] [route-map map-name] • metric range: 0 to 16
• map-name: name of a configured route
map.
Note: IS-IS is not supported on the
S-Series platform.
redistribute ospf process-id [match external {1 | ROUTER RIP Include specific OSPF routes in RIP.
2} | match internal] [metric value] [route-map Configure the following parameters:
map-name] • process-id range: 1 to 65535
• metric range: 0 to 16
• map-name: name of a configured route
map.
To view the current RIP configuration, use the show running-config command in the EXEC mode or the
show config command in the ROUTER RIP mode.
To specify the RIP version, use the version command in the ROUTER RIP mode. To set an interface to
receive only one or the other version, use the ip rip send version or the ip rip receive version commands
in the INTERFACE mode.
To change the RIP version globally in FTOS, use the following command in the ROUTER RIP mode:
version {1 | 2} ROUTER RIP Set the RIP version sent and received on the system.
You can set one RIP version globally on the system. This command sets the RIP version for RIP traffic on
the interfaces participating in RIP unless the interface was specifically configured for a specific RIP
version.
Use the show config command in the ROUTER RIP mode to see whether the version command is
configured. You can also use the show ip protocols command in the EXEC mode to view the routing
protocols configuration.
FTOS#
To configure the interfaces to send or receive different RIP versions from the RIP version configured
globally, use either of the following commands in the INTERFACE mode:
ip rip receive version [1] [2] INTERFACE Set the RIP version(s) received on that interface.
ip rip send version [1] [2] INTERFACE Set the RIP version(s) sent out on that interface.
To configure an interface to receive or send both versions of RIP, include 1 and 2 in the command syntax.
Figure 42-4 displays the command syntax for sending both RIPv1 and RIPv2 and receiving only RIPv2.
Figure 42-4. Configuring an interface to send both versions of RIP
FTOS(conf-if)#ip rip send version 1 2
FTOS(conf-if)#ip rip receive version 2
The show ip protocols command example Figure 42-5 confirms that both versions are sent out that
interface. This interface no longer sends and receives the same RIP versions as FTOS does globally.
FTOS#show ip protocols
FTOS#
Traffic is forwarded to the default route when the traffic’s network is not explicitly listed in the routing
table. Default routes are not enabled in RIP unless specified. Use the default-information originate
command in the ROUTER RIP mode to generate a default route into RIP. In FTOS, default routes received
in RIP updates from other routes are advertised if the default-information originate command is
configured.
To configure FTOS to generate a default route, use the following command in the ROUTER RIP mode:
default-information originate [always] [metric ROUTER RIP Specify the generation of a default route
value] [route-map route-map-name] in RIP. Configure the following
parameters:
• always: enter this keyword to
always generate a default route.
• value range: 1 to 16.
• route-map-name: name of a
configured route map.
Use the show config command in the ROUTER RIP mode to confirm that the default route configuration
is completed.
Summarize routes
Routes in the RIPv2 routing table are summarized by default, thus reducing the size of the routing table
and improving routing efficiency in large networks. By default, the autosummary command in the
ROUTER RIP mode is enabled and summarizes RIP routes up to the classful network boundary.
The command autosummary requires no other configuration commands. To disable automatic route
summarization, in the ROUTER RIP mode, enter no autosummary.
Note: If the ip split-horizon command is enabled on an interface, then the system does not advertise the
summarized address.
As a distance-vector protocol, RIP uses hop counts to determine the best route, but sometimes the shortest
hop count is a route over the lowest-speed link. To manipulate RIP routes so that the routing protocol
prefers a different route, you must manipulate the route by using the offset command.
Exercise caution when applying an offset command to routers on a broadcast network, as the router using
the offset command is modifying RIP advertisements before sending out those advertisements.
The distance command also allows you to manipulate route metrics. Use the command to assign different
weights to routes so that the ones with the lower weight or administrative distance assigned are preferred.
To set route metrics, use either of the following commands in the ROUTER RIP mode:
distance weight [ip-address mask ROUTER RIP Apply a weight to all routes or a specific route and
[access-list-name]] ACL. Configure the following parameters:
• weight range: 1 to 255 (default is 120)
• ip-address mask: the IP address in dotted
decimal format (A.B.C.D), and the mask in
slash format (/x).
• access-list-name: name of a configured IP
ACL.
offset access-list-name {in | out} offset ROUTER RIP Apply an additional number to the incoming or
[interface] outgoing route metrics. Configure the following
parameters:
• access-list-name: the name of a configured IP
ACL
• offset range: 0 to 16.
• interface: the type, slot, and number of an
interface.
Use the show config command in the ROUTER RIP mode to view configuration changes.
Debug RIP
The debug ip rip command enables RIP debugging. When debugging is enabled, you can view
information on RIP protocol changes or RIP routes.
debug ip rip [interface | database | events | trigger] EXEC privilege Enable debugging of RIP.
Figure 42-6 shows the confirmation when the debug function is enabled.
Figure 42-6. debug ip rip Command Example
FTOS#debug ip rip
RIP protocol debug is ON
FTOS#
Core 2 Output
Core2#
Core2#show ip route
Core2#
Figure 42-11. Using show ip protocols Command to Show RIP Configuration Activity on Core 2
Core2#show ip protocols
Routing Protocol is "RIP"
Sending updates every 30 seconds, next due in 17
Invalid after 180 seconds, hold down 180, flushed after 240
Output delay 8 milliseconds between packets
Automatic network summarization is in effect
Outgoing filter for all interfaces is
Incoming filter for all interfaces is
Default redistribution metric is 1
Default version control: receive version 2, send version 2
Interface Recv Send
GigabitEthernet 2/42 2 2
GigabitEthernet 2/41 2 2
GigabitEthernet 2/31 2 2
GigabitEthernet 2/11 2 2
Routing for Networks:
10.300.10.0
10.200.10.0
10.11.20.0
10.11.10.0
Core2#
Core3#show ip routes
Figure 42-15. Using show ip protocols Command to Show RIP Configuration Activity on Core 3
Core3#show ip protocols
Core3#
!
interface GigabitEthernet 2/41
ip address 10.200.10.1/24
no shutdown
!
interface GigabitEthernet 2/42
ip address 10.250.10.1/24
no shutdown
router rip
version 2
10.200.10.0
10.300.10.0
10.11.10.0
10.11.20.0
Figure 42-17. Summary of Core 3 RIP Configuration Using Output of show run Command
!
interface GigabitEthernet 3/11
ip address 10.11.30.1/24
no shutdown
!
interface GigabitEthernet 3/21
ip address 10.11.20.1/24
no shutdown
!
interface GigabitEthernet 3/43
ip address 192.168.1.1/24
no shutdown
!
interface GigabitEthernet 3/44
ip address 192.168.2.1/24
no shutdown
!
router rip
version 2
network 10.11.20.0
network 10.11.30.0
network 192.168.1.0
network 192.168.2.0
RMON operates with SNMP and monitors all nodes on a LAN segment. RMON monitors traffic passing
through the router and segment traffic not destined for the router. The monitored interfaces may be chosen
by using alarms and events with standard MIBs.
Implementation
You must configure SNMP prior to setting up RMON. For a complete SNMP implementation discussion,
refer to Chapter 6, Simple Network Management Protocol (SNMP), on page 47.
Configuring RMON requires using the RMON CLI and includes the following tasks:
• Set rmon alarm
• Configure an RMON event
• Configure RMON collection statistics
• Configure RMON collection history
• Enable an RMON MIB collection history group
RMON implements the following standard RFCs (for details see Appendix 63, Standards Compliance):
• RFC-2819
• RFC-3273
• RFC-3434
Interface Down—When an RMON-enabled interface goes down, monitoring continues. However, all data
values are registered as 0xFFFFFFFF (32 bits) or ixFFFFFFFFFFFFFFFF (64 bits). When the interface
comes back up, RMON monitoring processes resumes.
Note: A Network Management System (NMS) should be ready to interpret a down interface
and plot the interface performance graph accordingly.
RPM Down, RPM Failover—Master and standby RPMs run the RMON sampling process in the
background. Therefore, when an RPM goes down, the other RPM maintains the sampled data—the new
master RPM provides the same sampled data as did the old master—as long as the master RPM had been
running long enough to sample all the data.
NMS backs up all the long-term data collection, and displays the failover downtime from the performance
graph.
Chassis Down—When a chassis goes down, all sampled data is lost. But the RMON configurations are
saved in the configuration file, and the sampling process continues after the chassis returns to operation.
Platform Adaptation—RMON supports all Dell Force10 chassis and all Dell Force10 Ethernet
Interfaces.
To set an alarm on any MIB object, use the rmon alarm or rmon hc-alarm command in GLOBAL
CONFIGURATION mode. To disable the alarm, use the no form of this command:
[no] rmon alarm number variable CONFIGURATION Set an alarm on any MIB object. Use the no form of
interval {delta | absolute} this command to disable the alarm.
rising-threshold [value Configure the alarm using the following optional
event-number] falling-threshold parameters:
value event-number [owner string] • number: Alarm number, should be an integer
or from 1 to 65,535, the value must be unique in the
[no] rmon hc-alarm number variable RMON Alarm Table
interval {delta | absolute} • variable: The MIB object to monitor—the
variable must be in the SNMP OID format. For
rising-threshold value event-number example, 1.3.6.1.2.1.1.3. The object type must be
falling-threshold value event-number a 32-bit integer for the rmon alarm command
[owner string] and 64 bits for the rmon hc-alarm command.
• interval: Time in seconds the alarm monitors the
MIB variable, the value must be between 1 to
3,600.
• delta: Tests the change between MIB variables,
this is the alarmSampleType in the RMON Alarm
table.
• absolute: Tests each MIB variable directly, this is
the alarmSampleType in the RMON Alarm table.
• rising-threshold value: Value at which the
rising-threshold alarm is triggered or reset. For
the rmon alarm command this is a 32-bits value,
for rmon hc-alarm command this is a 64-bits
value.
• event-number: Event number to trigger when the
rising threshold exceeds its limit. This value is
identical to the alarmRisingEventIndex in the
alarmTable of the RMON MIB. If there is no
corresponding rising-threshold event, the value
should be zero.
• falling-threshold value: Value at which the
falling-threshold alarm is triggered or reset. For
the rmon alarm command, this is a 32-bits
value, for rmon hc-alarm command this is a
64bits value.
• event-number: Event number to trigger when the
falling threshold exceeds its limit. This value is
identical to the alarmFallingEventIndex in the
alarmTable of the RMON MIB. If there is no
corresponding falling-threshold event, the value
should be zero.
• owner string: (Optional) Specifies an owner for
the alarm, this is the alarmOwner object in the
alarmTable of the RMON MIB. Default is a
null-terminated string.
The following example configures an RMON alarm using the rmon alarm command.
Alarm Number MIB Variable Monitor Interval Counter Value Limit Triggered Event
The above example configures RMON alarm number 10. The alarm monitors the MIB variable
1.3.6.1.2.1.2.2.1.20.1 (ifEntry.ifOutErrors) once every 20 seconds until the alarm is disabled, and checks
the rise or fall of the variable. The alarm is triggered when the 1.3.6.1.2.1.2.2.1.20.1 value shows a MIB
counter increase of 15 or more (such as from 100000 to 100015). The alarm then triggers event number 1,
which is configured with the RMON event command. Possible events include a log entry or a SNMP trap.
If the 1.3.6.1.2.1.2.2.1.20.1 value changes to 0 (falling-threshold 0), the alarm is reset and can be triggered
again.
To add an event in the RMON event table, use the rmon event command in GLOBAL CONFIGURATION
mode. To disable RMON on the interface, use the no form of this command:
[no] rmon event number [log] CONFIGURATION number: Assigned event number, which is identical to the
[trap community] [description eventIndex in the eventTable in the RMON MIB. The value
string] [owner string] must be an integer from 1 to 65,535, the value must be
unique in the RMON Event Table.
log: (Optional) Generates an RMON log entry when the
event is triggered and sets the eventType in the RMON
MIB to log or log-and-trap. Default is no log.
trap community: (Optional) SNMP community string used
for this trap. Configures the setting of the eventType in the
RMON MIB for this row as either snmp-trap or
log-and-trap. This value is identical to the
eventCommunityValue in the eventTable in the RMON
MIB. Default is “public”.
description string: (Optional) Specifies a description of
the event, which is identical to the event description in the
eventTable of the RMON MIB. Default is a null-terminated
string.
owner string: (Optional) Owner of this event, which is
identical to the eventOwner in the eventTable of the
RMON MIB. Default is a null-terminated string.
FTOS(conf)#rmon event 1 log trap eventtrap description “High ifOutErrors” owner nms1
The above configuration example creates RMON event number 1, with the description “High ifOutErrors”,
and generates a log entry when the event is triggered by an alarm. The user nms1 owns the row that is
created in the event table by this command. This configuration also generates an SNMP trap when the
event is triggered using the SNMP community string “eventtrap”.
[no] rmon collection statistics CONFIGURATION controlEntry: Specifies the RMON group of statistics
{controlEntry integer} [owner INTERFACE using a value.
ownername] (config-if) integer: A value from 1 to 65,535 that identifies the RMON
Statistics Table. The value must be unique in the RMON
Statistic Table.
owner: (Optional) Specifies the name of the owner of the
RMON group of statistics.
ownername: (Optional) Records the name of the owner of
the RMON group of statistics. Default is a null-terminated
string
The following command enables the RMON statistics collection on the interface, with an ID value of 20
and an owner of “john.”
To enable the RMON MIB history group of statistics collection on an interface, use the rmon collection
history command in interface configuration mode. To remove a specified RMON history group of
statistics collection, use the no form of this command.
[no] rmon collection history CONFIGURATION controlEntry: Specifies the RMON group of
{controlEntry integer} [owner INTERFACE statistics using a value.
ownername] [buckets (config-if) integer: A value from 1 to 65,535 that identifies the
bucket-number] RMON group of statistics. The value must be a
[interval seconds] unique index in the RMON History Table.
owner: (Optional) Specifies the name of the owner
of the RMON group of statistics.Default is a
null-terminated string.
ownername: (Optional) Records the name of the
owner of the RMON group of statistics.
buckets: (Optional) Specifies the maximum number
of buckets desired for the RMON collection history
group of statistics.
bucket-number: (Optional) A value associated with
the number of buckets specified for the RMON
collection history group of statistics. The value is
limited to from 1 to 1000. Default is 50 (as defined in
RFC-2819).
interval: (Optional) Specifies the number of seconds
in each polling cycle.
seconds: (Optional) The number of seconds in each
polling cycle. The value is ranged from 5 to 3,600
(Seconds). Default is 1,800 as defined in RFC-2819.
Protocol Overview
Rapid Spanning Tree Protocol (RSTP) is a Layer 2 protocol—specified by IEEE 802.1w—that is
essentially the same as Spanning-Tree Protocol (STP) but provides faster convergence and interoperability
with switches configured with STP and MSTP.
FTOS supports three other variations of Spanning Tree, as shown in Table 44-1.
R1 R2
R1(conf)# int range gi 1/1 - 4
R1(conf-if-gi-1/1-4)# switchport 1/3 2/1
R1(conf-if-gi-1/1-4)# no shutdown
R1(conf-if-gi-1/1-4)#show config
! 1/4 2/2
interface GigabitEthernet 1/1
no ip address 1/1 1/2 2/3 2/4
switchport
no shutdown
!
interface GigabitEthernet 1/2
no ip address
switchport
no shutdown
! 3/1 3/2 3/3
interface GigabitEthernet 1/3
no ip address
switchport
no shutdown 3/4
!
interface GigabitEthernet 1/4
no ip address R3
switchport
no shutdown
Verify that an interface is in Layer 2 mode and enabled using the show config command from INTERFACE
mode.
Note: To disable RSTP globally for all Layer 2 interfaces, enter the disable command from PROTOCOL
SPANNING TREE RSTP mode.
Verify that Rapid Spanning Tree is enabled using the show config command from PROTOCOL
SPANNING TREE RSTP mode.
FTOS(conf-rstp)#show config
!
protocol spanning-tree rstp Indicates that Rapid Spanning Tree is enabled
no disable
FTOS(conf-rstp)#
When you enable Rapid Spanning Tree, all physical and port-channel interfaces that are enabled and in
Layer 2 mode are automatically part of the RST topology.
• Only one path from any bridge to any other bridge is enabled.
• Bridges block a redundant path by disabling one of the link ports.
Figure 44-4. Rapid Spanning Tree Enabled Globally
root
R1 R2
1/3 Forwarding 2/1
3/4
R3
View the interfaces participating in Rapid Spanning Tree using the show spanning-tree rstp command from
EXEC privilege mode. If a physical interface is part of a port channel, only the port channel is listed in the
command output.
Confirm that a port is participating in Rapid Spanning Tree using the show spanning-tree rstp brief
command from EXEC privilege mode.
• Forward-delay is the amount of time an interface waits in the Listening State and the Learning State
before it transitions to the Forwarding State.
• Hello-time is the time interval in which the bridge sends RSTP Bridge Protocol Data Units (BPDUs).
• Max-age is the length of time the bridge maintains configuration information before it refreshes that
information by recomputing the RST topology.
Note: Dell Force10 recommends that only experienced network administrators change the Rapid Spanning
Tree group parameters. Poorly planned modification of the RSTG parameters can negatively impact
network performance.
RSTP
Parameter Default Value
Forward Delay 15 seconds
Hello Time 2 seconds
Max Age 20 seconds
Port Cost 100-Mb/s Ethernet interfaces 200000
1-Gigabit Ethernet interfaces 20000
10-Gigabit Ethernet interfaces 2000
Port Channel with 100 Mb/s Ethernet interfaces 180000
Port Channel with 1-Gigabit Ethernet interfaces 18000
Port Channel with 10-Gigabit Ethernet interfaces 1800
Port Priority 128
To change these parameters, use the following commands, on the root bridge:
View the current values for global parameters using the show spanning-tree rstp command from EXEC
privilege mode. See Figure 44-5.
On interfaces in Layer 2 mode, you can set the port cost and port priority values.
• Port cost is a value that is based on the interface type. The default values are listed in Table 44-2. The
greater the port cost, the less likely the port will be selected to be a forwarding port.
• Port priority influences the likelihood that a port will be selected to be a forwarding port in case that
several ports have the same port cost.
To change the port cost or priority of an interface, use the following commands:
Change the port cost of an interface. spanning-tree rstp cost cost INTERFACE
Range: 0 to 65535
Default: see Table 44-2.
Change the port priority of an interface. spanning-tree rstp priority priority-value INTERFACE
Range: 0 to 15
Default: 128
View the current values for interface parameters using the show spanning-tree rstp command from EXEC
privilege mode. See Figure 44-5.
Configure an EdgePort
The EdgePort feature enables interfaces to begin forwarding traffic approximately 30 seconds sooner. In
this mode an interface forwards frames by default until it receives a BPDU that indicates that it should
behave otherwise; it does not go through the Learning and Listening states. The bpduguard
shutdown-on-violation option causes the interface hardware to be shutdown when it receives a BPDU.
When only bpduguard is implemented, although the interface is placed in an Error Disabled state when
receiving the BPDU, the physical interface remains up and spanning-tree will drop packets in the hardware
after a BPDU violation. BPDUs are dropped in the software after receiving the BPDU violation. This
feature is the same as PortFast mode in Spanning Tree.
Caution: Configure EdgePort only on links connecting to an end station. EdgePort can cause loops if it is enabled
on an interface connected to a network.
FTOS(conf-if-gi-2/0)#show config
!
interface GigabitEthernet 2/0
no ip address
switchport
spanning-tree rstp edge-port Indicates the interface is in EdgePort mode
shutdown
FTOS(conf-if-gi-2/0)#
The Rapid Spanning Tree Protocol determines the root bridge, but you can assign one bridge a lower
priority to increase the likelihood that it will be selected as the root bridge.
Assign a number as the bridge priority or designate it as the bridge-priority priority-value PROTOCOL
primary or secondary root. SPANNING TREE
priority-value range: 0 to 65535. The lower the number RSTP
assigned, the more likely this bridge will become the root
bridge. The default is 32768. Entries must be multiples of
4096.
A console message appears when a new root bridge has been assigned. Figure 44-8 shows the console
message after the bridge-priority command is used to make R2 the root bridge.
RSTP Fast Hellos decrease the hello interval to the order of milliseconds and all timers derived from the
hello timer are adjusted accordingly. This feature does not inter-operate with other vendors, and is
available only for RSTP.
Configure a hello time on the order of milliseconds. hello-time milli-second interval PROTOCOL RSTP
Range: 50 - 950 milliseconds
Note: The hello time is encoded in BPDUs in increments of 1/256ths of a second. The standard minimum
hello time in seconds is 1 second, which is encoded as 256. Millisecond hello times are encoded using
values less than 256; the millisecond hello time equals (x/1000)*256.
Note: When millisecond hellos are configured, the default hello interval of 2 seconds is still used for edge
ports; the millisecond hello interval is not used.
Use the Root Guard feature in a Layer 2 RSTP network to avoid bridging loops.
FTOS Behavior: The following conditions apply to a port enabled with root guard:
• Root guard is supported on any RSTP-enabled port or port-channel interface except when used as a
stacking port.
• Root guard is supported on a port in any Spanning Tree mode:
•Spanning Tree Protocol (STP)
•Rapid Spanning Tree Protocol (RSTP)
•Multiple Spanning Tree Protocol (MSTP)
•Per-VLAN Spanning Tree Plus (PVST+)
• When enabled on a port, root guard applies to all VLANs configured on the port.
• Root guard and loop guard cannot be enabled at the same time on an RSTP port. For example, if you
configure loop guard on a port on which root guard is already configured, the following error message is
displayed:
% Error: RootGuard is configured. Cannot configure LoopGuard.
To enable a root guard on an RSTP-enabled port or port-channel interface, enter the spanning-tree rstp
rootguard command. Refer to STP Root Guard on page 1060 for more information on how to use the root
guard feature.
Enable root guard on a port or port-channel interface. spanning-tree rstp rootguard INTERFACE
INTERFACE
PORT-CHANNEL
To disable RSTP root guard on a port or port-channel interface, enter the no spanning-tree rstp rootguard
command in an interface configuration mode.
To verify the RSTP root guard configuration on a port or port-channel interface, enter the show
spanning-tree rstp guard [interface interface]
command in global configuration mode.
FTOS Behavior: The following conditions apply to a port enabled with loop guard:
• Loop guard is supported on any RSTP-enabled port or port-channel interface.
• Loop guard is supported on a port or port-channel in any Spanning Tree mode:
•Spanning Tree Protocol (STP)
•Rapid Spanning Tree Protocol (RSTP)
•Multiple Spanning Tree Protocol (MSTP)
•Per-VLAN Spanning Tree Plus (PVST+)
• Root guard and loop guard cannot be enabled at the same time on an RSTP port. For example, if you
configure loop guard on a port on which root guard is already configured, the following error message is
displayed:
% Error: RootGuard is configured. Cannot configure LoopGuard.
• Enabling Portfast BPDU guard and loop guard at the same time on a port results in a port that remains in a
blocking state and prevents traffic from flowing through it. For example, when Portfast BPDU guard and
loop guard are both configured:
- If a BPDU is received from a remote device, BPDU guard places the port in an err-disabled
blocking state and no traffic is forwarded on the port.
- If no BPDU is received from a remote device, loop guard places the port in a loop-inconsistent
blocking state and no traffic is forwarded on the port.
To enable a loop guard on an RSTP-enabled port or port-channel interface, enter the spanning-tree rstp
loopguard command. Refer to STP Loop Guard on page 1064 for more information on how to use the loop
guard feature.
Enable loop guard on an RSTP-enabled port or port-channel spanning-tree rstp loopguard INTERFACE
interface.
INTERFACE
PORT-CHANNEL
To disable RSTP loop guard on a port or port-channel interface, enter the no spanning-tree rstp loopguard
command in an INTERFACE configuration mode.
To verify the RSTP loop guard configuration on a port or port-channel interface, enter the show
spanning-tree rstp guard [interface interface]
command in global configuration mode.
To verify the STP guard configured on RSTP port or port-channel interfaces, enter the show spanning-tree
rstp guard command. Refer to Chapter 52, “Spanning Tree Protocol,” on page 1049 for information on
how to configure and use the STP root guard, loop guard, and BPDU guard features.
Security features are supported on the E-Series ExaScale platform with FTOS 8.1.1.0 and later.
For details on all commands discussed in this chapter, see the Security Commands chapter in the FTOS
Command Reference.
AAA Accounting
AAA Accounting is part of the AAA security model (Accounting, Authentication, and Authorization),
which includes services for authentication, authorization, and accounting. For details on commands related
to AAA security, refer to the Security chapter in the FTOS Command Reference.
AAA Accounting enables tracking of services that users are accessing and the amount of network
resources being consumed by those services. When AAA Accounting is enabled, the network server
reports user activity to the security server in the form of accounting records. Each accounting record is
comprised of accounting AV pairs and is stored on the access control server.
As with authentication and authorization, you must configure AAA Accounting by defining a named list of
accounting methods, and then apply that list to various interfaces.
Security | 913
Configuration Task List for AAA Accounting
www.dell.com | support.dell.com
The aaa accounting command enables you to create a record for any or all of the accounting functions
monitored. To enable AAA accounting, perform the following task in CONFIGURATION mode:
aaa accounting {system | exec | CONFIGURATION Enable AAA Accounting and create a record for
command level} {default | name} monitoring the accounting function.
{start-stop | wait-start | stop-only} The variables are:
{tacacs+} • system—sends accounting information of any
other AAA configuration
• exec—sends accounting information when a user
has logged in to the EXEC mode
• command level—sends accounting of commands
executed at the specified privilege level
• default | name—Enter the name of a list of
accounting methods.
• start-stop—Use for more accounting information,
to send a start-accounting notice at the beginning
of the requested event and a stop-accounting
notice at the end.
• wait-start—ensures that the TACACS+ security
server acknowledges the start notice before
granting the user's process request
• stop-only—Use for minimal accounting; instructs
the TACACS+ server to send a stop record
accounting notice at the end of the requested user
process.
• tacacs+ —Designate the security service.
Currently, FTOS supports only TACACS+
914 | Security
Suppress AAA Accounting for null username sessions
When AAA Accounting is activated, the FTOS software issues accounting records for all users on the
system, including users whose username string, because of protocol translation, is NULL. An example of
this is a user who comes in on a line where the AAA Authentication login method-list none command is
applied. To prevent accounting records from being generated for sessions that do not have usernames
associated with them, perform the following task in CONFIGURATION mode:
aaa accounting suppress CONFIGURATION Prevent accounting records from being generated for
null-username users whose username string is NULL
The network access server monitors the accounting functions defined in the TACACS+ attribute/value
(AV) pairs.
In the following sample configuration, AAA accounting is set to track all usage of EXEC commands and
commands on privilege level 15.
Use the following commands to enable accounting with a named method list for a specific terminal line
(where com15 and execAcct are the method list names):
FTOS does not support periodic interim accounting, because the periodic command can cause heavy
congestion when many users are logged in to the network.
Security | 915
No specific show command exists for TACACS+ accounting. To obtain accounting records displaying
www.dell.com | support.dell.com
information about users currently logged in, perform the following task in Privileged EXEC mode:
show accounting CONFIGURATION Step through all active sessions and print all the accounting records
for the actively accounted functions.
916 | Security
AAA Authentication
FTOS supports a distributed client/server system implemented through Authentication, Authorization, and
Accounting (AAA) to help secure networks against unauthorized access. In the Dell Force10
implementation, the Dell Force10 system acts as a RADIUS or TACACS+ client and sends authentication
requests to a central RADIUS or TACACS+ server that contains all user authentication and network
service access information.
Dell Force10 uses local usernames/passwords (stored on the Dell Force10 system) or AAA for login
authentication. With AAA, you can specify the security protocol or mechanism for different login methods
and different users. In FTOS, AAA uses a list of authentication methods, called method lists, to define the
types of authentication and the sequence in which they are applied. You can define a method list or use the
default method list. User-defined method lists take precedence over the default method list.
For a complete listing of all commands related to login authentication, refer to the Security chapter in the
FTOS Command Reference.
You can assign up to five authentication methods to a method list. FTOS evaluates the methods in the order
in which you enter them in each list. If the first method list does not respond or returns an error, FTOS
applies the next method list until the user either passes or fails the authentication. If the user fails a method
list, FTOS does not apply the next method list.
Security | 917
Configure AAA Authentication login methods
www.dell.com | support.dell.com
To configure an authentication method and method list, use these commands in the following sequence in
the CONFIGURATION mode:
2 line {aux 0 | console 0 | vty number CONFIGURATION Enter the LINE mode.
[... end-number]}
FTOS Behavior: If you use a method list on the console port in which RADIUS or TACACS is the last
authentication method, and the server is not reachable, FTOS allows access even though the
username and password credentials cannot be verified. Only the console port behaves this way, and
does so to ensure that users are not locked out of the system in the event that network-wide issue
prevents access to these servers.
To view the configuration, use the show config command in the LINE mode or the show running-config in
the EXEC Privilege mode.
Note: Dell Force10 recommends that you use the none method only as a backup. This method
does not authenticate users. The none and enable methods do not work with SSH.
You can create multiple method lists and assign them to different terminal lines.
918 | Security
Enable AAA Authentication
To enable AAA authentication, use the following command in the CONFIGURATION mode:
If the default list is not set, only the local enable is checked. This has the same effect as issuing:
aaa authentication enable default enable
AAA Authentication—RADIUS
To enable authentication from the RADIUS server, and use TACACS as a backup, use the following
commands:
1 aaa authentication enable default CONFIGURATION To enable RADIUS and to set up TACACS
radius tacacs as backup.
2 radius-server host x.x.x.x key CONFIGURATION To establish host address and password.
some-password
3 tacacs-server host x.x.x.x key CONFIGURATION To establish host address and password.
some-password
To get enable authentication from the RADIUS server, and use TACACS as
a backup, issue the following commands:
Security | 919
Server-side configuration
www.dell.com | support.dell.com
TACACS+: When using TACACS+, Dell Force10 sends an initial packet with service type
SVC_ENABLE, and then, a second packet with just the password. The TACACS server must have an
entry for username $enable$.
RADIUS: When using RADIUS authentication, FTOS sends an authentication packet with the following:
Username: $enab15$
Password: <password-entered-by-user>
Therefore, the RADIUS server must have an entry for this username.
AAA Authorization
FTOS enables AAA new-model by default.You can set authorization to be either local or remote. Different
combinations of authentication and authorization yield different results. By default, FTOS sets both to
local.
Every command in FTOS is assigned a privilege level of 0, 1 or 15. You can configure up to 16 privilege
levels in FTOS. FTOS is pre-configured with 3 privilege levels and you can configure 13 more. The three
pre-configured levels are:
• Privilege level 1—is the default level for the EXEC mode. At this level, you can interact with the
router, for example, view some show commands and Telnet and ping to test connectivity, but you
cannot configure the router. This level is often called the “user” level. One of the commands available
in Privilege level 1 is the enable command, which you can use to enter a specific privilege level.
• Privilege level 0—contains only the end, enable and disable commands.
• Privilege level 15—the default level for the enable command, is the highest level. In this level you can
access any command in FTOS.
Privilege levels 2 through 14 are not configured and you can customize them for different users and access.
After you configure other privilege levels, enter those levels by adding the level parameter after the enable
command or by configuring a user name or password that corresponds to the privilege level. Refer to
Configure a username and password on page 921 for more information on configuring user names.
920 | Security
By default, commands in FTOS are assigned to different privilege levels. You can access those commands
only if you have access to that privilege level. For example, to reach the protocol spanning-tree command,
you must log in to the router, enter the enable command for privilege level 15 (this is the default level for
the command) and then enter the CONFIGURATION mode.
You can configure passwords to control access to the box and assign different privilege levels to users.
FTOS supports the use of passwords when you log in to the system and when you enter the enable
command. If you move between privilege levels, you are prompted for a password if you move to a higher
privilege level.
For a complete listing of all commands related to FTOS privilege levels and passwords, refer to the
Security chapter in the FTOS Command Reference.
In FTOS, you can assign a specific username to limit user access to the system.
To configure a username and password, use the following command in the CONFIGURATION mode:
username name [access-class CONFIGURATION Assign a user name and password. Configure the
access-list-name] [nopassword | password optional and required parameters:
[encryption-type] password] [privilege level] • name: Enter a text string up to 63 characters
long.
• access-class access-list-name: Enter the
name of a configured IP ACL.
• nopassword: Do not require the user to
enter a password.
• encryption-type: Enter 0 for plain text or 7
for encrypted text.
• password: Enter a string.
• privilege level range: 0 to 15.
To view usernames, use the show users command in the EXEC Privilege mode.
Security | 921
Configure the enable password command
www.dell.com | support.dell.com
To configure FTOS, you must use the enable command to enter the EXEC Privilege level 15. After
entering the command, FTOS requests that you enter a password. Privilege levels are not assigned to
passwords, rather passwords are assigned to a privilege level. A password for any privilege level can
always be changed. To change to a different privilege level, enter the enable command, followed by the
privilege level. If you do not enter a privilege level, the default level 15 is assumed.
To configure a password for a specific privilege level, use the following command in the
CONFIGURATION mode:
enable password [level level] CONFIGURATION Configure a password for a privilege level. Configure the
[encryption-mode] password optional and required parameters:
• level level: Specify a level 0 to 15. Level 15 includes all
levels.
• encryption-type: Enter 0 for plain text or 7 for encrypted
text.
• password: Enter a string.
To change only the password for the enable command,
configure only the password parameter.
To view the configuration for the enable secret command, use the show running-config command in the
EXEC Privilege mode.
In custom-configured privilege levels, the enable command is always available. No matter what privilege
level you entered FTOS, you can enter the enable 15 command to access and configure all CLI.
In addition to assigning privilege levels to the user, you can configure the privilege levels of commands so
that they are visible in different privilege levels. Within FTOS, commands have certain privilege levels.
With the privilege command, the default level can be changed or you can reset their privilege level back to
the default.
• Assign the launch keyword (for example, configure) for the keyword’s command mode.
• If you assign only the first keyword to the privilege level, all commands beginning with that keyword
are also assigned to the privilege level. If you enter the entire command, the software assigns the
privilege level to that command only.
922 | Security
To assign commands and passwords to a custom privilege level, you must be in privilege level 15 and use
these commands in the following sequence in the CONFIGURATION mode:
1 username name [access-class CONFIGURATION Assign a user name and password. Configure the
access-list-name] [privilege level] optional and required parameters:
[nopassword | password • name: Enter a text string (up to 63
[encryption-type] password] characters).
• access-class access-list-name: Enter the
name of a configured IP ACL.
• privilege level range: 0 to 15.
• nopassword: Do not require the user to
enter a password.
• encryption-type: Enter 0 for plain text or 7 for
encrypted text.
• password: Enter a string.
2 enable password [level level] CONFIGURATION Configure a password for privilege level.
[encryption-mode] password Configure the optional and required parameters:
• level level: Specify a level 0 to 15. Level 15
includes all levels.
• encryption-type: Enter 0 for plain text or 7 for
encrypted text.
• password: Enter a string up to 25 characters
long.
To change only the password for the enable
command, configure only the password
parameter.
3 privilege mode {level level command CONFIGURATION Configure level and commands for a mode or
| reset command} reset a command’s level. Configure the
following required and optional parameters:
• mode: Enter a keyword for the modes (exec,
configure, interface, line, route-map, router)
• level level range: 0 to 15. Levels 0, 1 and 15
are pre-configured. Levels 2 to 14 are
available for custom configuration.
• command: A FTOS CLI keyword (up to 5
keywords allowed).
• reset: Return the command to its default
privilege mode.
To view the configuration, use the show running-config command in the EXEC Privilege mode.
Figure 45-2 is an example of a configuration to allow a user “john” to view only the EXEC mode
commands and all snmp-server commands. Since the snmp-server commands are “enable” level
commands and, by default, found in the CONFIGURATION mode, you must also assign the launch
command for the CONFIGURATION mode, configure, to the same privilege level as the snmp-server
commands.
Security | 923
Figure 45-2. Configuring a Custom Privilege Level
www.dell.com | support.dell.com
FTOS(conf)#username john privilege 8 password john The user john is assigned privilege level
FTOS(conf)#enable password level 8 notjohn
8 and assigned a password.
FTOS(conf)#privilege exec level 8 configure
FTOS(conf)#privilege config level 8 snmp-server All other users are assigned a password
FTOS(conf)#end to access privilege level 8
FTOS#show running-config The command configure is assigned to
Current Configuration ... privilege level 8 since it is needed to
!
reach the CONFIGURATION mode
hostname Force10
! where the snmp-server commands are
enable password level 8 notjohn located.
enable password force10 The snmp-server commands, in the
! CONFIGURATION mode, are assigned
username admin password 0 admin
to privilege level 8.
username john password 0 john privilege 8
!
Figure 45-3 is a screen shot of the Telnet session for user “john”. The show privilege command output
confirms that “john” is in privilege level 8. In the EXEC Privilege mode, “john” can access only the
commands listed. In CONFIGURATION mode, “john” can access only the snmp-server commands.
Figure 45-3. User john’s Login and the List of Available Commands
You can specify a password authentication of all users on different terminal lines. The user’s privilege
level will be the same as the privilege level assigned to the terminal line, unless a more specific privilege
level is is assigned to the user.
924 | Security
To specify a password for the terminal line, use the following commands, in any order, in the LINE mode:
privilege level level LINE Configure a custom privilege level for the terminal
lines.
• level level range: 0 to 15. Levels 0, 1 and 15 are
pre-configured. Levels 2 to 14 are available for
custom configuration.
password [encryption-type] password LINE Specify either a plain text or encrypted password.
Configure the following optional and required
parameters:
• encryption-type: Enter 0 for plain text or 7 for
encrypted text.
• password: Enter a text string up to 25 characters
long.
To view the password configured for a terminal, use the show config command in the LINE mode.
Enter the enable or enable privilege-level command in the EXEC Privilege mode to set a user’s security
level. If you do not enter a privilege level, FTOS sets it to 15 by default.
To move to a lower privilege level, enter the command disable followed by the level-number you wish to
set for the user in the EXEC Privilege mode. If you enter disable without a level-number, your security
level is 1.
RADIUS
Remote Authentication Dial-In User Service (RADIUS) is a distributed client/server protocol. This
protocol transmits authentication, authorization, and configuration information between a central RADIUS
server and a RADIUS client (the Dell Force10 system). The system sends user information to the RADIUS
server and requests authentication of the user and password. The RADIUS server returns one of the
following responses:
• Access-Accept—the RADIUS server authenticates the user
• Access-Reject—the RADIUS server does not authenticate the user
If an error occurs in the transmission or reception of RADIUS packets, the error can be viewed by enabling
the debug radius command.
Transactions between the RADIUS server and the client are encrypted (the users’ passwords are not sent in
plain text). RADIUS uses UDP as the transport protocol between the RADIUS server host and the client.
For more information on RADIUS, refer to RFC 2865, Remote Authentication Dial-in User Service.
Security | 925
RADIUS Authentication and Authorization
www.dell.com | support.dell.com
FTOS supports RADIUS for user authentication (text password) at login and can be specified as one of the
login authentication methods in the aaa authentication login command.
When configuring AAA authorization, you can configure to limit the attributes of services available to a
user. When authorization is enabled, the network access server uses configuration information from the
user profile to issue the user's session. The user’s access is limited based on the configuration attributes.
Code Attribute
1 RADIUS_USER_NAME
2 RADIUS_USER_PASSWORD
4 RADIUS_NAS_IP_ADDRESS
5 RADIUS_NAS_PORT
28 RADIUS_IDLE_TIMEOUT
61 RADIUS_NAS_PORT_TYPE
95 NAS_IPv6_ADDRESS
802.1x supported:
1 RADIUS_USER_NAME
4 RADIUS_NAS_IP_ADDRESS
5 RADIUS_NAS_PORT
24 RADIUS_STATE
30 RADIUS_CALLING_STATION_ID
61 RADIUS_NAS_PORT_TYPE
64 RADIUS_TUNNEL_TYPE
65 RADIUS_TUNNEL_MEDIUM_TYPE
926 | Security
79 RADIUS_EAP_MSG
80 RADIUS_MSG_AUTHENTICATOR
81 RADIUS_TUNNEL_PRIVATE_GROUP_ID
95 NAS_IPv6_ADDRESS
RADIUS exec-authorization stores a user-shell profile and that is applied during user login. You may name
the relevant named-lists with either a unique name or the default name. When authorization is enabled by
the RADIUS server, the server returns the following information to the client:
• Idle time
• ACL configuration information
• Auto-command
• Privilege level
After gaining authorization for the first time, you may configure these attributes.
Note: RADIUS authentication/authorization is done for every login. There is no difference between
first-time login and subsequent logins.
Idle Time
Every session line has its own idle-time. If the idle-time value is not changed, the default value of 30
minutes is used. RADIUS specifies idle-time allow for a user during a session before timeout. When a user
logs in, the lower of the two idle-time values (configured or default) is used. The idle-time value is updated
if both of the following happens:
• The administrator changes the idle-time of the line on which the user has logged in
• The idle-time is lower than the RADIUS-returned idle-time
ACL
The RADIUS server can specify an ACL. If an ACL is configured on the RADIUS server, and if that ACL
is present, user may be allowed access based on that ACL. If the ACL is absent, authorization fails, and a
message is logged indicating the this.
RADIUS can specify an ACL for the user if both of the following are true:
• If an ACL is absent
• There is a very long delay for an entry, or a denied entry because of an ACL, and a message is logged
Note: The ACL name must be a string. Only standard ACLs in authorization (both RADIUS and TACACS)
are supported. Authorization is denied in cases using Extended ACLs.
Security | 927
Auto-command
www.dell.com | support.dell.com
You can configure the system through the RADIUS server to automatically execute a command when you
connect to a specific line. To do this, use the command auto-command. The auto-command is executed
when the user is authenticated and before the prompt appears to the user.
Through the RADIUS server, you can use the command privilege level to configure a privilege level for the
user to enter into when they connect to a session.This value is configured on the client system.
For a complete listing of all FTOS commands related to RADIUS, refer to the Security chapter in the
FTOS Command Reference.
Note: RADIUS authentication and authorization are done in a single step. Hence, authorization cannot be
used independent of authentication. However, if RADIUS authorization is configured and authentication is
not, then a message is logged stating this. During authorization, the next method in the list (if present) is
used, or if another method is not present, an error is reported.
To view the configuration, use the show config in the LINE mode or the show running-config command in
the EXEC Privilege mode.
To configure RADIUS to authenticate or authorize users on the system, you must create a AAA method
list. Default method lists do not need to be explicitly applied to the line, so they are not mandatory. To
create a method list, enter one of the following commands in CONFIGURATION mode:
aaa authentication login CONFIGURATION Enter a text string (up to 16 characters long) as the name
method-list-name radius of the method list you wish to use with the RADIUS
authentication method.
928 | Security
Command Syntax Command Mode Purpose
aaa authorization exec CONFIGURATION Create methodlist with RADIUS and TACACS+ as
{method-list-name | default} radius authorization methods. Typical order of methods:
tacacs+ RADIUS, TACACS+, Local, None. If authorization is
denied by RADIUS, the session ends (radius should not
be the last method specified).
To enable RADIUS AAA login authentication for a method list, you must apply it to a terminal line. To
configure a terminal line for RADIUS authentication and authorization, enter the following commands:
line {aux 0 | console 0 | vty number CONFIGURATION Enter the LINE mode.
[end-number]}
login authentication {method-list-name | LINE Enable AAA login authentication for the specified
default} RADIUS method list. This procedure is mandatory if
you are not using default lists.
When configuring a RADIUS server host, you can set different communication parameters, such as the
UDP port, the key password, the number of retries, and the timeout.
To specify a RADIUS server host and configure its communication parameters, use the following
command in the CONFIGURATION mode:
radius-server host {hostname | CONFIGURATION Enter the host name or IP address of the RADIUS server
ipv4-address | ipv6-address} host. Configure the optional communication parameters
[auth-port port-number] [retransmit for the specific host:
retries] [timeout seconds] [key • auth-port port-number range: 0 to 65335. Enter a
[encryption-type] key] UDP port number. The default is 1812.
• retransmit retries range: 0 to 100. Default is 3.
• timeout seconds range: 0 to 1000. Default is 5
seconds.
• key [encryption-type] key: Enter 0 for plain text or 7
for encrypted text, and a string for the key. The key
can be up to 42 characters long. This key must match
the key configured on the RADIUS server host.
If these optional parameters are not configured, the
global default values for all RADIUS host are applied.
Security | 929
To specify multiple RADIUS server hosts, configure the radius-server host command multiple times. If
www.dell.com | support.dell.com
multiple RADIUS server hosts are configured, FTOS attempts to connect with them in the order in which
they were configured. When FTOS attempts to authenticate a user, the software connects with the
RADIUS server hosts one at a time, until a RADIUS server host responds with an accept or reject
response.
If you want to change an optional parameter setting for a specific host, use the radius-server host
command. To change the global communication settings to all RADIUS server hosts, refer to Set global
communication parameters for all RADIUS server hosts on page 930.
To view the RADIUS configuration, use the show running-config radius command in the EXEC Privilege
mode.
To delete a RADIUS server host, use the no radius-server host {hostname | ip-address} command.
You can configure global communication parameters (auth-port, key, retransmit, and timeout parameters)
and specific host communication parameters on the same system. However, if both global and specific host
parameters are configured, the specific host parameters override the global parameters for that RADIUS
server host.
To set global communication parameters for all RADIUS server hosts, use any or all of the following
commands in the CONFIGURATION mode:
radius-server deadtime seconds CONFIGURATION Set a time interval after which a RADIUS host
server is declared dead.
• seconds range: 0 to 2147483647.
Default: 0 seconds
radius-server key [encryption-type] key CONFIGURATION Configure a key for all RADIUS communications
between the system and RADIUS server hosts.
• encryption-type: Enter 7 to encrypt the
password. Enter 0 to keep the password as plain
text.
• key: Enter a string. The key can be up to 42
characters long. You cannot use spaces in the
key.
radius-server retransmit retries CONFIGURATION Configure the number of times FTOS retransmits
RADIUS requests.
• retries range: 0 to 100. Default is 3 retries.
radius-server timeout seconds CONFIGURATION Configure the time interval the system waits for a
RADIUS server host response.
• seconds range: 0 to 1000.
Default is 5 seconds.
930 | Security
To view the configuration of RADIUS communication parameters, use the show running-config command
in the EXEC Privilege mode.
Monitor RADIUS
To view information on RADIUS transactions, use the following command in the EXEC Privilege mode:
TACACS+
FTOS supports Terminal Access Controller Access Control System (TACACS+ client, including support
for login authentication.
For a complete listing of all commands related to TACACS+, refer to the Security chapter in the FTOS
Command Reference.
One of the login authentication methods available is TACACS+ and the user’s name and password are sent
for authentication to the TACACS hosts specified.To use TACACS+ to authenticate users, you must
specify at least one TACACS+ server for the system to communicate with and configure TACACS+ as one
of your authentication methods.
Security | 931
To select TACACS as the login authentication method, use these commands in the following sequence in
www.dell.com | support.dell.com
3 line {aux 0 | console 0 | vty number CONFIGURATION Enter the LINE mode.
[end-number]}
4 login authentication {method-list-name | LINE Assign the method-list to the terminal line.
default}
To view the configuration, use the show config in the LINE mode or the show running-config tacacs+
command in the EXEC Privilege mode.
If authentication fails using the primary method, FTOS employs the second method (or third method, if
necessary) automatically. For example, if the TACACS+ server is reachable, but the server key is invalid,
FTOS proceeds to the next authentication method. In Figure 45-4, the TACACS+ is incorrect, but the user
is still authenticated by the secondary method.
932 | Security
Figure 45-4. Failed Authentication
FTOS(conf)#
FTOS(conf)#do show run aaa
!
aaa authentication enable default tacacs+ enable
aaa authentication enable LOCAL enable tacacs+
aaa authentication login default tacacs+ local
aaa authentication login LOCAL local tacacs+
aaa authorization exec default tacacs+ none
aaa authorization commands 1 default tacacs+ none
aaa authorization commands 15 default tacacs+ none
aaa accounting exec default start-stop tacacs+
aaa accounting commands 1 default start-stop tacacs+
aaa accounting commands 15 default start-stop tacacs+
FTOS(conf)#
FTOS(conf)#do show run tacacs+
!
tacacs-server key 7 d05206c308f4d35b Server key purposely changed to incorrect value
tacacs-server host 10.10.10.10 timeout 1
FTOS(conf)#tacacs-server key angeline
FTOS(conf)#%RPM0-P:CP %SEC-5-LOGIN_SUCCESS: Login successful for user admin on vty0
(10.11.9.209)
%RPM0-P:CP %SEC-3-AUTHENTICATION_ENABLE_SUCCESS: Enable password authentication
success on vty0 ( 10.11.9.209 )
%RPM0-P:CP %SEC-5-LOGOUT: Exec session is terminated for user admin on line vty0
(10.11.9.209)
FTOS(conf)#username angeline password angeline
FTOS(conf)#%RPM0-P:CP %SEC-5-LOGIN_SUCCESS: Login successful for user angeline on
vty0 (10.11.9.209)
%RPM0-P:CP %SEC-3-AUTHENTICATION_ENABLE_SUCCESS: Enable password authentication
success on vty0 ( 10.11.9.209 ) User authenticated using secondary method
Monitor TACACS+
To view information on TACACS+ transactions, use the following command in the EXEC Privilege mode:
Security | 933
Figure 45-5 demonstrates how to configure the access-class from a TACACS+ server. This causes the
www.dell.com | support.dell.com
configured access-class on the VTY line to be ignored. If you have configured a deny10 ACL on the
TACACS+ server, FTOS downloads it and applies it. If the user is found to be coming from the 10.0.0.0
subnet, FTOS also immediately closes the Telnet connection. Note, that no matter where the user is coming
from, they see the login prompt.
FTOS#
FTOS(conf)#
FTOS(conf)#ip access-list standard deny10
FTOS(conf-ext-nacl)#permit 10.0.0.0/8
FTOS(conf-ext-nacl)#deny any
FTOS(conf)#
FTOS(conf)#aaa authentication login tacacsmethod tacacs+
FTOS(conf)#aaa authentication exec tacacsauthorization tacacs+
FTOS(conf)#tacacs-server host 25.1.1.2 key force10
FTOS(conf)#
FTOS(conf)#line vty 0 9
FTOS(config-line-vty)#login authentication tacacsmethod
FTOS(config-line-vty)#authorization exec tacauthor
FTOS(config-line-vty)#
FTOS(config-line-vty)#access-class deny10
FTOS(config-line-vty)#end
When configuring a TACACS+ server host, you can set different communication parameters, such as the
the key password.
To specify a TACACS+ server host and configure its communication parameters, use the following
command in the CONFIGURATION mode:
tacacs-server host {hostname | CONFIGURATION Enter the host name or IP address of the TACACS+
ipv4-address | ipv6-address} [port server host. Configure the optional communication
port-number] [timeout seconds] [key parameters for the specific host:
key] • port port-number range: 0 to 65335. Enter a TCP
port number. The default is 49.
• timeout seconds range: 0 to 1000. Default is 10
seconds.
• key key: Enter a string for the key. The key can be up
to 42 characters long. This key must match a key
configured on the TACACS+ server host. This
parameter should be the last parameter configured.
If these optional parameters are not configured, the
default global values are applied.
To specify multiple TACACS+ server hosts, configure the tacacs-server host command multiple times. If
multiple TACACS+ server hosts are configured, FTOS attempts to connect with them in the order in which
they were configured.
To view the TACACS+ configuration, use the show running-config tacacs+ command in the EXEC
Privilege mode.
934 | Security
To delete a TACACS+ server host, use the no tacacs-server host {hostname | ip-address} command.
Command Authorization
The AAA command authorization feature configures FTOS to send each configuration command to a
TACACS server for authorization before it is added to the running configuration.
By default, the AAA authorization commands configure the system to check both EXEC mode and
CONFIGURATION mode commands. Use the command no aaa authorization config-commands to enable
only EXEC mode command checking.
If rejected by the AAA server, the command is not added to the running config, and messages similar to
Message 1 are displayed.
Security | 935
FTOS supports both inbound and outbound SSH sessions using IPv4 or IPv6 addressing. Inbound SSH
www.dell.com | support.dell.com
supports accessing the system through the management interface as well as through a physical Layer 3
interface.
For details on command syntax, see the Security chapter in the FTOS Command Line Interface Reference.
SCP is a remote file copy program that works with SSH and is supported by FTOS.
Note: The Windows-based WinSCP client software is not supported for secure copying between a PC
and an FTOS-based system. Unix-based SCP client software is supported.
To use the SSH client, use the following command in the EXEC Privilege mode:
ssh {hostname | hostip} [-l EXEC Privilege Open an SSH connection specifying the hostname or
username | -p port-number | -v {1 | hostip, username, port number, and version of the SSH
2} client.
hostip is the IP address of the remote device, which can
be an IPv4 address (A.B.C.D)or IPv6 address
(X:X:X:X::X).
To enable the SSH server for version 1 and 2, use the following command in the CONFIGURATION
mode:
ip ssh server {enable | port port-number} CONFIGURATION Configure the Dell Force10 system as an
SCP/SSH server.
To enable the SSH server for version 1 or 2 only, use the following command:
ip ssh server version {1|2} CONFIGURATION Configure the Dell Force10 system as an SSH server that
uses only version 1 or 2.
To view the SSH configuration, use the following command in EXEC Privilege mode:
Figure 45-6 on page 937 shows the use of the command ip ssh server version 2 to enable SSH version 2,
and the show ip ssh command to confirm the setting.
936 | Security
Figure 45-6. Specifying an SSH version
1 On Chassis One, set the SSH port ip ssh server port number
CONFIGURATION
number (port 22 by default).
This example shows the use of SCP and SSH to copy a software image from one switch running SSH
Server on UDP port 99 to the local switch:
Figure 45-7. Using SCP to copy from an SSH Server on another Switch
Security | 937
• ip ssh connection-rate-limit: Configure the maximum number of incoming SSH connections per
www.dell.com | support.dell.com
minute.
• ip ssh hostbased-authentication enable: Enable hostbased-authentication for the SSHv2 server.
• ip ssh key-size: Configure the size of the server-generated RSA SSHv1 key.
• ip ssh password-authentication enable: Enable password authentication for the SSH server.
• ip ssh pub-key-file: Specify the file to be used for host-based authentication.
• ip ssh rhostsfile: Specify the rhost file to be used for host-based authorization.
• ip ssh rsa-authentication enable: Enable RSA authentication for the SSHv2 server.
• ip ssh rsa-authentication: Add keys for the RSA authentication.
• show crypto: Display the public part of the SSH host-keys.
• show ip ssh client-pub-keys: Display the client public keys used in host-based authentication.
• show ip ssh rsa-authentication: Display the authorized-keys for the RSA authentication.
• ssh-peer-rpm: Open an SSH connection to the peer RPM.
Authenticate an SSH client by prompting for a password when attempting to connect to the Dell Force10
system. This is the simplest methods of authentication and uses SSH version 1.
Enable SSH password authentication using the command ip ssh password-authentication enable from
CONFIGURATION mode. View your SSH configuration using the command show ip ssh from EXEC
Privilege mode.
938 | Security
Figure 45-8. Enabling SSH Password Authentication
FTOS(conf)#ip ssh server enable
% Please wait while SSH Daemon initializes ... done.
FTOS(conf)#ip ssh password-authentication enable
FTOS#sh ip ssh
SSH server : enabled.
Password Authentication : enabled.
Hostbased Authentication : disabled.
RSA Authentication : disabled.
1 On the SSH client (Unix machine), generate an RSA key, as shown in Figure 45-9.
Figure 45-9. Generating RSA Keys
admin@Unix_client#ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/admin/.ssh/id_rsa):
/home/admin/.ssh/id_rsa already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/admin/.ssh/id_rsa.
Your public key has been saved in /home/admin/.ssh/id_rsa.pub.
5 Bind the public keys to RSA authentication. ip ssh rsa-authentication EXEC Privilege
my-authorized-keys flash://
public_key
Security | 939
To configure host-based authentication:
www.dell.com | support.dell.com
3 Create a list of IP addresses and usernames that are permitted to SSH in a file called rhosts, as shown in
Figure 45-11.
Figure 45-11. Creating rhosts
admin@Unix_client# ls
id_rsa id_rsa.pub rhosts shosts
admin@Unix_client# cat rhosts
10.16.127.201 admin
4 Copy the file shosts and rhosts to the Dell Force10 system.
SSH from the chassis to the SSH client using using the command ssh ip_address. This method uses SSH
version 1 or version 2. If the SSH port is a non-default value, use the command ip ssh server port number,
to change the default port number. You may only change the port number when SSH is disabled. When
must then still use the -p option with the command ssh.
940 | Security
Figure 45-12. Client-based SSH Authentication
FTOS#ssh 10.16.127.201 ?
-l User name option
-p SSH server port option (default 22)
-v SSH protocol version
Troubleshooting SSH
• You may not bind id_rsa.pub to RSA authentication while logged in via the console. In this case,
Message 2 appears.
• Host-based authentication must be enabled on the server (Dell Force10 system) and the client (Unix
machine). Message 3 appears if you attempt to log in via SSH and host-based is disabled on the client.
In this case, verify that host-based authentication is set to “Yes” in the file ssh_config (root permission
is required to edit this file).
• If the IP address in the RSA key does not match the IP address from which you attempt to log in,
Message 4 appears. In this case, verify that the name and IP address of the client is contained in the file
/etc/hosts.
Telnet
To use Telnet with SSH, you must first enable SSH, as described above.
By default, the Telnet daemon is enabled. If you want to disable the Telnet daemon, use the following
command, or disable Telnet in the startup config.
Use the [no] ip telnet server enable command to enable or disable the Telnet daemon.
Security | 941
Trace Lists
www.dell.com | support.dell.com
In the E-Series, you can create a trace filter based on any of the following criteria:
• Source IP address
• Destination IP address
• Source TCP port number
• Destination TCP port number
• Source UDP port number
• Destination UDP port number
For trace lists, you can match criteria on specific or ranges of TCP or UDP ports or established TCP
sessions.
Note: If there are unresolved next-hops and a trace-list is enabled, there is a possibility that the traffic
hitting the CPU will not be rate-limited.
When creating a trace list, the sequence of the filters is important. You have a choice of assigning sequence
numbers to the filters as you enter them, or FTOS assigns numbers in the order the filters were created. For
more information on sequence numbering, refer to Chapter 21, IP Access Control Lists, Prefix Lists, and
Route-maps, on page 419.
For a complete listing of all commands related to trace lists, refer to the Security chapter in the FTOS
Command Reference.
Trace lists filter and log traffic based on source and destination IP addresses, IP host addresses, TCP
addresses, TCP host addresses, UDP addresses, and UDP host addresses. When configuring the Trace list
filters, include the count and bytes parameters so that any hits to that filter are logged.
942 | Security
Since traffic passes through the filter in the order of the filter’s sequence, you can configure the trace list by
first entering the TRACE LIST mode and then assigning a sequence number to the filter.
To create a filter for packets with a specified sequence number, use these commands in the following
sequence, starting in the CONFIGURATION mode:
2 seq sequence-number {deny | permit} {ip TRACE LIST Configure a drop or forward filter.
| ip-protocol-number} {source mask | any | Configure the following required and
host ip-address} {destination mask | any | optional parameters:
host ip-address} [count [byte] | log] • sequence-number range: 0 to,
4294967290.
• ip: to specify IP as the protocol to filter
for.
• ip-protocol-number range: 0 to 255.
• source: An IP address as the source IP
address for the filter to match.
• mask: a network mask
• any: to match any IP source address
• host ip-address: to match IP addresses
in a host.
• destination: An IP address as the source
IP address for the filter to match.
• count: count packets processed by the
filter.
• byte: count bytes processed by the
filter.
• log: is supported.
To create a filter for TCP packets with a specified sequence number, use these commands in the following
sequence, starting in the CONFIGURATION mode:
Security | 943
www.dell.com | support.dell.com
2 seq sequence-number {deny | permit} tcp TRACE LIST Configure a trace list filter for TCP
{source mask | any | host ip-address} packets.
[operator port [port]] {destination mask | • source: An IP address as the source IP
any | host ip-address} [operator port address for the filter to match.
[port]] [established] [count [byte] | log] • mask: a network mask
• any: to match any IP source address
• host ip-address: to match IP addresses
in a host.
• destination: An IP address as the source
IP address for the filter to match.
• count: count packets processed by the
filter.
• byte: count bytes processed by the
filter.
• log: is supported.
To create a filter for UDP packets with a specified sequence number, use these commands in the following
sequence, starting in the CONFIGURATION mode:
2 seq sequence-number {deny | permit} TRACE LIST Configure a trace list filter for UDP
udp {source mask | any | host ip-address} packets.
[operator port [port]] {destination mask | • source: An IP address as the source IP
any | host ip-address} [operator port address for the filter to match.
[port]] [count [byte] | log] • mask: a network mask
• any: to match any IP source address
• host ip-address: to match IP addresses
in a host.
• destination: An IP address as the source
IP address for the filter to match.
• count: count packets processed by the
filter.
• byte: count bytes processed by the
filter.
• log: is supported.
When you create the filters with a specific sequence number, you can create the filters in any order and the
filters are placed in the correct order.
Note: When assigning sequence numbers to filters, keep in mind that you might need to insert a
new filter. To prevent reconfiguring multiple filters, assign sequence numbers in multiples of five or
another number.
Figure 45-13 illustrates how the seq command orders the filters according to the sequence number
assigned. In the example, filter 15 was configured before filter 5, but the show config command displays
the filters in the correct order.
944 | Security
Figure 45-13. Trace list Using seq Command Example
If you are creating a Trace list with only one or two filters, you can let FTOS assign a sequence number
based on the order in which the filters are configured. FTOS assigns filters in multiples of 5.
To configure a filter for a Trace list without a specified sequence number, use any or all of the following
commands in the TRACE LIST mode:
{deny | permit} {ip | ip-protocol-number} {source TRACE LIST Configure a deny or permit filter to
mask | any | host ip-address} {destination mask | any examine IP packets. Configure the
| host ip-address} [count [byte] | log] following required and optional
parameters:
• ip: to specify IP as the protocol to
filter for.
• ip-protocol-number range: 0 to 255.
• source: An IP address as the source IP
address for the filter to match.
• mask: a network mask
• any: to match any IP source address
• host ip-address: to match IP addresses
in a host.
• destination: An IP address as the
source IP address for the filter to
match.
• count: count packets processed by the
filter.
• byte: count bytes processed by the
filter.
• log: is supported.
Security | 945
www.dell.com | support.dell.com
{deny | permit} tcp {source mask | any | host TRACE LIST Configure a deny or permit filter to
ip-address} [operator port [port]] {destination mask | examine TCP packets. Configure the
any | host ip-address} [operator port [port]] following required and optional
[established] [count [byte] | log] parameters:
• source: An IP address as the source IP
address for the filter to match.
• mask: a network mask
• any: to match any IP source address
• host ip-address: to match IP addresses
in a host.
• destination: An IP address as the
source IP address for the filter to
match.
• precedence precedence range: 0 to 7.
• tos tos-value range: 0 to 15
• count: count packets processed by the
filter.
• byte: count bytes processed by the
filter.
• log: is supported.
{deny | permit} udp {source mask | any | host TRACE LIST Configure a deny or permit filter to
ip-address} [operator port [port]] {destination mask | examine UDP packets. Configure the
any | host ip-address} [operator port [port]] | log] following required and optional
parameters:
• source: An IP address as the source IP
address for the filter to match.
• mask: a network mask
• any: to match any IP source address
• host ip-address: to match IP addresses
in a host.
• destination: An IP address as the
source IP address for the filter to
match.
• precedence precedence range: 0 to 7.
• tos tos-value range: 0 to 15
• count: count packets processed by the
filter.
• byte: count bytes processed by the
filter.
• log: is supported.
Figure 45-14 illustrates a Trace list in which the sequence numbers were assigned by the software. The
filters were assigned sequence numbers based on the order in which they were configured (for example,
the first filter was given the lowest sequence number). The show config command in the TRACE LIST
mode displays the two filters with the sequence numbers 5 and 10.
946 | Security
Figure 45-14. Trace List Example
To view all configured Trace lists and the number of packets processed through the Trace list, use the show
ip accounting trace-list command (Figure 110) in the EXEC Privilege mode.
After you create a Trace list, you must enable it. Without enabling the Trace list, no traffic is filtered.
To enable a Trace list, use the following command in the CONFIGURATION mode:
Once the Trace list is enabled, you can view its log with the show ip accounting trace-list trace-list-name
[linecard number] command.
Figure 45-15. show ip accounting trace-list Command Example
FTOS#show ip accounting trace-list dilling
Trace List dilling on linecard 0
seq 2 permit ip host 10.1.0.0 any count (0 packets)
seq 5 deny ip any any
FTOS#
Security | 947
VTY Line and Access-Class Configuration
www.dell.com | support.dell.com
Various methods are available to restrict VTY access in FTOS. These depend on which authentication
scheme you use — line, local, or remote:
Username
VTY access-class access-class
Authentication Method support? support? Remote authorization support?
Line YES NO NO
Local NO YES NO
TACACS+ YES NO YES (with FTOS 5.2.1.0 and later)
RADIUS YES NO YES (with FTOS 6.1.1.0 and later)
FTOS provides several ways to configure access classes for VTY lines, including:
• VTY Line Local Authentication and Authorization on page 948
• VTY Line Remote Authentication and Authorization on page 949
Line authentication can be assigned on a per-VTY basis; it is a simple password authentication, using an
access-class as authorization.
Local authentication is configured globally. You configure access classes on a per-user basis.
FTOS can assign different access classes to different users by username. Until users attempt to log in,
FTOS does not know if they will be assigned a VTY line. This means that incoming users always see a
login prompt even if you have excluded them from the VTY line with a deny-all access class. Once users
identify themselves, FTOS retrieves the access class from the local database and applies it. (FTOS also
subsequently can close the connection if a user is denied access).
Figure 45-16 shows how to allow or deny a Telnet connection to a user. Users will see a login prompt, even
if they cannot login. No access class is configured for the VTY line. It defaults from the local database.
948 | Security
Figure 45-16. Example Access-Class Configuration Using Local Database
Note: See also the section Chapter 8, IP Access Control Lists (ACL), Prefix Lists, and Route-maps.
The Dell Force10 OS takes the access class from the VTY line and applies it to ALL users. FTOS does not
need to know the identity of the incoming user and can immediately apply the access class. If the
authentication method is radius, TACACS+, or line, and you have configured an access class for the VTY
line, FTOS immediately applies it. If the access-class is deny all or deny for the incoming subnet, FTOS
closes the connection without displaying the login prompt. Figure shows how to deny incoming
connections from subnet 10.0.0.0 without displaying a login prompt. The example uses TACACS+ as the
authentication mechanism.
Figure 45-17. Example Access Class Configuration Using TACACS+ Without Prompt
To apply a MAC ACL on a VTY line, use the same access-class command as IP ACLs (Figure 45-18).
Figure 45-18 shows how to deny incoming connections from subnet 10.0.0.0 without displaying a login
prompt..
Security | 949
Figure 45-18. Example Access Class Configuration Using TACACS+ Without Prompt
www.dell.com | support.dell.com
950 | Security
46
Service Provider Bridging
Service Provider Bridging is supported on platforms: ces
This chapter contains the following major sections:
• VLAN Stacking on page 951
• VLAN Stacking Packet Drop Precedence on page 962
• Dynamic Mode CoS for VLAN Stacking on page 965
• Layer 2 Protocol Tunneling on page 967
• Provider Backbone Bridging on page 971
VLAN Stacking
VLAN Stacking is supported on platforms:ces
VLAN Stacking is supported on E-Series ExaScale ex with FTOS 8.2.1.0. and later.
VLAN Stacking, also called Q-in-Q, is defined in IEEE 802.1ad—Provider Bridges, which is an
amendment to IEEE 802.1Q—Virtual Bridged Local Area Networks. It enables service providers to use
802.1Q architecture to offer separate VLANs to customers with no coordination between customers, and
minimal coordination between customers and the provider.
Using only 802.1Q VLAN tagging all customers would have to use unique VLAN IDs to ensure that traffic
is segregated, and customers and the service provider would have to coordinate to ensure that traffic
mapped correctly across the provider network. Even under ideal conditions, customers and the provider
would still share the 4094 available VLANs.
Instead, 802.1ad allows service providers to add their own VLAN tag to frames traversing the provider
network. The provider can then differentiate customers even if they use the same VLAN ID, and providers
can map multiple customers to a single VLAN to overcome the 4094 VLAN limitation. Forwarding
decisions in the provider network are based on the provider VLAN tag only, so the provider can map traffic
through the core independently; the customer and provider need only coordinate at the provider edge.
frame before the 802.1Q tag. From this point, the frame is double-tagged. The service provider uses the
S-Tag, to forward the frame traffic across its network. At the egress edge, the provider removes the S-Tag,
so that the customer receives the frame in its original condition (Figure 46-1).
tagged 100
1 00
AN
VL
AN
VL
trunk port
10
0
100
VLAN
VLAN 300
00
N1
VLA VL
AN
20
0
access port
tagged 100
TE
IN
RN Rw / V
ET ID E LAN G
S E RV I C E P R O V S TA C KI N
A trunk port is a port on a service provider bridge that connects to another service provider bridge and is
a member of multiple service provider VLANs.
1 Assign the role of access port to a Layer 2 port on a provider vlan-stack access INTERFACE
bridge that is connected to a customer.
2 Assign the role of trunk port to a Layer 2 port on a provider vlan-stack trunk INTERFACE
bridge that is connected to another provider bridge.
3 Assign all access ports and trunk ports to service provider member INTERFACE VLAN
VLANs.
Display the status and members of a VLAN using the show vlan command from EXEC Privilege mode.
Members of a VLAN-Stacking-enabled VLAN are marked with an M in column Q.
Configure the Protocol Type Value for the Outer VLAN Tag
The Tag Protocol Identifier (TPID) field of the S-Tag is user-configurable:
Display the S-Tag TPID for a VLAN using the command show running-config from EXEC privilege
mode. FTOS displays the S-Tag TPID only if it is a non-default value.
You can enable trunk ports to carry untagged, single-tagged, and double-tagged VLAN traffic by making
the trunk port a hybrid port.
1 Configure a trunk port to carry untagged, single-tagged, and portmode hybrid INTERFACE
double-tagged traffic by making it a hybrid port.
Note: Note: On the C-Series and S-Series, a trunk port
can be added to an 802.1Q VLAN as well as a Stacking
VLAN only when the TPID 0x8100.
2 Add the port to a 802.1Q VLAN as tagged or untagged. [tagged | untagged] INTERFACE VLAN
In Figure 46-5 GigabitEthernet 0/1 a trunk port that is configured as a hybrid port and then added to VLAN
100 as untagged VLAN 101 as tagged, and VLAN 103, which is a stacking VLAN.
Figure 46-5. Hybrid Port as VLAN-Stack Trunk Port and as Member of other VLANs
FTOS(conf)#int gi 0/1
FTOS(conf-if-gi-0/1)#portmode hybrid
FTOS(conf-if-gi-0/1)#switchport
FTOS(conf-if-gi-0/1)#vlan-stack trunk
FTOS(conf-if-gi-0/1)#show config
!
interface GigabitEthernet 0/1
no ip address
portmode hybrid
switchport
vlan-stack trunk
shutdown
FTOS(conf-if-gi-0/1)#interface vlan 100
FTOS(conf-if-vl-100)#untagged gigabitethernet 0/1
FTOS(conf-if-vl-100)#interface vlan 101
FTOS(conf-if-vl-101)#tagged gigabitethernet 0/1
FTOS(conf-if-vl-101)#interface vlan 103
FTOS(conf-if-vl-103)#vlan-stack compatible
FTOS(conf-if-vl-103-stack)#member gigabitethernet 0/1
FTOS(conf-if-vl-103-stack)#do show vlan
The first field in the VLAN tag is the Tag Protocol Identifier (TPID), which is two bytes. In a
VLAN-stacking network, once the frame is double tagged, the outer tag TPID must match the TPID of the
next-hop system.
While 802.1Q requires that the inner tag TPID is 0x8100, it does not require a specific value for the outer
tag TPID. Systems may use any two-byte value; FTOS uses 0x9100 (Figure 46-6) while non-Dell Force10
systems might use a different value.
If the next-hop system’s TPID does not match the outer-tag TPID of the incoming frame, the system drops
the frame. For example, in Figure 46-6, the frame originating from Building A is tagged VLAN RED, and
then double-tagged VLAN PURPLE on egress at R4. The TPID on the outer tag is 0x9100. R2’s TPID
must also be 0x9100, and it is, so R2 forwards the frame.
Given the matching-TPID requirement, there are limitations when you employ Dell Force10 systems at
network edges, at which, frames are either double tagged on ingress (R4) or the outer tag is removed on
egress (R3).
The default TPID for the outer VLAN tag is 0x9100. Although the TPID field is 16 bits, E-Series
TeraScale only uses the first eight to make forwarding decisions, and as such makes no distinction between
0x8100 and any other TPID beginning with 0x81, for example, 0x8181. You can configure the first eight
bits of the TPID using the command vlan-stack protocol-type command. In Figure 46-6, the frame
originating from Building C is tagged 0x9191 on egress of R1. R2’s TPID is 0x9100, but it its an E-Series
TeraScale system and makes no distinction between 0x9191 and 0x9100, so it forwards the frame.
Building D
LUE
CE PROVIDER
RVI
NB
SE
VLA
ET
TPID 0x9191
RN
INTE
D
PURPLE VLAN RE
VLAN GREEN, VLAN
VLAN GREEN
UE
N BL R3-E-Series TeraScale
VLA R2-E-Series TeraScale VL
AN TPID: 0x9100
TPID: 0x9100
PU
R1-E-Series TeraScale
TPID: 0x9191 RP Building B
LE
TPID PCP CFI VID TPID PCP CFI VID
(0x9100) (0) (VLAN Purple) (0x8100) (0) (VLAN Red)
Building C R4
R4-Non-Force10 System
VL
TPID PCP CFI VID
TPID: 0x9100 (0x8100) (0) (VLAN Red)
AN
RE
D
Building A
E-Series TeraScale treats TPID 0x8100 as a normal VLAN even when on the outer tag. E-Series TeraScale
makes forwarding decisions based strictly on the protocol type, without regard for whether the port is an
access port. Therefore, when the outer tag has TPID 0x8100, the system does not remove it from frames
egressing an access port. Still, although the frames cannot be decapsulated, the system is able to switch
them. In Figure 46-7, the frame originating from Building A is double tagged on egress at R4 and is
switched towards Building B, but is not decapsulated on egress at R2 because its TPID is 0x8181.
FTOS Behavior: The E-Series ExaScale and TeraScale forward frames with TPID 0x8100 even when
its own TPID is not 0x8100. This behavior is required to service ARP and PVST packets, which use
TPID 0x8100.
Building D
LUE
CE PROVIDER
RVI
TPID 0x8100
NB
SE
VLA
ET
TPID 0x9100
X
RN
INTE
ED
PURPLE VLAN R
X
VLAN GREEN, VLAN
VLAN GREEN
UE
N BL R3-E-Series TeraScale
VLA R2-E-Series TeraScale VL
AN TPID: 0x8181
TPID: 0x8181
PU
R1-E-Series TeraScale
TPID: 0x9100 RP Building B
LE
TPID PCP CFI VID TPID PCP CFI VID
(0x8100) (0) (VLAN Purple) (0x8100) (0) (VLAN Red)
Building C
R4-Non-Force10 System
VL
TPID PCP CFI VID
TPID: 0x8100 (0x8100) (0) (VLAN Red)
AN
RE
D
Building A
E-Series ExaScale, beginning with FTOS version 8.2.1.0, allows you to configure both bytes of the 2-byte
TPID. TeraScale systems allow you to configure the first byte only and thus, the system did not
differentiate between TPIDs with a common first byte. For example 0x9100 and 0x91A8 were treated as
the same TPID. In Figure 46-6, R2 forwards the frame with TPID 0x9191 which originated from Building
C. In contrast, R2 drops the frame with TPID 0x9191 originating from Building C in Figure 46-8 because
the frames TPID does not match both bytes of its own TPID.
FTOS Behavior: The E-Series ExaScale and TeraScale forwards frames with TPID 0x8100 even
when its own TPID is not 0x8100. This behavior is required to service ARP and PVST packets, which
use TPID 0x8100.
Building D
LUE
CE PROVIDER
RVI
NB
SE
VLA
ET
TPID 0x9191
RN
INTE
ED
PURPLE VLAN R
VLAN GREEN, VLAN
VLA
N BL
UE
VLAN GREEN
X
R2-E-Series ExaScale VL
AN
TPID: 0x9100
R1-E-Series TeraScale PU
TPID: 0x9191 RP
LE
Building C
VL
AN
RE
D
Table 46-1 details the outcome of matched and mis-matched TPIDs in a VLAN-stacking network with the
E-Series.
The default TPID for the outer VLAN tag is 0x9100. Beginning with FTOS version 8.2.1.0, both the
C-Series and S-Series allow you to configure both bytes of the 2-byte TPID. Previous versions allowed
you to configure the first byte only, and thus, the systems did not differentiate between TPIDs with a
common first byte. For example 0x8100 and any other TPID beginning with 0x81 were treated as the same
TPID, as shown in Figure 46-9. Versions 8.2.1.0 and later differentiate between 0x9100 and 0x91XY, as
shown in Figure 46-11.
The TPID on the C-Series and S-Series systems is global. Ingress frames that do not match the system
TPID are treated as untagged. This rule applies for both the outer tag TPID of a double-tagged frame and
the TPID of a single-tagged frame.
For example, if you configure TPID 0x9100, then the system treats 0x8100 and untagged traffic the same
and maps both types to the default VLAN, as shown by the frame originating from Building C in
Figure 46-11. For the same traffic types, if you configure TPID 0x8100, then the system is able to
differentiate between 0x8100 and untagged traffic and maps each to the appropriate VLAN, as shown by
the packet originating from Building A in Figure 46-11.
Therefore, a mismatched TPID results in the port not differentiating between tagged and untagged traffic.
Figure 46-9. Single and Double-tag TPID Match on the C-Series and S-Series
Building D
LUE
NB
VLA
TPID 0x8100
R2-C-Series
TPID: 0x8100 ED
Building C VLAN GREEN, VLAN
PURPLE VLAN R
VLAN GREEN
UE
N BL R3-C-Series
VLA VL TPID: 0x8100
AN
R1-C-Series
TPID: 0x8100
PU
RP Building B
LE
TPID PCP CFI VID TPID PCP CFI VID
(0x8100) (0) (VLAN Purple) (0x8100) (0) (VLAN Red)
R4-Non-Force10 System
TPID: 0x8100
IN
TE
RN
ET S ER
TPID PCP CFI VID
E R V I C E P R O VID
VL
Building A
DEFAULT VLAN
LUE
NB
VLA
TPID 0x8181
R2-C-Series w/ FTOS <8.2.1.0
TPID: 0x8181 ED
PURPLE VLAN R
VLAN GREEN, VLAN
VLAN GREEN
UE DEFAULT VLAN
N BL R3-C-Series w/ FTOS >=8.2.1.0
VLA VL TPID: 0x8181
AN
R1-C-Series w/ FTOS <8.2.1.0
TPID: 0x8181
PU
RP Building B
LE
R4-Non-Force10 System
TPID: 0x8100
IN
TE
RN
ET S ER
TPID PCP CFI VID
E R V I C E P R O VID
VL
(0x8100) (0) (VLAN Red)
AN
RE
D
Building A
Figure 46-11. Single and Double-tag TPID Mismatch on the C-Series and S-Series
DEFAULT VLAN
Building D
LUE
DEFAULT VLAN
NB
VLA
VLA
R4-Non-Force10 System
TPID: 0x8181
IN
TE
RN R4
ET S ER
TPID PCP CFI VID
E R V I C E P R O VID
VL
Building A
Make packets eligible for dropping based on their DEI value. By dei enable CONFIGURATION
default, packets are colored green, and DEI is marked 0 on egress.
When Drop Eligibility is enabled, DEI mapping or marking takes place according to the defaults. In this
case, the CFI is affected according to Table 46-3.
Precedence Description
Green High priority packets that are the least preferred to be dropped.
Yellow Lower priority packets that are treated as best-effort.
Red Lowest priority packets that are always dropped (regardless of
congestion status).
Honor the incoming DEI value by mapping it to an dei honor {0 | 1} {green | red | yellow} INTERFACE
FTOS drop precedence. You may enter the
command once for 0 and once for 1. Packets with an
unmapped DEI value are colored green.
Display the DEI-honoring configuration. show interface dei-honor [interface slot/ EXEC Privilege
port | linecard number port-set number]
Set the DEI value on egress according to the color dei mark {green | yellow} {0 | 1} INTERFACE
currently assigned to the packet.
Display the DEI-marking configuration. show interface dei-mark [interface slot/ EXEC Privilege
port | linecard number port-set number]
Figure 46-12. Statically and Dynamically Assigned dot1p for VLAN Stacking
S-Tag
DATA 0x0800 SA DA DATA 0x0800 1 400 0x9100 SA DA
a mark the S-Tag dot1p and queue the frame according to the original C-Tag dot1p. In this case, you
must have other dot1p QoS configurations; this option is classic dot1p marking.
b mark the S-Tag dot1p and queue the frame according to the S-Tag dot1p. For example, if frames
with C-Tag dot1p values 0, 6 and 7 are mapped to an S-Tag dot1p value 0, then all such frames are
sent to the queue associated with the S-Tag 802.1p value 0. This option requires two different
CAM entries, each in a different Layer 2 ACL FP block.
Note: The ability to map incoming C-Tag dot1p to any S-Tag dot1p requires up to 8 entries to be installed
in the Layer 2 QoS and Layer 2 ACL table for each configured customer VLAN. The scalability of this
feature is limited by the impact of the 1:8 expansion in these CAM tables.
Dynamic Mode CoS (vlan-stack dot1p-mapping) and a QoS configuration, the queue selected by
Dynamic Mode CoS takes precedence. However, rate policing for the queue is determined by QoS
configuration. For example, the following access-port configuration maps all traffic to Queue 0:
policy-map-input in layer2
service-queue 3 class-map a qos-policy 3
!
class-map match-any a layer2
match mac access-group a
!
mac access-list standard a
seq 5 permit any
!
qos-policy-input 3 layer2
rate-police 40
Likewise, in the configuration below, packets with dot1p priority 0 – 3 are marked as dot1p 7
in the outer tag and queued to Queue 3. Rate policing is according to qos-policy-input 3. All
other packets will have outer dot1p 0 and hence are queued to Queue 1. They are therefore
policed according to qos-policy-input 1.
A policy map output with rate shape for different queues can also be used.
policy-map-input in layer2
service-queue 1 qos-policy 1
service-queue 3 qos-policy 3
!
qos-policy-input 1 layer2
rate-police 10
!
qos-policy-input 3 layer2
rate-police 30
!
interface GigabitEthernet 0/21
no ip address
switchport
vlan-stack access
vlan-stack dot1p-mapping c-tag-dot1p 0-3 sp-tag-dot1p 7
service-policy input in layer2
no shutdown
1 Allocate CAM space to enable queuing cam-acl l2acl number ipv4acl number CONFIGURATION
frames according to the C-Tag or the ipv6acl number ipv4qos number l2qos
S-Tag. number l2pt number ipmacacl number
vman-qos: mark the S-Tag dot1p and ecfmacl number {vman-qos |
queue the frame according to the original vman-qos-dual-fp} number
C-Tag dot1p. This method requires half as Default: 0 FP blocks for vman-qos and
many CAM entries as vman-qos-dual-fp. vman-qos-dual-fp
vman-qos-dual-fp: mark the S-Tag dot1p
and queue the frame according to the
S-Tag dot1p. This method requires twice
as many CAM entries as vman-qos and
FP blocks in multiples of 2.
2 The new CAM configuration is stored in copy running-config startup-config EXEC Privilege
NVRAM and takes effect only after a save reload
and reload.
3 Map C-Tag dot1p values to a S-Tag dot1p vlan-stack dot1p-mapping c-tag-dot1p INTERFACE
value. C-Tag values may be separated by values sp-tag-dot1p value
commas, and dashed ranges are permitted.
Dynamic Mode CoS overrides any Layer 2
QoS configuration in case of conflicts.
Note: Since dot1p-mapping marks and queues packets, the only remaining applicable QoS configuration
is rate metering. You may use Rate Shaping or Rate Policing.
EE
TR
EE
TR
NG
SPANNI
ING TREE
ANN Building B
SP
no spanning-tree VICE PROVIDER w/
R
SE no spanning-tree
T
E
ETWORK
RN
EN
RE
INTE
T
G
NIN
SPAN
X
BPDU w/ destination
MAC address: 01-80-C2-00-00-00
Building A
You might need to transport control traffic transparently through the intermediate network to the other
region. Layer 2 Protocol Tunneling enables BPDUs to traverse the intermediate network by identifying
frames with the Bridge Group Address, rewriting the destination MAC to a user-configured non-reserved
address, and forwarding the frames. Since the frames now use a unique MAC address, BPDUs are treated
as normal data frames by the switches in the intermediate network core. On egress edge of the intermediate
network, the MAC address rewritten to the original MAC address and forwarded to the opposing network
region (Figure 46-14).
FTOS Behavior: In FTOS versions prior to 8.2.1.0, the MAC address that Dell Force10 systems use to
overwrite the Bridge Group Address on ingress was non-configurable. The value of the L2PT MAC
address was the Force10-unique MAC address, 01-01-e8-00-00-00. As such, with these FTOS
versions, Dell Force10 systems are required at the egress edge of the intermediate network because
only FTOS could recognize the significance of the destination MAC address and rewrite it to the
original Bridge Group Address. In FTOS version 8.2.1.0 and later, the L2PT MAC address is
user-configurable, so you can specify an address that non-Dell Force10 systems can recognize and
rewrite the address at egress edge.
TR
NG
SPANNI
ING TREE BPDU w/ destination
ANN Building B
SP MAC address: 01-80-C2-00-00-00
ICE PROVIDER w/
no spanning-tree RV no spanning-tree
SE BPDU w/ destination
T
E MAC address: 01-01-e8-00-00-00
RN
E NETWORK
RE
INTE
T
G
NIN
SPAN
R2 R3
Non-Force10 Non-Force10
R1-E-Series System System
BPDU w/ destination
MAC address: 01-80-C2-00-00-00
Building A
Implementation Information
• L2PT is available for STP, RSTP, MSTP, and PVST+ BPDUs.
• No protocol packets are tunneled when VLAN Stacking is enabled.
• L2PT requires the default CAM profile.
1 Verify that the system is running the default CAM profile; show cam-profile EXEC Privilege
you must use this CAM profile for L2PT.
2 Enable protocol tunneling globally on the system. protocol-tunnel enable CONFIGURATION
Set a maximum rate at which the RPM will process BPDUs for protocol-tunnel rate-limit CONFIGURATION
L2PT.
Default: 75 pps
E-Series Range: 75 to 3000 pps
There are total 13 user-configurable FP blocks on the C-Series and S-Series. The default number of blocks
for L2PT is 0; you must allocate at least one to enable BPDU rate-limiting.
1 Create at least one FP group for L2PT. See cam-acl l2acl CONFIGURATION
CAM Allocation on page 289 for details on
this command.
4 Set a maximum rate at which the RPM will protocol-tunnel rate-limit VLAN STACKING
process BPDUs for L2PT.
Default: no rate limiting
C-Series Range: 64 to 640 kbps
S-Series Range: 64 to 320 kbps
802.1ad specifies that provider bridges operating Spanning Tree use a reserved destination MAC address
called the Provider Bridge Group Address, 01-80-C2-00-00-08, to exchange BPDUs instead of the Bridge
Group Address, 01-80-C2-00-00-00, originally specified in 802.1Q. Only bridges in the service provider
network use this destination MAC address so these bridges treat BPDUs originating from the customer
network as normal data frames, rather than consuming them.
destination MAC address called the Provider Bridge GVRP Address, 01-80-C2-00-00-0D, to exchange
GARP PDUs instead of the GVRP Address, 01-80-C2-00-00-21, specified in 802.1Q. Only bridges in the
service provider network use this destination MAC address so these bridges treat GARP PDUs originating
from the customer network as normal data frames, rather than consuming them.
Provider Backbone Bridging through IEEE 802.1ad eliminates the need for tunneling BPDUs with L2PT
and increases the reliability of provider bridge networks as the network core need only learn the MAC
addresses of core switches, as opposed to all MAC addresses received from attached customer devices.
Use the Provider Bridge Group address bpdu-destination-mac-address [stp | gvrp] CONFIGURATION
as the destination MAC address in provider-bridge-group
BPDUs. The xstp keyword applies this
functionality to STP, RSTP, and MSTP;
this functionality is not available for
PVST+.
Overview
FTOS supports sFlow version 5. sFlow is a standard-based sampling technology embedded within
switches and routers which is used to monitor network traffic. It is designed to provide traffic monitoring
for high speed networks with many switches and routers. sFlow uses two types of sampling:
The sFlow monitoring system consists of an sFlow Agent (embedded in the switch/router) and an sFlow
collector. The sFlow Agent resides anywhere within the path of the packet, and combines the flow samples
and interface counters into sFlow datagrams and forwards them to the sFlow Collector at regular intervals.
The datagrams consists of information on, but not limited to, packet header, ingress and egress interfaces,
sampling parameters, and interface counters.
Packet sampling is typically done by the ASIC. sFlow Collector analyses the sFlow datagrams received
from different devices and produces a network-wide view of traffic flows.
sFlow | 973
Figure 47-1. sFlow Traffic Monitoring System
www.dell.com | support.dell.com
sFlow Collector
sFlow Datagrams
Switch/Router
sFlow Agent
Poll Interface
Counters Interface Flow Samples
Counters
Switch ASIC
Implementation Information
Dell Force10 sFlow is designed so that the hardware sampling rate is per line card port-pipe and is decided
based upon all the ports in that port-pipe. If sFlow is not enabled on any port specifically, then the global
sampling rate is downloaded to that port and is to calculate the port-pipe’s lowest sampling rate. This
design supports, then, the possibility that sFlow might be configured on that port in the future. Back-off is
triggered based on the port-pipe’s hardware sampling rate.
For example, if port 1 in a the port-pipe has sFlow configured with a 16384 sampling rate while port 2 in
the port-pipe has sFlow configured but no sampling rate set, FTOS applies a global sampling rate of 512 to
port 2. The hardware sampling rate on the port-pipe is ten set at 512 because that is the lowest configured
rate on the port-pipe. When a high traffic situation occurs, a back-off is triggered and the hardware
sampling rate is backed-off from 512 to 1024. Note that port 1 maintains its sampling rate of 16384; port 1
is unaffected because it maintains its configured sampling rate of 16484.
To avoid the back-off, either increase the global sampling rate or configure all the line card ports with the
desired sampling rate even if some ports have no sFlow configured.
974 | sFlow
• FTOS exports all sFlow packets to the collector. A small sampling rate can equate to a large number of
exported packets. A backoff mechanism will automatically be applied to reduce this amount. Some
sampled packets may be dropped when the exported packet rate is high and the backoff mechanism is
about to or is starting to take effect. The dropEvent counter, in the sFlow packet, will always be zero.
• Community list and local preference fields are not filled in extended gateway element in sFlow
datagram.
• 802.1P source priority field is not filled in extended switch element in sFlow datagram.
• Only Destination and Destination Peer AS number are packed in the dst-as-path field in extended
gateway element
• If packet being sampled is redirected using PBR (Policy-Based Routing), sFlow datagram may contain
incorrect extended gateway/router information.
• Source VLAN field in the extended switch element will not be packed in case of routed packet.
• Destination VLAN field in the extended switch element will not be packed in case of Multicast packet.
• On the C-Series, Layer 3 and Layer 2 multicast traffic is not collected with sFlow sampling.
• On the S-Series, up to 700 packets can be sampled and processed per second.
• On the C-Series up to 1000 packets can be sampled and processed per second.
• On the E-Series, the maximum number of packets that can be sampled and processed per second is:
— 7500 packets when no extended information packing is enabled.
— 1000 packets when only extended-switch information packing is enabled.
— 1600 packets when extended-router and/or extended-gateway information packing is
enabled.
sFlow | 975
sFlow Show Commands
www.dell.com | support.dell.com
show sflow interface EXEC Display sFlow configuration information and statistics on a
interface-name specific interface.
Figure 47-3 is a sample output from the show sflow interface command.
976 | sFlow
Figure 47-3. Command Example: show sflow interface
FTOS#show sflow interface gigabitethernet 1/16
Gi 1/16
Configured sampling rate :8192
Actual sampling rate :8192
Sub-sampling rate :2
Counter polling interval :15
Samples rcvd from h/w :33
Samples dropped for sub-sampling :6
The configuration, shown in Figure 47-2, is also displayed in the running configuration (Figure 47-4):
Figure 47-4. Command Example: show running-config interface
FTOS#show running-config interface gigabitethernet 1/16
!
interface GigabitEthernet 1/16
no ip address
mtu 9252
ip mtu 9234
switchport
sflow enable
sflow sample-rate 8192
no shutdown
show sflow linecard slot-number EXEC Display sFlow configuration information and statistics on
the specified interface.
Figure 47-5 is a sample output from the show sflow linecard command:
Figure 47-5. Command Example: show sflow linecard
sFlow | 977
Configure Collectors
www.dell.com | support.dell.com
The sflow collector command allows you to configure sFlow collectors to which sFlow datagrams are
forwarded. You can configure up to two sFlow collectors (IPv4 or IPv6). If you configure two collectors,
traffic samples are sent to both devices.
e.
sFlow collection through the Management interface is supported on platform:
Polling Intervals
The sflow polling-interval command configures the polling interval for an interface in the maximum
number of seconds between successive samples of counters to be sent to the collector. This command
changes the global default counter polling (20 seconds) interval. You can configure an interface to use a
different polling interval.
The polling interval can be configured globally (in CONFIGURATION mode) or by interface (in
INTERFACE mode) by executing the interval command:
.
sflow polling-interval CONFIGURATION or Change the global default counter polling interval.
interval value INTERFACE interval value—in seconds.
Range: 15 to 86400 seconds
Default: 20 seconds
978 | sFlow
Sampling Rate
Sampling Rate is supported on platform et.
The sFlow sampling rate is the number of packets that are skipped before the next sample is taken. sFlow
does not have time-based packet sampling.
The sflow sample-rate command, when issued in CONFIGURATION mode, changes the default
sampling rate. By default, the sampling rate of an interface is set to the same value as the current global
default sampling rate.If the value entered is not a correct power of 2, the command generates an error
message with the previous and next power-of-2 value. Select one of these two number and re-enter the
command. (For more information on values in power-of-2, see Sub-sampling on page 979.)
The sample rate can be configured globally or by interface using the sample rate command:
[no] sflow sample-rate CONFIGURATION Change the global or interface sampling rate. Rate must
sample-rate or be entered in factors of 2 (eg, 4096, 8192).
INTERFACE sample-rate range:
256-8388608 for C-Series and S-Series
2-8388608 for E-Series
Sub-sampling
Sub-sampling is available only on platform: et
The sFlow sample rate is not the frequency of sampling, but the number of packets that are skipped before
the next sample is taken. Although a sampling rate can be configured for each port, TeraScale line cards
can support only a single sampling rate per port-pipe.
Therefore, sFlow Agent uses sub-sampling to create multiple sampling rates per port-pipe. To achieve
different sampling rates for different ports in a port-pipe, sFlow Agent takes the lowest numerical value of
the sampling rate of all the ports within the port-pipe, and configures all ports to this value. sFlow Agent is
then able to skip samples on ports where you require a larger sampling rate value.
Sampling rates are configurable in powers of two. This allows the smallest sampling rate possible to be
configured on the hardware, and also allows all other sampling rates to be available through sub-sampling.
For example, if Gig 1/0 and 1/1 are in a port-pipe, and they are configured with a sampling rate of 4096 on
interface Gig 1/0, and 8192 on Gig 1/1, sFlow Agent does the following:
1. Configures the hardware to a sampling rate of 4096 for all ports with sFlow enabled on that port-pipe.
2. Configure interface Gig 1/0 to a sub-sampling rate of 1 to achieve an actual rate of 4096.
3. Configure interface Gig 1/1 to a sub-sampling rate of 2 to achieve an actual rate of 8192.
sFlow | 979
www.dell.com | support.dell.com
Note: Sampling rate backoff can change the sampling rate value that is set in the hardware. This equation
shows the relationship between actual sampling rate, sub-sampling rate, and the hardware sampling rate
for an interface:
Actual sampling rate = sub-sampling rate * hardware sampling rate
Note the absence of a configured rate in the equation. That is because when the hardware sampling rate
value on the port-pipe exceeds the configured sampling rate value for an interface, the actual rate changes
to the hardware rate. The sub-sampling rate never goes below a value of one.
Back-off Mechanism
If the sampling rate for an interface is set to a very low value, the CPU can get overloaded with flow
samples under high-traffic conditions. In such a scenario, a binary back-off mechanism gets triggered,
which doubles the sampling-rate (halves the number of samples per second) for all interfaces. The backoff
mechanism continues to double the sampling-rate until CPU condition is cleared. This is as per sFlow
version 5 draft. Once the back-off changes the sample-rate, users must manually change the sampling rate
to the desired value.
As a result of back-off, the actual sampling-rate of an interface may differ from its configured sampling
rate. The actual sampling-rate of the interface and the configured sample-rate can be viewed by using the
show sflow command.
Extended sFlow
Extended sFlow is supported fully on platform e
Platforms c and s support extended-switch information processing only.
Extended sFlow packs additional information in the sFlow datagram depending on the type of sampled
packet. The following options can be enabled:
Note: The entire AS path is not included. BGP community-list and local preference information are not
included. These fields are assigned default values and are not interpreted by the collector.
980 | sFlow
Use the command sflow [extended-switch] [extended-router] [extended-gateway] enable command. By
default packing of any of the extended information in the datagram is disabled.
Use the command show sflow to confirm that extended information packing is enabled, as shown in
Figure 47-6.
FTOS#show sflow
sFlow services are enabled
Global default sampling rate: 4096 Extended sFlow settings
Global default counter polling interval: 15 show all 3 types are enabled
Global extended information enabled: gateway, router, switch
1 collectors configured
Collector IP addr: 10.10.10.3, Agent IP addr: 10.10.0.0, UDP port: 6343
77 UDP packets exported
0 UDP packets dropped
165 sFlow samples collected
69 sFlow samples dropped due to sub-sampling
If none of the extended information is enabled, the show output is as shown in Figure 47-7.
FTOS#show sflow
sFlow services are disabled
Global default sampling rate: 32768
Global default counter polling interval: 20
Global extended information enabled: none Indicates no Extended sFlow types
0 collectors configured enabled.
0 UDP packets exported
0 UDP packets dropped
0 sFlow samples collected
0 sFlow samples dropped due to sub-sampling
sFlow | 981
Important Points to Remember
www.dell.com | support.dell.com
• The IP destination address has to be learned via BGP in order to export extended-gateway data, prior to
FTOS version 7.8.1.0.
• If the IP destination address is not learned via BGP the Dell Force10 system does not export
extended-gateway data, prior to FTOS version 7.8.1.0.
• FTOS 7.8.1.0 and later enhances the sFlow implementation for real time traffic analysis on the
E-Series to provide extended gateway information in cases where the destination IP addresses are
learned by different routing protocols, and for cases where the destination is reachable over ECMP.
• If the IP source address is learned via IGP then srcAS and srcPeerAS are zero.
• The srcAS and srcPeerAS might be zero even though the IP source address is learned via BGP. The
Dell Force10 system packs the srcAS and srcPeerAS information only if the route is learned via BGP
and it is reachable via the ingress interface of the packet.
982 | sFlow
48
Simple Network Management Protocol
Simple Network Management Protocol is supported on platforms ces
SNMP is supported on the E-Series ExaScale platform with FTOS 8.1.1.0 and later.
Note: On Dell Force10 routers, standard and private SNMP MIBs are supported, including all Get and a
limited number of Set operations (such as set vlan and copy cmd).
Protocol Overview
Network management stations use Simple Network Management Protocol (SNMP) to retrieve or alter
management data from network elements. A datum of management information is called a managed
object; the value of a managed object can be static or variable. Network elements store managed objects in
a database called a Management Information Base (MIB).
MIBs are hierarchically structured and use object identifiers to address managed objects, but managed
objects also have a textual name called an object descriptor.
Implementation Information
• FTOS supports SNMP version 1 as defined by RFC 1155, 1157, and 1212, SNMP version 2c as
defined by RFC 1901, and SNMP version 3 as defined by RFC 2571.
• FTOS supports up to 15 trap receivers.
• The FTOS implementation of the sFlow MIB supports sFlow configuration via SNMP sets.
• SNMP traps for STP and MSTP state changes are based on BRIDGE MIB (RFC 1483) for STP and
IEEE 802.1 draft ruzin-mstp-mib-02 for MSTP.
Create a Community
The management station generates requests to either retrieve or alter the value of a management object and
is called the SNMP manager. A network element that processes SNMP requests is called an SNMP agent.
An SNMP community is a group of SNMP agents and managers that are allowed to interact. Communities
are necessary to secure communication between SNMP managers and agents; SNMP agents do not
respond to requests from management stations that are not part of the community.
FTOS enables SNMP automatically when you create an SNMP community and displays Message 1. You
must specify whether members of the community may only retrieve values (read), or retrieve and alter
values (read-write).
Choose a name for the community. snmp-server community name {ro | rw} CONFIGURATION
View your SNMP configuration, using the command show running-config snmp from EXEC Privilege
mode, as shown in Figure 48-1.
Task Command
Read the value of a single managed object, snmpget -v version -c community agent-ip {identifier.instance |
as shown in Figure 48-2. descriptor.instance}
Read the value of the managed object snmpgetnext -v version -c community agent-ip {identifier.instance |
directly below the specified object, as descriptor.instance}
shown in Figure 48-3.
Figure 48-3. Reading the Value of the Next Managed Object in the MIB
> snmpgetnext -v 2c -c mycommunity 10.11.131.161 .1.3.6.1.2.1.1.3.0
SNMPv2-MIB::sysContact.0 = STRING:
> snmpgetnext -v 2c -c mycommunity 10.11.131.161 sysContact.0
SNMPv2-MIB::sysName.0 = STRING: S50V_7.7
Read the value of many objects at once, as snmpwalk -v version -c community agent-ip {identifier.instance |
shown in Figure 48-4. descriptor.instance}
Task Command
Task Command
To configure system contact and location information from the Dell Force10 system:
Identify the system manager along with this person’s contact snmp-server contact text CONFIGURATION
information (e.g E-mail address or phone number). You may use
up to 55 characters.
Default: None
Identify the physical location of the system. For example, San snmp-server location text CONFIGURATION
Jose, 350 Holger Way, 1st floor lab, rack A1-1. You may use up
to 55 characters.
Default: None
Identify the system manager along with this person’s snmpset -v version -c community CONFIGURATION
contact information (e.g E-mail address or phone agent-ip sysContact.0 s “contact-info”
number). You may use up to 55 characters.
Default: None
Identify the physical location of the system. For snmpset -v version -c community CONFIGURATION
example, San Jose, 350 Holger Way, 1st floor lab, agent-ip sysLocation.0 s “location-info”
rack A1-1. You may use up to 55 characters.
Default: None
By default, the Dell Force10 system displays some unsolicited SNMP messages (traps) upon certain events
and conditions. You can also configure the system to send the traps to a management station. Traps cannot
be saved on the system.
1 Configure the Dell Force10 system send snmp-server host ip-address CONFIGURATION
notifications to an SNMP server.
2 Specify which traps the Dell Force10 system sends snmp-server enable traps CONFIGURATION
to the trap receiver.
• Enable all Dell Force10 enterpriseSpecific and
RFC-defined traps using the command
snmp-server enable traps from
CONFIGURATION mode.
• Enable all of the RFC-defined traps using the
command snmp-server enable traps snmp
from CONFIGURATION mode.
3 Specify the interfaces out of which FTOS sends snmp-server trap-source CONFIGURATION
SNMP traps.
Table 48-1 lists the traps the RFC-defined SNMP traps and the command used to enable each. Note that
the coldStart and warmStart traps are enabled using a single command.
To enable a subset of Dell Force10 enterprise-specific SNMP traps, enter any of the snmp-server enable
traps command options in Table 48-2. Note that the envmon option enables all environment traps,
including fan, supply, and temperature.
RPM0-P:CP %CHMGR-2-CARD_PARITY_ERR
envmon supply PEM_PRBLM: Major alarm: problem with power entry module %s
FAN_OK: Minor alarm cleared: all fans in fan tray %d are good
Table 48-3. MIB Objects for Copying Configuration Files via SNMP
2 Copy the f10-copy-config.mib MIB from the Dell Force10 iSupport webpage to the server to which you are
copying the configuration file.
• Every specified object must have an object value, which must be preceded by the keyword i. See Table 6 for
valid values.
• index must be unique to all previously executed snmpset commands. If an index value has been used
previously, a message like the one in Message 3 appears. In this case, increment the index value and enter the
command again.
• Use as many MIB Objects in the command as required by the MIB Object descriptions in Table 6 to complete
the command. See Table 7 or examples.
Note: You can use the entire OID rather than the object name. Use the form: OID.index i object-value, as
shown in Figure 57.
Table 7 shows examples of using the command snmpset to copy a configuration. These examples assume
that:
Task
Copy the running-config to the startup-config using the following command from the Unix machine:
Figure 48-6 show the command syntax using MIB object names, and Figure 48-7 shows the same command using the
object OIDs. In both cases, the object is followed by a unique index number.
Figure 48-6. Copying Configuration Files via SNMP using Object-Name Syntax
> snmpset -v 2c -r 0 -t 60 -c public -m ./f10-copy-config.mib 10.10.10.10 copySrcFileType.101 i
2 copyDestFileType.101 i 3
FORCE10-COPY-CONFIG-MIB::copySrcFileType.101 = INTEGER: runningConfig(2)
FORCE10-COPY-CONFIG-MIB::copyDestFileType.101 = INTEGER: startupConfig(3)
Figure 48-7. Copying Configuration Files via SNMP using OID Syntax
> snmpset -v 2c -c public -m ./f10-copy-config.mib 10.10.10.10
.1.3.6.1.4.1.6027.3.5.1.1.1.1.2.100 i 2 .1.3.6.1.4.1.6027.3.5.1.1.1.1.5.100 i 3
FORCE10-COPY-CONFIG-MIB::copySrcFileType.100 = INTEGER: runningConfig(2)
FORCE10-COPY-CONFIG-MIB::copyDestFileType.100 = INTEGER: startupConfig(3)
Copy the startup-config to the running-config using the following command from a Unix machine:
snmpset -c private -v 2c force10system-ip-address copySrcFileType.index i 3 copyDestFileType.index i 2
Figure 48-8. Copying Configuration Files via SNMP using Object-Name Syntax
> snmpset -c public -v 2c -m ./f10-copy-config.mib 10.11.131.162 copySrcFileType.7 i 3
copyDestFileType.7 i 2
FORCE10-COPY-CONFIG-MIB::copySrcFileType.7 = INTEGER: runningConfig(3)
FORCE10-COPY-CONFIG-MIB::copyDestFileType.7 = INTEGER: startupConfig(2)
Figure 48-9. Copying Configuration Files via SNMP using OID Syntax
>snmpset -c public -v 2c 10.11.131.162 .1.3.6.1.4.1.6027.3.5.1.1.1.1.2.8 i 3
.1.3.6.1.4.1.6027.3.5.1.1.1.1.5.8 i 2
SNMPv2-SMI::enterprises.6027.3.5.1.1.1.1.2.8 = INTEGER: 3
SNMPv2-SMI::enterprises.6027.3.5.1.1.1.1.5.8 = INTEGER: 2
Copy the startup-config to the server via FTP using the following command from the Unix machine:
Task
Copy the startup-config to the server via TFTP using the following command from the Unix machine:
Note: Verify that the file exists and its permissions are set to 777, and specify the relative path to the TFTP root
directory.
Figure 48-11. Copying Configuration Files via SNMP and TFTP to a Remote Server
.snmpset -v 2c -c private -m ./f10-copy-config.mib 10.10.10.10
copySrcFileType.4 i 3
copyDestFileType.4 i 1
copyDestFileLocation.4 i 3
copyDestFileName.4 s /home/myfilename
copyServerAddress.4 a 11.11.11.11
Copy a binary file from the server to the startup-configuration on the Dell Force10 system via FTP using the following
command from the Unix server:
Figure 48-12. Copying Configuration Files via SNMP and FTP from a Remote Server
> snmpset -v 2c -c private -m ./f10-copy-config.mib 10.10.10.10 copySrcFileType.10 i 1
copySrcFileLocation.10 i 4 copyDestFileType.10 i 3 copySrcFileName.10 s /home/myfilename
copyServerAddress.10 a 172.16.1.56 copyUserName.10 s mylogin copyUserPassword.10 s mypass
Table 48-5. MIB Objects for Copying Configuration Files via SNMP
Step Task
• index is the index value used in the snmpset command used to complete the copy operation.
Note: You can use the entire OID rather than the object name. Use the form: OID.index, as shown in
Figure 48-14.
Figure 48-13 and Figure 48-14 are examples of using the command snmpget to obtain a MIB object value.
These examples assume that:
Note: In Unix, enter the command snmpset for help using this command.
command using the object OIDs. In both cases, the object is followed by same index number used in the
snmpset command.
Figure 48-13. Obtaining MIB Object Values for a Copy Operation using Object-name Syntax
> snmpget -v 2c -c private -m ./f10-copy-config.mib 10.11.131.140 copyTimeCompleted.110
FORCE10-COPY-CONFIG-MIB::copyTimeCompleted.110 = Timeticks: (1179831) 3:16:38.31
Figure 48-14. Obtaining MIB Object Values for a Copy Operation using OID Syntax
> snmpget -v 2c -c private 10.11.131.140 .1.3.6.1.4.1.6027.3.5.1.1.1.1.13.110
SNMPv2-SMI::enterprises.6027.3.5.1.1.1.1.13.110 = Timeticks: (1179831) 3:16:38.31
Create a VLAN
Use the dot1qVlanStaticRowStatus object to create a VLAN. The snmpset operation in Figure 48-15
creates VLAN 10 by specifying a value of 4 for instance 10 of the dot1qVlanStaticRowStatus object.
To display the ports in a VLAN, send an snmpget request for the object dot1qStaticEgressPorts using the
interface index as the instance number, as shown for an S-Series in Figure 48-18.
The table that the Dell Force10 system sends in response to the snmpget request is a table that contains
hexadecimal (hex) pairs, each pair representing a group of eight ports.
• On the E-Series, 12 hex pairs represents a line card. Twelve pairs accommodates the greatest currently
available line card port density, 96 ports.
• On the C-Series, 28 hex pairs represents a line card. Twenty-eight pairs accommodates the greatest
currently available line card port density, 28 ports per port-pipe, and any remaining hex pairs are
unused.
• On the S-Series, 7 hex pairs represents a stack unit. Seven pairs accommodates the greatest number of
ports available on an S-Series, 56 ports. The last stack unit is assigned 8 pairs; the eighth pair is
unused.
The first hex pair, 00 in Figure 48-18, represents ports 1-7 in Stack Unit 0. The next pair to the right
represents ports 8-15. To resolve the hex pair into a representation of the individual ports, convert the hex
pair to binary. Consider the first hex pair 00, which resolves to 0000 0000 in binary:
• On the E-Series and C-Series each position in the 8-character string is for one port, starting with Port 0
at the left end of the string, and ending with Port 7 at the right end. A 0 indicates that the port is not a
member of the VLAN; a 1 indicates VLAN membership.
• On the S-Series, each position in the 8-character string is for one port, starting with Port 1 at the left
end of the string, and ending with Port 8 at the right end. A 0 indicates that the port is not a member of
the VLAN; a 1 indicates VLAN membership.
The value 40 is in the first set of 7 hex pairs, indicating that these ports are in Stack Unit 0. The hex value
40 is 0100 0000 in binary. As described above, the left-most position in the string represents Port 1. The
next position from the left represents Port 2 and has a value of 1, indicating that Port 0/2 is in VLAN 10.
The remaining positions are 0, so those ports are not in the VLAN.
Note that the table contains none of the other information provided by the show vlan command, such as
port speed or whether the ports are tagged or untagged.
The dot1qVlanStaticUntaggedPorts object is an array of only untagged VLAN members. All VLAN
members that are not in dot1qVlanStaticUntaggedPorts are tagged.
• To add a tagged port to a VLAN, write the port to the dot1qVlanStaticEgressPorts object, as shown in
Figure 48-20.
• To add an untagged port to a VLAN, write the port to the dot1qVlanStaticEgressPorts and
dot1qVlanStaticUntaggedPorts objects, as shown in Figure 48-21.
Note: Whether adding a tagged or untagged port, you must specify values for both
dot1qVlanStaticEgressPorts and dot1qVlanStaticUntaggedPorts.
2 From the Dell Force10 system, identify the interface show interface EXEC Privilege
index of the port for which you want to change the admin
status. Or, from the management system, use the
snmpwwalk command to identify the interface index.
3 Enter the command snmpset to change the admin status using either the object descriptor or the OID. Choose
integer 1 to change the admin status to Up, or 2 to change the admin status to Down.
snmpset with descriptor: snmpset -v version -c community agent-ip ifAdminStatus.ifindex i {1 | 2}
snmpset with OID: snmpset -v version -c community agent-ip .1.3.6.1.2.1.2.2.1.7.ifindex i {1 | 2}
Note: The 802.1q Q-BRIDGE MIB defines VLANs with regard to 802.1d, as 802.1d itself does not define
them. As a switchport must belong a VLAN (the default VLAN or a configured VLAN), all MAC address
learned on a switchport are associated with a VLAN. For this reason, the Q-Bridge MIB is used for MAC
address query. Moreover, specific to MAC address query, dot1dTpFdbTable is indexed by MAC address
only for a single forwarding database, while dot1qTpFdbTable has two indices —VLAN ID and MAC
address —to allow for multiple forwarding databases and considering that the same MAC address is
learned on multiple VLANs. The VLAN ID is added as the first index so that MAC addresses can be read
by VLAN, sorted lexicographically. The MAC address is are part of the OID instance, so in this case,
lexicographic order is according to the most significant octet.
Table 48-6. MIB Objects for Fetching Dynamic MAC Entries in the Forwarding Database
In Figure 48-22, R1 has one dynamic MAC address, learned off of port GigabitEthernet 1/21, which a
member of the default VLAN, VLAN 1. The SNMP walk returns the values for dot1dTpFdbAddress,
dot1dTpFdbPort, and dot1dTpFdbStatus.
instance number is the decimal equivalent of the MAC address; derive the instance number by converting
each hex pair to its decimal equivalent. For example, the decimal equivalent of E8 is 232, and so the
instance number for MAC address 00:01:e8:06:95:ac is .0.1.232.6.149.172.
The value of dot1dTpFdbPort is the port number of the port off which the system learns the MAC address.
In this case, of GigabitEthernet 1/21, the manager returns the integer 118. The maximum line card port
density on the E-Series is 96 ports, and line card numbering begins with 0; GigabitEthernet 1/21 is the 21st
port on Line Card 1, and 96 + 21 yields 118.
In Figure 48-23, GigabitEthernet 1/21 is moved to VLAN 1000, a non-default VLAN. Use the objects
dot1qTpFdbTable to fetch the MAC addresses learned on non-default VLANs. The instance number is the
VLAN number concatenated with the decimal conversion of the MAC address.
Use dot3aCurAggFdbTable to fetch the learned MAC address of a port-channel. The instance number is
the decimal conversion of the MAC address concatenated with the port-channel number.
The interface index is a binary number with bits that indicate the slot number, port number, interface type,
and card type of the interface. FTOS converts this binary index number to decimal, and displays it in the
output of the show interface command.
Unused P/L Flag Slot Number Port Number Interface Type Card Type
For example, the index 72925242 is 100010110001100000000111010 in binary. The binary interface index
for GigabitEthernet 1/21 of a 48-port 10/100/1000Base-T line card with RJ-45 interface is shown in
Figure 48-27. Notice that the physical/logical bit and the final, unused bit are not given. The interface is
physical, so this must be represented by a 0 bit, and the unused bit is always 0. These two bits are not given
because they are the most significant bits, and leading zeros are often omitted.
Note that the interface index does not change if the interface reloads or fails over. On the S-Series, if the
unit is renumbered (for any reason) the interface index will change during a reload.
Monitor Port-channels
To check the status of a Layer 2 port-channel, use f10LinkAggMib (.1.3.6.1.4.1.6027.3.2). Below, Po 1 is a
switchport and Po 2 is in Layer 3 mode.
dot3aCurAggVlanId
SNMPv2-SMI::enterprises.6027.3.2.1.1.4.1.1.1.0.0.0.0.0.1.1 = INTEGER: 1
dot3aCurAggMacAddr
SNMPv2-SMI::enterprises.6027.3.2.1.1.4.1.2.1.0.0.0.0.0.1.1 = Hex-STRING: 00 00 00 00 00 01
dot3aCurAggIndex
SNMPv2-SMI::enterprises.6027.3.2.1.1.4.1.3.1.0.0.0.0.0.1.1 = INTEGER: 1
dot3aCurAggStatus
SNMPv2-SMI::enterprises.6027.3.2.1.1.4.1.4.1.0.0.0.0.0.1.1 = INTEGER: 1 << Status active, 2 –
status inactive
• When you query an IPv4 icmpMsgStatsInPkts object in the ICMP table by using the snmpwalk
command, the output for echo replies may be incorrectly displayed. Use the show ip traffic command to
correctly display this information under ICMP statistics in the command output.
• When you query an icmpStatsInErrors object in the icmpStats table by using the snmpget or snmpwalk
command, the output for IPv4 addresses may be incorrectly displayed. Use the show ip traffic
command to correctly display this information under IP and ICMP statistics.
• When you query an IPv4 icmpMsgStatsInPkts object in the ICMP table by using the snmpwalk
command, the echo response output may not be displayed. Use the show ip traffic command to
correctly display ICMP statistics, such as echo response.
FTOS supports two line cards with SONET—Packet-Over-SONET (POS) and PPP-over-SONET/SDH.
SONET/SDH | 1007
• Protection switching is not supported.
www.dell.com | support.dell.com
• Encapsulation
• MTU
• Clock Settings
Encapsulation
The E-Series’ POS line card requires PPP encapsulation. A SONET interface without encapsulation is
always administratively down.
When enabling encapsulation on an interface, PPP negotiation only begins after it has been turned on using
the no shutdown command. You can enable authentication and other related commands after negotiation is
completed. When removing encapsulation using the no encap command on a SONET interface, the
interface is administratively shutdown and all configuration information (IP addresses for example) is
deleted from the interface.
Equipment vendors use unique defaults for PPP encapsulation. When configuring PPP encapsulation
between the E-Series and another vendor’s equipment, verify the following settings:
• One side of the link is set using the command clock source internal.
• Default SONET settings are compatible. The E-Series defaults to ATM scrambling disabled; flag is C2
0xCF(207), J0 is 0xCF(207).
• A common PPP authentication method is configured. FTOS supports Challenge-Handshake
Authentication Protocol (CHAP) and/or Password Authentication Protocol (PAP) authentication.
• The MTU and IP MTU settings on both ends of the link are the same. If you input the ip mtu command
with a value which differs from the far-end interface, the interface on the E-Series will go down.
• Confirm that the MTU settings are the same on both end of the link. If you configure the ip mtu
command with a different value on the far end of the link, the interface on the E-Series goes down.
Note: SONET uses synchronous transport signal (STS) framing. When framing is configured
on an interface, it should only be done when the interface is shut down.
1008 | SONET/SDH
Configuring Maximum Transmission Unit (MTU)
Maximum Transmission Unit is an integer value that represents the greatest number of bytes that any given
interface on the system can handle. MTU settings allow the router to determine if a large packet needs to
be fragmented before transmission. PPP must be enabled on a SONET interface before MTU can become
configurable. MTU size can be changed in INTERFACE mode by entering the command mtu size.
Note that the port must be in shutdown state before the wanport command can be executed successfully.
(Figure 49-2).
Note: For E-Series ExaScale systems, you must configure all the ports in a port-pipe to either WANPHY
or non-WANPHY. They cannot be mixed on the same port-pipe. If you configure port 3 for example to be
a WANPHY port then ports 0-4 (same port pipe) all must be WANPHY as well.
SONET/SDH | 1009
Figure 49-2. wanport command example
www.dell.com | support.dell.com
SECTION
LOF = 0 LOS = 0 BIP(B1) = 13
LINE
AIS = 0 RDI = 1 FEBE = 7633 BIP(B2) = 19264
Alarm reporting enabled for: SLOS SLOF B1-TCA LAIS LRDI B2-TCA PAIS PRDI PLOP B3-TCA SD SF
1010 | SONET/SDH
While performance monitoring provides advanced alert of link degradation, alarms indicate a failure. Fault
management involves alarm monitoring and generation, reporting, logging, correlation, and clearing.
E-Series POS and 10GE WAN interfaces support the SONET alarms shown in Table 49-1:
• Section alarms—SLOS, SLOF
• Line alarms—AIS, RDI, FEBE(REI), SD, SF
• Path Alarms—AIS, RDI, FEBE(REI), LOP
Since E-Series is Terminal Equipment (TE), it must support the alarms in Table 49-1.
AIS Path Alarm Indication Signal is sent by the LTE to alert the
downstream path terminating equipment (PTE) that it has detected a
defect on its incoming line signal.
SONET/SDH | 1011
Use the alarm-report command to configure the SONET alarms that a POS or 10 GE WAN interface can
www.dell.com | support.dell.com
Specify which POS/SDH alarms to report alarm-report {lais | lrdi | pais | plop | prdi INTERFACE
to the remote SNMP server. | sd-ber | sf-ber | slof | slos}
To view active alarms and defects, use the show controllers sonet command in EXEC Privilege mode.
Note: Historical data is not saved. The command input will show current information only.
Alarm Description
When an E-Series POS or 10GE WAN interface detects a SONET alarm, a Syslog and SNMP trap message
are generated containing information about the alarm condition.
1012 | SONET/SDH
SONET TRAP Example
SONET Traps on page 1015 describes the traps and OIDs for SONET alarms that are reported on an
SNMP trap receiver. Figure 49-4 shows an example of a SONET trap.
Figure 49-5 shows an example of the Syslog messages generated for SONET alarms:
• Line Alarm Indication Signal (lais)
• Path Remote Defect Indication (prdi)
• Section Loss of Frame (slof)
Figure 49-5. SONET Syslog Message examples
Oct 6 04:46:51: %EXW4PF:13 %SONETAGT-5-ALARM: Interface Te 13/1 is out of alarm LAIS
Oct 6 04:46:42: %EXW4PF:13 %SONETAGT-6-ALARM: Interface Te 13/1 is out of alarm PRDI
Oct 6 04:46:44: %EXW4PF:13 %SONETAGT-4-ALARM: Interface Te 13/1 is in alarm SLOF
You can configure the SONET interface to change to a “down state” when certain SONET events are
reported. When the event (or trigger) occurs, FTOS brings down the SONET interface. You can use the
delay triggers command to indicate a 100ms delay in bringing down the SONET interface once the event
or trigger is detected.
SONET/SDH | 1013
www.dell.com | support.dell.com
Delay triggering the line or path alarms delay triggers {line [lrdi | sd-ber | sf-ber] INTERFACE
with a 100ms delay. | path [pais | prdi] }
By default, certain alarms (LOS, LOF, LAIS, PLOP) bring the line protocol down immediately. Use this
command, with the line option, to delay that trigger event by 100ms.
By default, path alarms (AIS, RDI, LOP) do not cause (or trigger) the interface line protocol to go down.
The delay triggers command, used with the path option, can be used to trigger this action.
Note: FTOS does not support configurable thresholds; delay triggers uses a default value of 100 ms.
To keep a port in shutdown use the use the hardware monitor mac action-on-error port-shutdown command.
1014 | SONET/SDH
SONET MIB
Table 49-3 lists the managed objects supported in the SONET MIB, as defined in RFC 2558.
SONET Traps
Table 49-4 describes SONET traps supported in the Force10-specific MIB.
SONET/SDH | 1015
Table 49-4. SONET Traps and OIDs (continued)
www.dell.com | support.dell.com
1016 | SONET/SDH
Table 49-4. SONET Traps and OIDs (continued)
SONET/SDH | 1017
www.dell.com | support.dell.com
1018
|
SONET/SDH
50
Stacking S-Series Switches
Stacking S-Series Switches is supported on platform s
Note: S-Series Stackin is not supported on the S60 system.
A stack is analogous to an E-Series or C-Series system with redundant RPMs and multiple line cards.
FTOS elects a primary and secondary management unit, and all other units are member units. The
forwarding database resides on the primary, and all other units maintain a sychnronized local copy. Each
unit in the stack makes forwarding decisions based on their local copy.
FTOS presents all of the units like line cards; for example, to access GigabitEthernet Port 1 on Stack Unit
0, enter interface gigabitethernet 0/1 from CONFIGURATION mode.
Stack#show redundancy
-- Stack-unit Status --
------------------------------------------------
Mgmt ID: 0
Stack-unit ID: 1
Stack-unit Redundancy Role: Primary
Stack-unit State: Active
Stack-unit SW Version: 7.8.1.0
Link to Peer: Up
For example, if you add a powered standalone unit to a stack, either the standalone unit or the stack reloads
(excluding the new unit), depending on which has the higher priority, the new unit or the existing stack
manager. If the new unit has the higher priority, it becomes the new stack manager after the stack reloads.
All switches have a default priority of 0; if a priority tie occurs, the system with the highest MAC address
supersedes, as shown in Figure 50-2.
-- Stack Info --
Unit UnitType Status ReqTyp CurTyp Version Ports
---------------------------------------------------------------------------
0 Standby online S50V S50V 7.8.1.0 52
1 Management online S50N S50N 7.8.1.0 52
2 Member online S50V S50V 7.8.1.0 52
3 Member not present
4 Member not present
5 Member not present
6 Member not present
7 Member not present
Stack#show system stack-unit 0 | grep priority
Master priority : 0
Stack#show system stack-unit 1 | grep priority
Master priority : 0
Stack#show system stack-unit 2 | grep priority
Master priority : 0
Stack#show system stack-unit 0| grep "Burned In MAC"
Burned In MAC : 00:01:e8:d5:ef:81
Stack#show system stack-unit 0 | grep "Burned In MAC"
Burned In MAC : 00:01:e8:d5:ef:81
Stack#show system stack-unit 1 | grep "Burned In MAC"
Burned In MAC : 00:01:e8:d5:f9:6f
Stack#show system stack-unit 2 | grep "Burned In MAC"
Burned In MAC : 00:01:e8:cc:cc:cc
Note: If the removed management unit is brought up as a standalone unit or as part of a different stack,
there is a possibility of MAC address collisions.
In Figure 50-3 and Figure 50-4, a standalone is added to a stack. The standalone and the stack master have
the same priority, but the standalone has a lower MAC address, so the standalone reboots. In Figure 50-4
and Figure 50-5, a standalone is added to a stack. The standalone has a higher priority than the stack, so the
stack (excluding the new unit) reloads.
-- Stack Info --
Unit UnitType Status ReqTyp CurTyp Version Ports
---------------------------------------------------------------------------
0 Management online S50V S50V 7.8.1.0 52
1 Member not present
2 Member not present
3 Member not present
4 Member not present
5 Member not present
6 Member not present
7 Member not present
[output omitted]
Standalone#show system | grep priority
Master priority : 0
------------------------------------STACK BEFORE CONNECTION----------------------------------
Stack#show system brief
-- Stack Info --
Unit UnitType Status ReqTyp CurTyp Version Ports
---------------------------------------------------------------------------
0 Standby online S50V S50V 7.8.1.0 52
1 Management online S50N S50N 7.8.1.0 52
2 Member not present
3 Member not present
4 Member not present
5 Member not present
6 Member not present
7 Member not present
[output omitted]
Stack#show system stack-unit 0 | grep priority
Master priority : 0
Stack#show system stack-unit 1 | grep priority
Master priority : 0
-- Stack Info --
Unit UnitType Status ReqTyp CurTyp Version Ports
---------------------------------------------------------------------------
0 Standby online S50V S50V 7.8.1.0 52
1 Management online S50N S50N 7.8.1.0 52
2 Member online S50V S50V 7.8.1.0 52
3 Member not present
4 Member not present
5 Member not present
6 Member not present
7 Member not present
Before
-------------------------------STANDALONE BEFORE CONNECTION----------------------------------
Standalone#show system brief
-- Stack Info --
Unit UnitType Status ReqTyp CurTyp Version Ports
---------------------------------------------------------------------------
0 Member not present S50V
1 Member not present S50N
2 Management online S50V S50V 7.8.1.0 52
3 Member not present
4 Member not present
5 Member not present
6 Member not present
7 Member not present
[output omitted]
Stack#show system | grep priority
Master priority : 1
------------------------------------STACK BEFORE CONNECTION----------------------------------
Stack##show system brief
-- Stack Info --
Unit UnitType Status ReqTyp CurTyp Version Ports
---------------------------------------------------------------------------
0 Standby online S50V S50V 7.8.1.0 52
1 Management online S50N S50N 7.8.1.0 52
2 Member not present
3 Member not present
4 Member not present
5 Member not present
6 Member not present
7 Member not present
Stack#show system stack-unit 0 | grep priority
Master priority : 0
Stack#show system stack-unit 1 | grep priority
Master priority : 0
-- Stack Info --
Unit UnitType Status ReqTyp CurTyp Version Ports
---------------------------------------------------------------------------
0 Member online S50V S50V 7.8.1.0 52
1 Standby online S50N S50N 7.8.1.0 52
2 Management online S50V S50V 7.8.1.0 52
3 Member not present
4 Member not present
5 Member not present
6 Member not present
7 Member not present
• Console access: You may access the stack through the console port of the stack manager only. Like a
standby RPM, the console port of the standby unit does not provide management capability; only a
limited number of commands are available. Member units provide a severely limited set of commands,
as shown in Figure 50-7.
• Remote access: You may access the stack with SNMP, SSH, or Telnet through any enabled, Layer 3
interface on any stack unit. There is no dedicated management port or management route table.
A A
B B
A A
B B
A A
B B
A
B
Stacking 001
Facing the rear of an S-Series unit, stack-port are numbered from left to right, beginning with the highest
Ethernet port number (n) plus 1. For example, for a 48-port unit with two 12-Gigabyte stacking modules,
the stack-ports are 49, 50, 51, and 52, starting from the left.
1 Verify that each unit has the same FTOS version prior to show version EXEC Privilege
stacking them together.
2 Pre-configure unit numbers for each unit so that the stack-unit renumber EXEC Privilege
stacking is deterministic upon boot up.
3 Configure the switch priority for each unit to make stack-unit priority CONFIGURATION
management unit selection deterministic.
5 Power the stack one unit at a time. Start with the show system brief EXEC Privilege
management unit, then the standby, followed by each of the
members in order of their assigned stack number (or the
position in the stack you want each unit to take). Allow each
unit to completely boot, and verify that the unit is detected
by the stack manager, and then power the next unit.
Figure 50-9 shows a daisy-chain topology. Figure 50-10 shows the same stack converted to a ring by
connecting stack-port 2/51 to 0/51; you may rearrange the stacking cables without triggering a unit reset,
so long as the stack manager is never disconnected from the stack.
You can connect two units with two stacking cables as shown in, in case of a stacking port, module, or
cable failure. Removal of only one of the cables does not trigger a reset.
A
B
A
B
Stacking 002
The stack unit is displayed in an LED panel on the front of each switch. Each panel displays the stack unit
ID — from 0 through 7 — and:
• allow FTOS to automatically assign the new unit a position in the stack, or
• manually determine each units position in the stack by configuring each unit to correspond with the
stack before connecting it
Three configurable system variables affect how a new unit joins a stack: priority, stack number, and
provision.
• Depending on which has the higher priority, either the standalone unit or the entire stack reloads
(excluding the new unit). If the new unit has the higher priority, it becomes the new stack manager and
the stack reloads, as shown in Figure 50-3, Figure 50-4, Figure 50-5, and Figure 50-6.
• If you add a unit that has a stack number that conflicts with the stack, the stack assigns the first
available stack number, as shown in Figure 50-12 and Figure 50-13.
• If the stack has a provision for the stack-number that will be assigned to the new unit, the provision
must match the unit type, or FTOS generates a type mismatch error, as show in Figure 50-14 and
Figure 50-15.
After the new unit loads, it synchronizes its running and startup configurations with the stack.
1 While the unit is unpowered, install stacking modules in the new unit.
2 On the stack, determine the next available stack-unit show system brief EXEC Privilege
number, and the management prioritity of the show system stack-unit
management unit.
3 Create a virtual unit and assign it the next available stack-unit provision CONFIGURATION
stack-unit number.
4 On the new unit, number it the next available stack-unit stack-unit renumber EXEC Privilege
number.
To remove a stack member from the stack, disconnect the stacking cables from the unit. You may do this at
any time, whether the unit is powered or unpowered, online or offline. Note that if you remove a unit in the
middle of the stack, the stack will be split into multiple parts, and each will form a new stack according to
the stacking algorithm described throughout this chapter.
-- Stack Info --
Unit UnitType Status ReqTyp CurTyp Version Ports
---------------------------------------------------------------------------
0 Standby online S50V S50V 7.8.1.0 52
1 Management online S50N S50N 7.8.1.0 52
2 Member online S50V S50V 7.8.1.0 52
3 Member not present
4 Member not present
5 Member not present
6 Member not present
7 Member not present
-- Stack Info --
Unit UnitType Status ReqTyp CurTyp Version Ports
---------------------------------------------------------------------------
0 Member not present S50V
1 Member not present S50N
2 Management online S50V S50V 7.8.1.0 52
3 Member not present
4 Member not present
5 Member not present
6 Member not present
7 Member not present
[output omitted]
---------------------------------STACK AFTER DISCONNECTION----------------------------------
Stack#3w1d15h: %STKUNIT1-M:CP %CHMGR-2-STACKUNIT_DOWN: Stack unit 2 down - card removed
3w1d15h: %STKUNIT1-M:CP %IFMGR-1-DEL_PORT: Removed port: Gi 2/1-48
3w1d15h: %STKUNIT0-S:CP %IFMGR-1-DEL_PORT: Removed port: Gi 2/1-48
Stack#show system brief
-- Stack Info --
Unit UnitType Status ReqTyp CurTyp Version Ports
---------------------------------------------------------------------------
0 Standby online S50V S50V 7.8.1.0 52
1 Management online S50N S50N 7.8.1.0 52
2 Member not present S50V
3 Member not present
4 Member not present
5 Member not present
6 Member not present
7 Member not present
• FTOS selects a primary stack manager from the two existing mangers.
• FTOS resets all the units in the losing stack, and they all become stack members.
• If there is no unit numbering conflict, the stack members retain their previous unit numbers.
Otherwise, the stack manager assigns new unit numbers, based on the order that they come online.
• The stack manager overwrites the startup and running config on the losing stack members with its
own.
For a parent stack that is split into two child stacks, A and B, each with multiple units:
• If one of the new stacks receives the primary and the secondary management units, it is unaffected by
the split.
• If one of the new stacks receives only the primary management unit, that units remains the stack
manager, and FTOS elects a new secondary management unit.
• If one of the new stacks receives only the secondary management unit, it becomes the primary
management, and FTOS elects a new secondary management unit.
• If one of the new stacks receives neither the primary nor the secondary management unit, the stack is
reset so that a new election can take place.
Renumbering master unit will reload the stack. Proceed to renumber [confirm yes/no]: yes
Use virtual stack units to configure ports on the stack before adding a new unit, or to prevent FTOS from
assigning a particular stack-number.
Display most of the information in show show system brief EXEC Privilege
system, but in a more convenient tabular
form (Figure 50-19).
Display the same information in show show system stack-unit EXEC Privilege
system, but only for the specified unit
(Figure 50-19).
Display topology and stack link status for show system stack-ports [status | topology] EXEC Privilege
the entire stack. The available options
separate the show system stack-port
output into topology information from link
status information (Figure 50-19).
-- Unit 0 --
Unit Type : Member Unit
Status : online
Next Boot : online
Required Type : S50V - 48-port E/FE/GE with POE (SB)
Current Type : S50V - 48-port E/FE/GE with POE (SB)
Master priority : 0
Hardware Rev : 2.0
Num Ports : 52
Up Time : 30 min, 7 sec
FTOS Version : 7.8.1.0
Jumbo Capable : yes
POE Capable : yes
Burned In MAC : 00:01:e8:d5:ef:81
No Of MACs : 3
-- Module 0 --
Status : not present
-- Module 1 --
Status : online
Module Type : S50-01-12G-2S - 2-port 12G Stacking (SB)
Num Ports : 2
Hot Pluggable : no
-- Power Supplies --
Unit Bay Status Type
---------------------------------------------------------------------------
0 0 up AC
0 1 absent
-- Fan Status --
Unit TrayStatus Speed Fan0 Fan1 Fan2 Fan3 Fan4 Fan5
--------------------------------------------------------------------------------
0 up low up up up up up up
-- Stack Info --
Unit UnitType Status ReqTyp CurTyp Version Ports
---------------------------------------------------------------------------
0 Member online S50V S50V 7.8.1.0 52
1 Management online S50N S50N 7.8.1.0 52
2 Standby online S50V S50V 7.8.1.0 52
3 Member not present
4 Member not present
5 Member not present
6 Member not present
7 Member not present
-- Module Info --
Unit Module No Status Module Type Ports
---------------------------------------------------------------------------
0 0 not present No Module 0
0 1 online S50-01-12G-2S 2
1 0 online S50-01-12G-2S 2
1 1 not present No Module 0
2 0 not present No Module 0
2 1 online S50-01-12G-2S 2
-- Power Supplies --
Unit Bay Status Type
---------------------------------------------------------------------------
0 0 up AC
0 1 absent
1 0 absent
1 1 up DC
2 0 up AC
2 1 absent
-- Fan Status --
Unit TrayStatus Speed Fan0 Fan1 Fan2 Fan3 Fan4 Fan5
--------------------------------------------------------------------------------
0 up low up up up up up up
1 up low up up up up up up
2 up low up up up up up up
Influence the selection of the stack management units. The unit with the stack-unit priority CONFIGURATION
numerically highest priority is elected the primary management unit,
and the unit with the second highest priority is the secondary
management unit.
Default: 0
Range: 1-14
Reset the current management unit, and make redundancy force-failover stack-unit EXEC Privilege
the secondary management unit the new
primary. A new secondary is elected, and when
the former stack manager comes back online, it
becomes a member unit.
Prevent the stack manager from rebooting after redundancy disable-auto-reboot stack-unit CONFIGURATION
a failover. This command does not affect a
forced failover, manual reset, or a stack-link
disconnect.
Reload a member unit, from the unit itself reset-self EXEC Privilege
Reset a stack-unit when the unit is in a problem state. reset stack-unit 0-7 hard EXEC Privilege
In Figure 50-21, a stack-port on the manager flaps. The remote member, Member 2, displays a console
message, and the manager and standby display KERN-2-INT messages.
• remove the provision from the stack, then reconnect the standalone unit, or
• renumber the standalone unit with another available stack number on the stack.
• Storm Control is supported on the E-Series ExaScale platform with FTOS 8.1.1.0 and later.
• The percentage of storm control is calculated based on the advertised rate of the line card, not by the
speed setting of the interface.
• Do not apply per-VLAN QoS on an interface that has Storm Control enabled either on an interface or
globally.
• On E-Series, bi-directional traffic (unknown-unicast and broadcast) along with egress Storm Control
causes the configured traffic rates to be split between the involved ports. The percentage of traffic that
each port receives after the split is not predictable. Ports are affected whether they are in the same or
different port-pipes or line cards.
You can enable Storm Control for Layer 3 broadcasts from INTERFACE mode, CONFIGURATION
mode, or both. Each option has a different result.
• From INTERFACE mode: Storm Control limits ingress broadcast traffic on a single interface.
• From CONFIGURATION mode:
• On the E-Series, Storm Control limits ingress and egress broadcast traffic on all interfaces.
• On the C-Series and S-Series, Storm Control limits only ingress broadcast traffic, but still on all
interfaces.
• From INTERFACE and CONFIGURATION mode: the INTERFACE mode configuration overrides
the CONFIGURATION mode configuration.
FTOS Behavior: On the E-Series, when broadcast Storm Control is enabled on an interface or
globally on ingress and DSCP marking is enabled and set to DSCP=1 is configured for data traffic, the
traffic is queued to Queue 1 instead of Queue 0.
On the E-Series, suppress Layer 3 all-hosts and subnet storm-control broadcast percentage INTERFACE
broadcasts on ingress if they exceed a user-defined partial-percentage [in | out]
limit.
On the C-Series and S-Series, suppress Layer 3 all-host storm-control broadcast INTERFACE
and subnet broadcasts on ingress if they exceed a packets-per-second in
user-defined limit.
• On the E-Series, enabling Storm Control from CONFIGURATION mode limits ingress and egress
broadcast traffic on all interfaces.
• On the C-Series and S-Series, enabling Storm Control from CONFIGURATION mode limits only
ingress broadcast traffic, but still on all interfaces.
On the E-Series, suppress Layer 3 all-hosts and subnet storm-control broadcast percentage CONFIGURATION
broadcasts on ingress and egress if they exceed a partial-percentage [in | out]
user-defined limit.
On the C-Series and S-Series, suppress Layer 3 all-host storm-control broadcast CONFIGURATION
and subnet broadcasts on ingress if they exceed a packets-per-second in
user-defined limit.
These show commands can be entered with or without the interface option. Without the interface option,
storm control configuration information for the entire Dell Force10 platform is displayed.
To display the storm control configuration of a particular interface, use the interface option along with the
interface-type keyword and the slot and port information.
The following example uses the show storm-control broadcast command to display the storm control
configuration on a Gigabit Ethernet interface on port 11, in slot 11 of an E-Series platform.
The following example displays the output of the show storm-control broadcast command on a C-Series
platform.
FTOS#
The following example displays the output from the show storm-control multicast command on a S-Series
platform
FTOS#
The following example displays the output from the show storm-control unknown-unicast command on a
C-Series platform
FTOS#
1048
|
Broadcast Storm Control
52
Spanning Tree Protocol
Spanning Tree Protocol is supported on platforms: ces
STP is supported on the E-Series ExaScale platform with FTOS 8.1.1.2 and later.
Protocol Overview
Spanning Tree Protocol (STP) is a Layer 2 protocol—specified by IEEE 802.1d—that eliminates loops in a
bridged topology by enabling only a single path through the network. By eliminating loops, the protocol
improves scalability in a large network and enables you to implement redundant paths, which can be
activated upon the failure of active paths. Layer 2 loops, which can occur in a network due to poor network
design and without enabling protocols like xSTP, can cause unnecessarily high switch CPU utilization and
memory consumption.
R1 R2
R1(conf)# int range gi 1/1 - 4
R1(conf-if-gi-1/1-4)# switchport 1/3 2/1
R1(conf-if-gi-1/1-4)# no shutdown
R1(conf-if-gi-1/1-4)#show config
! 1/4 2/2
interface GigabitEthernet 1/1
no ip address 1/1 1/2 2/3 2/4
switchport
no shutdown
!
interface GigabitEthernet 1/2
no ip address
switchport
no shutdown
! 3/1 3/2 3/3
interface GigabitEthernet 1/3
no ip address
switchport
no shutdown 3/4
!
interface GigabitEthernet 1/4
no ip address R3
switchport
no shutdown
Verify that an interface is in Layer 2 mode and enabled using the show config command from INTERFACE
mode.
Note: To disable STP globally for all Layer 2 interfaces, enter the disable command from PROTOCOL
SPANNING TREE mode.
Verify that Spanning Tree is enabled using the show config command from PROTOCOL SPANNING
TREE mode.
When you enable Spanning Tree, all physical, VLAN, and port-channel interfaces that are enabled and in
Layer 2 mode are automatically part of the Spanning Tree topology.
• Only one path from any bridge to any other bridge participating in STP is enabled.
• Bridges block a redundant path by disabling one of the link ports.
root
R1 R2
1/3 Forwarding 2/1
View the Spanning Tree configuration and the interfaces that are participating in STP using the show
spanning-tree 0 command from EXEC privilege mode. If a physical interface is part of a port channel, only
the port channel is listed in the command output.
In FTOS versions prior to 7.6.1.0, the command no spanning tree disables Spanning Tree on the interface,
however, BPDUs are still forwarded to the RPM, where they are dropped. Beginning in FTOS version 7.6.1.0,
the command no spanning tree disables Spanning Tree on the interface, and incoming BPDUs are dropped at
the line card instead of at the RPM, which frees processing resources. This behavior is called Layer 2 BPDU
filtering and is available for STP, RSTP, PVST+, and MSTP.
Note: Dell Force10 recommends that only experienced network administrators change the Spanning Tree
parameters. Poorly planned modification of the Spanning Tree parameters can negatively impact network
performance.
Change the forward-delay parameter (the wait time before the forward-delay seconds PROTOCOL
interface enters the forwarding state). SPANNING TREE
• Range: 4 to 30
• Default: 15 seconds
Change the hello-time parameter (the BPDU transmission interval). hello-time seconds PROTOCOL
Note: With large configurations (especially those with more SPANNING TREE
ports) Dell Force10 recommends that you increase the
hello-time.
Range: 1 to 10
Default: 2 seconds
Change the max-age parameter (the refresh interval for configuration max-age seconds PROTOCOL
information that is generated by recomputing the Spanning Tree SPANNING TREE
topology).
Range: 6 to 40
Default: 20 seconds
View the current values for interface parameters using the show spanning-tree 0 command from EXEC
privilege mode. See Figure 52-5.
Enabling PortFast
The PortFast feature enables interfaces to transition to a forwarding state and start to transmit traffic
approximately 30 seconds sooner.
Interfaces forward frames by default until they receive a BPDU that indicates that they should behave
otherwise; they do not go through the Learning and Listening states. The bpduguard shutdown-on-violation
option causes the interface hardware to shut down when it receives a BPDU. When only bpduguard is
configured, although the interface is placed in an Error Disabled state when receiving the BPDU, the
physical interface remains up and spanning-tree will drop packets in the hardware after a BPDU violation.
BPDUs are dropped in the software after receiving the BPDU violation.
Caution: Enable PortFast only on links connecting to an end station. PortFast can cause loops if it is enabled on an
interface connected to a network.
Verify that PortFast is enabled on a port using the show spanning-tree command from the EXEC privilege
mode or the show config command from INTERFACE mode; Dell Force10 recommends using the show
config command, as shown in Figure 52-7.
The BPDU Guard feature blocks an edge port upon receiving a BPDU to prevent network disruptions, and
FTOS displays Message 1.
Caution: Do not enable Portfast BPDU guard and loop guard at the same time on a port. Enabling both features
may result in a port that remains in a blocking state and prevents traffic from flowing through it. For example, when
Portfast BPDU guard and loop guard are both configured:
• If a BPDU is received from a remote device, BPDU guard places the port in an err-disabled
blocking state and no traffic is forwarded on the port.
• If no BPDU is received from a remote device, loop guard places the port in a
loop-inconsistent blocking state and no traffic is forwarded on the port.
Enable BPDU Guard using the option bpduguard when enabling PortFast or EdgePort. Configure the
bpduguard shutdown-on-violation option to cause the interface hardware to shut down when it receives a
BPDU. Otherwise with only the option enabled, although the interface is placed in an Error Disabled state
when receiving the BPDU, the physical interface remains up and spanning-tree will only drop packets
after a BPDU violation.
Dell Force10 system is configured with Portfast. If the switch is connected to the hub, the BPDUs that the
switch generates might trigger an undesirable topology change. If BPDU Guard is enabled, when the edge
port receives the BPDU, the BPDU will be dropped, the port will be blocked, and a console message will
be generated.
Note: Note that unless the shutdown-on-violation option is enabled, spanning-tree only drops packets
after a BPDU violation; the physical interface remains up, as shown below.
FTOS(conf-if-gi-0/7)#do show spanning-tree rstp brief
Executing IEEE compatible Spanning Tree Protocol
Root ID Priority 32768, Address 0001.e805.fb07
Root Bridge hello time 2, max age 20, forward delay 15
Bridge ID Priority 32768, Address 0001.e85d.0e90
Configured hello time 2, max age 20, forward delay 15
Interface Designated
Name PortID Prio Cost Sts Cost Bridge ID PortID
---------- -------- ---- ------- --- ------- -------------------- --------
Gi 0/6 128.263 128 20000 FWD 20000 32768 0001.e805.fb07 128.653
Gi 0/7 128.264 128 20000 EDS 20000 32768 0001.e85d.0e90 128.264
Interface
Name Role PortID Prio Cost Sts Cost Link-type Edge
---------- ------ -------- ---- ------- --- ------- --------- ----
Gi 0/6 Root 128.263 128 20000 FWD 20000 P2P No
Gi 0/7 ErrDis 128.264 128 20000 EDS 20000 P2P No
FTOS(conf-if-gi-0/7)#do show ip int br gi 0/7
Interface IP-Address OK Method Status Protocol
GigabitEthernet 0/7 unassigned YES Manual up up
To verify the Portfast BPDU loop guard configuration on a port or port-channel interface, enter the show
spanning-tree 0 guard [interface interface]
command in global configuration mode.
FTOS Behavior: BPDU Guard and BPDU filtering (see Removing an Interface from the Spanning
Tree Group on page 1054) both block BPDUs, but are two separate features.
BPDU Guard:
• is used on edgeports and blocks all traffic on edgeport if it receives a BPDU
• drops the BPDU after it reaches the RPM and generates a console message
BPDU Filtering:
• disables Spanning Tree on an interface
• drops all BPDUs at the line card without generating a console message
Assign a number as the bridge priority or designate it as the bridge-priority {priority-value | PROTOCOL
root or secondary root. primary | secondary} SPANNING TREE
priority-value range: 0 to 65535. The lower the number
assigned, the more likely this bridge will become the root
bridge. The default is 32768.
• The primary option specifies a bridge priority of 8192.
• The secondary option specifies a bridge priority of 16384.
View only the root information using the show spanning-tree root command (see Figure 52-9) from EXEC
privilege mode.
Because any switch in an STP network with a lower priority can become the root bridge, the forwarding
topology may not be stable. The location of the root bridge can change, resulting in unpredictable network
behavior. The STP root guard feature ensures that the position of the root bridge does not change.
In STP topology 3 (Figure 52-10 lower middle), if the root guard feature is enabled on the STP port on
Switch C that connects to device D, and device D sends a superior BPDU that would trigger the election of
device D as the new root bridge, the BPDU is ignored and the port on Switch C transitions from a
forwarding to a root-inconsistent state (shown by the green X icon). As a result, Switch A becomes the root
bridge.
All incoming and outgoing traffic is blocked on an STP port in a root-inconsistent state. After the timeout
period, the Switch C port automatically transitions to a forwarding state as soon as device D stops sending
BPDUs that advertise a lower priority.
If you enable a root guard on all STP ports on the links where the root bridge should not appear, you can
ensure a stable STP network topology and avoid bridging loops.
1 2
Port State:
STP Block
STP Root-Inconsistent
FTOS Behavior: The following conditions apply to a port enabled with STP root guard:
• Root guard is supported on any STP-enabled port or port-channel interface except when used as a stacking
port.
• Root guard is supported on a port in any Spanning Tree mode:
• Spanning Tree Protocol (STP)
• Rapid Spanning Tree Protocol (RSTP)
• Multiple Spanning Tree Protocol (MSTP)
• Per-VLAN Spanning Tree Plus (PVST+)
• When enabled on a port, root guard applies to all VLANs configured on the port.
• Root guard and loop guard cannot be enabled at the same time on an STP port. For example, if you
configure root guard on a port on which loop guard is already configured, the following error message is
displayed:
% Error: LoopGuard is configured. Cannot configure RootGuard.
• When used in an MSTP network, if root guard blocks a boundary port in the CIST, the port is also blocked
in all other MST instances.
To enable the root guard on an STP-enabled port or port-channel interface in instance 0, enter the
spanning-tree 0 rootguard command:
Enable root guard on a port or port-channel interface. spanning-tree {0 | mstp | rstp | INTERFACE
0: Enables root guard on an STP-enabled port assigned to pvst} rootguard
instance 0. INTERFACE
mstp: Enables root guard on an MSTP-enabled port. PORT-CHANNEL
rstp: Enables root guard on an RSTP-enabled port.
pvst: Enables root guard on a PVST-enabled port.
To disable STP root guard on a port or port-channel interface, enter the no spanning-tree 0 rootguard
command in an interface configuration mode.
To verify the STP root guard configuration on a port or port-channel interface, enter the show
spanning-tree 0 guard [interface interface] command in global configuration mode.
Configure all Spanning Tree types to be hitless using the command redundancy protocol xstp from
CONFIGURATION mode, as shown in Figure 52-11.
For example, in Figure 52-12 (STP topology 1 - upper left), Switch A is the root switch and Switch B
normally transmits BPDUs to Switch C. The link between Switch C and Switch B is in a blocking state.
However, if there is a unidirectional link failure (STP topology 1 - lower left), Switch C does not receive
BPDUs from Switch B. When the max-age timer expires, the STP port on Switch C becomes unblocked
and transitions to forwarding state. A loop is created as both Switch A and Switch C transmit traffic to
Switch B.
Note that in Figure 52-12 (STP topology 2 - upper right), a loop can also be created if the forwarding port
on Switch B becomes busy and does not forward BPDUs within the configured forward-delay time. As a
result, the blocking port on Switch C transitions to a forwarding state, and both Switch A and Switch C
transmit traffic to Switch B (STP topology 2 - lower right).
As soon as a BPDU is received on an STP port in a loop-inconsistent state, the port returns to a blocking
state. If you disable STP loop guard on a port in a loop-inconsistent state, the port transitions to an STP
blocking state and restarts the max-age timer.
1 2
1 2
Port State:
STP Loop-Inconsistent
No traffic is transmitted
FTOS Behavior: The following conditions apply to a port enabled with loop guard:
• Loop guard is supported on any STP-enabled port or port-channel interface.
• Loop guard is supported on a port or port-channel in any Spanning Tree mode:
•Spanning Tree Protocol (STP)
•Rapid Spanning Tree Protocol (RSTP)
•Multiple Spanning Tree Protocol (MSTP)
•Per-VLAN Spanning Tree Plus (PVST+)
• Root guard and loop guard cannot be enabled at the same time on an STP port. For example, if you
configure loop guard on a port on which root guard is already configured, the following error message is
displayed:
% Error: RootGuard is configured. Cannot configure LoopGuard.
• C-Series and E-Series only: Loop guard is supported on a C-Series or E-Series switch configured for
hitless STP (see Configuring Spanning Trees as Hitless on page 1064).
• Enabling Portfast BPDU guard and loop guard at the same time on a port results in a port that remains in a
blocking state and prevents traffic from flowing through it. For example, when Portfast BPDU guard and
loop guard are both configured:
- If a BPDU is received from a remote device, BPDU guard places the port in an err-disabled
blocking state and no traffic is forwarded on the port.
- If no BPDU is received from a remote device, loop guard places the port in a loop-inconsistent
blocking state and no traffic is forwarded on the port.
• When used in a PVST+ network, STP loop guard is performed per-port or per-port channel at a VLAN
level. If no BPDUs are received on a VLAN interface, the port or port-channel transitions to a
loop-inconsistent (blocking) state only for this VLAN.
To enable a loop guard on an STP-enabled port or port-channel interface, enter the spanning-tree 0
loopguard command:
Enable loop guard on a port or port-channel interface. spanning-tree {0 | mstp | rstp | INTERFACE
0: Enables loop guard on an STP-enabled port assigned to pvst} loopguard
instance 0. INTERFACE
mstp: Enables loop guard on an MSTP-enabled port. PORT-CHANNEL
rstp: Enables loop guard on an RSTP-enabled port.
pvst: Enables loop guard on a PVST-enabled port.
To disable STP loop guard on a port or port-channel interface, enter the no spanning-tree 0 loopguard
command in an INTERFACE configuration mode.
To verify the STP loop guard configuration on a port or port-channel interface, enter the show
spanning-tree 0 guard [interface interface] command in global configuration mode.
To verify the STP guard configured on port or port-channel interfaces, enter the show spanning-tree 0 guard
[interface interface] command.
System times and dates can be set and maintained through the Network Time Protocol (NTP). They are
also set through FTOS CLIs and hardware settings.
NTP is a fault-tolerant protocol that will automatically select the best of several available time sources to
synchronize to. Multiple candidates can be combined to minimize the accumulated error. Temporarily or
permanently insane time sources will be detected and avoided.
Dell Force10 recommends configuring NTP for the most accurate time. In FTOS, other time sources can
be configured (the hardware clock and the software clock).
• Clock offset represents the amount to adjust the local clock to bring it into correspondence with the
reference clock.
• Roundtrip delay provides the capability to launch a message to arrive at the reference clock at a
specified time.
• Dispersion represents the maximum error of the local clock relative to the reference clock.
Since most host time servers will synchronize via another peer time server, there are two components in
each of these three products, those determined by the peer relative to the primary reference source of
standard time and those measured by the host relative to the peer.
Each of these components are maintained separately in the protocol in order to facilitate error control and
management of the subnet itself. They provide not only precision measurements of offset and delay, but
also definitive maximum error bounds, so that the user interface can determine not only the time, but the
quality of the time as well.
In what may be the most common client/server model a client sends an NTP message to one or more
servers and processes the replies as received. The server interchanges addresses and ports, overwrites
certain fields in the message, recalculates the checksum and returns the message immediately. Information
included in the NTP message allows the client to determine the server time with respect to local time and
adjust the local clock accordingly. In addition, the message includes information to calculate the expected
timekeeping accuracy and reliability, as well as select the best from possibly several servers.
Following conventions established by the telephone industry [BEL86], the accuracy of each server is
defined by a number called the stratum, with the topmost level (primary servers) assigned as one and each
level downwards (secondary servers) in the hierarchy assigned as one greater than the preceding level.
FTOS synchronizes with a time-serving host to get the correct time. You can set FTOS to poll specific NTP
time-serving hosts for the current time. From those time-serving hosts, the system chooses one NTP host
with which to synchronize and serve as a client to the NTP host. As soon as a host-client relationship is
established, the networking device propagates the time information throughout its local network.
Protocol Overview
NTP message to one or more servers and processes the replies as received. The server interchanges
addresses and ports, fills in or overwrites certain fields in the message, recalculates the checksum and
returns it immediately. Information included in the NTP message allows each client/server peer to
determine the timekeeping characteristics of its other peers, including the expected accuracies of their
clocks. Using this information each peer is able to select the best time from possibly several other clocks,
update the local clock and estimate its accuracy.
Leap Status Type Precision Est. Error Est. Drift Rate Reference Reference Originate Recieve Transmit
Indicator Clock ID Timestamp Timestamp Timestamp Timestamp
Implementation Information
• Dell Force10 systems can only be an NTP client.
NTP is disabled by default. To enable it, specify an NTP server to which the Dell Force10 system will
synchronize. Enter the command multiple times to specify multiple servers. You may specify an unlimited
number of servers at the expense of CPU resources.
Specify the NTP server to which the Dell Force10 ntp server {hostname | ipv4-address | CONFIGURATION
system will synchronize. You may specify an IPv4 ipv6-address} [key keyid] [prefer]
or IPv6 address, or hostname that resolves to an [version number]
IPv4 or IPv6 address.
Display the system clock state with respect to NTP using the command show ntp status from EXEC
Privilege mode, as shown in Figure 53-2.
Figure 53-2. Displaying the System Clock State with respect to NTP
FTOS(conf)#do show ntp status
Clock is synchronized, stratum 2, reference is 192.168.1.1
frequency is -369.623 ppm, stability is 53.319 ppm, precision is 4294967279
reference time is CD63BCC2.0CBBD000 (16:54:26.049 UTC Thu Mar 12 2009)
clock offset is 997.529984 msec, root delay is 0.00098 sec
root dispersion is 10.04271 sec, peer dispersion is 10032.715 msec
peer mode is client
Display the calculated NTP synchronization variables received from the server that the system will use to
synchronize its clock using the command show ntp associations from EXEC Privilege mode, as shown in
Figure 53-3.
Periodically update the system hardware clock with the time ntp update-calendar CONFIGURATION
value derived from NTP.
To configure an interface to receive NTP broadcasts, use the following commands in the INTERFACE
mode:
Set the interface to receive NTP packets. ntp broadcast client INTERFACE
Table 53-1.
To view whether NTP is configured on the interface, use the show config command in the INTERFACE
mode. If ntp disable is not listed in the show config command output, then NTP is enabled. (The show
config command displays only non-default configuration information.)
To configure an IP address as the source address of NTP packets, use the following command in the
CONFIGURATION mode:
ntp source interface CONFIGURATION Enter the following keywords and slot/port or number information:
• For a 1-Gigabit Ethernet interface, enter the keyword
GigabitEthernet followed by the slot/port information.
• For a loopback interface, enter the keyword loopback followed by
a number between 0 and 16383.
• For a port channel interface, enter the keyword lag followed by a
number from 1 to 255 for TeraScale and ExaScale, 1 to 32 for
EtherScale.
• For a SONET interface, enter the keyword sonet followed by the
slot/port information.
• For a 10-Gigabit Ethernet interface, enter the keyword
TenGigabitEthernet followed by the slot/port information.
• For a VLAN interface, enter the keyword vlan followed by a
number from 1 to 4094.
E-Series ExaScale platforms support 4094 VLANs with FTOS
version 8.2.1.0 and later. Earlier ExaScale supports 2094
VLANS.
To view the configuration, use the show running-config ntp command (Figure 38) in the EXEC privilege
mode.
FTOS Behavior: FTOS versions 8.2.1.0 and later use an encryption algorithm to store the
authentication key that is different from previous FTOS versions; beginning in version 8.2.1.0, FTOS
uses DES encryption to store the key in the startup-config when you enter the command ntp
authentication-key. Therefore, if your system boots with a startup-configuration from an FTOS versions
prior to 8.2.1.0 in which you have configured ntp authentication-key, the system cannot correctly
decrypt the key, and cannot authenticate NTP packets. In this case you must re-enter this command
and save the running-config to the startup-config.
To configure NTP authentication, use these commands in the following sequence in the
CONFIGURATION mode:
2 ntp authentication-key number md5 key CONFIGURATION Set an authentication key. Configure the
following parameters:
number: Range 1 to 4294967295. This
number must be the same as the number in
the ntp trusted-key command.
key: Enter a text string. This text string is
encrypted.
To view the NTP configuration, use the show running-config ntp command (Figure 40) in the EXEC
privilege mode. Figure 53-5 shows an encrypted authentication key. All keys are encrypted.
ntp server ip-address [key keyid] [prefer] CONFIGURATION Configure an NTP server. Configure the IP
[version number] address of a server and the following optional
parameters:
• key keyid: Configure a text string as the key
exchanged between the NTP server and
client.
• prefer: Enter the keyword to set this NTP
server as the preferred server.
• version number: Enter a number 1 to 3 as the
NTP version.
rtdel-root delay
rtdsp - round trip dispersion
refid - reference id
org -
rec - (last?) receive timestamp
xmt - transmit timestamp
• Leap Indicator (sys.leap, peer.leap, pkt.leap): This is a two-bit code warning of an impending leap
second to be inserted in the NTP time scale. The bits are set before 23:59 on the day of insertion and
reset after 00:00 on the following day. This causes the number of seconds (rollover interval) in the day
of insertion to be increased or decreased by one. In the case of primary servers the bits are set by
operator intervention, while in the case of secondary servers the bits are set by the protocol. The two
bits, bit 0 and bit 1, respectively, are coded as follows:
• Poll Interval: integer indicating the minimum interval between transmitted messages, in seconds as a
power of two. For instance, a value of six indicates a minimum interval of 64 seconds.
• Precision: integer indicating the precision of the various clocks, in seconds to the nearest power of two.
The value must be rounded to the next larger power of two; for instance, a 50-Hz (20 ms) or 60-Hz
(16.67ms) power-frequency clock would be assigned the value -5 (31.25 ms), while a 1000-Hz (1 ms)
crystal-controlled clock would be assigned the value -9 (1.95 ms).
• Set the time and date for the switch hardware clock
• Set the time and date for the switch software clock
• Set the timezone
• Set daylight savings time
• Set Daylight Saving Time Once
• Set Recurring Daylight Saving Time
calendar set time month day year EXEC Privilege Set the hardware clock to the current time and date.
time: Enter the time in hours:minutes:seconds. For the
hour variable, use the 24-hour format, for example,
17:15:00 is 5:15 pm.
Set the time and date for the switch software clock
You can change the order of the month and day parameters to enter the time and date as time day month
year. You cannot delete the software clock.
clock set time month day year EXEC Privilege Set the system software clock to the current time and
date.
time: Enter the time in hours:minutes:seconds. For the
hour variable, use the 24-hour format, for example,
17:15:00 is 5:15 pm.
Coordinated Universal Time (UTC) is the time standard based on the International Atomic Time standard,
commonly known as Greenwich Mean time. When determining system time, you must include the
differentiator between UTC and your local timezone. For example, San Jose, CA is the Pacific Timezone
with a UTC offset of -8.
clock timezone timezone-name offset CONFIGURATION Set the clock to the appropriate timezone.
FTOS#conf
FTOS(conf)#clock timezone Pacific -8
FTOS(conf)#01:40:19: %RPM0-P:CP %CLOCK-6-TIME CHANGE: Timezone
configuration changed from "UTC 0 hrs 0 mins" to "Pacific -8 hrs
0 mins"
Set a date (and time zone) on which to convert the switch to daylight savings time on a one-time basis.
clock summer-time time-zone CONFIGURATION Set the clock to the appropriate time zone and daylight
date start-month start-day savings time.
start-year start-time end-month
end-day end-year end-time time-zone: Enter the three-letter name for the time zone.
[offset] This name is displayed in the show clock output.
FTOS(conf)#clock summer-time pacific date Mar 14 2009 00:00 Nov 7 2009 00:00
FTOS(conf)#02:02:13: %RPM0-P:CP %CLOCK-6-TIME CHANGE: Summertime configuration changed from
"none" to "Summer time starts 00:00:00 Pacific Sat Mar 14 2009;Summer time ends 00:00:00 pacific
Sat Nov 7 2009"
Set a date (and time zone) on which to convert the switch to daylight savings time on a specific day every
year.
If you have already set daylight savings for a one-time setting, you can set that date and time as the
recurring setting with the clock summer-time time-zone recurring command.
clock summer-time time-zone CONFIGURATION Set the clock to the appropriate timezone and adjust to
recurring start-week start-day daylight savings time every year.
start-month start-time end-week
end-day end-month end-time time-zone: Enter the three-letter name for the time zone.
[offset] This name is displayed in the show clock output.
FTOS(conf)#clock summer-time pacific recurring Mar 14 2009 00:00 Nov 7 2009 00:00 ?
FTOS(conf)#02:02:13: %RPM0-P:CP %CLOCK-6-TIME CHANGE: Summertime configuration changed from
"none" to "Summer time starts 00:00:00 Pacific Sat Mar 14 2009;Summer time ends 00:00:00 pacific
Sat Nov 7 2009"
Note: If you enter <CR> after entering the recurring command parameter, and you have already set a one-time daylight
saving time/date, the system will use that time and date as the recurring setting.
Feature Description
Uplink Failure Detection (UFD) provides detection of the loss of upstream connectivity and, if used with
NIC teaming, automatic recovery from a failed link.
A switch provides upstream connectivity for devices, such as servers. If a switch loses its upstream
connectivity, downstream devices also lose their connectivity. However, the devices do not receive a direct
indication that upstream connectivity is lost since connectivity to the switch is still operational.
UFD allows a switch to associate downstream interfaces with upstream interfaces. When upstream
connectivity fails, the switch disables the downstream links. Failures on the downstream links allow
downstream devices to recognize the loss of upstream connectivity.
For example, in Figure 54-1 Switches S1 and S2 both have upstream connectivity to Router R1 and
downstream connectivity to the server. UFD operation is shown in Steps A through C:
• In Step A, the server configuration uses the connection to S1 as the primary path. Network traffic flows
from the server to S1 and then upstream to R1.
• In Step B, the upstream link between S1 and R1 fails. The server continues to use the link to S1 for its
network traffic, but the traffic is not successfully switched through S1 because the upstream link is
down.
• In Step C, UFD on S1 disables the link to the server. The server then stops using the link to S1 and
switches to using its link to S2 to send traffic upstream to R1.
R1 R1 R1
X X
S1 S2 S1 S2 S1 S2
X
An enabled uplink-state group tracks the state of all assigned upstream interfaces. Failure on an upstream
interface results in the automatic disabling of downstream interfaces in the uplink-state group. As a result,
downstream devices can execute the protection or recovery procedures they have in place to establish
alternate connectivity paths as shown in Figure 54-2.
Core
Network
Layer 3 Network
When an upstream
port-channel link goes X
down ...
Primary links:
Backup links:
UFD brings down a X Uplink-state groups:
downstream link in
the same uplink-
state group ...
If only one of the upstream interfaces in an uplink-state group goes down, a specified number of
downstream ports associated with the upstream interface are put into a link-down state. This number is
user-configurable and is calculated by the ratio of upstream port bandwidth to downstream port bandwidth
in the same uplink-state group. This calculation ensures that there are no traffic drops due to insufficient
bandwidth on the upstream links to the routers/switches.
By default, if all upstream interfaces in an uplink-state group go down, all downstream interfaces in the
same uplink-state group are put into a link-down state.
Using UFD, you can configure the automatic recovery of downstream ports in an uplink-state group when
the link status of an upstream port changes. The tracking of upstream link status does not have a major
impact on CPU usage.
When you configure Uplink Failure Detection, the following conditions apply:
• You can configure up to sixteen uplink-state groups. By default, no uplink-state groups are created.
An uplink-state group is considered to be operationally up if it has at least one upstream interface in
the link-up state.
An uplink-state group is considered to be operationally down if it has no upstream interfaces in the
link-up state. No uplink-state tracking is performed when a group is disabled or in an operationally
down state.
• You can assign physical port or port-channel interfaces to an uplink-state group.
You can assign an interface to only one uplink-state group. Each interface assigned to an uplink-state
group must be configured as either an upstream or downstream interface, but not both.
You can assign individual member ports of a port channel to the group. An uplink-state group can con-
tain either the member ports of a port channel or the port channel itself, but not both.
If you assign a port channel as an upstream interface, the port channel interface enters a link-down
state when the number of port-channel member interfaces in a link-up state drops below the configured
Minimum Number of Members parameter.
• If one of the upstream interfaces in an uplink-state group goes down, either a user-configurable set of
downstream ports or all the downstream ports in the group are put in an operationally down state with
an UFD Disabled error. The order in which downstream ports are disabled is from the lowest
numbered port to the highest.
If one of the upstream interfaces in an uplink-state group that was down comes up, the set of UFD-dis-
abled downstream ports (which were previously disabled due to this upstream port going down) are
brought up and the UFD Disabled error is cleared.
• If an uplink-state group is disabled, the downstream interfaces are not disabled regardless of the state
of the upstream interfaces.
If an uplink-state group has no upstream interfaces assigned, downstream interfaces cannot be disabled
when an upstream link goes down.
• To enable the debug messages for events related to a specified uplink-state group or all groups, enter
the debug uplink-state-group [group-id] command, where group-id is 1 to 16.
To turn off debugging event messages, enter the no debug uplink-state-group [group-id] command.
For an example of debug log messages, see Message 1.
3 downstream disable links Configures the number of downstream links in the uplink-state
{number | all} group that will be disabled (Oper Down state) if one upstream link
in the group goes down.
Command Mode: number specifies the number of downstream links to be brought
UPLINK-STATE-GROUP down. Range: 1 to 1024.
all brings down all downstream links in the group.
Default: No downstream links are disabled when an upstream link
goes down.
Note: Downstream interfaces in an uplink-state group are put into a
link-down state with an UFD-Disabled error message only when all
upstream interfaces in the group go down.
To revert to the default setting, enter the no downstream
disable links command.
clear ufd-disable {interface interface | Re-enables a downstream interface on the switch/router that is in a
uplink-state-group group-id } UFD-disabled error state so that it can send and receive traffic.
Command Mode: CONFIGURATION For interface, enter one of the following interface types:
Fast Ethernet: fastethernet {slot/port | slot/port-range}
1-Gigabit Ethernet: gigabitethernet {slot/port |slot/port-range}
10-Gigabit Ethernet:
tengigabitethernet {slot/port |slot/port-range}
Port channel: port-channel {1-512 | port-channel-range}
Where port-range and port-channel-range specify a range of ports
separated by a dash (-) and/or individual ports/port channels in any
order; for example:
gigabitethernet 1/1-2,5,9,11-12
port-channel 1-3,5
A comma is required to separate each port and port-range entry.
uplink-state-group group-id re-enables all UFD-disabled
downstream interfaces in the group. Valid values are 1 to 16.
Message 1 Syslog Messages before and after entering clear ufd-disable uplink-state-group Command
02:37:29: %RPM0-P:CP %IFMGR-5-OSTATE_DN: Changed uplink state group state to down: Group 3
02:37:29: %RPM0-P:CP %IFMGR-5-OSTATE_DN: Downstream interface set to UFD error-disabled: Te
13/6
02:37:29: %RPM0-P:CP %IFMGR-5-OSTATE_DN: Changed interface state to down: Te 13/6
To display information on the Uplink Failure Detection feature, enter any of the following show
commands:
show uplink-state-group [group-id] [detail] Displays status information on a specified uplink-state group or all
Command Mode: EXEC groups. Valid group-id values are 1 to 16.
detail displays additional status information on the upstream and
downstream interfaces in each group (see Figure 54-3).
show interfaces interface Displays the current status of a port or port-channel interface assigned
Command Mode: EXEC to an uplink-state group.
interface specifies one of the following interface types:
Fast Ethernet: Enter fastethernet slot/port.
1-Gigabit Ethernet: Enter gigabitethernet slot/port.
10-Gigabit Ethernet: Enter tengigabitethernet slot/port.
Port channel: Enter port-channel {1-512}.
If a downstream interface in an uplink-state group has been disabled
(Oper Down state) by uplink-state tracking because an upstream port
went down, the message error-disabled[UFD] is displayed in the
output (see Figure 54-4).
show running-config uplink-state-group Displays the current configuration of all uplink-state groups
[group-id] (Figure 54-5) or a specified group (Figure 54-6).
Command Mode: EXEC Valid group-id values are 1 to 16.
Or
show configuration
Command Mode: UPLINK-STATE-GROUP
1098
|
Upgrade Procedures
56
VLAN
VLANs are supported on platforms: ces
This chapter contains the following configuration topics:
VLAN | 1099
Virtual LANs (VLANs) are a cost-effective method of segmenting and organizing a network. A single
www.dell.com | support.dell.com
switch can be divided into multiple broadcast domains so that devices can be grouped and isolated; each
logical segment is virtual LAN. Applying VLANs reduces broadcast traffic, introduces flexibility in the
placement of devices on the network, and increases network security by allowing separate policies to be
applied to each group.
On a LAN users are bound to a physical location VLANs can logically organize users
and performance is reduced with a large number of users into groups increasing performance
Port-based VLANs
On FTOS, a VLAN is a user-defined group of ports (there is also the concept of protocol-based VLANs).
Ports in different VLANs do not communicate unless routing is configured between them. A port may
belong to more than one VLAN. Typically, ports connected to a host belong to only one VLAN, and ports
on an inter-switch link belong to more than one VLAN; these ports are sometimes called trunk ports.
Ports of an inter-switch
link typically belong to
multiple VLANs
VLAN 100
VLAN 200
1100 | VLAN
VLAN Tagging
Since a port may belong to more than one VLAN, the switch must be able to identify the VLAN two which
a broadcast frame belongs. For this case, IEEE 802.1Q defines a method of marking frames to indicate the
VLAN on which the frame originated.
The marker, called a VLAN tag, is 4 bytes and is inserted after the source MAC in the Ethernet frame
header, as shown in Figure 56-2. The tag is preserved as the frame moves through the network so that
intermediate switches can forward the frame appropriately.
Ports that belong to more than one VLAN insert VLAN tags into frames and so they are called tagged
ports. Ports that belong to a single VLAN, do not insert VLAN tags into frames and are called untagged
ports. When you add a port to a VLAN, you must specify whether the port should be tagged or untagged.
Ports on either side of the link must have the same tagged/untagged designation, and if tagged, must
belong to the same VLAN. Else, the frame is dropped.
VLAN | 1101
Figure 56-4. Switch Behavior for Tagged/Untagged Port Mismatch
www.dell.com | support.dell.com
Default VLAN
The Default VLAN and is part of the system startup configuration, and is by default VLAN 1. You may
make another VLAN the default VLAN. The default VLAN cannot be deleted, disabled, or configured
(you cannot assign it an IP address), and only untagged interfaces can belong to it.
Implementation Information
• FTOS supports up to 4093 port-based VLANs plus 1 Default VLAN.
• E-Series ExaScale FTOS versions earlier than 8.2.1.0 for the E-Series ExaScale support 2094 VLANs.
Configuring VLANs
Configuring a VLAN is a two-step process:
1102 | VLAN
• Set the Null VLAN as the Default VLAN on page 1107
• Enable VLAN Interface Counters on page 1108
• 802.1X
• Chapter 17, GARP VLAN Registration Protocol.
• Chapter 46, Service Provider Bridging
• Chapter 40, Per-VLAN Spanning Tree Plus.
Create a VLAN
A VLAN is created when you assign it a VLAN ID.
FTOS#show vlan
A VLAN is active only if the VLAN contains interfaces and those interfaces are up. VLAN 1 is inactive
because it contains the interfaces that are not up. When you delete a VLAN (no interface vlan vlan-id), any
interfaces assigned to that VLAN are reassigned to the default VLAN as untagged.
VLAN | 1103
Assign Interfaces to VLANs
www.dell.com | support.dell.com
A port may either be an untagged member of a single VLAN, or a tagged member of perhaps multiple
VLANs.
• Untagged Ports — ports that do not append an 802.1Q VLAN tag to frames on egress, and do not
accept tagged frames on ingress (tagged frames are dropped). Untagged ports must be connected to
VLAN-unaware devices.
• Tagged Ports — ports that append an 802.1Q tag to frames on egress, and accept only tagged frames
on ingress (untagged frames are dropped). Tagged ports must be connected to VLAN-aware devices.
When you place configure an enabled port as a switchport, the port is placed in the default VLAN. To
remove a switchport from the default VLAN, remove the switchport configuration. To move the port to
another VLAN, add it to the desired VLAN as either a tagged or untagged member.
FTOS(conf)#int vlan 4
FTOS(conf-if-vlan)#tagged po 1
FTOS(conf-if-vlan)#show conf
!
interface Vlan 4
no ip address
tagged Port-channel 1
1104 | VLAN
Step Task Command Syntax Command Mode
FTOS#show vlan
Note: The shutdown command marks a physical interface as unavailable for traffic. Disabling a VLAN
or a port-channel results in a different behavior. When a VLAN is disabled, the Layer 3 functions within
that VLAN are disabled, but Layer 2 traffic continues to flow.
VLAN | 1105
Figure 56-5. Communicating between VLANs
www.dell.com | support.dell.com
VLAN 100
10.11.100.1/24 VLAN 200
10.11.200.1/24
Ports that are an untagged and tagged member concurrently are called hybrid ports; physical ports and
port-channels may be hybrid ports. On a hybrid port, the VLAN of which the port is an untagged member
is the native VLAN.
A Native VLAN is useful on trunk ports, which receive both tagged and untagged traffic (a trunk port is a
port that carries traffic for one or more VLANs on the switch). The classic example is a VOIP phone and a
PC connected to the same port of a switch, where the VOIP phone generates packets tagged with VLAN
ID = VOICE VLAN, and the PC generates untagged packets.
1106 | VLAN
To configure a port so that it has a native VLAN:
4 Add the interface as a member of one or more VLANs. [tagged | untagged] VLAN INTERFACE
Make a VLAN other than VLAN 1 the default VLAN. default vlan-id CONFIGURATION
Disable the default VLAN, so that all ports belong to default-vlan disable CONFIGURATION
the Null VLAN until configured as a member of another Default: the default VLAN is enabled
VLAN. (no default-vlan disable).
VLAN | 1107
Enable VLAN Interface Counters
www.dell.com | support.dell.com
Configure ingress, egress or both counters enable vlan-counter [ingress | egress | all] CONFIGURATION
for VLAN interfaces.
1108 | VLAN
57
Virtual Routing and Forwarding (VRF)
Virtual Routing and Forwarding (VRF) (VRF) is supported only on platform: e
VRF allows a physical router to partition itself into multiple Virtual Routers (VRs). The control and data
plane are isolated in each VR so that traffic does NOT flow across VRs.Virtual Routing and Forwarding
(VRF) allows multiple instances of a routing table to co-exist within the same router at the same time.
VRF improves functionality by allowing network paths to be segmented without using multiple devices.
Using VRF also increases network security and can eliminate the need for encryption and authentication
due to traffic segmentation. Internet service providers (ISPs) often take advantage of VRF to create
separate virtual private networks (VPNs) for customers; VRF is also referred to as VPN routing and
forwarding.
VRF is implemented in a network device by having a distinct Forwarding Information Base (FIB) per VRF
instance. A network device has the ability to configure different virtual routers, so that each has its own
FIB that is not accessible to any other virtual router instance on the same device.
VRF acts like a logical router; while a physical router may include many routing tables, a VRF instance
uses only a single routing table. VRF uses a forwarding table that designates the next hop for each data
packet, a list of devices that may be called upon to forward the packet, and a set of rules and routing
protocols that govern how the packet is forwarded. These VRF forwarding tables prevent traffic from
being forwarded outside a specific VRF path and also keep out traffic that should remain outside the VRF
path.
VRF uses interfaces to distinguish routes for different VRF instances. Interfaces in a VRF can be either
physical (Ethernet port or port channel) or logical (VLANs). Starting in release 8.4.1.0, you can configure
identical or overlapping IP subnets on different interfaces if each interface belongs to a different VRF
instance.
Edge
Routers
Provider
Edge Router
with VRF
Although there is no restriction on the number of VLANs that can be assigned to a VRF instance, the total
number of routes supported in VRF is limited by the size of the IPv4 FIB table in the CAM.
VRF is implemented in a network device by using Forwarding Information Bases (FIBs). Each VRF uses
one FIB.
A network device may have the ability to configure different virtual routers, where each one has its own
FIB that is not accessible to any other virtual router instance on the same device.
VRF supports route redistribution between routing protocols (including static routes) only when the routes
are within the same VRF.
FTOS uses both the VRF name and VRF ID to manage VRF instances. The VRF name and VRF ID
number are assigned using the ip vrf command. The VRF ID is displayed in show ip vrf command output.
The VRF ID is not exchanged between routers. VRF IDs are local to a router.
VRF supports some routing protocols only on the default VRF (default-vrf) instance. Table 57-1 displays
the software features supported in VRF and whether they are supported on all VRF instances or only the
default VRF.
Table 57-1.
CAM Profiles
Layer 3 CAM resources are shared among all VRF instances. To ensure that each VRF instance has
sufficient CAM space:
• On an E-Series Terascale platform, use the cam-profile ipv4-vrf or cam-profile ipv4-v6-vrf command and
reload the system command to activate the VRF CAM profile for IPv4 or IPv6.
Table 57-2 and Table 57-3 each show the required CAM settings for IPv4 and IPv6.
Note: When configuring the IPv6 CAM profile, the CAM tables that are carved within l2acl and ipv4Flow
tables remain at default values. For more information on the CAM and CAM profiling, refer to Chapter 11,
“Content Addressable Memory,” on page 281
DHCP
DHCP requests are not forwarded across VRF instances. The DHCP client and server must be on the same
VRF instance.
IP addressing
Starting in release 8.4.1.0, you can configure identical or overlapping IP subnets on different interfaces if
each interface belongs to a different VRF instance. In previous releases, VRF did not support the same IP
address on multiple interfaces in different VRF instances.
VRF Configuration
Note: Starting in FTOS 8.4.2.1, when VRF microcode is loaded on an E-Series ExaScale or TeraScale
router, the ip vrf [default-vlan | vrf-name] command is deprecated, and is replaced by the ip vrf vrf-name
vrf-id command. The ip vrf-vlan-block, start-vlan-id default-vrf, and start-vlan-id vlan-start-id commands are
also deprecated.
On an E-series Exascale platform, configure the CAM size used to support VRF. Then enable VRF
microcode for use with the CAM profile and reload the system to activate the profile. You can set the CAM
size to 40M (default) which supports both IPv4 and IPv6 or 10M which supports only IPv4.
Enable VRF
VRF is enabled by default when VRF microcode is loaded on an E-Series ExaScale or TeraScale router.
On an E-Series router, Dell Force10 VRF supports up to 15 VRF instances: 1 to 14 and the default VRF
(0).
A VRF name is not exchanged between routers. VRF IDs are local to a router. The following features and
functionality are supported only on the default VRF (0) instance:
• ISIS
• BGP
• RIP
• IPv6
• Multicast
• Static ARP
Note: Starting in FTOS 8.4.2.1, when VRF microcode is loaded on a E-Series ExaScale or TeraScale
router, the ip vrf [default-vlan | vrf-name] command is deprecated, and is replaced by the ip vrf vrf-name
vrf-id command. The ip vrf-vlan-block, start-vlan-id default-vrf, and start-vlan-id vlan-start-id commands are
also deprecated.
Note: Starting in release 8.4.1.0, you can configure an IP address or subnet on a physical or VLAN
interface that overlaps the same IP address or subnet configured on another interface only if the
interfaces are assigned to different VRFs. If two interfaces are assigned to the same VRF, you cannot
configure overlapping IP subnets or the same IP address on them.
When you assign a VLAN interface to a VRF instance, the following conditions apply:
• VLANs assigned to the same VRF have the same MAC address. VLANs assigned to different VRFs
have different MAC addresses. The last four bits of a VLAN’s MAC address correspond to the VRF
ID configured with the ip vrf command.
• On a switch port on which multiple VLANs are assigned to different VRFs, the source MAC address
in packets routed on a VRF may not be the same as the MAC address distributed in ARP requests. As
a result, security applications running on neighboring routers that check the source MAC address in
incoming packets may find that the address does not match the ARP-learned MAC address.
• You can assign a static ARP only to a VLAN that is mapped to the default VRF (0) instance.
• By default, all VLANs (4096) are associated with the default VRF until you reassign them to a
non-default VRF with the ip vrf forwarding command. You can assign up to 4096 VLANs to a
non-default VRF instance.
• VLANs used with VRF must be Layer 3 VLANs. Layer 2 VLANs can be configured for non-VRF use.
Refer to Chapter 56, “VLAN,” on page 1099 for complete information.
• All VLAN member ports must be removed from a VLAN that you move from one VRF instance to
another.
OSPF routes are supported on all VRF instances. Refer to Chapter 32, Open Shortest Path First (OSPFv2
and OSPFv3) for complete OSPF configuration information.
Assign an OSPF process to a VRF instance . Return to CONFIGURATION mode to enable the OSPF
process. The OSPF Process ID is the identifying number assigned to the OSPF process, and the Router ID
is the IP address associated with the OSPF process..
Enable the OSPFv2 process globally for a VRF router ospf process-id vrf vrf name CONFIGURATION
instance.
Enter the VRF key word and instance name to tie the OSPF
instance to the VRF. All network commands under this OSPF
instance are subsequently tied to the VRF instance.
process-id range: 0-65535
Once the OSPF process and the VRF are tied together, the OSPF Process ID cannot be used again in the
system.
In a virtualized network that consists of multiple VRFs, various overlay networks can exist on a shared
physical infrastructure. Nodes (hosts and servers) that are part of the VRFs can be configured with IP static
routes for reaching specific destinations through a given gateway in a VRF. VRRP provides high
availability and protection for next-hop static routes by eliminating a single point of failure in the default
static routed network. For more information, refer to Chapter 58, “Virtual Router Redundancy Protocol
(VRRP),” on page 1127.
ip vrf default-vrf 0
ip vrf blue 1
ip vrf orange 2
ip vrf green 3
7/0 9/18
7/2 9/20
R2
R1 router ospf 1 vrf blue
router ospf 1 vrf blue
router-id 1.0.0.2
router-id 1.0.0.1
network 11.0.0.0/24 area 0
network 1.0.0.0/24 area 0
network 1.0.0.0/24 area 0
network 10.0.0.0/24 area 0
passive-interface GigabitEthernet 9/18
router ospf 2 vrf orange
router ospf 2 vrf orange
router-id 2.0.0.1
router-id 2.0.0.2
network 2.0.0.0/24 area 0
network 21.0.0.0/24 area 0
network 20.0.0.0/24 area 0
network 2.0.0.0/24 area 0
passive-interface GigabitEthernet 9/19
ip route vrf green 31.0.0.0/24 3.0.0.2
ip route vrf green 31.0.0.0/24 3.0.0.1
7/0 9/18
7/2 9/20
R1 interface TenGigabitEthernet 3/0 R2
no ip address
switchport
no shutdown
ROUTER 1
============================================================================================
ROUTER 2
cam-profile ipv4-vrf microcode ipv4-vrf
!
ip vrf default-vrf 0
!
ip vrf blue 1
!
ip vrf orange 2
!
ip vrf green 3
!
interface TenGigabitEthernet 3/0
no ip address
switchport
no shutdown
!
interface GigabitEthernet 9/18
ip vrf forwarding blue
ip address 11.0.0.1/24
no shutdown
!
interface GigabitEthernet 9/19
ip vrf forwarding orange
ip address 21.0.0.1/24
no shutdown
!
interface GigabitEthernet 9/20
ip vrf forwarding green
ip address 31.0.0.1/24
no shutdown
!
interface Vlan 128
ip vrf forwarding blue
ip address 1.0.0.2/24
tagged TenGigabitEthernet 3/0
no shutdown
ROUTER 1
FTOS#show ip vrf
VRF-Name VRF-ID Interfaces
default-vrf 0 Gi 2/0-89,
Te 3/0-3,
Gi 4/0-89,
Gi 5/0-89,
Gi 7/3-47,
Gi 9/0-47,
Gi 10/0-47,
Gi 11/0-47,
Gi 12/0-47,
Gi 13/0-47,
Ma 0/0,
Ma 1/0,
Nu 0,
Vl 1
blue 1 Gi 7/0,
Vl 128
orange 2 Gi 7/1,
Vl 192
green 3 Gi 7/2,
Vl 256
ROUTER 1 continued
FTOS#show ip ospf 1 neighbor
Neighbor ID Pri State Dead Time Address Interface Area
1.0.0.2 1 FULL/DR 00:00:32 1.0.0.2 Vl 128 0
default-vrf 0 Gi1/0-89,
Te3/0-3,
Gi4/0-89,
Gi5/0-89,
Gi6/0-89,
Gi9/0-17,21-47,
Gi11/0-47,
Gi12/0-47,
Gi13/0-47,
Ma0/0,
Ma1/0,
Nu0,
Vl1
blue 1 Gi9/18,
Vl128
orange 2 Gi 9/19,
Vl 192
green 3 Gi 9/20,
Vl 256
ROUTER 2 continued
FForce10#show ip route vrf orange
• VRRP Overview
• VRRP Benefits
• VRRP Implementation
• VRRP Configuration
• Sample Configurations
Virtual Router Redundancy Protocol (VRRP) is designed to eliminate a single point of failure in a
statically routed network.
VRRP Overview
VRRP specifies a MASTER router that owns the next hop IP and MAC address for end stations on a LAN.
The MASTER router is chosen from the virtual routers by an election process and forwards packets sent to
the next hop IP address. If the MASTER router fails, VRRP begins the election process to choose a new
MASTER router and that new MASTER continues routing traffic.
VRRP uses the Virtual Router Identifier (VRID) to identify each virtual router configured The IP address
of the MASTER router is used as the next hop address for all end stations on the LAN. The other routers
represented by IP addresses are BACKUP routers.
VRRP packets are transmitted with the virtual router MAC address as the source MAC address. The MAC
address is in the following format: 00-00-5E-00-01-{VRID}. The first three octets are unchangeable. The
next two octets (00-01) indicate the address block assigned to the VRRP protocol, and are unchangeable.
The final octet changes depending on the VRRP Virtual Router Identifier and allows for up to 255 VRRP
routers on a network.
network 10.10.10.0 with the IP address of either Router A or Router B as their default router; their default
router is the IP Address configured on the virtual router. When any host on the LAN segment wants to
access the Internet, it sends packets to the IP address of the virtual router.
In Figure 58-1 below, Router A is configured as the MASTER router. It is configured with the IP address
of the virtual router and sends any packets addressed to the virtual router through interface GigabitEthernet
1/1 to the Internet. As the BACKUP router, Router B is also configured with the IP address of the virtual
router. If for any reason Router A becomes unavailable, VRRP elects a new MASTER Router. Router B
assumes the duties of Router A and becomes the MASTER router. At that time, Router B responds to the
packets sent to the virtual IP address.
All workstations continue to use the IP address of the virtual router to address packets destined to the
Internet. Router B receives and forwards them on interface GigabitEthernet 10/1. Until Router A resumes
operation, VRRP allows Router B to provide uninterrupted service to the users on the LAN segment
accessing the Internet.
Figure 58-1. Basic VRRP Configuration
INTERNET
Virtual IP Address
10.10.10.3
10.10.10.0/24
LAN Segment
FN0001_lp
For more detailed information on VRRP, refer to RFC 2338, Virtual Router Redundancy Protocol.
VRRP Implementation
On E-Series ExaScale and TeraScale routers, VRRP is implemented as follows:
• When VRF microcode is not loaded, VRRP supports an unlimited total number of VRRP groups on a
router and up to 255 VRRP groups on an interface (see Table 58-1).
• When VRF microcode is loaded (see Load the VRF CAM Profile on page 1115), VRRP supports an
unlimited total number of VRRP groups on a router and up to 15 VRRP groups on an interface (see
Table 58-1).
C-Series supports a total of 128 VRRP groups on the switch with varying number of maximum VRRP
groups per interface (Table 58-1).
S-Series supports a total of 120 VRRP groups on a switch with FTOS or a total of 20 VRRP groups when
using SFTOS. The S-Series supports varying number of maximum VRRP groups per interface
(Table 58-1).
Within a single VRRP group, up to 12 virtual IP addresses are supported. Virtual IP addresses can belong
to the primary or secondary IP address’ subnet configured on the interface. You can ping all the virtual IP
addresses configured on the Master VRRP router from anywhere in the local subnet.
Though FTOS on E-Series supports unlimited VRRP groups, default VRRP settings may affect the
maximum number of groups that can be configured and work efficiently, as a result of hardware throttling
VRRP advertisement packets reaching the RP2 processor on the E-Series, the CP on the C-Series, or the
FP on the S-Series. To avoid throttling VRRP advertisement packets, Dell Force10 recommends you to
increase the VRRP advertisement interval to a value higher than the default value of 1 second. The
recommendations are as follows:
E-Series E-Series
Total VRRP Groups E-Series C-Series S-Series ExaScale TeraScale C-Series S-Series
E-Series E-Series
Total VRRP Groups E-Series C-Series S-Series ExaScale TeraScale C-Series S-Series
Between 1000 and 1200 7 seconds 7 seconds 7 seconds 512 255 100 100
Between 1200 and 1500 8 seconds 8 seconds 8 seconds 512 255 120 120
Note: 1500 VRRP groups are supported in FTOS Release 6.3.1.0 and later.
The recommendations in Table 58-1 may vary depending on various factors like ARP broadcasts, IP
broadcasts, or STP before changing the advertisement interval. When the number of packets processed by
RP2/CP/FP processor increases or decreases based on the dynamics of the network, the advertisement
intervals in may increase or decrease accordingly.
CAUTION: Increasing the advertisement interval increases the VRRP Master dead interval, resulting in an
increased failover time for Master/Backup election. Take extra caution when increasing the advertisement
interval, as the increased dead interval may cause packets to be dropped during that switch-over time.
VRRP version 3
VRRP version 3 defines VRRP for IPv6. The vrrp-ipv6-group command is used to create IPv6 VRRP
groups, and is similar to the vrrp-group command, which creates an IPv4 VRRP group and moves you from
INTERFACE mode to a group-specific VRRP command sub-mode.
In the VRRP mode, all VRRP commands are supported for IPv4 and IPv6, except for authentication-type
which is not supported for IPv6. Also, the following EXEC commands are different for IPv4 and IPv6:
• clear:
• IPv4: clear counters vrrp
• IPv6: clear counters vrrp ipv6
• debug:
• IPv4: debug vrrp
• IPv6: debug vrrp ipv6
• show:
• IPv4: show vrrp
• IPv6: show vrrp ipv6
For a complete listing of all commands related to VRRP, refer to FTOS Command Line Interface.
Starting in release 8.4.1.0, you can configure a VRRP group on an interface that belongs to a non-default
VRF instance.
Prerequisite: The interface on which you create the virtual interface must be enabled and configured with
a primary IP address.
To enable a Virtual Router, use the following command in the INTERFACE mode. To delete a VRRP
group, use the no vrrp-group vrid command in the INTERFACE mode.
FTOS(conf-if-gi-1/1)#show conf
!
interface GigabitEthernet 1/1
ip address 10.10.10.1/24
!
Note that the interface
vrrp-group 111
has an IP Address and is enabled
no shutdown
FTOS(conf-if-gi-1/1)#
• When VRF microcode is not loaded, VRRP supports an unlimited total number of VRRP groups on a
router and up to 255 VRRP groups on an interface (see Table 58-1).
• When VRF microcode is loaded (see Load the VRF CAM Profile on page 1115), VRRP supports an
unlimited total number of VRRP groups on a router and up to 15 VRRP groups on an interface (see
Table 58-1).
C-Series supports a total of 128 VRRP groups on the switch with varying number of maximum VRRP
groups per interface (Table 58-1).
S-Series supports a total of 120 VRRP groups on a switch with FTOS or a total of 20 VRRP groups when
using SFTOS. The S-Series supports varying number of maximum VRRP groups per interface
(Table 58-1).
To activate a VRRP Group on an interface (so that VRRP group starts transmitting VRRP packets),
configure at least one Virtual IP address in a VRRP group. The Virtual IP address is the IP address of the
Virtual Router and does not require the IP address mask.
You can configure up to 12 virtual IP addresses for a VRRP group (VRID). The following configuration
rules apply to a virtual IP address:
• A virtual IP address must be in the same subnet as the primary or secondary IP address configured on
the interface. Although a single VRRP group can contain virtual IP addresses belonging to multiple IP
subnets configured on the interface, Dell Force10 recommends that you configure virtual IP addresses
belonging to the same IP subnet for any one VRRP group.
For example, an interface (on which VRRP is to be enabled) contains a primary IP address of 50.1.1.1/24 and a
secondary IP address of 60.1.1.1/24. The VRRP Group (VRID 1) must contain virtual addresses belonging to
either subnet 50.1.1.0/24 or subnet 60.1.1.0/24, but not from both subnets (though FTOS allows the same).
Configure a Virtual IP address with these commands in the following sequence in the INTERFACE mode.
Note: After you enter the vrrp-group or vrrp-ipv6-group command, a message similar to the following is
displayed to confirm the VRID number used with the VRRP group and displayed in show vrrp command
output: The VRID used by the VRRP group is 41.
For information on how the VRID number changes when VRF microcode is loaded, see the Note in VRRP
on a VRF Interface on page 1142.
Figure 58-5. Command Example Display: show config for the Interface
FTOS(conf-if-gi-1/1)#show conf
!
interface GigabitEthernet 1/1
ip address 10.10.10.1/24
!
vrrp-group 111 Note that the Primary IP address
and the Virtual IP addresses are
priority 255
on the same subnet
virtual-address 10.10.10.1
virtual-address 10.10.10.2
virtual-address 10.10.10.3
!
vrrp-group 222
no shutdown
Note: show vrrp displays all of the active IPv4 groups, and show ipv6 vrrp displays all of the active IPv6
groups.
When the VRRP process completes its initialization, the State field contains either Master or Backup.
If two routers in a VRRP group come up at the same time and have the same priority value, the interface’s
physical IP addresses are used as tie-breakers to decide which is MASTER. The router with the higher IP
address will become MASTER.
Configure the VRRP Group’s priority with the following command in the VRRP mode:
Configure the priority for the VRRP INTERFACE -VRID priority priority
group.
Range: 1-255
Default: 100
Simple authentication of VRRP packets ensures that only trusted routers participate in VRRP processes.
When authentication is enabled, FTOS includes the password in its VRRP transmission, and the receiving
router uses that password to verify the transmission.
Note: All virtual routers in the VRRP group must be configured the same: authentication must be enabled
with the same password or authentication is disabled.
Configure simple authentication with the following command in VRRP configuration mode:
Note: As shown in Figure 58-9, the VRRP authentication password that you configure is displayed in
encrypted form in show running-config (EXEC Privilege) and show config (INTERFACE) command
output. To display the VRRP authentication password (as well as all other FTOS passwords) in clear text
in show command output, you must enter the no service password-encryption (CONFIGURATION)
command. To remove the currently configured VRRP authentication password, enter the no
authentication-type simple [encryption-type] password command.
Prevent the BACKUP router with the higher priority from becoming the MASTER router by disabling
preempt.
Note: All virtual routers in the VRRP group must be configured the same: all configured with preempt
enabled or configured with preempt disabled.
Since preempt is enabled by default, disable the preempt function with the following command in the
VRRP mode. Re-enable preempt by entering the preempt command. When preempt is enabled, it does not
display in the show commands, because it is a default setting.,
By default, the MASTER router transmits a VRRP advertisement to all members of the VRRP group every
1 second, indicating it is operational and is the MASTER router. If the VRRP group misses 3 consecutive
advertisements, then the election process begins and the BACKUP virtual router with the highest priority
transitions to MASTER.
Note: Dell Force10 recommends you to increase the VRRP advertisement interval to a value
higher than the default value of 1 second to avoid throttling VRRP advertisement packets. If you do
change the time interval between VRRP advertisements on one router, you must change it on all
participating routers.
Change that advertisement interval with the following command in the VRRP mode:
FTOS(conf-if-gi-1/1-vrid-111)#show conf
!
vrrp-group 111
advertise-interval 10
authentication-type simple 7 387a7f2df5969da4
no preempt
priority 255
virtual-address 10.10.10.1
virtual-address 10.10.10.2
virtual-address 10.10.10.3
virtual-address 10.10.10.10
FTOS(conf-if-gi-1/1-vrid-111)#
Each VRRP group can track changes in the status of up to 12 interfaces and up to 20 additional objects,
which may affect the priority of the VRRP group. If a tracked interface or object goes down, the VRRP
group’s priority is decreased by a default value of 10 (also known as cost). If the state of a tracked interface
or object goes up, the VRRP group’s priority is increased by 10.
The lowered priority of a VRRP group may trigger an election. Because Master/Backup VRRP routers are
selected based on the VRRP group’s priority, tracking interfaces and/or objects ensures that the best VRRP
router is the Master for a group. In object and interface tracking, the following conditions apply:
• The sum of the costs of all tracked interfaces and objects cannot equal or exceed the priority of the
VRRP group.
• If the VRRP group is configured as the Owner router (priority 255), tracking for the group is disabled,
irrespective of the state of the tracked interfaces and objects. The priority of the owner group always
remains as 255 and does not change.
For a virtual group, you can track the line-protocol state or the routing status of any of the following
interfaces with the interface interface parameter:
• 1-Gigabit Ethernet: Enter gigabitethernet slot/port in the track interface command (see Step 1 below).
• 10-Gigabit Ethernet: Enter tengigabitethernet slot/port.
• Port channel: Enter port-channel number, where valid port-channel numbers are:
• For the C-Series and S-Series, 1 to 128
• For the E-Series: 1 to 32 for EtherScale, 1 to 255 for TeraScale, and 1 to 512 for ExaScale
• SONET: Enter sonet slot/port.
• VLAN: Enter vlan vlan-id, where valid VLAN IDs are from 1 to 4094.
For a virtual group, you can also track the status of a configured object (track object-id command) by
entering its object number. See Object Tracking Configuration on page 681 for more information.
Note that you can configure a tracked object for a VRRP group (using the track object-id command in
INTERFACE-VRID mode) before you actually create the tracked object (using a track object-id command
in CONFIGURATION mode). However, no changes in the VRRP group’s priority will occur until the
tracked object is defined and determined to be down.
In addition, if you configure a VRRP group on an interface that belongs to a VRF instance and later
configure object tracking on an interface for the VRRP group, the tracked interface must belong to the
VRF instance.
Note: The sum of all the costs for all tracked interfaces and objects must be less than or equal to the
configured priority of the VRRP group.
Track 2
IPv6 route 2040::/64 metric threshold
Metric threshold is Up (STATIC/0/0)
5 changes, last change 00:02:16
Metric threshold down 255 up 254
First-hop interface is GigabitEthernet 13/2
Tracked by:
VRRP GigabitEthernet 7/30 IPv6 VRID 1
Track 3
IPv6 route 2050::/64 reachability
Reachability is Up (STATIC)
5 changes, last change 00:02:16
First-hop interface is GigabitEthernet 13/2
Tracked by:
VRRP GigabitEthernet 7/30 IPv6 VRID 1
vrrp-ipv6-group 1
track 2 priority-cost 20
track 3 priority-cost 30
virtual-address 2007::1
virtual-address fe80::1
no shutdown
VRRP is supported with Virtual Routing and Forwarding (VRF) only on platform: e
Starting in release 8.4.1.0, you can configure the VRRP feature on interfaces that belong to a non-default
Virtual Routing and Forwarding (VRF) instance on E-Series routers. In previous releases, the VRRP
feature was not supported on interfaces that were configured for VRF. For a sample VRRP configuration
on a VRF interface, see VRRP in VRF Configuration on page 1149.
The VRF feature allows a physical router to partition itself into multiple virtual routers (VRs) so that
multiple instances of a routing table can co-exist within the same router at the same time. The control and
data plane are isolated in each VR so that traffic does not flow across VRs. For more information, refer to
Chapter 57, “Virtual Routing and Forwarding (VRF),” on page 1109.
In a virtualized network that consists of multiple VRFs, various overlay networks can exist on a shared
physical infrastructure:
• The same IP addresses or overlapping IP subnets can exist in different VRFs. (If two interfaces are
assigned to the same VRF, you cannot configure overlapping IP subnets or the same IP address on
them.)
• The same VRRP virtual address can exist in different VRFs.
Nodes (hosts and servers) that are part of the VRFs can be configured with IP static routes for reaching
specific destinations through a given gateway in a VRF. VRRP can provide high availability and protection
for next-hop static routes by eliminating a single point of failure in the default static routed network.
• When VRF microcode is loaded in CAM, the VRID for a VRRP group is equal to 16 times the
vrrp-group vrid or vrrp-ipv6-group vrid number plus the ip vrf vrf-id number.
For example, if VRF microcode is loaded and VRRP group 10 is configured in VRF 2, the VRID used for
the VRRP group is (16 x 10) + 2, or 162. This VRID value is used in the lowest byte of the virtual MAC
address of the VRRP group and is also used for VRF routing.
Note that the actual VRID used by a VRRP group is displayed below the command line when you enter
the vrrp-group or vrrp-ipv6-group command in VRRP-group configuration mode, and in show vrrp
command output:
Figure 58-20. VRID used when VRF microcode is loaded
FTOS(conf)#ip vrf orange 2
FTOS(conf)#interface GigabitEthernet 3/0
FTOS(conf-if-gi-3/0)#ip vrf forwarding orange
FTOS(conf-if-gi-3/0)#ip address 1.1.1.1/24
FTOS(conf-if-gi-3/0)#vrrp-group 10
% Info: The VRID used by the VRRP group 10 in VRF 2 will be 162.
FTOS(conf-if-gi-3/0-vrid-162)#virtual-ip 1.1.1.10
FTOS(conf-if-gi-3/0-vrid-162)#exit The VRID used for the VRRP group
FTOS(conf-if-gi-3/0)#no shutdown is different from the VRID configured
with the vrrp-group command when
FTOS#show vrrp VRF microcode is loaded.
------------------
GigabitEthernet 3/0, IPv4 Vrrp-group: 10, VRID: 162, Version: 2, Net: 1.1.1.1
VRF: 2 orange
State: Master, Priority: 120, Master: 1.1.1.1 (local)
Hold Down: 0 sec, Preempt: TRUE, AdvInt: 1 sec
Adv rcvd: 0, Bad pkts rcvd: 0, Adv sent: 76, Gratuitous ARP sent: 1
Virtual MAC address:
00:00:5e:00:01:a2
Virtual IP address:
1.1.1.10
Authentication: (none)
Important: You must configure the same VRID on neighboring routers (Dell Force10 or non-Force10) in
the same VRRP group in order for all routers to interoperate.
R3#show vrrp
------------------
State Backup: R3 interface has the GigabitEthernet 3/21, VRID: 99, Net: 10.1.1.2
lower VRRP group priority (100) State: Backup, Priority: 100, Master: 10.1.1.1
Hold Down: 0 sec, Preempt: TRUE, AdvInt: 1 sec
Adv rcvd: 331, Bad pkts rcvd: 0, Adv sent: 0, Gratuitous ARP sent: 0
Virtual MAC address:
00:00:5e:00:01:63
Virtual IP address:
10.1.1.3
Authentication: (none)
R3#
10.1.1.1 10.1.1.2
GigE 2/31 GigE 3/21
R2 R3
VRID 99 10.1.1.3
Internet
R2#show vrrp
------------------
GigabitEthernet 2/31, VRID: 99, Net: 10.1.1.1
State: Master, Priority: 200, Master: 10.1.1.1 (local)
Hold Down: 0 sec, Preempt: TRUE, AdvInt: 1 sec
Adv rcvd: 0, Bad pkts rcvd: 0, Adv sent: 817, Gratuitous ARP sent: 1
Virtual MAC address:
00:00:5e:00:01:63
Virtual IP address:
10.1.1.3
Authentication: (none)
R2#
Router 3
R3(conf)#int gi 3/21
R3(conf-if-gi-3/21)#ip address 10.1.1.2/24
R3(conf-if-gi-3/21)#vrrp-group 99
R3(conf-if-gi-3/21-vrid-99)#virtual 10.1.1.3
R3(conf-if-gi-3/21-vrid-99)#no shut
R3(conf-if-gi-3/21)#show conf
!
interface GigabitEthernet 3/21
ip address 10.1.1.1/24
!
vrrp-group 99
virtual-address 10.1.1.3
no shutdown
R3(conf-if-gi-3/21)#end
R3#show vrrp
------------------
GigabitEthernet 3/21, VRID: 99, Net: 10.1.1.2
State: Backup, Priority: 100, Master: 10.1.1.1
Hold Down: 0 sec, Preempt: TRUE, AdvInt: 1 sec
Adv rcvd: 698, Bad pkts rcvd: 0, Adv sent: 0, Gratuitous ARP sent: 0
Virtual MAC address:
00:00:5e:00:01:63
Virtual IP address:
10.1.1.3
Authentication: (none)
Figure 58-22 shows an example of a VRRP for IPv6 configuration in which the IPv6 VRRP group consists
of two routers. This example does not contain comprehensive directions and is intended to provide
guidance for only a typical VRRP configuration. You can copy and paste from the example to your CLI.
Be sure you make the necessary changes to support your own IP addresses, interfaces, names, etc.
Figure 58-21 shows the VRRP for IPv6 topology with the CLI configuration in Figure 58-22.
R3#show vrrp
Backup State: R3 is the backup in ------------------
the VRRP group because the R3 GigabitEthernet 1/0, IPv6 VRID: 10, Net: fe80::201:e8ff:fe6b:1845
interface has a lower IPv6 address. VRF: 0 default-vrf
State: BackupPriority: 100, Master: fe80::201:e8ff:fe6a:c59f
Hold Down: 0 centisec, Preempt: TRUE, AdvInt: 100 centisec
Virtual MAC is automatically Accept Mode: FALSE, Master AdvInt: 100 centisec
assigned and is the same on Adv rcvd: 0, Bad pkts rcvd: 0, Adv sent: 135
both Routers Virtual MAC address:
00:00:5e:00:02:0a
You must configure Virtual IP address:
both a virtual IPv6 address and a 1::10 fe80::10
virtual link local (fe80) address for R2#
an IPv6 VRRP group
R2 R3
VRID 10 1::10 fe80::10
Internet
Note: In a VRRP or VRRPv3 group, if two routers come up with the same priority and another router
already has MASTER status, the router with master status continues to be master even if one of two
routers has a higher IP or IPv6 address.
Router 2
You must configure a virtual link local (fe80)
R2(conf)#interface gigabitethernet 0/0
address for each VRRPv3 group created for
R2(conf-if-gi-0/0)#no ip address
an interface. The VRRPv3 group becomes
R2(conf-if-gi-0/0)#ipv6 address 1::1/64
active as soon as you configure the link local
R2(conf-if-gi-0/0)#vrrp-group 10
address. Afterwards, you can configure the
R2(conf-if-gi-0/0-vrid-10)#virtual-address fe80::10
group’s virtual IPv6 address.
R2(conf-if-gi-0/0-vrid-10)#virtual-address 1::10
R2(conf-if-gi-0/0-vrid-10)#no shutdown
R2(conf-if-gi-0/0)#show config The virtual IPv6 address you configure
interface GigabitEthernet 0/0 should be the same as the IPv6 subnet to
ipv6 address 1::1/64 which the interface belongs.
vrrp-group 10
priority 100
virtual-address fe80::10
virtual-address 1::10
no shutdown
R2(conf-if-gi-0/0)#end
R2#show vrrp
------------------
GigabitEthernet 0/0, IPv6 VRID: 10, Version: 3, Net:fe80::201:e8ff:fe6a:c59f
State: Master, Priority: 100, Master: fe80::201:e8ff:fe6a:c59f (local)
Hold Down: 0 centisec, Preempt: TRUE, AdvInt: 100 centisec
Accept Mode: FALSE, Master AdvInt: 100 centisec
Adv rcvd: 0, Bad pkts rcvd: 0, Adv sent: 135
Virtual MAC address:
00:00:5e:00:02:0a
Virtual IP address:
1::10 fe80::10
Router 3
Although R2 and R3 have the same default
R3(conf)#interface gigabitethernet 1/0 priority (100), R2 is elected master in the
R3(conf-if-gi-1/0)#no ipv6 address VRRPv3
. group because the GigE 0/0
R3(conf-if-gi-1/0)#ipv6 address 1::2/64 interface has a higher IPv6 address than
R3(conf-if-gi-1/0)#vrrp-group 10 the GigE 1/0 interface on R3.
R2(conf-if-gi-1/0-vrid-10)#virtual-address fe80::10
R2(conf-if-gi-1/0-vrid-10)#virtual-address 1::10
R3(conf-if-gi-1/0-vrid-10)#no shutdown
R3(conf-if-gi-1/0)#show config
interface GigabitEthernet 1/0
ipv6 address 1::2/64
vrrp-group 10
priority 100
virtual-address fe80::10
virtual-address 1::10
no shutdown
R3(conf-if-gi-1/0)#end
R3#show vrrp
------------------
GigabitEthernet 1/0, IPv6 VRID: 10, Version: 3, Net:
fe80::201:e8ff:fe6b:1845
State: Backup, Priority: 100, Master: fe80::201:e8ff:fe6a:c59f
Hold Down: 0 centisec, Preempt: TRUE, AdvInt: 100 centisec
Accept Mode: FALSE, Master AdvInt: 100 centisec
Adv rcvd: 11, Bad pkts rcvd: 0, Adv sent: 0
Virtual MAC address:
00:00:5e:00:02:0a
Virtual IP address:
1::10 fe80::10
To view a VRRP in VRF configuration, use the show commands described in Displaying a VRRP in VRF
Configuration on page 1154.
Non-VLAN Scenario
Figure 58-25. VRRP in VRF: Non-VLAN Example
Switch-1 Switch-2
VRID 11 VRID 11
Node IP 10.10.1.5 Node IP 10.10.1.2
Virtual IP 10.10.1.2 Virtual IP 10.10.1.2
VRID 11 VRID 11
Node IP 10.10.1.6 Node IP 10.10.1.2
Virtual IP 10.10.1.2 Virtual IP 10.10.1.2
VRID 15 VRID 15
Node IP 20.1.1.5 Node IP 20.1.1.6
Virtual IP 20.1.1.5 Virtual IP 20.1.1.5
Figure 58-25 shows a typical use case in which three virtualized overlay networks are created by
configuring three VRFs in two E-Series switches. The default gateway to reach the internet in each VRF is
a static route with the next hop being the virtual IP address configured in VRRP. In this scenario, a single
VLAN is associated with each VRF.
a separate physical interface to a LAN switch and an upstream VPN interface to connect to the Internet.
Both Switch-1 and Switch-2 use VRRP groups on each VRF instance in order that there is one master and
one backup router for each VRF. In VRF-1 and VRF-2, Switch-2 serves as owner-master of the VRRP
group and Switch-1 serves as the backup. On VRF-3, Switch-1 is the owner-master and Switch-2 is the
backup.
Note that in VRF-1 and VRF-2 on Switch-2, the virtual IP and node IP address, subnet, and VRRP group
are the same. On Switch-1, the virtual IP address, subnet, and VRRP group are the same in VRF-1 and
VRF-2, but the IP address of the node interface is unique. There is no requirement for the virtual IP and
node IP addresses to be the same in VRF-1 and VRF-2; similarly, there is no requirement for the IP
addresses to be different. In VRF-3, the node IP addresses and subnet are unique.
VLAN Scenario
In another scenario, VRF-1, VRF-2, and VRF-3 use a single physical interface with multiple tagged
VLANS (instead of separate physical interfaces) to connect to the LAN. In this case, three VLANs are
configured: VLAN-100, VLAN-200, and VLAN-300. Each VLAN is a member of one VRF. A physical
interface (gigabitethernet 0/1) attaches to the LAN and is configured as a tagged interface in VLAN-100,
VLAN-200, and VLAN-300. The rest of this user case is the same as the non-VLAN scenario.
This VLAN scenario often occurs in a service-provider network in which VLAN tags are configured for
traffic from multiple customers on customer-premises equipment (CPE), and separate VRF instances
associated with each VLAN are configured on the provider edge (PE) router in the point-of-presence
(POP).
Switch-1
S1(conf)#ip vrf VRF-1 1
!
S1(conf)#ip vrf VRF-2 2
!
S1(conf)#ip vrf VRF-3 3
!
S1(conf)#interface GigabitEthernet 12/4
S1(conf-if-gi-12/4)#no ip address
S1(conf-if-gi-12/4)#switchport
S1(conf-if-gi-12/4)#no shutdown
!
S1(conf-if-gi-12/4)#interface vlan 100
S1(conf-if-vl-100)#ip vrf forwarding VRF-1
S1(conf-if-vl-100)#ip address 10.10.1.5/24
S1(conf-if-vl-100)#tagged gigabitethernet 12/4
S1(conf-if-vl-100)#vrrp-group 11
% Info: The VRID used by the VRRP group 11 in VRF 1 will be 177.
S1(conf-if-vl-100-vrid-101)#priority 100
S1(conf-if-vl-100-vrid-101)#virtual-address 10.10.1.2
S1(conf-if-vl-100)#no shutdown
!
S1(conf-if-gi-12/4)#interface vlan 200
S1(conf-if-vl-200)#ip vrf forwarding VRF-2
S1(conf-if-vl-200)#ip address 10.10.1.6/24
S1(conf-if-vl-200)#tagged gigabitethernet 12/4
S1(conf-if-vl-200)#vrrp-group 11
% Info: The VRID used by the VRRP group 11 in VRF 2 will be 178.
S1(conf-if-vl-200-vrid-101)#priority 100
S1(conf-if-vl-200-vrid-101)#virtual-address 10.10.1.2
S1(conf-if-vl-200)#no shutdown
!
S1(conf-if-gi-12/4)#interface vlan 300
S1(conf-if-vl-300)#ip vrf forwarding VRF-3
S1(conf-if-vl-300)#ip address 20.1.1.5/24
S1(conf-if-vl-300)#tagged gigabitethernet 12/4
S1(conf-if-vl-300)#vrrp-group 15
% Info: The VRID used by the VRRP group 15 in VRF 3 will be 243.
S1(conf-if-vl-300-vrid-101)#priority 255
S1(conf-if-vl-300-vrid-101)#virtual-address 20.1.1.5
S1(conf-if-vl-300)#no shutdown
To display information on a VRRP group that is configured on an interface that belongs to a VRF instance,
enter the show running-config track [interface interface] command:
vrrp-group 4
virtual-address 192.168.0.254
no shutdown
To display information on the VRRP groups configured on interfaces that belong to a VRF instance, enter
the show vrrp vrf [vrf instance] command:
XML Functionality
Through SSH/Telnet client sessions, FTOS XML provides a way of interfacing with the system by entering
XML-formatted requests and retrieving XML output. See The Form of XML Requests and Responses on
page 1156.
FTOS XML supports the following functionality:
• Configure both physical and logical interfaces
• Layer 2 and Layer 3 Standard ACLs
• Layer 2 and Layer 3 Extended ACLs
• Supported show commands and their output. Some show command options supported by FTOS are not
supported in XML, so each option that is supported in XML is listed separately here for clarity:
• Protocol commands:
— show ip bgp neighbors (no parameters accepted)
— show qos statistics
— show qos statistics wred-profile
• System commands:
— show chassis
— show rpm slot ID
— show rpm all
Note: FTOS accepts well-formed XML requests, except that it does not currently support XML
Namespaces.
Request Format
You can then enter XML-formatted requests that conform to the following schema. Every XML request
begins with an XML declaration, followed by a “Method” type tag, followed by an “Operation” type tag,
as shown in this shell schema:
<?xml version="1.0" encoding="UTF-8"?>
<Request MajorVersion="1" MinorVersion="0">
<Method>
<Operation>
<command>
:: ! The number of allowed <command> tag sets depends on the type of request. !
::
</command>
</Operation>
</Method>
</Request>
Currently, for “Method”, you must enter “cli”. In place of “Operation”, you enter either “configuration” or
“action”, depending on the CLI mode that you want to invoke:
Namespace Description
<configuration> This tag tells the CLI to invoke the CONFIGURATION mode.
These requests encapsulate configuration modification commands.
Response Format
Similarly, every response from FTOS begins with the XML declaration, followed by a “Response” tag:
<?xml version="1.0" encoding="UTF-8"?>
<Response MajorVersion="1" MinorVersion="0">
::
::
</Response>
What goes between the Response tags depends on the type of response, as discussed next.
Just as you enter commands in the CLI, you have the option of entering abbreviated commands in XML
messages. For example, instead of using the full show running-config statement, you can enter show run.
Also, spaces before or after the command are allowed, as shown in the following example.
The following sequence of XML tags shows the structure of a configuration request containing several
commands:
<?xml version="1.0" encoding="UTF-8"?>
<request MajorVersion="1" MinorVersion="0">
<cli>
<configuration>
<command>ip access standard test2 </command>
<command> seq 10 deny any</command>
<command> seq 20 permit host 10.1.1.1 count </command>
<command>seq 30 deny 10.2.0.0 /16</command>
</configuration>
</cli>
</request>
The response from FTOS, if the command executes successfully, is as follows:
<?xml version="1.0" encoding="UTF-8"?>
<response MajorVersion="1" MinorVersion="0">
<responseType>NO_ERROR</responseType>
<responseSeverity>SEVERITY_INFO</responseSeverity>
<responseMsg>Xml request successfully processed.</responseMsg>
</response>
For details on responses to error conditions, see XML Error Conditions and Reporting on page 1162.
To generate an XML request that encapsulates a “show” command (to request a report), you use the
<action> tag instead of the <configuration> tag as the Operation type. The schema of a show request
allows only one <command>, as shown here for the show linecard command. (Note that
“<command>show line all</command>” demonstrates that you can use both an abbreviated form of the
command and options, just as in the standard CLI):
<?xml version="1.0" encoding="UTF-8"?>
<request MajorVersion="1" MinorVersion="0">
<cli>
<action>
<command>show line all</command>
</action>
</cli>
</request>
The response from FTOS, if the command executes successfully, presents all of the content that you would
get in the equivalent CLI report. Note that the data are encapsulated in self-explanatory XML tags. The
following is an example of a show linecard report embedded in XML tags:
<?xml version="1.0" encoding="UTF-8" ?>
<response MajorVersion="1" MinorVersion="0">
<action>
<linecard>
<slotId>3</slotId>
<status>online</status>
<nextBoot>online</nextBoot>
<reqType>E48TF3</reqType>
<numPorts>0</numPorts>
<swVer>6.5.1.1</swVer>
</linecard>
</action>
</response>
Use the following procedure to start, run, and close an FTOS XML session:
1 terminal xml EXEC Privilege Invoke XML interface in Telnet and SSH client
sessions.
2 [Construct input to the CLI by FTOS XML Cut and paste your XML request from a text editor
following the XML request schema, or other type of XML presentation tool, or type your
as described in The Form of XML XML request line by line.
Requests and Responses on
page 1156.]
3 Press Ctrl-Y (or press Enter twice, FTOS XML Execute the request.
creating an empty line). Alternatively, to cancel the request (only possible
before sending) and get a fresh XML prompt, press
Ctrl-C.
4 Press Ctrl-Z (or enter terminal no FTOS XML Exit from FTOS XML mode.
xml as the <command> string in the
XML request <action> schema).
Figure 59-1, below, illustrates entering FTOS XML mode. Figure 59-1 on page 1159, below, illustrates the
full sequence of invoking an XML session, entering a command, receiving a success response, and leaving
the session with the terminal no xml command in XML:
FTOS(xml)#
Enter XML request with CTRL-Y or empty line
Clear XML request with CTRL-C
Exit XML mode with CTRL-Z:
<?xml version="1.0" encoding="UTF-8"?>
<request MajorVersion="1" MinorVersion="0">
<cli>
<action>
<command>terminal no xml</command>
</action>
</cli>
</request>
FTOS#
To configure a standard ACL with XML, first enter FTOS XML mode, and then construct a configuration
request, as described above. An example of a complete standard ACL configuration request message is:
To configure an extended ACL through XML, enter FTOS XML mode and construct an XML
configuration request (see Run an FTOS XML session on page 1159). An example of a complete request
message is:
<?xml version="1.0" encoding="UTF-8"?>
<request MajorVersion="1" MinorVersion="0">
<cli>
<configuration>
<command> interface GigabitEthernet 0/0</command>
<command> ip address 10.2.1.100 255.255.255.0 </command>
<command> ip access-group nimule in no shutdown</command>
</configuration>
</cli>
</request>
Apply an IP ACL
To apply the IP ACL (standard or extended) that you created, above, to a physical or port channel interface,
construct an XML configuration request (see Run an FTOS XML session on page 1159) that encapsulates
the appropriate CLI commands, as exemplified here:
<?xml version="1.0" encoding="UTF-8"?>
<request MajorVersion="1" MinorVersion="0">
<cli>
<configuration>
<command> interface GigabitEthernet 0/0</command>
<command> ip address 10.2.1.100 255.255.255.0 </command>
<command> ip access-group nimule in no shutdown</command>
</configuration>
</cli>
</request>
To create an egress ACL and apply rules to the ACL in one single XML request, first enter FTOS XML
mode, and then construct the configuration request (see Run an FTOS XML session on page 1159). The
following example shows a configuration request message that accomplishes this task:
<?xml version="1.0" encoding="UTF-8"?>
<request MajorVersion="1" MinorVersion="0">
<cli>
<configuration>
<command> interface GigabitEthernet 0/0</command>
<command> ip access-group abcd out</command>
<command> ip access-list extended abcd</command>
<command> seq 5 permit tcp any any</command>
<command> seq 10 deny icmp any any</command>
<command> permit 1.1.1.2</command>
</configuration>
</cli>
</request>
Error Messages
The following strings can appear after the <responseType> tag:
• XML_PARSE_ERROR
• CLI_PARSE_ERROR—This error is caused by:
— Malformed XML or mismatched XML tags
The following XML request is missing the XML declaration (the first line in the schema):
<request MajorVersion="1" MinorVersion="0">
<cli>
<configuration>
<command>ip access standard test2</command>
</configuration>
</cli>
</request>
This following XML request has transposed the <configuration> and <cli> tag sets:
<?xml version="1.0" encoding="UTF-8"?>
<request MajorVersion="1" MinorVersion="0">
<configuration>
<cli>
<command>ip access standard test2</command>
</cli>
</configuration>
</request>
show keyword | display xml EXEC privilege FTOS treats “ | display xml” as a request to format the show
command report in XML format.
As shown in the following Figure 59-3, FTOS formats the response with the XML tags from the same
response schema used by the XML response, discussed in The “Show” Request and Response on
page 1158. For more on pipe options, see Filtering show Command Outputs on page 43.
The switch fabric is formed through the installed RPMs and line cards via C-Series Switch Fabric (CSF)
ASICs.
Each RPM includes four CSFs, each of which provides eight Backplane Data (BDP) links, one link for
each line card slot. In total, an RPM provides 32 BDP links of forwarding capacity.
Each line card includes two CSFs. Six of the eight links on the CSFs are used as follows:
• Up to four ports—ports 1 to 4—connect to the Forwarding Processors (FP). These ports are referred to
as the Internal Dataplane (IDP) link.
• Ports 5-8 connect to the RPMs. These ports are referred to as the BDP links.
Figure 60-1. Architecture Diagram of the 1x48GE Line Card
The number of FPs varies with the line card type, as shown in Table 60-1.
Table 60-1. FPs, CSFs, and IDP Links by Line Card Type
FTOS Link Monitoring task continually polls the status of the IDP and BDP links. If it finds an open link,
the system brings down the link and reports the condition via a message similar to the one shown in
Message 1.
Note: These messages are not reported when a line card is reset by a user command.
If a backplane link on a line card goes down, the RPM side of the link stays up to avoid duplicate reporting.
Bringing down an IDP or BDP link causes the card to be powered-off and placed into a "card problem -
port pipe problem" state. Use the show linecard command to view the status of a line card.
If a single BDP link to the active RPM is down, the line card will be placed in an error state. Use the show
switch links command to view the status of the dataplane links, as shown in Figure 60-2.
To monitor the status of a virtual SFM, use the show sfm command shown in Figure 60-3. The system
reports an “active” status if all CSF ASICs on the RPM initialize successfully, whether or not any line
cards are installed and the BDP links are up.
FTOS#show sfm
Switch Fabric State: up
-- SFM 0 --
Status : active
Module Type : SFM - Switch Fabric Module
Up Time : 1 day, 6 hr, 0 min
-- SFM 1 --
Status : not present
Use the FTOS Syslogging feature to monitor the overall status of the switch fabric. Changes in switch
fabric status are reported via messages similar those in Message 2.
The Poll Manager runs automatically in the background and cannot be disabled. The possible Poll
Manager Syslog messages are given in Table 60-2.
Message Description
POLLMGR-2-ALT_RPM_STA Reports that either the standby RPM is not present or has been detected.
TE
POLLMGR-2-USER_FLASH_ Reports the status of the flash disks.
DETECT If reported during boot up, this message indicates either:
a External flash disk missing in slot0:
b Internal flash disk missing in flash:
If reported during runtime, this message indicates either:
a External flash disk removed from slot0:
b Internal flash disk removed from flash:
Message Description
POLLMGR-2-POLLMGR_RP Indicates that the system detected a single-bit ECC memory error in the RPM CPU
M_ECC_ERR_DETECT memory (SDRAM). The system tracks the number of multi-bit errors and resets the
system after a certain number of such errors are recorded. Upon reset, the system writes
a failure trace file to the TRACE_LOG directory for analysis by Dell Force10.
POLLMGR-2-POLLMGR_BPL Indicates that the system detected an error on the internal IPC switch subsystem
_IRC_ERR connection between the two RPMs. This connection is referred to as Inter-RPM
Communication (IRC). When a number of consecutive IRC heartbeat messages are
lost, the system will declare an IRC timeout via a Syslog message and reset the system.
This message suggests that a hardware fault on the RPM may have caused the IRC
timeout.
To troubleshoot this issue:
• Verify that the RPMs are fully inserted.
• Try a swap test of the RPMs.
• Capture the output of the following show hardware commands:
•show hardware rpm number cpu party-bus statistics
•show hardware rpm number mac counters
•show hardware rpm number mac port-statistics rpm number (of alternate RPM)
POLLMGR-2-POLLMGR_PT Indicates the internal IPC party bus connection to a line card has changed to down. IPC,
YBUS_LINK_SCAN or inter-process communication, is the protocol used among the RPM and line card
CPUs to exchange information. The underlying IPC subsystem uses internal Ethernet
links.
To troubleshoot this condition:
• Capture the output of the show hardware linecard cpu party-bus statistics
command, and forward it to Dell Force10.
Figure 60-4 illustrates the IPC subsystem, including the IRC links between the RPMs, and the relevant
troubleshooting commands.
The CP monitors the health status of the other processors using heartbeat messaging exchange.
FTOS automatically saves critical information about the IPC failure to NVRAM. Such information
includes:
Upon the next boot, this information is uploaded to a file in the CRASH_LOG directory. Use the following
command sequence beginning in EXEC mode to capture this file for analysis by the Dell Force10 TAC.
1 Display the directories in flash memory. The output dir flash: EXEC
should include:
1 drwx 2048 Jan 01 1980 00:00:06
CRASH_LOG_DIR
3 View any saved files in the CRASH_LOG directory. dir EXEC Privilege
The naming convention is:
sysinfo_RPMIDProcessorID _ timestamp
For example:
sysinfo_RPM1CP_20060616_013125
4 View the contents of the file. show file flash:// EXEC Privilege
CRASH_LOG_DIR/[file_name]
In a dual RPM system, the two RPMs send synchronization messages via inter-RPM communication
(IRC). As described in the High Availability chapter, an RPM failover can be triggered by loss of the
heartbeat (similar to a keepalive message) between the two RPMs. FTOS reports this condition via syslog
messages, as follows:
FTOS automatically saves critical information, about the IRC failure, to NVRAM. Use the same three-step
procedure to capture this file for analysis by Dell Force10.
Bootup diagnostics
During bootup and reset of a card, diagnostics check the status of key hardware sub-components and verify
that all ASICs initialize successfully.
Environmental monitoring
All C-Series components use environmental monitoring hardware to detect overtemperature, undervoltage,
and overvoltage conditions. Use the show environment command to monitor the components for any major
or minor alarm conditions. The output in Figure 60-5 displays the environment status of the RPM.
Inspect cards adjacent to the one reporting the condition to discover the cause.
• If directly adjacent cards are not normal temperature, suspect a genuine overheating condition.
• If directly adjacent cards are normal temperature, suspect a faulty sensor.
When the system detects a genuine over-temperature condition, it powers off the card. To recognize this
condition, look for the system messages in Message 7.
To view the programmed alarm thresholds levels, including the shutdown value, execute the show alarms
threshold command shown in Figure 60-6.
In addition, Dell Force10 requires that you install blanks in all slots without a line card to control airflow
for adequate system cooling.
Note: Exercise care when removing a card; if it has exceeded the major or shutdown thresholds, the card
could be hot to the touch!
This message in Message 8 indicates that the specified card is not receiving enough power. In response, the
system first shuts down Power over Ethernet (PoE). If the under-voltage condition persists, line cards are
shut down, then RPMs.
Trace logs
In addition to the syslog buffer, FTOS buffers trace messages which are continuously written by various
FTOS software tasks to report hardware and software events and status information. Each trace message
provides the date, time, and name of the FTOS process. All messages are stored in a ring buffer and can be
saved to a file either manually or automatically upon failover.
Some trace files are automatically saved and stored in the flash:/TRACE_LOG_DIR directory for SW and
HW Traces of the CP and for all Linecards. This directory contains the TRACE_CURR_BOOT directory
which in turn contains the saved trace buffer files.
Trace file hw_trace_RPM0CP.0 is not overwritten so that chassis bootup message are preserved.
Trace files are saved in the directory flash:/TRACE_LOG_DIR/TRACE_CURR_BOOT. Upon a system reload
this directory is renamed flash:/TRACE_LOG_DIR/TRACE_LAST_BOOT, and an empty flash:/
TRACE_LOG_DIR/TRACE_CURR_BOOT directory is created.
Write the RPM trace log to flash. upload trace-log cp [cmd-history | hw-trace | sw-trace EXEC Privilege
]
To manually write the contents of a line card log to the internal flash:
Write the line card trace log to flash. upload trace-log linecard [0-7] | [hw-trace | EXEC Privilege
sw-traceupload trace-log cp | [cmd-history | hw-trace |
sw-trace ]
Disable writing the contents of a hardware log to the internal the flash:
Stop the writing the hardware log to flash. trace disable EXEC Privilege
View the hardware log contents or clear them with the following commands.:
View the content of the hardware log. show trace hardware slot-number EXEC Privilege
Clear the hardware log buffer clear trace hardware EXEC Privilege
• CP: reload_traceRPM0_CP
• LP: reload_traceLP[0-7]
CP software exceptions
When a RPM resets due to a software exception, the linecard trace files are saved to flash:/
TRACE_LOG_DIR directory.
The CP and LP trace file names in the case of a software exception are:
• CP: failure_trace_RPM1_CP
• LP: failure_trace_RPM1_LP[0-7]
For systems with a single RPM, the linecard traces are saved on the failed RPM itself.
For systems with dual RPM, linecard trace logs are saved when the CP, RP1, or RP2 crashes. The linecard
trace logs are saved on the new Primary RPM. The linecard trace file name identifies the failed RPM. For
example, if RPM0 fails the trace files saved in RPM1 with filename as failure_trace_RPM0_LP1.
Command history
The command-history trace feature captures all commands entered by all users of the system with a time
stamp and writes these messages to a dedicated trace log buffer. When the show command-history
command is entered, the system displays a trace message for each executed command. No password
information is saved to the file. The trace messages are not saved to a file or directory on the internal
system flash.
To view the command-history trace, use the show command-history command, as shown in Figure 60-9.
Clear the command history buffer using the command clear command-history from EXEC Privilege mode,
as shown in Figure 60-10.
debug commands
The debug command tree provides packet- and event-level debugging for major protocols, as shown in
Figure 60-11.
FTOS#debug ?
aaa AAA debug information
arp IP ARP debug information
cpu-traffic-stats Start collecting CPU traffic statistics
dot1x Dot1x debug information
ftpserver FTP Server debug information
ifm IFM Debug information
ip IP debug information
ntp NTP debug information
ppp PPP debug commands
radius RADIUS debug information
spanning-tree Spanning tree debug information
tacacs+ TACACS+ debug information
Table 60-3 lists the show hardware commands available as of the latest FTOS version.
Note: show hardware commands should only be used under the guidance of Dell Force10 Technical
Assistance Center.
Command Description
show hardware interface phy View link status information, including the transmitted and received
auto-negotiation control words.
Use the registers keyword to capture a dump of key PHY registers for
your technical support representative.
show hardware drops View internal packet-drop counters on a line card or RPM
show hardware rpm mac counters Enter the keyword counters keyword to view or clear the receive and
clear hardware rpm mac counters transmit frame counters for the party bus switch in the IPC subsystem on
the RPM.
show hardware rpm mac port-statistics Enter the keyword port-statistics to view or clear detailed Ethernet
clear hardware rpm mac port-statistics statistics for the specified port on the party bus switch.
show hardware rpm cpu management View internal interface status information for the RPM CPU port which
connects to the external management interface.
show hardware cpu party-bus View or clear statistics for the party-bus port on the CPU of the specified
clear hardware cpu party-bus line card or RPM.
Command Description
show hardware cpu data-plane View driver-level statistics for the data-plane port on the CPU for the
specified line card or RPM.
show hardware unit Views advanced counters, statistics, and register information for the FP
and CSF ASICs.
A high CPU condition exist when any of the messages in Message 10 appear.
Feb 13 13:56:20: %RPM1-S:CP %CHMGR-5-CPU_THRESHOLD: Overall cp cpu usage above threshold. Cpu5SecUsage
(100)
Feb 13 13:56:20: %RPM1-S:CP %CHMGR-5-TASK_CPU_THRESHOLD_CLR: Cpu usage drops below threshold for task
"sysAdmTsk"(0.00%) in CP.
The SNMP traps and OIDs in Table 60-4 provide information on C-Series hardware components.
RPM
.1.3.6.1.4.1.6027.3.1.1.3.8 chRPMMajorAlarmStatus Fault status of the major alarm LED on the RPM
.1.3.6.1.4.1.6027.3.1.1.3.9 chRPMMinorAlarmStatus Fault status of the minor alarm LED on the RPM
.1.3.6.1.4.1.6027.3.1.1.4.0.11 chAlarmRpmUp Trap generated when the status of primary or
secondary RPM changes to up and running
.1.3.6.1.4.1.6027.3.1.1.4.0.12 chAlarmRpmDown Trap generated when the status of primary or
secondary RPM changes to down, either by
software reset or by being physically removed from
the chassis
Line Card
.1.3.6.1.4.1.6027.3.1.1.2.3.1.15 chSysCardOperStatus Operational status of the card.
• If the chSysCardAdminStatus is up, the valid
state is ready—the card is present and ready and
the chSysCardOperStatus status is up.
• If the chSysCardAdminStatus is down the
service states can be:
• offline: the card is not used.
• cardNotmatch: the card does not
match what is configured
• cardProblem: a hardware
problem has been detected on the
card.
• diagMode: the card is in the
diagnostic mode.
Note: chSysCardFaultStatus is supported only the
C-Series.
.1.3.6.1.4.1.6027.3.1.1.4.0.1 chAlarmCardDown Trap reported when a card operational status
changes to down
.1.3.6.1.4.1.6027.3.1.1.4.0.2 chAlarmCardUp Trap reported when a card operational status
changes to up
.1.3.6.1.4.1.6027.3.1.1.4.0.3 chAlarmCardReset Trap reported when a card is reset
.1.3.6.1.4.1.6027.3.1.1.4.0.7 chAlarmCardProblem Trap reported when a card operational status
changes to card problem
.1.3.6.1.4.1.6027.3.1.1.1.4.0.5 chAlarmCardMismatch Trap generated when the configured card does not
match the installed card
.1.3.6.1.4.1.6027.3.1.1.1.4.0.6 chAlarmCardRemove Trap generated when a card is removed
Power Supply Unit
Command Description
hardware watchdog Enable the hardware watchdog mechanism.
Note: As the SFM on the C-Series is a logical concept only, the FORCE10-CHASSIS-MIB SFM-related
SNMP alarms and traps are not used.
The offline diagnostics test suite is useful for isolating faults and debugging hardware.
Diagnostics are invoked from the FTOS CLI. While diagnostics are running, the status can be monitored
via the CLI. The tests results are written to a file in flash memory and can be displayed on screen. Detailed
statistics for all tests are collected. These statistics include:
• Level 0 checks the device inventory and verifies the existence of the devices (e.g., device ID test).
• Level 1 verifies that the devices are accessible via designated paths (e.g., line integrity tests) and tests
the internal parts (e.g., registers) of the devices.
• Level 2 performs on-board loopback tests on various data paths (e.g., data port pipe and Ethernet).
Note: This procedure assumes you have already loaded an FTOS image. These instructions illustrates
the process of running offline diagnostics using line cards, but the process is the same for RPMs. Only the
command keyword linecard must change to rpm. See the Command Line Reference Guide for details.
Use the show linecard all command to confirm offline status, as shown in Figure 60-13.
Use the show file flash:/filename view the detailed test results in the test report saved to flash memory on the
RPM. Use the command. Figure 60-16 shows the filename of the test results, and Figure 60-16 shows the
contents of the file.
Note: Report any test failures to your Dell Force10 technical support engineer.
The C-Series and S-Series ASICs implement the key functions of queuing, feature lookups, and
forwarding lookups in hardware.
• Forwarding Processor (FP) ASICs provide Ethernet MAC functions, queueing and buffering, as well
as store feature and forwarding tables for hardware-based lookup and forwarding decisions. 1G and
10G interfaces use different FPs.
• Switch Fabric (CSF) ASICs are on the C-Series only. They provide some queuing while also providing
the physical pathway through which frames are switched between ports when the source and
destination ports are attached to different FP ASICs.
Table 60-5 describes the type and number of ASICs per platform.
Hardware FP CSF
48-port LC on C-Series 2 2
All ports support eight queues, 4 for data traffic and 4 for control traffic. All 8 queues are tunable.
Physical memory is organized into cells of 128 bytes. The cells are organized into two buffer pools—
dedicated buffer and dynamic buffer.
• Dedicated buffer is reserved memory that cannot be used by other interfaces on the same ASIC or by
other queues on the same interface. This buffer is always allocated, and no dynamic recarving takes
place based on changes in interface status. Dedicated buffers introduce a trade-off. They provide each
interface with a guaranteed minimum buffer to prevent an overused and congested interface from
starving all other interfaces. However, this minimum guarantee means the buffer manager does not
reallocate the buffer to an adjacent congested interface, which means that in some cases, memory is
underused.
• Dynamic buffer is shared memory that is allocated as needed, up to a configured limit. Using dynamic
buffers provides the benefit of statistical buffer sharing. An interface requests dynamic buffers when
its dedicated buffer pool is exhausted. The buffer manager grants the request based on three
conditions:
• the number of used and available dynamic buffers
• the maximum number of cells that an interface can occupy
You can configure dynamic buffers per port on both 1G and 10G FPs and per queue on CSFs. By default,
the FP dynamic buffer allocation is 10 times oversubscribed. For 48-port 1G card:
• Dynamic Pool= Total Available Pool(16384 cells) – Total Dedicated Pool =5904 cells
• Oversubscription ratio = 10
• Dynamic Cell Limit Per port= 59040/29 =2036 cells
Figure 60-18. Buffer Tuning Points
CSF Unit 3
1
IDP Switch Links
FP Unit 1
Front-end Links 3
PHY PHY
As a guideline, consider tuning buffers if traffic is very bursty (and coming from several interfaces). In this
case:
Define a buffer profile for the CSF queues. buffer-profile csf csqueue CONFIGURATION
Change the maximum amount of dynamic buffers buffer dynamic BUFFER PROFILE
an interface can request.
Change the number of packet-pointers per queue. buffer packet-pointers BUFFER PROFILE
Apply the buffer profile to a line card. buffer fp-uplink linecard CONFIGURATION
Apply the buffer profile to a CSF to FP link. buffer csf linecard CONFIGURATION
FTOS Behavior: If you attempt to apply a buffer profile to a non-existent port-pipe, FTOS displays the
following message. However, the configuration still appears in the running-config.
%DIFFSERV-2-DSA_BUFF_CARVING_INVALID_PORT_SET: Invalid FP port-set 2 for linecard 2. Valid
range of port-set is <0-1>
Configuration changes take effect immediately and appear in the running configuration. Since under
normal conditions all ports do not require the maximum possible allocation, the configured dynamic
allocations can exceed the actual amount of available memory; this is called oversubscription. If you
choose to oversubscribe the dynamic allocation, a burst of traffic on one interface might prevent other
interfaces from receiving the configured dynamic allocation, which causes packet loss.
You cannot allocate more than the available memory for the dedicated buffers. If the system determines
that the sum of the configured dedicated buffers allocated to the queues is more than the total available
memory, the configuration is rejected, returning a syslog message similar to the following.
FTOS Behavior: When you move to a different chassis a line card that has a buffer profile applied at
interface level on the fp-uplink, the line card retains the buffer profile. To return the line card to the
default buffer profile, remove the current profile using the command no buffer-profile fp-uplink linecard
from INTERFACE mode, and then reload the chassis.
from CONFIGURATION mode, the buffer-profile name still appears in the output of show
buffer-profile [detail | summary]. After a line card reset, the buffer profile correctly returns to the
default values, but the profile name remains. Remove it from the show buffer-profile [detail | summary]
command output by entering no buffer [fp-uplink |csf] linecard port-set buffer-policy from
CONFIGURATION mode and no buffer-policy from INTERFACE mode.
Display the allocations for any buffer profile using the show commands in Figure 60-20. Display the
default buffer profile using the command show buffer-profile {summary | detail} from EXEC Privilege
mode, as shown in Figure 60-19.
FTOS provides two pre-defined buffer profiles, one for single queue (i.e non-QoS) applications, and one
for four queue (i.e QoS) applications.
Apply one of two pre-defined buffer profiles for all buffer-profile global [1Q|4Q] CONFIGURATION
port-pipes in the system.
You must reload the system for the global buffer-profile to take effect (Message 12).
FTOS Behavior: After you configure buffer-profile global 1Q, Message 12 is displayed during every
bootup. Only one reboot is required for the configuration to take effect; afterwards this bootup
message may be ignored.
FTOS Behavior: The buffer profile does not returned to the default, 4Q, if you configure 1Q, save the
running-config to the startup-config, and then delete the startup-config and reload the chassis. The
only way to return to the default buffer profile is to explicitly configure 4Q, and then reload the chassis.
The buffer-profile global command fails if you have already applied a custom buffer-profile on an interface.
Similarly, when buffer-profile global is configured, you cannot not apply buffer-profile on any interface.
If the default buffer-profile (4Q) is active, FTOS displays an error message instructing you to remove the
default configuration using the command no buffer-profile global.
Sample configuration
The two general types of network environments are sustained data transfers and voice/data. Dell Force10
recommends a single-queue approach for data transfers. Figure 60-21 is a sample configuration for a
C-Series 48-port line card that uses the default packet pointer values.
!
buffer fp-uplink linecard 0 port-set 0 buffer-policy fsqueue-hig
buffer fp-uplink linecard 0 port-set 1 buffer-policy fsqueue-hig
!
Interface range gi 0/1 - 48
buffer-policy fsqueue-fp
In addition to the FTOS high availability features, E-Series and FTOS support several diagnostics and
debug features that are integral components to delivering maximum uptime. These features consist of the
following:
Note: These diagnostics and debugability features are available on TeraScale systems only, unless
specifically noted.
Overview
The FTOS diagnostics and debugging features are a proactive approach to maximizing system uptime and
reducing meantime to resolution (MTTR) when a problem occurs. This feature set includes a combination
of proactive and reactive components designed to alert the user to network events, automatically collect
information on the event, and allow the user to collect diagnostic information from the system.
• Proactive component
• The system health check detects, reports, and takes action on an error in real time.
• When an automatic corrective action is not appropriate, the system health check reports the
detected anomaly, in real time, via a syslog message and/or SNMP.
• Reactive component
• When an error condition is asserted, appropriate show and debug commands are available to assist
in identifying the condition as well as rapid fault isolation.
If three consecutive packets are lost, an error message is logged and then one of the following happens:
• The RPM-SFM runtime loopback test failure initiates an SFM walk whenever it is enabled, feasible
and necessary. The system automatically places each SFM (in sequential order) in an offline state, runs
the loopback test, and then places the SFM back in an active state. This continues until the system
determines a working SFM combination. If no working combination is found, the system restores to
the pre-walking SFM state and the switch fabric state remains up. No more SFM walks are conducted
as long as the SFM settings remain unchanged (setting changes include SFM reset, power off/on, and
hotswap). However, the runtime loopback tests will continue with failure messages being logged every
five minutes.
Note: SFM walking assumes a chassis with the maximum number of SFMs in an active state.
The loopback runtime test results reflect the overall health status of the dataplane. SFM walking can help to
identify a single faulty SFM which is persistently dropping all traffic. For any partial packet loss, the loopback
test results can only indicate that there is partial packet loss on the dataplane.
When an automatic SFM walk is conducted, events are logged to indicate the start and completion of the SFM
walk and the results. A complete system message set is shown below.
FTOS Behavior: In very rare circumstances, FTOS is not able to recover from a SFM looback failure.
You must recover manually from the loopback failure, by power-cycling the SFM. See Power the SFM
on/off on page 1202.
• If a line card runtime loopback test fails, the system does not launch an SFM walk. A message is
logged indicating the failure.
The runtime dataplane loopback test is enabled by default. To disable this feature, use the following
command.
Disable the runtime loopback test on the primary dataplane-diag disable CONFIGURATION
RPM and line cards. loopback
To re-enable, use the no dataplane-diag
disable loopback command
Note: Disabling the runtime loopback test prevents the sfm-walk command and sfm-bringdown
commands from taking effect.
To disable the automatic SFM walk that is launched after an RPM-SFM runtime loopback test failure, use
the following command in CONFIGURATION mode.
Disable the automatic SFM walk that is dataplane-diag disable sfm-walk CONFIGURATION
launched after an RPM-SFM runtime
loopback test failure.
To re-enable the automatic SFM walk, use
the no dataplane-diag disable
sfm-walk command.
Note: Disabling the sfm-walk command prevents the sfm-bringdown command from taking effect.
To disable the automatic bring-down of an SFM that is identified by the SFM walk during the RPM-SFM
runtime loopback test, use the following CONFIGURATION mode command.
If the RPM-SFM or line card-SFM loopback test detects an SFM failure, an attempt is made to isolate a
single faulty SFM by automatically walking the SFMs. For this failure case, error messages similar to the
runtime loopback test error are generated.
Note: The dataplane runtime loopback configuration does not apply to this manual loopback test.
In the example in Figure 61-2, the manual loopback tests is successful, and no SFM failure is detected.
FTOS#
If the test passes when the switch fabric is down and there are at least (max-1) SFMs in the chassis, then
the system will bring the switch fabric back up automatically. Like the runtime loopback test, the manual
loopback test failure will not bring the switch fabric down.
Note: Line card-SFM loopback test failure, during the manual test, will trigger an SFM walk.
When there are a full set of SFMs online, powering down one SFM will reduce the total bandwidth
supported by the chassis, and may affect data flow. A warning message is issued at the command line that
requires user confirmation to proceed with the command (Figure 61-3).
Figure 61-3. power-off sfm command with data traffic warning message
FTOS#power-off sfm 0
SFM0 is active. Powering it off it might impact the data traffic.
Proceed with power-off [confirm yes/no]:yes
Feb 15 23:52:53: %RPM1-P:CP %CHMGR-2-MINOR_SFM: Minor alarm: only eight working SFM
FTOS#
Since this command is for diagnostic purposes, you can power off more than one SFM which may cause a
switch fabric module to go down. A warning message is issued at the command line and requires user
confirmation to proceed with the command (Figure 61-4).
Figure 61-4. power-off sfm command with switch fabric down warning message
FTOS#power-off sfm 1
WARNING!! SFM1 is active. Powering it off it will cause Switch Fabric to go down!!
Proceed with power-off [confirm yes/no]:yes
Feb 16 00:03:19: %RPM1-P:CP %TSM-6-SFM_SWITCHFAB_STATE: Switch Fabric: DOWN
Feb 16 00:03:20: %RPM1-P:CP %CHMGR-0-MAJOR_SFM: Major alarm: Switch fabric down
FTOS#
Once the SFM is powered off, the SFM status indicates that the SFM has been powered off by the user. Use
the show sfm all command to display the status (Figure 61-5).
FTOS#
When the SFM is taken offline due to an error condition, you can execute the reset sfm command and
initiate a manual recovery.
Reset a specific SFM module (power-off and then reset sfm slot-number EXEC
power-on).
When an error is detected on an SFM module, this command is a manual recovery mechanism. Since this
command can be used with live traffic running, the switch fabric will not go down if the switch fabric is in
an UP state. When there is a full set of SFMs online in the chassis, resetting one SFM will reduce the total
bandwidth supported by the chassis and may effect data flow. A warning message is issued at the command
line and requires user confirmation to proceed. (Figure 61-6)
This command does not permit resetting any SFM when the system has (max-1) SFM and switch fabric is
up (Figure 61-7).
Note: Resetting an SFM in a power-off state is not permitted. Use the command power-on sfm to bring
the SFM back to a power-on state.
The following graphic illustrates the E600 and E1200 switch fabric architecture. Each ingress and egress
Buffer and Traffic Management (BTM) ASIC maintains nine channel connections to the TeraScale Switch
Fabric (TSF) ASIC.
• Backplane noise
• Data corruption
• Bad epoch timing
• Mis-configuration of backplane
There are two PCDFO error types: Transient and Systematic. Transient error are non-persistent events that
occur as one-events during normal operation. Systematic errors are repeatable events. For example, some
hardware device or component is malfunctioning in such a way that it persistently exhibits incorrect
behavior.
recovers from the error state, and the dataplane continues to function properly. In persistent case, PCDFO
errors will appear in the log, and the error state is likely to remain if not handled.
With PCDFO error data alone, it is impossible to arrive at a conclusion which will pinpoint the cause for
PCDFO error or reason for packets drop. For example, it is quite possible to have multiple line cards/RPM
show different channels with PCDFO error. Nonetheless, PCDFO status is a very useful data point as an
indication of the health of the dataplane, particularly when an error is persistent.
To disable the PCDFO polling feature, use the following command in CONFIGURATION mode.
Detection of a PCDFO event causes the system to generate a message similar to the following.
Events are logged when PCDFO error first occurs on any SFM and when PCDFO error pattern changes.
No automatic action is taken by the system when a DFO error is detected. If such an error is reported, note
the SFM slot number identified in the message and contact Dell Force10 technical support. In addition, to
confirm that the identified SFM needs to be replaced, use the diag sfm all-loopback to execute a manual
dataplane loopback test.
Inter-CPU timeouts
Each RPM consists of three CPUs:
Message 6 CP monitor
%RPM1-P:CP %IPC-2-STATUS: target rp2 not responding
%RPM0-S:CP %RAM-6-FAILOVER_REQ: RPM failover request from active peer: Auto failover on failure
%RPM0-S:CP %RAM-6-ELECTION_ROLE: RPM0 is transitioning to Primary RPM.
%RPM0-P:CP %TSM-6-SFM_SWITCHFAB_STATE: Switch Fabric: UP
FTOS automatically saves critical information about the IPC failure to NVRAM. Such information
includes:
Upon the next boot, this information is uploaded to a file in the CRASH_LOG directory. Use the following
command sequence beginning in EXEC mode to capture this file for analysis by the Dell Force10 TAC.
1 Display the directories in flash memory. The output dir flash: EXEC
should include:
1 drwx 2048 Jan 01 1980 00:00:06
CRASH_LOG_DIR
4 View the contents of the file. show file flash://CRASH_LOG_DIR/ EXEC Privilege
[file_name]
(IRC). As described in the High Availability chapter, an RPM failover can be triggered by loss of the
heartbeat (similar to a keepalive message) between the two RPMs. FTOS reports this condition via syslog
messages, as follows:
FTOS automatically saves critical information, about the IRC failure, to NVRAM. Use the same three-step
procedure to capture this file for analysis by Dell Force10.
FTOS actually saves up to three persistent files depending upon the type of failure. When reporting an
RPM failover triggered by a loss of the IPC or IRC heartbeats, look for failure records in the following
directories:
Debug commands
FTOS supports an extensive suite of debug commands for troubleshooting specific problems while
working with Dell Force10 technical support staff. All debug commands are entered in privileged EXEC
mode. See the FTOS Command Reference for details.
Command Description
hardware watchdog Enable the hardware watchdog mechanism.
The following table lists the show hardware commands. For detailed information on these and other
commands, see the FTOS Command Line Interface Reference document.
Command Description
show hardware rpm slot-number mac counters [port View or clear the receive- and transmit- counters
port-number] for the party-bus control switch on the IPC
clear hardware rpm slot-number mac counters subsystem of the RPM.
show hardware rpm slot-number cp {data-plane | Display advanced debugging information for the
management-port} | party-bus} {counters | RPM processors.
statistics}
show hardware rpm slot-number {rp1 | rp2}
{data-plane | party-bus} {counters | statistics}
show hardware linecard number port-set pipe-number Display receive and transmit counters, error
fpc forward {counters | drops | spi {err-counters | counters and status registers for the forwarding
spichannel# counters} | status} functional area of the FPC (flexible packet
classification engine).
show hardware linecard number port-set pipe-number Display diagnostic and debug information related
fpc lookup detail to the lookup functional area of the Flexible Packet
Classification (FPC).
show running-config hardware-monitor Display hardware-monitor action-on-error settings.
show cpu-interface-stats Provides an immediate snapshot of internal RPM
and line card CPU health counters.
Offline diagnostics
These diagnostics can be useful for isolating faults and debugging TeraScale hardware installed in a
chassis.
Diagnostics are invoked from the FTOS CLI. While diagnostics are running, the status can be monitored
via the CLI. The tests results are written to a file in flash memory and can be displayed on screen. Detailed
statistics for all tests are collected and include:
Level 0—Check the inventory of devices. Verify the existence of devices (e.g., device ID test).
Level 1—Verify the devices are accessible via designated paths (e.g., line integrity tests). Test the internal
parts (e.g., registers) of devices.
Level 2—Perform on-board loopback tests on various data paths (e.g., data port-pipe and Ethernet).
1. Place the line card in an offline state with the offline linecard command. Use the show linecard
command to confirm the new status.
Foce10#offline line 4
Mar 27 05:18:26: %RPM0-P:CP %CHMGR-2-CARD_DOWN: Line card 4 down - card offline
Mar 27 05:18:26: %RPM0-P:CP %IFMGR-5-OSTATE_DN: Changed interface state to down: Te 4/3
2. Start diagnostics on the line card with the diag command. The system will confirm that diagnostics
tests are running by displaying the syslog message shown below.
FTOS#diag linecard 4 ?
alllevels Execute level 0-2 diags (default)
level0 Execute level 0 diags
level1 Execute level 1 diags
level2 Execute level 2 diags
terminate Stops the running test
FTOS#diag linecard 4
Mar 27 01:54:00: %E12PD3:2 %DIAGAGT-6-DA_DIAG_STARTED: Starting diags on slot 4
Mar 27 02:05:47: %E12PD3:2 %DIAGAGT-6-DA_DIAG_DONE: Diags finished on slot 4
4. Report any test failures to your Dell Force10 technical support engineer.
5. Bring the card back online with the online linecard {slot#} command. The card will be reset.
• Transient Parity Error— implies that a read value was corrupted in transit but that the actual
memory may not be corrupt. Transient errors are further categorized as a recoverable and phantom.
• Recoverable Transient Parity Error—a transient parity error indicated by SRAM that FTOS
was able to correct (rewrite).
• Phantom Transient Parity Error—a recoverable parity error for which the software was unable
to determine a problem location.
• Non-recoverable Error—implies a persistent corrupted memory location for which the only means of
recovery is to reboot the line card.
FTOS has the ability determine the error type when a parity error occurs and correct recoverable transient
parity errors using the Parity Error Correction feature. During the SRAM scanning function, anytime the
system detects a parity error, it must determine which type it is. To distinguish between the two types of
parity errors (transient and non-recoverable), the system maintains a copy of all SRAM writes. If a location
does not match the SRAM copy or causes another parity error indication in the status register, the system
rewrites the location. After rewriting the location, the system again reads the location and checks the status
register for parity error indication. If the location fails either of these two tests after a rewrite, then the
parity error is non-recoverable, the location is marked as corrupt, and FTOS generates log messages. If the
location passes these tests, then the parity error is transient (recoverable), the location is marked as having
had a transient parity error, and FTOS continues the scan to the end of the SRAM bank.
1 Verify that the line card has show processes memory lp EXEC Privilege
sufficient memory to enable this
feature, as shown in Figure 61-8.
2 Enable Parity Error Correction hardware monitor linecard asic fpc CONFIGURATION
parity-correction
FTOS displays Message 8 on the console, when you enable Parity Error Correction. FTOS also records the
messages in Message 9 in the trace log when you enable and disable Parity Error Correction, or insert a
line card with Parity Error Correction enabled.
Use SNMP to poll the number of transient errors using the objects chSysCardParityPhantomError and
chSysCardParityRecoverableError. If it has been more than one hour since the last occurrence of the same
type of error, the counter associated with that type of error is reset to 1.
-- Line card 6 --
Status : online
Next Boot : online
Required Type : E48TF - 48-port 10/100/1000Base-T line card with RJ-45 interfaces (EF)
Current Type : E48TF - 48-port 10/100/1000Base-T line card with RJ-45 interfaces (EF)
Hardware Rev : Base - 1.1 PP0 - 1.0 PP1 - 1.0
Num Ports : 48
Up Time : 3 min, 44 sec
FTOS Version : 6.5.4.1
Jumbo Capable : yes
Boot Flash : A: 2.3.1.3 B: 2.3.1.3 [booted]
Memory Size : 268435456 bytes
Temperature : 42C
Power Status : AC
Voltage : ok
Serial Number : 0045149
Part Number : 7520016602 Rev 06
Vendor Id : 04
Date Code : 01442005
Country Code : 01
Parity Status : Last Event - FPC DDR Bank [191:128], Transient Failure, Running Count 5
FTOS#show linecard 7 | find “Parity Status”
Parity Status : Last Event - FPC DDR Bank [191:128], Real Failure, Address 0x11ffe00
In addition to the syslog buffer, FTOS buffers trace messages which are continuously written by various
FTOS software tasks to report hardware and software events and status information. Each trace message
provides the date, time, and name of the FTOS process. All messages are stored in a ring buffer and can be
saved to a file either manually or automatically upon failover.
Some trace files are automatically saved and stored in the flash:/TRACE_LOG_DIR directory for SW and
HW Traces of the CP and for all Linecards. This directory contains the TRACE_CURR_BOOT file which
in turn contains the saved trace buffer files.
The TRACE_LOG_DIR/TRACE_CURR_BOOT files can be reached by FTP or by using the show file
command from the flash://TRACE_LOG_DIR directory.
Trace file hw_trace_RPM0CP.0 is not overwritten so that chassis bootup message are preserved.
Note: Line card 1 is taken as the example for the following filenames.
Trace files are saved in the directory flash:/TRACE_LOG_DIR/TRACE_CURR_BOOT. Upon a system reload
this directory is renamed flash:/TRACE_LOG_DIR/TRACE_LAST_BOOT, and an empty flash:/
TRACE_LOG_DIR/TRACE_CURR_BOOT directory is created.
When the trace messages are being saved on reload, Message 13 is displayed.
• CP: reload_traceRPM0_CP
• LP: reload_traceLP1
CP software exceptions
When a RPM resets due to a software exception, the linecard trace files are saved to flash:/
TRACE_LOG_DIR directory.
The CP and LP trace file names in the case of a software exception are:
• CP: failure_trace_RPM1_CP
• LP: failure_trace_RPM1_LP1
For systems with a single RPM, the linecard traces are saved on the failed RPM itself.
For systems with dual RPM, linecard trace logs are saved when the CP, RP1, or RP2 crashes. The linecard
trace logs are saved on the new Primary RPM. The linecard trace file name identifies the failed RPM. For
example, if RPM0 fails the trace files saved in RPM1 with filename as failure_trace_RPM0_LP1.
To view the command-history trace, use the show command-history command, as shown in Figure 61-10.
FTOS#show command-history
[12/5 10:57:8]: CMD-(CLI):service password-encryption
[12/5 10:57:12]: CMD-(CLI):hostname Force10
[12/5 10:57:12]: CMD-(CLI):ip telnet server enable
[12/5 10:57:12]: CMD-(CLI):line console 0
[12/5 10:57:12]: CMD-(CLI):line vty 0 9
[12/5 10:57:13]: CMD-(CLI):boot system rpm0 primary flash://FTOS-CB-1.1.1.2E2.bin
Command
Step Task Command Syntax Mode
1 Write the buffered trace log to flash. upload trace-log cp [cmd-history | EXEC Privilege
hw-trace | sw-trace]
Command
Step Task Command Syntax Mode
1 Write the buffered trace log to flash. upload trace-log [rp1 | rp2 | linecard] number EXEC Privilege
[hw-trace | sw-trace ]
Feb 13 13:56:16: %RPM1-S:CP %CHMGR-5-TASK_CPU_THRESHOLD: Cpu usage above threshold for task
"sysAdmTsk"(100.00%) in CP.
%RPM0-P:CP %CHMGR-1-QMERR_RDBE: (0x30004) Double bit error detected in SRAM pointer memory on
Ingress BTM port-pipe 0 Line card slot 9.
%RPM0-P:CP %CHMGR-1-QMERR_RDBE: (0x30004) Double bit error detected in SRAM pointer memory on
Egress BTM port-pipe 0 Line card slot 9.
RPM0-P:CP %CHMGR-3-BM_STATUS_DBE: Double-bit error detected when reading internal header from
buffer memory on Ingress BTM port-pipe 0 Line card slot 9. Check for temporary or sustained
packet loss with show hardware commands.
%RPM0-P:CP %CHMGR-1-LF_MEM_ERR: Low free memory error detected on Ingress BTM port-pipe 0
Line card slot 9
%RPM0-P:CP %CHMGR-1-LF_MEM_ERR: Low free memory error detected on Egress BTM port-pipe 1 Line
card slot 9
%RPM0-P:CP %CHMGR-1-SOP_EOP_ERR: SOP/EOP error detected on Ingress BTM port-pipe 1 Line card
slot 9
Core dumps
RP kernel core dumps are enabled by default. New files are written in flash until space is exhausted, in
which case the write is aborted.
CP kernel core dumps are disabled by default. Enable them using the command logging coredump cp from
CONFIGURATION mode. If you use the keyword cp with this command, the system creates a file, named
f10cp.kcore.gz, that preserves space on the internal flash so that there is always enough space for a core
dump. Undoing this command using the no logging coredump cp removes this file. The CP kernel core
dumps are overwritten every time there is a new core dump. You should manually upload kernel core
dumps periodically if you want to save this information.
You may choose to write the core dump directly to an FTP server using the keyword server. However, the
server option supports only RP coredumps; it does not support CP coredumps. By default the kernel core
dump is sent to the root directory of the internal flash CP and the CORE_DUMP_DIR directory for RP.
Application core dump—On the E-Series, the application core dump has the file name format
f10{cp|rp{1|2}}<yymmddhhmmss>.acore.gz, where <yymmddhhmmss> is a time stamp, and FTOS writes
it to the internal flash.
Note: The kernel core dump can be large and may take up to 5 to 30 minutes to upload. FTOS does not
overwrite application core dumps, so you should delete them as necessary to conserve space on the flash;
if the flash is out of memory, the core dump is aborted. On the S-Series, if the FTP server is not reachable,
the application core dump is aborted.
The FTOS High Availability module is aware of the core dump upload, and it does not reboot the crashed
RPM until the core dump has completed or is aborted.
%E48TF:0 %TME-2-TASK SUSPENDED: LINECARD TASK SUSPENDED. SAVING FAILURE RECORD IN PROGRESS
Writing a line card core dump to memory on the RPM requires 5 to 30 minutes. During this time, the
physical interfaces remain in their current state, which is normally operationally up. This behavior assumes
that most FTOS agent tasks running on the line card CPU continue to operate correctly and that you want
to maximize uptime by having packets continue to flow while FTOS writes the core dump.
If you want to failover to a redundant system when a line card exception occurs, use the command logging
coredump linecard port-shutdown (Figure 663) to shut down ports during a core dump so that the backup
system can take over.
mode:
1 Enable line card core dumps and logging coredump linecard {all | {0-13}} EXEC Privilege
specify the shutdown mode. [port-shutdown | no-port-shutdown]
Note: In the absence of port-shutdown and no-port-shutdown, the option no-port-shutdown is applied.
Once the core dump file has been created with the logging coredump command, the file can be deleted
from the Standby RPM flash although the space is not released. The CP kernel core dump file space cannot
be recovered by deleting the files. You must format the flash drive to recover the space.
Offline diagnostics
The offline diagnostics test suite is useful for isolating faults and debugging hardware.The diagnostics tests
are grouped into three levels:
• Level 0—Level 0 diagnostics check for the presence of various components and perform essential path
verifications. In addition, they verify the identification registers of the components on the board.
• Level 1—A smaller set of diagnostic tests. Level 1 diagnostics perform status/self-test for all the
components on the board and test their registers for appropriate values. In addition, they perform
extensive tests on memory devices (e.g., SDRAM, flash, NVRAM, EEPROM, and CPLD) wherever
possible.
• Level 2—The full set of diagnostic tests. Level 2 diagnostics are used primarily for on-board loopback
tests and more extensive component diagnostics. Various components on the board are put into
loopback mode, and test packets are transmitted through those components. These diagnostics also
perform snake tests using VLAN configurations.
• You can only perform offline diagnostics on an offline standalone unit or offline member unit of a
stack of three or more. You cannot perform diagnostics on the management or standby unit in a stack
of two or more (Message 1).
Message 1 Offline Diagnostics on Master/Standby Error
Running Diagnostics on master/standby unit is not allowed on stack.
2. Use the show system brief command from EXEC Privilege mode to confirm offline status, as shown in
Figure 62-2.
-- Stack Info --
Unit UnitType Status ReqTyp CurTyp Version Ports
---------------------------------------------------------------------------
0 Standby online S25V S25V 4.7.7.220 28
1 Management offline S50N S50N 4.7.7.220 52
2 Member online S25P S25P 4.7.7.220 28
3 Member not present
4 Member not present
5 Member not present
6 Member not present
7 Member not present
-- Module Info --
Unit Module No Status Module Type Ports
---------------------------------------------------------------------------
0 0 online S50-01-10GE-2C 2
0 1 online S50-01-12G-2S 2
1 0 online S50-01-10GE-2P 2
1 1 online S50-01-12G-2S 2
2 0 not present No Module 0
2 1 offline S50-01-12G-2S 2
-- Power Supplies --
Unit Bay Status Type
---------------------------------------------------------------------------
0 0 up AC
0 1 absent
1 0 up AC
1 1 absent
2 0 up AC
2 1 absent
3. Start diagnostics on the unit using the command diag, as shown in Figure 62-3. When the tests are
complete, the system displays syslog Message 2, and automatically reboots the unit. Diagnostic results
are printed to a file in the flash using the filename format TestReport-SU-<stack-unit>.txt.
As shown in Figure 62-3 and Figure 62-4, log messages differ somewhat when diagnostics are done on a
standalone unit and on a stack member.
Figure 62-4 shows the output of the master and member units when you run offline diagnostics on a
member unit.
4. View the results of the diagnostic tests using the command show file flash:// from EXEC Privilege
mode, as shown in Figure 62-5.
**********************************S-Series Diagnostics********************
Stack Unit Board Serial Number : DL267160098
CPU Version : MPC8541, Version: 1.1
PLD Version : 5
Diag image based on build : E_MAIN4.7.7.206
Stack Unit Board Voltage levels - 3.300000 V, 2.500000 V, 1.800000 V, 1.250000 V, 1.200000
V, 2.000000 V
Stack Unit Board temperature : 26 Degree C
Stack Unit Number : 0
********MFG INFO*******************
Trace logs
In addition to the syslog buffer, FTOS buffers trace messages which are continuously written by various
FTOS software tasks to report hardware and software events and status information. Each trace message
provides the date, time, and name of the FTOS process. All messages are stored in a ring buffer and can be
saved to a file either manually or automatically upon failover.
Exception information on for master or standby units is stored in the flash:/TRACE_LOG_DIR directory.
This directory contains files that save trace information when there has been a task crash or timeout.
On a master unit, the TRACE_LOG_DIR files can be reached by FTP or by using the show file command
from the flash://TRACE_LOG_DIR directory.
On a Standby unit, the TRACE_LOG_DIR files can be reached only by using the show file command
from the flash://TRACE_LOG_DIR directory.
Command Description
hardware watchdog Enable the hardware watchdog mechanism.
Buffer tuning
Buffer Tuning allows you to modify the way your switch allocates buffers from its available memory, and
helps prevent packet drops during a temporary burst of traffic.
The S-Series ASICs implement the key functions of queuing, feature lookups, and forwarding lookups in
hardware.
• Forwarding Processor (FP) ASICs provide Ethernet MAC functions, queueing and buffering, as well
as store feature and forwarding tables for hardware-based lookup and forwarding decisions. 1G and
10G interfaces use different FPs.
Table 62-1 describes the type and number of ASICs per platform.
Hardware FP CSF
S50N, S50V 2 0
S25V, S25P, S25N 1 0
All ports support eight queues, 4 for data traffic and 4 for control traffic. All 8 queues are tunable.
Physical memory is organized into cells of 128 bytes. The cells are organized into two buffer pools—
dedicated buffer and dynamic buffer.
• Dedicated buffer is reserved memory that cannot be used by other interfaces on the same ASIC or by
other queues on the same interface. This buffer is always allocated, and no dynamic recarving takes
place based on changes in interface status. Dedicated buffers introduce a trade-off. They provide each
interface with a guaranteed minimum buffer to prevent an overused and congested interface from
starving all other interfaces. However, this minimum guarantee means the buffer manager does not
reallocate the buffer to an adjacent congested interface, which means that in some cases, memory is
underused.
• Dynamic buffer is shared memory that is allocated as needed, up to a configured limit. Using dynamic
buffers provides the benefit of statistical buffer sharing. An interface requests dynamic buffers when
its dedicated buffer pool is exhausted. The buffer manager grants the request based on three
conditions:
• The number of used and available dynamic buffers
• The maximum number of cells that an interface can occupy
• Available packet pointers (2k per interface). Each packet is managed in the buffer using a unique
packet pointer. Thus, each interface can manage up to 2k packets.
You can configure dynamic buffers per port on both 1G and 10G FPs and per queue on CSFs. By default,
the FP dynamic buffer allocation is 10 times oversubscribed. For the 48-port 1G card:
• Dynamic Pool= Total Available Pool(16384 cells) – Total Dedicated Pool = 5904 cells
• Oversubscription ratio = 10
• Dynamic Cell Limit Per port = 59040/29 = 2036 cells
CSF Unit 3
1
IDP Switch Links
FP Unit 1
Front-end Links 3
PHY PHY
As a guideline, consider tuning buffers if traffic is very bursty (and coming from several interfaces). In this
case:
Define a buffer profile for the CSF queues. buffer-profile csf csqueue CONFIGURATION
Change the maximum amount of dynamic buffers buffer dynamic BUFFER PROFILE
an interface can request.
Change the number of packet-pointers per queue. buffer packet-pointers BUFFER PROFILE
Apply the buffer profile to a line card. buffer fp-uplink linecard CONFIGURATION
Apply the buffer profile to a CSF to FP link. buffer csf linecard CONFIGURATION
FTOS Behavior: If you attempt to apply a buffer profile to a non-existent port-pipe, FTOS displays the
following message. However, the configuration still appears in the running-config.
%DIFFSERV-2-DSA_BUFF_CARVING_INVALID_PORT_SET: Invalid FP port-set 2 for linecard 2. Valid
range of port-set is <0-1>
Configuration changes take effect immediately and appear in the running configuration. Since under
normal conditions all ports do not require the maximum possible allocation, the configured dynamic
allocations can exceed the actual amount of available memory; this is called oversubscription. If you
choose to oversubscribe the dynamic allocation, a burst of traffic on one interface might prevent other
interfaces from receiving the configured dynamic allocation, which causes packet loss.
You cannot allocate more than the available memory for the dedicated buffers. If the system determines
that the sum of the configured dedicated buffers allocated to the queues is more than the total available
memory, the configuration is rejected, returning a syslog message similar to the following.
FTOS Behavior: When you remove a buffer-profile using the command no buffer-profile [fp | csf] from
CONFIGURATION mode, the buffer-profile name still appears in the output of show buffer-profile
[detail | summary]. After a line card reset, the buffer profile correctly returns to the default values, but
the profile name remains. Remove it from the show buffer-profile [detail | summary] command output
by entering no buffer [fp-uplink |csf] linecard port-set buffer-policy from CONFIGURATION mode
and no buffer-policy from INTERFACE mode.
Display the allocations for any buffer profile using the show commands in Figure 62-8. Display the default
buffer profile using the command show buffer-profile {summary | detail} from EXEC Privilege mode, as
shown in Figure 62-7.
FTOS provides two pre-defined buffer profiles, one for single-queue (i.e non-QoS) applications, and one
for four-queue (i.e QoS) applications.
Apply one of two pre-defined buffer profiles for all port buffer-profile global [1Q|4Q] CONFIGURATION
pipes in the system.
You must reload the system for the global buffer profile to take effect (Message 3).
FTOS Behavior: After you configure buffer-profile global 1Q, Message 3 is displayed during every
bootup. Only one reboot is required for the configuration to take effect; afterwards this bootup
message may be ignored.
FTOS Behavior: The buffer profile does not returned to the default, 4Q, if you configure 1Q, save the
running-config to the startup-config, and then delete the startup-config and reload the chassis. The
only way to return to the default buffer profile is to explicitly configure 4Q, and then reload the chassis.
The buffer-profile global command fails if you have already applied a custom buffer profile on an interface.
Similarly, when buffer-profile global is configured, you cannot not apply a buffer profile on any single
interface.
If the default buffer profile (4Q) is active, FTOS displays an error message instructing you to remove the
default configuration using the command no buffer-profile global.
!
buffer-profile fp fsqueue-fp
buffer dedicated queue0 3 queue1 3 queue2 3 queue3 3 queue4 3 queue5 3 queue6 3 queue7 3
buffer dynamic 1256
!
buffer-profile fp fsqueue-hig
buffer dedicated queue0 3 queue1 3 queue2 3 queue3 3 queue4 3 queue5 3 queue6 3 queue7 3
buffer dynamic 1256
!
buffer fp-uplink stack-unit 0 port-set 0 buffer-policy fsqueue-hig
buffer fp-uplink stack-unit 0 port-set 1 buffer-policy fsqueue-hig
!
Interface range gi 0/1 - 48
buffer-policy fsqueue-fp
Display drop counters with the show hardware stack-unit drops unit port command:
Dataplane Statistics
The show hardware stack-unit cpu data-plane statistics command provides insight into the packet types
coming to the CPU. As shown in Figure 62-12, the command output has been augmented, providing
detailed RX/TX packet statistics on a per-queue basis. The objective is to see whether CPU-bound traffic is
internal (so-called party bus or IPC traffic) or network control traffic, which the CPU must process.
The show hardware stack-unit cpu party-bus statistics command displays input and output statistics on the
party bus, which carries inter-process communication traffic between CPUs, as shown in Figure 62-13.
The show hardware stack-unit stack-port command displays input and output statistics for a stack-port
interface, as shown in Figure 62-14.
Enable RPM core dumps and specify the logging coredump server CONFIGURATION
shutdown mode. You may specify an IPv4 or
IPv6 address for the server.
Application and kernel mini core dumps are always enabled. The mini core dumps contain the stack space
and some other very minimal information that can be used to debug a crash. These files are small files and
are written into flash until space is exhausted. When the flash is full, the write process is stopped.
Note: If the Hardware watchdog timer is enabled and it triggers, no kernel core dump is generated
because this is considered a power-off. In all other kernel crashes, a kernel mini core dump is be
generated. When an application crashes, only the application coredump is generated.
A mini core dump contains critical information in the event of a crash. Mini core dump files are located in
flash:/ (root dir). The application mini core file name format is f10StkUnit<Stack_unit_no>.<Application
name>.acore.mini.txt. The kernel mini core file name format is f10StkUnit<Stack_unit_no>.kcore.mini.txt.
Sample files names are shown in Figure 62-16 and sample file text is shown in Figure 62-17.
FTOS#dir
Directory of flash:
When a member or standby unit crashes, the mini core file gets uploaded to master unit. When the master
unit crashes, the mini core file is uploaded to new master.
VALID MAGIC
------------------------PANIC STRING -----------------
panic string is :<null>
----------------------STACK TRACE START---------------
0035d60c <f10_save_mmu+0x120>:
00274f8c <panic+0x144>:
0024e2b0 <db_fncall+0x134>:
0024dee8 <db_command+0x258>:
0024d9c4 <db_command_loop+0xc4>:
002522b0 <db_trap+0x158>:
0026a8d0 <mi_switch+0x1b0>:
0026a00c <bpendtsleep>:
------------------------STACK TRACE END----------------
---------------------------FREE MEMORY---------------
uvmexp.free = 0x2312
The panic string contains key information regarding the crash. Several panic string types exist, and they are
displayed in regular english text to enable easier understanding of the crash cause.
IEEE Compliance
• 802.1AB — LLDP
• 802.1D — Bridging, STP
• 802.1p — L2 Prioritization
• 802.1Q — VLAN Tagging, Double VLAN Tagging, GVRP
• 802.1s — MSTP
• 802.1w — RSTP
• 802.1X — Network Access Control (Port Authentication)
• 802.3ab — Gigabit Ethernet (1000BASE-T)
• 802.3ac — Frame Extensions for VLAN Tagging
• 802.3ad — Link Aggregation with LACP
• 802.3ae — 10 Gigabit Ethernet (10GBASE-W, 10GBASE-X)
• 802.3af — Power over Ethernet
• 802.3ak — 10 Gigabit Ethernet (10GBASE-CX4)
• 802.3i — Ethernet (10BASE-T)
• 802.3u — Fast Ethernet (100BASE-FX, 100BASE-TX)
• 802.3x — Flow Control
• 802.3z — Gigabit Ethernet (1000BASE-X)
• ANSI/TIA-1057— LLDP-MED
• Dell Force10 — FRRP (Force10 Redundant Ring Protocol)
Note: Checkmarks () in the E-Series column indicate that FTOS support was added before FTOS
version 7.5.1.
E-Series E-Series
RFC# Full Name S-Series C-Series TeraScale ExaScale
768 User Datagram Protocol 7.6.1 7.5.1 8.1.1
793 Transmission Control Protocol 7.6.1 7.5.1 8.1.1
854 Telnet Protocol Specification 7.6.1 7.5.1 8.1.1
959 File Transfer Protocol (FTP) 7.6.1 7.5.1 8.1.1
1321 The MD5 Message-Digest Algorithm 7.6.1 7.5.1 8.1.1
1350 The TFTP Protocol (Revision 2) 7.6.1 7.5.1 8.1.1
1661 The Point-to-Point Protocol (PPP)
1989 PPP Link Quality Monitoring
1990 The PPP Multilink Protocol (MP)
1994 PPP Challenge Handshake Authentication Protocol
(CHAP)
2474 Definition of the Differentiated Services Field (DS Field) 7.7.1 7.5.1 8.1.1
in the IPv4 and IPv6 Headers
2615 PPP over SONET/SDH
2615 PPP over SONET/SDH
2698 A Two Rate Three Color Marker 8.1.1
3164 The BSD syslog Protocol 7.6.1 7.5.1 8.1.1
draft-ietf-bfd Bidirectional Forwarding Detection 7.6.1 8.1.1
-base-03
E-Series E-Series
RFC# Full Name S-Series C-Series TeraScale ExaScale
791 Internet Protocol 7.6.1 7.5.1 8.1.1
792 Internet Control Message Protocol 7.6.1 7.5.1 8.1.1
826 An Ethernet Address Resolution Protocol 7.6.1 7.5.1 8.1.1
1027 Using ARP to Implement Transparent Subnet Gateways 7.6.1 7.5.1 8.1.1
1035 DOMAIN NAMES - IMPLEMENTATION AND 7.6.1 7.5.1 8.1.1
SPECIFICATION (client)
1042 A Standard for the Transmission of IP Datagrams over IEEE 7.6.1 7.5.1 8.1.1
802 Networks
1191 Path MTU Discovery 7.6.1 7.5.1 8.1.1
1305 Network Time Protocol (Version 3) Specification, 7.6.1 7.5.1 8.1.1
Implementation and Analysis
1519 Classless Inter-Domain Routing (CIDR): an Address 7.6.1 7.5.1 8.1.1
Assignment and Aggregation Strategy
1542 Clarifications and Extensions for the Bootstrap Protocol 7.6.1 7.5.1 8.1.1
1812 Requirements for IP Version 4 Routers 7.6.1 7.5.1 8.1.1
2131 Dynamic Host Configuration Protocol 7.6.1 7.5.1 8.1.1
2338 Virtual Router Redundancy Protocol (VRRP) 7.6.1 7.5.1 8.1.1
3021 Using 31-Bit Prefixes on IPv4 Point-to-Point Links 7.7.1 7.7.1 7.7.1 8.1.1
3046 DHCP Relay Agent Information Option 7.8.1 7.8.1
3069 VLAN Aggregation for Efficient IP Address Allocation 7.8.1 7.8.1
3128 Protection Against a Variant of the Tiny Fragment Attack 7.6.1 7.5.1 8.1.1
E-Series E-Series
RFC# Full Name S-Series C-Series TeraScale ExaScale
1886 DNS Extensions to support IP version 6 7.8.1 7.8.1 8.2.1
1981 Path MTU Discovery for IP version 6 7.8.1 7.8.1 8.2.1
(Partial)
2460 Internet Protocol, Version 6 (IPv6) Specification 7.8.1 7.8.1 8.2.1
2461 Neighbor Discovery for IP Version 6 (IPv6) 7.8.1 7.8.1 8.2.1
(Partial)
2462 IPv6 Stateless Address Autoconfiguration 7.8.1 7.8.1 8.2.1
(Partial)
2463 Internet Control Message Protocol (ICMPv6) for the 7.8.1 7.8.1 8.2.1
Internet Protocol Version 6 (IPv6) Specification
2464 Transmission of IPv6 Packets over Ethernet Networks 7.8.1 7.8.1 8.2.1
2675 IPv6 Jumbograms 7.8.1 7.8.1 8.2.1
3587 IPv6 Global Unicast Address Format 7.8.1 7.8.1 8.2.1
4291 Internet Protocol Version 6 (IPv6) Addressing Architecture 7.8.1 7.8.1 8.2.1
E-Series E-Series
RFC# Full Name S-Series C-Series TeraScale ExaScale
2385 Protection of BGP Sessions via the TCP MD5 Signature 7.8.1 7.7.1 8.1.1
Option
2796 BGP Route Reflection: An Alternative to Full Mesh 7.8.1 7.7.1 8.1.1
Internal BGP (IBGP)
2842 Capabilities Advertisement with BGP-4 7.8.1 7.7.1 8.1.1
4893 BGP Support for Four-octet AS Number Space 7.8.1 7.7.1 7.7.1 8.1.1
5396 Textual Representation of Autonomous System (AS) 8.1.2 8.1.2 8.1.2 8.2.1
Numbers
E-Series E-Series
RFC# Full Name S-Series C-Series TeraScale ExaScale
1587 The OSPF Not-So-Stubby Area (NSSA) Option 7.6.1 7.5.1 8.1.1
4222 Prioritized Treatment of Specific OSPF Version 2 Packets and 7.6.1 7.5.1 8.1.1
Congestion Avoidance
E-Series E-Series
RFC# Full Name S-Series C-Series TeraScale ExaScale
1195 Use of OSI IS-IS for Routing in TCP/IP and Dual 8.1.1
Environments
E-Series E-Series
RFC# Full Name S-Series C-Series TeraScale ExaScale
E-Series E-Series
RFC# Full Name S-Series C-Series TeraScale ExaScale
E-Series E-Series
RFC# Full Name S-Series C-Series TeraScale ExaScale
E-Series E-Series
RFC# Full Name S-Series C-Series TeraScale ExaScale
1215 A Convention for Defining Traps for use with the 7.6.1 7.5.1 8.1.1
SNMP
1493 Definitions of Managed Objects for Bridges [except 7.6.1 7.5.1 8.1.1
for the dot1dTpLearnedEntryDiscards object]
2011 SNMPv2 Management Information Base for the 7.6.1 7.5.1 8.1.1
Internet Protocol using SMIv2
2012 SNMPv2 Management Information Base for the 7.6.1 7.5.1 8.1.1
Transmission Control Protocol using SMIv2
2013 SNMPv2 Management Information Base for the 7.6.1 7.5.1 8.1.1
User Datagram Protocol using SMIv2
2024 Definitions of Managed Objects for Data Link 7.6.1 7.5.1 8.1.1
Switching using SMIv2
2572 Message Processing and Dispatching for the Simple 7.6.1 7.5.1 8.1.1
Network Management Protocol (SNMP)
2574 User-based Security Model (USM) for version 3 of 7.6.1 7.5.1 8.1.1
the Simple Network Management Protocol
(SNMPv3)
2575 View-based Access Control Model (VACM) for the 7.6.1 7.5.1 8.1.1
Simple Network Management Protocol (SNMP)
E-Series E-Series
RFC# Full Name S-Series C-Series TeraScale ExaScale
2618 RADIUS Authentication Client MIB, except the 7.6.1 7.5.1 8.1.1
following four counters:
radiusAuthClientInvalidServerAddresses
radiusAuthClientMalformedAccessResponses
radiusAuthClientUnknownTypes
radiusAuthClientPacketsDropped
2665 Definitions of Managed Objects for the Ethernet-like 7.6.1 7.5.1 8.1.1
Interface Types
2674 Definitions of Managed Objects for Bridges with 7.6.1 7.5.1 8.1.1
Traffic Classes, Multicast Filtering and Virtual LAN
Extensions
2787 Definitions of Managed Objects for the Virtual 7.6.1 7.5.1 8.1.1
Router Redundancy Protocol
3416 Version 2 of the Protocol Operations for the Simple 7.6.1 7.5.1 8.1.1
Network Management Protocol (SNMP)
3418 Management Information Base (MIB) for the 7.6.1 7.5.1 8.1.1
Simple Network Management Protocol (SNMP)
3434 Remote Monitoring MIB Extensions for High 7.6.1 7.5.1 8.1.1
Capacity Alarms, High-Capacity Alarm Table (64
bits)
3580 IEEE 802.1X Remote Authentication Dial In User 7.6.1 7.5.1 8.1.1
Service (RADIUS) Usage Guidelines
E-Series E-Series
RFC# Full Name S-Series C-Series TeraScale ExaScale
ANSI/TIA-1057 The LLDP Management Information Base extension 7.7.1 7.6.1 7.6.1 8.1.1
module for TIA-TR41.4 Media Endpoint Discovery
information
draft-ietf-idr-bgp4 Definitions of Managed Objects for the Fourth 7.8.1 7.7.1 8.1.1
-mib-06 Version of the Border Gateway Protocol (BGP-4)
using SMIv2
IEEE 802.1AB Management Information Base module for LLDP 7.7.1 7.6.1 7.6.1 8.1.1
configuration, statistics, local system data and
remote systems data components.
IEEE 802.1AB The LLDP Management Information Base extension 7.7.1 7.6.1 7.6.1 8.1.1
module for IEEE 802.1 organizationally defined
discovery information.
(LLDP DOT1 MIB and LLDP DOT3 MIB)
IEEE 802.1AB The LLDP Management Information Base extension 7.7.1 7.6.1 7.6.1 8.1.1
module for IEEE 802.3 organizationally defined
discovery information.
(LLDP DOT1 MIB and LLDP DOT3 MIB)
ruzin-mstp-mib-0 Definitions of Managed Objects for Bridges with 7.6.1 7.6.1 7.6.1 8.1.1
2 (Traps) Multiple Spanning Tree Protocol
FORCE10-FIB-M Dell Force10 CIDR Multipath Routes MIB (The IP 7.6.1 8.1.1
IB Forwarding Table provides information that you can
use to determine the egress port of an IP packet and
troubleshoot an IP reachability issue. It reports the
autonomous system of the next hop, multiple next
hop support, and policy routing support)
E-Series E-Series
RFC# Full Name S-Series C-Series TeraScale ExaScale
FORCE10-IF-EX Dell Force10 Enterprise IF Extension MIB (extends 7.6.1 7.6.1 7.6.1 8.1.1
TENSION-MIB the Interfaces portion of the MIB-2 (RFC 1213) by
providing proprietary SNMP OIDs for other
counters displayed in the ”show interfaces” output)
FORCE10-LINK Dell Force10 Enterprise Link Aggregation MIB 7.6.1 7.5.1 8.1.1
AGG-MIB
FORCE10-PROD Dell Force10 Product Object Identifier MIB 7.6.1 7.5.1 8.1.1
UCTS-MIB
FORCE10-SYST Dell Force10 System Component MIB (enables the 7.6.1 7.5.1 8.1.1
EM-COMPONE user to view CAM usage information)
NT-MIB
https://www.force10networks.com/csportal20/KnowledgeBase/Documentation.aspx
You also can obtain a list of selected MIBs and their OIDs at the following URL:
https://www.force10networks.com/csportal20/MIBs/MIB_OIDs.aspx
https://www.force10networks.com/CSPortal20/Support/AccountRequest.aspx
If you have forgotten or lost your account information, contact Dell Force10 TAC for assistance.
1252
|
Standards Compliance
Index
Numerics definition 133
10/100/1000 Base-T Ethernet line card, auto IP ACL definition 133
negotiation 455 RADIUS 927
100/1000 Ethernet interfaces ACL, apply (through XML CLI) 1161
port channels 429 ACL, create egress and apply rules through XML
4-Byte AS Numbers 218 CLI 1162
802.1AB 1239 ACL, extended (configure through XML CLI) 1161
802.1D 1239 ACL, standard (configure through XML CLI) 1161
802.1p 1239 ANSI/TIA-1057 586
802.1p/Q 1239 Applying an ACL to Loopback 151
802.1Q 1239 Area Border Router. See ABR.
802.1s 1239 AS 206
802.1w 1239 support 226
802.1X 1239 AS-PATH ACL
802.3ab 1239 "permit all routes" statement 257
802.3ac 1239 configuring 243
802.3ad 1239 AS_PATH attribute
using 243
802.3ae 1239
authentication
802.3af 1239
implementation 917
802.3ak 1239
Authentication, TACACS+ 933
802.3i 1239
Authentication, VTY 948
802.3u 1239
Authorization, TACACS+ 933
802.3x 1239
Authorization, VTY 948
802.3z 1239
auto negotiation 455
auto negotiation, line card 455
A Auto-command 928
AAA (Accounting, Authentication, and Authorization)
security model 913
AAA Accounting 913
B
balancing, load 436
aaa accounting command 914
BGP
aaa accounting suppress null-username command 915
Attributes 211
AAA Authentication
Autonomous Systems 206
authentication and authorization, local by default 920
aaa authentication best path criteria 211
configuring 918 changing COMMUNITY numbers in a path 250
enable method 918 changing how MED attribute is used 252
line method 918 changing LOCAL_PREF default value 252
local method 918 changing the LOCAL_PREF default values for routes on
a router 252
none method 918
clearing route dampening information 262
radius method 918
Communities 210
tacacs+ 918
configuring a route reflector 257
aaa authentication command 919
configuring an AS-PATH ACL 243
aaa authentication enable command 919
configuring an IP community list 248
AAA Authentication—Enable 919
AAA Authorization configuring BGP confederations 259
AAA new-model enabled by default 920 configuring BGP timers 263
ABR configuring route flap dampening 260
definition 711 configuring the router as next hop 253
access-class 934 creating a peer group 232
ACL default 250
Index | 1253
defaults 225 C
www.dell.com | support.dell.com
1254 | Index
flowcontrol 452 IEEE Standard 802.3ad 428
Force 10 Resilient Ring Protocol 335 IGMP
forward delay 905, 1055 viewing which interfaces are IGMP-enabled 408
FRRP 335 implicit deny 133
FRRP Master Node 335 interface GigabitEthernet command 1161, 1162
FRRP Transit Node 336 Interface modes
FTOS 699 Layer 2 420
FTOS XML session management 1159 Layer 3 420
FTP 68 Interface Range Macros 443
Interface types
100/1000 Ethernet 415, 420
G
10-Gigabit Ethernet 415, 420
GARP VLAN Registration Protocol (GVRP) 373 1-Gigabit Ethernet 415, 420
graceful restart 390
Loopback 420
grep option 43
management 420
GVRP (GARP VLAN Registration Protocol) 373 Management Ethernet interface 419
Port Channel 420
H VLAN 420
Hash algorithm 439 interface types
hash algorithm, LAG 332, 431, 433, 436 null interface 420
hashing algorithms for flows and fragments 436 interfaces
hello time 905, 1055 auto negotiation setting 455
High Availability clearing counters 461
cache boot 394 commands allowed when part of a port channel 431
core dumps 392 configuring secondary IP addresses 465
definition 379 determining configuration 421
graceful restart 390 member of port channel 433
hitless behavior 389 viewing Layer 3 interfaces 417
hot-lock behavior 393 viewing only Layer 2 interfaces 458
line card online insertion and removal 387 Inter-VLAN routing 426
process restartability 399 considerations 426
RPM online insertion and removal 387 ip access command 1163, 1164, 1165
RPM redundancy ip access list standard command 1161
RPM
ip access standard command 1160
redundancy 380 ip access-group command 1161, 1162
runtime system check 391 ip access-list extended command 1162
SFM channel monitoring 391 IP ACLs
software resiliency 390 applying ACL for loopback 151
system log 393 applying IP ACL to interface 148
trace log 392 configuring extended IP ACL 143
warm upgrade 393 configuring extended IP ACL for TCP 144
hitless behavior 389 configuring extended IP ACL for UDP 144
Hot Lock ACL 134 configuring filter without sequence number 145
Hot Lock PBRs 803 configuring standard IP ACL 141, 142
hot-lock behavior 393 deleting a filter 142, 143
extended IP ACLs 134, 143
I standard IP ACL 134
I-D (Internet Draft) Compliance 1240 types 134
Idle Time 927 viewing configuration 141
IEEE 802.1q 373 ip address command 1161
IEEE Compliance 1239 IP addresses
Index | 1255
assigning IP address to interface 421 ISO/IEC 10589 509
www.dell.com | support.dell.com
1256 | Index
LSAs 692 length 508
AS Boundary 699 N-selector 508
AS External 699 system address 508
Network 699 network boot facility 78
Network Summary 699 Network Entity Title. See NET.
NSSA External 700 NIC teaming 569
Opaque Area-local 699 no permit host command 1165
Opaque Link-local 700 no-more 44
Router 699 no-more parameter 44
types supported 699 NSAP addresses 508
LSPs 508 NTP
configuring authentication 1075
M configuring source address 1074
null 420
MAC hashing scheme 438
null interface
management interface 420
available command 427
accessing 423
definition 427
configuring a management interface 423
entering the interface 427
configuring IP address 423
information 420
definition 423
IP address consideration 423
O
management interface, switch 419
Object tracking
max age 905, 1055 IPv4 route 679, 684
MBGP 266 IPv6 route 679
Member VLAN (FRRP) 337 Layer 2 interface 678
MIB Location 1251 Layer 2 interfaces 681
minimum oper up links in a port channel 434 Layer 3 interface 679
mirror, port 813, 1085 Layer 3 interfaces 682
remote port mirroring 821, 1086 overview 677
monitor interfaces 444 VRRP 1139
MT IS-IS 509 object tracking
MT IS-IS TLVs 511 VRRP 1140
MTU Open Shortest Path First 692
configuring MTU values for Port Channels 453 OSFP Adjacency with Cisco Routers 703
configuring MTU values for VLANs 453 OSPF 692
definition 450 backbone area 708
IP MTU
configuring 453 changing authentication parameters 717
maximum size 450 changing interface parameters 716
link MTU configuring a passive interface 713
configuring 453 configuring a stub area 711
maximum size 450 configuring a stub-router advertisement 712
MTU Size, Configuring on an Interface 453 configuring network command 708
MULTI_EXIT_DISC attribute configuring virtual links 720
changing 252 debugging OSPF 724, 745
default value 225 default 704
Multi-Topology IS-IS 509 disabling OSPF 706, 708
enabling routing 705
N maximum metric in LSAs 712
NET 508 redistributing routes 721
area address 508 restarting OSPF 706, 708
Index | 1257
router ID 709 privilege levels
www.dell.com | support.dell.com
1258 | Index
adding routes 882 seq permit command 1164
auto summarization default 878 SFM channel monitoring 391
changing RIP version 882 show accounting command 916
configuring interfaces to run RIP 880 show chassis command 1155
debugging RIP 886 show commands supported by XML CLI 1155
default values 878 show crypto 938
default version 879 show interfaces command 458, 1156
disabling RIP 880 show interfaces switchport command 458
ECMP paths supported 878 show ip protocols command 887, 889
enabling RIP 879 show ip rip database command 887, 889
route information 881 show ip route command 887, 889
setting route metrics 885 show ip ssh client-pub-keys 938
summarizing routes 885 show ip ssh command 936
timer values 878 show ip ssh rsa-authentication 938
version 1 description 877 show linecard all command 1156
version default on interfaces 878 show linecard command 1156
RIP routes, maximum 878 show logging command 1156
RIPv1 877 show logging reverse command 1156
RIPv2 878 show rpm all command 1155
root bridge 904, 1055 show rpm command 1155
route maps show running-config command 1156
configuring match commands 164 show sfm all command 1156
configuring set commands 165 show sfm command 1156
creating 161 show version command 1156
creating multiple instances 162 soft-reconfiguration of BGP neighbor 263
default action 161 software resiliency 390
definition 160 SONET interfaces 415
deleting 162, 163 configuring 1007
implementation 160 Spanning Tree group. See STG.
implicit deny 160 SSH 935
redistributing routes 166 ssh command 936
tagging routes 167 SSH connection 938
route reachability SSH debug 937
used in object tracking 679, 684 SSH display 936
RPM SSH host-keys 938
hitless behavior 389 ssh-peer-rpm 938
online insertion and removal 387 SSHv2 server 938
RSA 938 standard IP ACL 134
runtime system check 391 static route 466
STG
S changing parameters 905, 1055
SCP 935, 936 default 905, 1055
SCP/SSH server 936 port cost 905, 1055
searching show commands 44 root bridge 904, 1055
display 44 sticky MAC addresses 564
grep 44 STP
Secure Shell (SSH) 935 benefits 1049
seq bridge priority 908, 1060
Redirect list 808 default 905, 1055
seq deny command 1161, 1162 definition 1049
Index | 1259
disabling STP 901, 1052 Virtual Routing and Forwarding. See VRF.
www.dell.com | support.dell.com
1260 | Index
remote authentication and local authorization 949
TACACS+ authentication, support for local
authorization 949
VTYlines
local authentication and authorization 948
W
warm upgrade 393
X
XML 1155, 1159
XML CLI
apply ACL 1161
configure extended ACL 1161
configure standard ACL 1161
create egress ACL and apply rules 1162
error conditions 1163
error responses 1162
show commands supported 1155
XML CLI Limitations 1162
XML CLI request 1159
XML mode 1156
XML namespace 1162
Index | 1261
www.dell.com | support.dell.com
1262
|
Index