OmniSwitch AOS Release 8 Network Configuration Guide

Part No. 060480-10
September 2017
OmniSwitch AOS Release 8
Network Configuration Guide
8.4.1.R02
This user guide covers multiple OmniSwitch product lines and describes overall AOS feature
configuration information. For platform specific feature support, please refer to the Specifications
Guide and the Release Notes.
www.al-enterprise.com
This user guide documents AOS Release 8.4.1.R02 for the
OmniSwitch 9900, OmniSwitch 6900, OmniSwitch 6860, OmniSwitch 6865, and OmniSwitch 6560.
The functionality described in this guide is subject to change without notice.
enterprise.alcatel-lucent.com Alcatel-Lucent and the Alcatel-Lucent Enterprise logo are trademarks of
Alcatel-Lucent. To view other trademarks used by affiliated companies of ALE Holding, visit:
enterprise.alcatel-lucent.com/trademarks. All other trademarks are the property of their respective owners.
The information presented is subject to change without notice. Neither ALE Holding nor any of its
affiliates assumes any responsibility for inaccuracies contained herein. (2017)
26801 West Agoura Road
Calabasas, CA 91301
(818) 880-3500 FAX (818) 880-3505
Service & Support Contact Information
North America: 800-995-2696
Latin America : 877-919-9526
EMEA : +800 00200100 (Toll Free) or +1(650)385-2193
Asia Pacific: +65 6240 8484
Web: support.esd.alcatel-lucent.com
Email: ebg_global_supportcenter@al-enterprise.com
Contents
About This Guide ........................................................................................................ xxi
Supported Platforms ........................................................................................................ xxi
Who Should Read this Manual? ...................................................................................... xxi
When Should I Read this Manual? .................................................................................. xxi
What is in this Manual? .................................................................................................. xxii
What is Not in this Manual? ........................................................................................... xxii
How is the Information Organized? ............................................................................... xxii
Documentation Roadmap ..............................................................................................xxiii
Related Documentation .................................................................................................. xxv
Technical Support ......................................................................................................... xxvi
Chapter 1
Configuring Ethernet Ports ...................................................................................... 1-1
In This Chapter ................................................................................................................1-1
Ethernet Port Defaults .....................................................................................................1-2
Ethernet Ports Overview .................................................................................................1-3
Configuring Ethernet Port Parameters ............................................................................1-3
Enabling and Disabling Autonegotiation .................................................................1-3
Configuring Crossover Settings ...............................................................................1-3
Setting Interface Line Speed ....................................................................................1-3
Configuring Duplex Mode .......................................................................................1-4
Setting Trap Port Link Messages .............................................................................1-4
Resetting Statistics Counters ....................................................................................1-4
Enabling and Disabling Interfaces ...........................................................................1-4
Configuring a Port Alias ..........................................................................................1-5
Configuring Maximum Frame Sizes ........................................................................1-5
Configuring Digital Diagnostic Monitoring (DDM) ................................................1-5
Configuring Flood Rate Limiting .............................................................................1-6
Configuring Flood Rate Limiting .............................................................................1-6
Configuring Flood Rate Limit Action ......................................................................1-7
Configuring Flow Control ........................................................................................1-7
Enabling and Disabling Enhanced Port Performance (EPP) ....................................1-9
Configuring Energy Efficient Ethernet (802.3az) ..................................................1-11
Configuring Split-Mode .........................................................................................1-11
Configuring Beacon LED .......................................................................................1-11
Clearing Ethernet Port Violations .................................................................................1-13
Link Monitoring ............................................................................................................1-14
Monitoring Interface Errors ...................................................................................1-14
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
iii
Contents
Monitoring Interface Flapping ...............................................................................1-14
Monitoring Window ...............................................................................................1-15
Configuring the Wait-to-Restore Timer .................................................................1-15
Configuring the Wait-to-Shutdown Timer .............................................................1-16
Displaying Link Monitoring Information ..............................................................1-17
Link Fault Propagation ..................................................................................................1-18
Interaction With Interfaces Violation Recovery ....................................................1-18
Configuring Link Fault Propagation ......................................................................1-19
LFP Application Example ......................................................................................1-20
IEEE 1588 Precision Time Protocol (PTP) ...................................................................1-21
Enabling/Disabling PTP Time Stamping ...............................................................1-21
Chapter 2
Configuring UDLD ...................................................................................................... 2-1
In This Chapter ................................................................................................................2-1
UDLD Defaults ..............................................................................................................2-2
Quick Steps for Configuring UDLD ...............................................................................2-3
UDLD Overview .............................................................................................................2-4
UDLD Operational Mode .........................................................................................2-4
Mechanisms to Detect Unidirectional Links ............................................................2-5
Configuring UDLD .........................................................................................................2-6
Enabling and Disabling UDLD ................................................................................2-6
Configuring the Operational Mode ..........................................................................2-7
Configuring the Probe-Timer ...................................................................................2-7
Configuring the Echo-Wait-Timer ...........................................................................2-7
Clearing UDLD Statistics .........................................................................................2-8
Verifying the UDLD Configuration ................................................................................2-8
Chapter 3
Managing Source Learning ................................................................................... 3-1
In This Chapter ................................................................................................................3-1
Source Learning Defaults ...............................................................................................3-2
MAC Address Table Overview .......................................................................................3-3
Using Static MAC Addresses ..........................................................................................3-3
Configuring Static MAC Addresses .........................................................................3-4
Using Static Multicast MAC Addresses .........................................................................3-5
Configuring Static Multicast MAC Addresses .........................................................3-5
Configuring MAC Address Table Aging Time ..............................................................3-7
Configuring the Source Learning Status .........................................................................3-8
Increasing the MAC Address Table Size ........................................................................3-9
Displaying Source Learning Information ......................................................................3-10
Chapter 4
Configuring VLANs .................................................................................................... 4-1
In This Chapter ................................................................................................................4-1
VLAN Defaults ..............................................................................................................4-2
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
iv
Contents
Sample VLAN Configuration .........................................................................................4-3
VLAN Management Overview .......................................................................................4-4
Creating/Modifying VLANs ...........................................................................................4-4
Adding/Removing a VLAN .....................................................................................4-5
Enabling/Disabling the VLAN Administrative Status .............................................4-5
Modifying the VLAN Description ...........................................................................4-5
Assigning Ports to VLANs ..............................................................................................4-6
Changing the Default VLAN Assignment for a Port ...............................................4-6
Using 802.1Q Tagging .............................................................................................4-7
Enabling/Disabling Spanning Tree for a VLAN .............................................................4-9
Enabling/Disabling Source Learning ..............................................................................4-9
Configuring VLAN IP Interfaces ..................................................................................4-10
Bridging VLANs Across Multiple Switches .................................................................4-11
Verifying the VLAN Configuration ..............................................................................4-13
Understanding Port Output Display .......................................................................4-13
Using Private VLANs ...................................................................................................4-15
Private VLAN Ports ...............................................................................................4-16
Quick Steps for Configuring PVLANs ..................................................................4-16
PVLAN Management Overview ............................................................................4-17
Creating PVLANs ..................................................................................................4-18
Creating Secondary VLANs ...................................................................................4-19
Assigning Ports to PVLANs ..................................................................................4-20
Protocol Configuration Requirements for PVLAN ................................................4-22
Sample PVLAN Use Case ......................................................................................4-24
Verifying the PVLAN Configuration .....................................................................4-25
Chapter 5
Configuring High Availability VLANs ................................................................... 5-1
In This Chapter ................................................................................................................5-1
High Availability Default Values ....................................................................................5-2
Quick Steps for Creating High Availability VLANs ......................................................5-3
High Availability VLAN Overview ................................................................................5-4
High Availability VLAN Operational Mode ...........................................................5-4
Traffic Flows in High Availability VLAN ...............................................................5-5
Configuring High Availability VLANs on a Switch .......................................................5-6
Creating and Deleting VLANs .................................................................................5-6
Adding and Removing Server Cluster Ports ............................................................5-7
Assigning and Modifying Server Cluster Mode ......................................................5-7
Assigning and Removing MAC Addresses ..............................................................5-8
Application Examples .....................................................................................................5-9
Example 1: Layer 2 Server Cluster ..........................................................................5-9
Example 2: Layer 3 Server Cluster ........................................................................5-11
Example 3: Layer 3 Server Cluster with IP Multicast Address to
Cluster (IGMP) ......................................................................................................5-13
Displaying High Availability VLAN Status .................................................................5-16
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
v
Contents
Chapter 6
Configuring Spanning Tree Parameters ............................................................. 6-1
In This Chapter ................................................................................................................6-2
Spanning Tree Bridge Parameter Defaults .....................................................................6-3
Spanning Tree Port Parameter Defaults ..........................................................................6-3
Multiple Spanning Tree (MST) Region Defaults ............................................................6-4
Spanning Tree Overview .................................................................................................6-5
How the Spanning Tree Topology is Calculated .....................................................6-5
MST General Overview ................................................................................................6-12
How MSTP Works .................................................................................................6-12
Comparing MSTP with STP and RSTP .................................................................6-15
What is a Multiple Spanning Tree Instance (MSTI) ..............................................6-15
What is a Multiple Spanning Tree Region .............................................................6-16
What is the Common Spanning Tree .....................................................................6-17
What is the Internal Spanning Tree (IST) Instance ................................................6-17
What is the Common and Internal Spanning Tree Instance ...................................6-17
MST Configuration Overview ...............................................................................6-17
MST Interoperability and Migration ......................................................................6-18
Spanning Tree Operating Modes ..................................................................................6-20
Using Flat Spanning Tree Mode ............................................................................6-20
Using Per-VLAN Spanning Tree Mode .................................................................6-21
Using Per-VLAN Spanning Tree Mode with PVST+ ............................................6-22
OmniSwitch PVST+ Interoperability .....................................................................6-23
Using Spanning Tree Configuration Commands ..........................................................6-26
Configuring STP Bridge Parameters .............................................................................6-26
Selecting the Spantree Protocol ..............................................................................6-27
Configuring the Bridge Priority .............................................................................6-28
Configuring the Bridge Hello Time .......................................................................6-29
Configuring the Bridge Max-Age Time .................................................................6-29
Configuring the Forward Delay Time for the Switch ............................................6-30
Enabling/Disabling the VLAN BPDU Switching Status .......................................6-30
Configuring the Path Cost Mode ............................................................................6-31
Using Automatic VLAN Containment ...................................................................6-31
Configuring STP Port Parameters .................................................................................6-33
Enabling/Disabling Spanning Tree on a Port .........................................................6-34
Enabling/Disabling Loop-guard .............................................................................6-35
Configuring Port Priority .......................................................................................6-35
Configuring Port Path Cost ....................................................................................6-36
Configuring Port Mode ..........................................................................................6-39
Configuring Port Connection Type ........................................................................6-40
Configuring the Edge Port Status ...........................................................................6-41
Restricting Port Roles (Root Guard) ......................................................................6-42
Restricting TCN Propagation .................................................................................6-42
Limiting BPDU Transmission ................................................................................6-42
Sample Spanning Tree Configuration ...........................................................................6-43
Example Network Overview ..................................................................................6-43
Example Network Configuration Steps ..................................................................6-44
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
vi
Contents
Sample MST Region Configuration ..............................................................................6-46
Sample MSTI Configuration .........................................................................................6-48
Verifying the Spanning Tree Configuration .................................................................6-51
Chapter 7
Configuring Loopback Detection ........................................................................... 7-1
In This Chapter ................................................................................................................7-1
LBD Defaults ..................................................................................................................7-2
Quick Steps for Configuring LBD ..................................................................................7-3
LBD Overview ................................................................................................................7-4
Transmission Timer ..................................................................................................7-4
Remote-origin LBD Overview ........................................................................................7-4
Interaction With Other Features ......................................................................................7-6
Spanning Tree Protocol ............................................................................................7-6
Link Aggregation .....................................................................................................7-6
Configuring LBD ............................................................................................................7-7
Enabling LBD ..........................................................................................................7-7
Enabling Remote-origin LBD ..................................................................................7-7
Configuring the LBD Transmission Timer ..............................................................7-8
Viewing LBD Statistics ............................................................................................7-8
Recovering a Port from LBD Shutdown ..................................................................7-8
Configuring Autorecovery-timer for LBD shutdown ports .....................................7-8
LBD for Service Access Interface ...................................................................................7-8
Enabling LBD on Service-access Interface ..............................................................7-9
LBD Packet Processing Mechanism for LBD Service Access Ports .....................7-10
Sample Scenarios ...................................................................................................7-11
Verifying the LBD Configuration .................................................................................7-13
Chapter 8
Configuring Static Link Aggregation .................................................................... 8-1
In This Chapter ................................................................................................................8-1
Static Link Aggregation Default Values .........................................................................8-2
Quick Steps for Configuring Static Link Aggregation ...................................................8-3
Static Link Aggregation Overview .................................................................................8-5
Static Link Aggregation Operation ..........................................................................8-5
Relationship to Other Features .................................................................................8-6
Configuring Static Link Aggregation Groups .................................................................8-6
Configuring Mandatory Static Link Aggregate Parameters .....................................8-6
Creating and Deleting a Static Link Aggregate Group ............................................8-7
Adding and Deleting Ports in a Static Aggregate Group .........................................8-7
Modifying Static Aggregation Group Parameters ...........................................................8-9
Modifying the Static Aggregate Group Name .........................................................8-9
Modifying the Static Aggregate Group Administrative State ..................................8-9
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
vii
Contents
Application Example .....................................................................................................8-10
Displaying Static Link Aggregation Configuration and Statistics ................................8-11
Chapter 9
Configuring Dynamic Link Aggregation .............................................................. 9-1
In This Chapter ................................................................................................................9-1
Dynamic Link Aggregation Default Values ...................................................................9-2
Quick Steps for Configuring Dynamic Link Aggregation ..............................................9-3
Dynamic Link Aggregation Overview ............................................................................9-5
Dynamic Link Aggregation Operation .....................................................................9-5
Relationship to Other Features .................................................................................9-7
Configuring Dynamic Link Aggregate Groups ...............................................................9-7
Configuring Mandatory Dynamic Link Aggregate Parameters ...............................9-8
Creating and Deleting a Dynamic Aggregate Group ...............................................9-8
Configuring Ports to Join and Removing Ports in a Dynamic
Aggregate Group .....................................................................................................9-9
Modifying Dynamic Link Aggregate Group Parameters ..............................................9-11
Modifying Dynamic Aggregate Group Parameters ...............................................9-11
Modifying Dynamic Link Aggregate Actor Port Parameters ................................9-16
Modifying Dynamic Aggregate Partner Port Parameters ......................................9-19
Application Examples ...................................................................................................9-25
Sample Network Overview ....................................................................................9-25
Link Aggregation and Spanning Tree Example .....................................................9-26
Link Aggregation and QoS Example .....................................................................9-27
Displaying Dynamic Link Aggregation Configuration and Statistics ..........................9-28
Chapter 10
Configuring Dual-Home Links .............................................................................. 10-1
In This Chapter ..............................................................................................................10-1
Dual-Home Link Active-Active Defaults .....................................................................10-2
Dual-Home Link Active-Active ....................................................................................10-3
DHL Active-Active Operation ...............................................................................10-3
DHL Configuration Guidelines ..............................................................................10-6
Configuring DHL Active-Active ...........................................................................10-6
Dual-Home Link Active-Active Example ..............................................................10-8
Recommended DHL Active-Active Topology ....................................................10-10
Unsupported DHL Active-Active Topology (Network Loops) ...........................10-11
Displaying the Dual-Home Link Configuration .........................................................10-12
Chapter 11
Configuring ERP ....................................................................................................... 11-1
In This Chapter ..............................................................................................................11-1
ERP Defaults .................................................................................................................11-2
ERP Overview ...............................................................................................................11-3
ERP Basic Operation ..............................................................................................11-5
ERPv2 Basic Operation ..........................................................................................11-7
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
viii
Contents
Interaction With Other Features ....................................................................................11-9
Quick Steps for Configuring ERP with Standard VLANs ..........................................11-10
Quick Steps for Configuring ERP with VLAN Stacking ............................................11-11
ERP Configuration Overview and Guidelines ............................................................11-12
Configuring an ERP Ring ...........................................................................................11-13
Adding VLANs to Ring Ports ..............................................................................11-13
Configuring an RPL Port ......................................................................................11-14
Setting the Wait-to-Restore Timer .......................................................................11-14
Setting the Guard Timer .......................................................................................11-14
Configuring ERP with VLAN Stacking NNIs .....................................................11-15
Clearing ERP Statistics ........................................................................................11-16
ERPv2 Configuration Overview and Guidelines ........................................................11-17
Major and Sub Ring Management .......................................................................11-17
Sample Switch Configuration ..............................................................................11-18
Sample Ethernet Ring Protection Configuration .........................................................11-21
Example ERP Overview .......................................................................................11-21
Example ERP Configuration Steps ......................................................................11-22
Sample ERPv2 Ring Configuration ............................................................................11-23
Example ERPv2 Overview ...................................................................................11-23
Configuring Shared Link ......................................................................................11-24
Configuring Switches in Main Ring .....................................................................11-25
Configuring Secondary RPL Node ......................................................................11-25
Configuring Switch in Sub Ring ..........................................................................11-25
Verifying the ERP Configuration ................................................................................11-26
Chapter 12
Configuring MVRP .................................................................................................... 12-1
In This Chapter ..............................................................................................................12-1
MVRP Defaults .............................................................................................................12-2
Quick Steps for Configuring MVRP .............................................................................12-3
MRP Overview ..............................................................................................................12-4
MVRP Overview ...........................................................................................................12-4
How MVRP Works ................................................................................................12-4
Interaction With Other Features .............................................................................12-6
Configuring MVRP .......................................................................................................12-7
Enabling MVRP .....................................................................................................12-7
Configuring the Maximum Number of VLANs .....................................................12-7
Configuring MVRP Registration ...........................................................................12-8
Configuring the MVRP Applicant Mode ...............................................................12-9
Modifying MVRP Timers ....................................................................................12-10
Restricting VLAN Registration ............................................................................12-11
Restricting Static VLAN Registration ..................................................................12-11
Restricting VLAN Advertisement ........................................................................12-12
Verifying the MVRP Configuration ............................................................................12-13
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
ix
Contents
Chapter 13
Configuring 802.1AB ............................................................................................... 13-1
In This Chapter ..............................................................................................................13-1
802.1AB Defaults Table ................................................................................................13-2
Quick Steps for Configuring 802.1AB ..........................................................................13-3
802.1AB Overview .......................................................................................................13-4
Mandatory TLVs ....................................................................................................13-4
Optional TLVs ........................................................................................................13-4
LLDP-Media Endpoint Devices .............................................................................13-5
LLDP Agent Operation ..........................................................................................13-6
LLDPDU Transmission and Reception ..................................................................13-6
Aging Time ............................................................................................................13-6
LLDP Agent Security Mechanism .........................................................................13-7
Configuring 802.1AB ....................................................................................................13-8
Configuring LLDPDU Flow ..................................................................................13-8
Enabling and Disabling Notification ......................................................................13-8
Enabling and Disabling Management TLV ...........................................................13-9
Enabling and Disabling 802.1 TLV .......................................................................13-9
Enabling and Disabling 802.3 TLV .......................................................................13-9
Enabling and Disabling MED TLV .....................................................................13-10
Enabling and Disabling Proprietary TLV ............................................................13-10
Enabling and Disabling Application Priority TLV ..............................................13-12
Setting the Transmit Interval ................................................................................13-13
Setting the Transmit Hold Multiplier Value ........................................................13-13
Setting the Reinit Delay .......................................................................................13-13
Setting the Notification Interval ...........................................................................13-13
Application Example - LLDP MED .....................................................................13-14
Verifying 802.1AB Configuration ..............................................................................13-15
Chapter 14
Configuring SIP Snooping ...................................................................................... 14-1
In This Chapter ..............................................................................................................14-1
SIP Snooping Defaults ..................................................................................................14-2
Parameter Description and Values ................................................................................14-3
Quick Steps for Configuring SIP Snooping ..................................................................14-4
SIP Snooping Overview ................................................................................................14-5
Using SIP Snooping ......................................................................................................14-6
Interoperability .......................................................................................................14-7
SIP Snooping Configuration Guidelines .......................................................................14-8
Configuring Edge Port ...........................................................................................14-8
Configuring Trusted SIP Server .............................................................................14-8
Configuring SIP Snooping TCP Ports ....................................................................14-9
Configuring SIP Snooping UDP Ports ...................................................................14-9
Configuring the SIP Control DSCP .......................................................................14-9
Configuring SOS Calls ...........................................................................................14-9
Configuring SOS Call DSCP .................................................................................14-9
Configuring RTCP Thresholds .............................................................................14-10
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
x
Contents
Configuring the Logging Threshold for the Number of Calls .............................14-10
Configuring Policy Rules for SIP Snooping ........................................................14-10
Unsupported Topologies ......................................................................................14-11
SIP Snooping Use Case ...............................................................................................14-12
SIP Snooping Limitations ...........................................................................................14-15
Verifying the SIP Snooping Configuration .................................................................14-16
Chapter 15
Configuring IP ........................................................................................................... 15-1
In This Chapter ..............................................................................................................15-1
IP Defaults .....................................................................................................................15-3
Quick Steps for Configuring IP Forwarding .................................................................15-3
IP Overview ..................................................................................................................15-4
IP Protocols ............................................................................................................15-4
IP Forwarding ................................................................................................................15-6
Configuring an IP Interface ....................................................................................15-7
Configuring a Loopback0 Interface .......................................................................15-9
Configuring an IP Managed Interface ..................................................................15-10
Creating a Static Route or Recursive Static Route ...............................................15-11
Creating a Default Route ......................................................................................15-12
Configuring an IP Routed Port .............................................................................15-12
Configuring Address Resolution Protocol (ARP) ................................................15-13
Distributed ARP ..........................................................................................................15-16
Designated-NI and Distributed ARP Management ..............................................15-16
Enabling/Disabling Distributed ARP ...................................................................15-16
Verifying the Distributed ARP .............................................................................15-17
Distributed ARP Management Example ..............................................................15-18
IP Configuration ..........................................................................................................15-19
Configuring the Router Primary Address .............................................................15-19
Configuring the Router ID ...................................................................................15-19
Configuring the Route Preference of a Router .....................................................15-19
Configuring the Time-to-Live (TTL) Value ........................................................15-20
Configuring Route Map Redistribution ................................................................15-20
IP-Directed Broadcasts .........................................................................................15-26
Denial of Service (DoS) Filtering ........................................................................15-26
Enabling/Disabling IP Services ............................................................................15-31
Managing IP ................................................................................................................15-32
Internet Control Message Protocol (ICMP) .........................................................15-32
Using the Ping Command ....................................................................................15-34
Tracing an IP Route ..............................................................................................15-35
Transmission Control Protocol (TCP) ..................................................................15-36
Displaying UDP Information ...............................................................................15-36
Tunneling ....................................................................................................................15-36
Generic Routing Encapsulation ............................................................................15-36
IP Encapsulation within IP ...................................................................................15-36
Tunneling Operation ............................................................................................15-37
Configuring a Tunnel Interface ............................................................................15-38
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
xi
Contents
Verifying the IP Configuration ...................................................................................15-39
VRF Route Leak .........................................................................................................15-40
Quick Steps for Configuring VRF Route Leak ....................................................15-40
Configuring VRF Route Leak ..............................................................................15-41
Verifying VRF Route Leak Configuration ...........................................................15-42
Chapter 16
Configuring Multiple VRF ....................................................................................... 16-1
In This Chapter ..............................................................................................................16-1
VRF Defaults ................................................................................................................16-2
Quick Steps for Configuring Multiple VRF ..................................................................16-3
Multiple VRF Overview ...............................................................................................16-6
VRF Profiles ...........................................................................................................16-8
Using the VRF Command Line Interface ..............................................................16-8
ASCII-File-Only Syntax ........................................................................................16-9
Management VRF ..................................................................................................16-9
VRF Interaction With Other Features .........................................................................16-11
AAA RADIUS/TACACS+/LDAP Servers ..........................................................16-11
BGPv4 ..................................................................................................................16-12
IP-IP and GRE Tunnels ........................................................................................16-12
Management Applications (Telnet and SSH) .......................................................16-12
FTP .......................................................................................................................16-12
NTP ......................................................................................................................16-12
WebView ..............................................................................................................16-12
Syslog Server ........................................................................................................16-12
Quality of Service (QoS) ......................................................................................16-13
SNMP ...................................................................................................................16-13
VLANs .................................................................................................................16-13
UDP/DHCP Relay ................................................................................................16-13
Configuring VRF Instances .........................................................................................16-15
Configuring the VRF Profile ................................................................................16-15
Selecting a VRF Instance .....................................................................................16-16
Assigning IP Interfaces to a VRF Instance ..........................................................16-17
Configuring Routing Protocols for a Specific VRF Instance ...............................16-17
Removing a VRF Instance ...................................................................................16-17
Verifying the VRF Configuration ...............................................................................16-18
Chapter 17
Configuring IPv6 ....................................................................................................... 17-1
In This Chapter ..............................................................................................................17-1
IPv6 Defaults ................................................................................................................. 17-2
Quick Steps for Configuring IPv6 Routing ...................................................................17-3
IPv6 Overview ..............................................................................................................17-4
IPv6 Addressing .....................................................................................................17-5
Tunneling IPv6 over IPv4 ......................................................................................17-9
Configuring an IPv6 Interface .....................................................................................17-12
Configuring a Unique Local IPv6 Unicast Address .............................................17-13
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
xii
Contents
Modifying an IPv6 Interface ................................................................................17-13
Removing an IPv6 Interface .................................................................................17-13
Assigning IPv6 Addresses ...........................................................................................17-14
Removing an IPv6 Address ..................................................................................17-15
Configuring IPv6 Tunnel Interfaces ............................................................................17-16
Creating an IPv6 Static Route .....................................................................................17-17
Configuring the Route Preference of a Router ............................................................17-19
Configuring Route Map Redistribution ......................................................................17-20
Reply or Ignore Echo Requests ...................................................................................17-26
ICMPv6 Error Message Rate Limiting .......................................................................17-26
IPv6 EMP Interface .....................................................................................................17-27
Configure IPv6 EMP Interface .............................................................................17-27
Verifying the IPv6 Configuration ...............................................................................17-29
Chapter 18
Configuring IPsec ..................................................................................................... 18-1
In This Chapter ..............................................................................................................18-1
IPsec Defaults ................................................................................................................18-2
Quick Steps for Configuring an IPsec AH Policy .........................................................18-3
Quick Steps for Configuring an IPsec Discard Policy ..................................................18-4
IPsec Overview .............................................................................................................18-5
Encapsulating Security Payload (ESP) ..................................................................18-5
Authentication Header (AH) ..................................................................................18-6
IPsec on the OmniSwtich .......................................................................................18-7
Securing Traffic Using IPsec .................................................................................18-8
Discarding Traffic using IPsec ...............................................................................18-9
Configuring IPsec on the OmniSwitch .......................................................................18-10
Configuring an IPsec Master Key ........................................................................18-10
Configuring an IPsec Policy .................................................................................18-11
Configuring an IPsec SA ......................................................................................18-15
Enabling and Disabling Default Discard Policy ..................................................18-19
Additional Examples ...................................................................................................18-20
Configuring ESP ..................................................................................................18-20
Discarding RIPng Packets ....................................................................................18-22
Verifying IPsec Configuration ....................................................................................18-23
Chapter 19
Configuring RIP ......................................................................................................... 19-1
In This Chapter ..............................................................................................................19-1
RIP Defaults .................................................................................................................. 19-2
Quick Steps for Configuring RIP Routing ....................................................................19-3
RIP Overview ................................................................................................................19-4
RIP Version 2 .........................................................................................................19-5
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
xiii
Contents
RIP Routing ...................................................................................................................19-6
Loading RIP ...........................................................................................................19-6
Enabling RIP ..........................................................................................................19-7
Creating a RIP Interface .........................................................................................19-7
Enabling a RIP Interface ........................................................................................19-7
RIP Options ...................................................................................................................19-9
Configuring the RIP Forced Hold-Down Interval ..................................................19-9
Configuring the RIP Update Interval .....................................................................19-9
Configuring the RIP Invalid Timer ......................................................................19-10
Configuring the RIP Garbage Timer ....................................................................19-10
Configuring the RIP Hold-Down Timer ..............................................................19-10
Reducing the Frequency of RIP Routing Updates ...............................................19-10
Enabling a RIP Host Route ..................................................................................19-11
Configuring Redistribution .........................................................................................19-12
RIP Security ................................................................................................................19-18
Configuring Authentication Type ........................................................................19-18
Configuring Passwords ........................................................................................19-18
Verifying the RIP Configuration .................................................................................19-19
Chapter 20
Configuring BFD ....................................................................................................... 20-1
In This Chapter ..............................................................................................................20-1
BFD Defaults ................................................................................................................20-2
Quick Steps for Configuring BFD ................................................................................20-3
Quick Steps for Configuring BFD Support for Layer 3 Protocols .........................20-5
BFD Overview ..............................................................................................................20-8
Benefits of Using BFD For Failure Detection .......................................................20-8
How the BFD Protocol Works ...............................................................................20-8
Operational Mode and Echo Function ...................................................................20-9
BFD Packet Formats ............................................................................................20-10
BFD Session Establishment .................................................................................20-10
Configuring BFD ........................................................................................................20-12
Configuring BFD Session Parameters ..................................................................20-12
Configuring BFD Support for Layer 3 Protocols .................................................20-15
BFD Application Example ..........................................................................................20-24
Example Network Overview ................................................................................20-24
Verifying the BFD Configuration ...............................................................................20-29
Chapter 21
Configuring DHCP Relay ......................................................................................... 21-1
In This Chapter ..............................................................................................................21-1
DHCP Relay Defaults ...................................................................................................21-2
Quick Steps for Setting Up DHCP Relay .....................................................................21-3
DHCP Relay Overview .................................................................................................21-4
DHCP .....................................................................................................................21-5
DHCP and the OmniSwitch ...................................................................................21-5
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
xiv
Contents
External DHCP Relay Application ........................................................................21-6
Internal DHCP Relay .............................................................................................21-7
DHCP Relay Implementation .......................................................................................21-8
Global DHCP .........................................................................................................21-8
Per-VLAN DHCP ..................................................................................................21-8
Configuring BOOTP/DHCP Relay Parameters .....................................................21-9
Setting the Forward Delay ......................................................................................21-9
Setting Maximum Hops .......................................................................................21-10
Setting the Relay Forwarding Option ...................................................................21-10
Using Automatic IP Configuration .............................................................................21-11
Enabling Automatic IP Configuration ..................................................................21-11
Configuring UDP Port Relay ......................................................................................21-12
Enabling/Disabling UDP Port Relay ....................................................................21-13
Specifying a Forwarding VLAN ..........................................................................21-13
How the Relay Agent Processes DHCP Packets from the Client ........................21-14
Using DHCP Snooping ........................................................................................21-16
Quick Steps for Configuring DHCPv6 Relay .............................................................21-23
DHCPv6 Relay Overview ...........................................................................................21-23
DHCPv6 Relay Interface ......................................................................................21-23
DHCPv6 Relay Messages ....................................................................................21-24
DHCPv6 Relay Configuration Overview ....................................................................21-24
Enabling the DHCPv6 Relay Per-VRF ................................................................21-24
Configuring the DHCPv6 Relay Interface ...........................................................21-24
Configuring the DHCPv6 Relay Destination .......................................................21-25
Viewing the DHCPv6 Relay configuration ..........................................................21-25
Verifying the DHCP Relay Configuration ..................................................................21-26
Chapter 22
Configuring an Internal DHCP Server ................................................................ 22-1
In This Chapter ..............................................................................................................22-1
DHCP Server Default Values ........................................................................................22-2
Quick Steps to Configure Internal DHCP Server .........................................................22-2
DHCP Server Overview ................................................................................................22-4
The DHCP process .................................................................................................22-4
Internal DHCP Server on OmniSwitch ..................................................................22-4
VitalQIP Server ......................................................................................................22-4
Interaction With Other Features ....................................................................................22-5
Virtual Router Forwarding (VRF) ..........................................................................22-5
DHCP Snooping .....................................................................................................22-5
IP Interfaces ............................................................................................................22-5
VitalQIP Server ......................................................................................................22-5
Configuring DHCP Server on OmniSwitch ..................................................................22-6
Policy file ...............................................................................................................22-6
DHCP Configuration Files .....................................................................................22-7
DHCP Server Database file ..................................................................................22-10
DHCP Server Application Example ............................................................................22-11
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
xv
Contents
Verifying the DHCP Server Configuration .................................................................22-13
Configuration File Parameters and Syntax .................................................................22-14
Policy File Parameters and Syntax ..............................................................................22-25
Chapter 23
Configuring VRRP ..................................................................................................... 23-1
In This Chapter ..............................................................................................................23-1
VRRP Defaults ..............................................................................................................23-2
Quick Steps for Creating a Virtual Router ....................................................................23-4
VRRP Overview ............................................................................................................23-5
Why Use VRRP? ....................................................................................................23-6
Definition of a Virtual Router ................................................................................23-6
VRRP MAC Addresses ..........................................................................................23-7
VRRP Startup Delay ..............................................................................................23-7
VRRP Tracking ......................................................................................................23-8
Configuring Collective Management Functionality ...............................................23-8
Interaction With Other Features ....................................................................................23-8
VRRP Tracking with BFD .....................................................................................23-8
VRRP Configuration Overview ....................................................................................23-9
Basic Virtual Router Configuration .......................................................................23-9
Creating/Deleting a Virtual Router ........................................................................23-9
Specifying an IP Address for a Virtual Router ....................................................23-10
Configuring the Advertisement Interval ..............................................................23-11
Configuring Virtual Router Priority .....................................................................23-11
Setting Preemption for Virtual Routers ................................................................23-12
Enabling/Disabling a Virtual Router ....................................................................23-12
Setting VRRP Traps .............................................................................................23-13
Setting VRRP Startup Delay ................................................................................23-13
Configuring Collective Management Functionality .............................................23-13
Verifying the VRRP Configuration ............................................................................23-17
VRRPv3 Configuration Overview ..............................................................................23-18
Basic VRRPv3 Virtual Router Configuration ......................................................23-18
Creating/Deleting a VRRPv3 Virtual Router .......................................................23-18
Specifying an IPv6 Address for a VRRPv3 Virtual Router .................................23-19
Configuring the VRRPv3 Advertisement Interval ...............................................23-20
Configuring the VRRPv3 Virtual Router Priority ................................................23-20
Setting Preemption for VRRPv3 Virtual Routers ................................................23-21
Enabling/Disabling a VRRPv3 Virtual Router ....................................................23-22
Setting VRRPv3 Traps .........................................................................................23-22
Verifying the VRRPv3 Configuration ........................................................................23-23
Creating VRRPv2/VRRPv3 Tracking Policies ...........................................................23-24
Associating a Tracking Policy with a Virtual Router ..........................................23-24
VRRP Application Example .......................................................................................23-25
VRRP Tracking Example .....................................................................................23-27
VRRPv3 Application Example ...................................................................................23-29
VRRPv3 Tracking Example .................................................................................23-30
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
xvi
Contents
Chapter 24
Configuring Server Load Balancing .................................................................... 24-1
In This Chapter ..............................................................................................................24-1
Server Load Balancing Default Values .........................................................................24-2
Quick Steps for Configuring Server Load Balancing ...................................................24-3
Quick Steps for Configuring a QoS Policy Condition Cluster ...............................24-4
Server Load Balancing Overview .................................................................................24-6
Server Load Balancing Cluster Identification ........................................................24-6
Server Load Balancing Example ............................................................................24-7
Weighted Round Robin Distribution Algorithm ....................................................24-8
Server Health Monitoring .......................................................................................24-9
Configuring Server Load Balancing on a Switch .......................................................24-10
Enabling and Disabling Server Load Balancing ..................................................24-10
Configuring and Deleting SLB Clusters ..............................................................24-11
Assigning Servers to and Removing Servers from a Cluster ...............................24-13
Modifying Optional Parameters ..................................................................................24-14
Modifying the Ping Period ...................................................................................24-14
Modifying the Ping Timeout ................................................................................24-14
Modifying the Ping Retries ..................................................................................24-15
Modifying the Relative Weight of a Physical Server ...........................................24-15
Taking Clusters and Servers On/Off Line ...................................................................24-16
Taking a Cluster On/Off Line ..............................................................................24-16
Taking a Server On/Off Line ...............................................................................24-16
Configuring SLB Probes .............................................................................................24-17
Creating SLB Probes ............................................................................................24-17
Deleting SLB Probes ............................................................................................24-17
Associating a Probe with a Cluster ......................................................................24-18
Associating a Probe with a Server ........................................................................24-18
Modifying SLB Probes .........................................................................................24-18
Displaying Server Load Balancing Status and Statistics ............................................24-21
Chapter 25
Configuring IP Multicast Switching ..................................................................... 25-1
In This Chapter ..............................................................................................................25-1
IPMS Default Values ....................................................................................................25-2
IPMSv6 Default Values ................................................................................................25-3
IPMS Overview .............................................................................................................25-4
IPMS Example .......................................................................................................25-4
Reserved IP Multicast Addresses ...........................................................................25-5
IP Multicast Routing ..............................................................................................25-5
Interaction With Other Features ....................................................................................25-7
IPMS for Shortest Path Bridging ...........................................................................25-7
VLAN and Service Domains ..................................................................................25-7
Configuring IPMS on a Switch .....................................................................................25-9
Enabling and Disabling IP Multicast Status ...........................................................25-9
Enabling and Disabling Flooding of Unknown Multicast Traffic .......................25-10
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
xvii
Contents
Enabling and Disabling IGMP Querier-forwarding .............................................25-11
Configuring and Restoring the IGMP Version ....................................................25-12
Configuring and Removing an IGMP Static Neighbor ........................................25-12
Configuring and Removing an IGMP Static Querier ...........................................25-13
Configuring and Removing an IGMP Static Group .............................................25-14
Modifying IPMS Parameters .......................................................................................25-15
Modifying the IGMP Query Interval ...................................................................25-15
Modifying the IGMP Last Member Query Interval .............................................25-16
Modifying the IGMP Query Response Interval ...................................................25-17
Enabling and Disabling Zero-based IGMP Query ...............................................25-17
Modifying the IGMP Router Timeout .................................................................25-18
Modifying the Source Timeout ............................................................................25-19
Enabling and Disabling IGMP Querying .............................................................25-20
Modifying the IGMP Robustness Variable ..........................................................25-21
Enabling and Disabling the IGMP Spoofing ........................................................25-22
Enabling and Disabling the IGMP Zapping .........................................................25-23
Limiting IGMP Multicast Groups ........................................................................25-23
IPMSv6 Overview .......................................................................................................25-25
IPMSv6 Example .................................................................................................25-25
Reserved IPv6 Multicast Addresses .....................................................................25-26
MLD Version 2 ....................................................................................................25-26
Configuring IPMSv6 on a Switch ...............................................................................25-27
Enabling and Disabling IPv6 Multicast Status .....................................................25-27
Enabling and Disabling Flooding of Unknown Multicast Traffic .......................25-28
Enabling and Disabling MLD Querier-forwarding ..............................................25-29
Configuring and Restoring the MLD Version ......................................................25-29
Configuring and Removing an MLD Static Neighbor .........................................25-30
Configuring and Removing an MLD Static Querier ............................................25-31
Configuring and Removing an MLD Static Group ..............................................25-32
Modifying IPMSv6 Parameters ...................................................................................25-33
Modifying the MLD Query Interval .....................................................................25-33
Modifying the MLD Last Member Query Interval ..............................................25-34
Modifying the MLD Query Response Interval ....................................................25-34
Enabling and Disabling Zero-based MLD Query ................................................25-35
Modifying the MLD Router Timeout ...................................................................25-36
Modifying the Source Timeout ............................................................................25-37
Enabling and Disabling the MLD Querying ........................................................25-37
Modifying the MLD Robustness Variable ...........................................................25-38
Enabling and Disabling MLD Spoofing ...............................................................25-39
Enabling and Disabling the MLD Zapping ..........................................................25-40
Limiting MLD Multicast Groups .........................................................................25-41
IPMS Application Example ........................................................................................25-42
IPMSv6 Application Example ....................................................................................25-44
Displaying IPMS Configurations and Statistics ..........................................................25-46
Displaying IPMSv6 Configurations and Statistics ......................................................25-47
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
xviii
Contents
Chapter 26
Configuring QoS ....................................................................................................... 26-1
In This Chapter ..............................................................................................................26-2
QoS General Overview .................................................................................................26-3
Classification .................................................................................................................26-5
How Traffic is Classified and Marked ...................................................................26-5
Configuring Trusted Ports ......................................................................................26-7
Congestion Management ...............................................................................................26-9
Queue Sets ..............................................................................................................26-9
QSet Profiles ........................................................................................................26-11
Multicast and Unicast Traffic Distribution ..........................................................26-15
Multicast Source PFC on the OmniSwitch 6900 .................................................26-18
OmniSwitCongestion Avoidance ................................................................................26-19
WRED Profiles .....................................................................................................26-19
Traffic Policing and Shaping ......................................................................................26-22
Policing .................................................................................................................26-22
Shaping .................................................................................................................26-22
Tri-Color Marking ................................................................................................26-22
Configuring Policy Bandwidth Policing ..............................................................26-26
Configuring Port Bandwidth Shaping ..................................................................26-27
QoS Policy Overview ..................................................................................................26-28
How Policies Are Used ........................................................................................26-28
Policy Lists ...........................................................................................................26-29
Interaction With Other Features ...........................................................................26-29
Valid Policies .......................................................................................................26-29
Policy Conditions .................................................................................................26-30
Policy Actions ......................................................................................................26-31
QoS Defaults ...............................................................................................................26-33
Global QoS Defaults ............................................................................................26-33
QoS Port Defaults .................................................................................................26-33
Queue Management Defaults ...............................................................................26-34
Policy Rule Defaults .............................................................................................26-35
Policy Action Defaults .........................................................................................26-35
Default (Built-in) Policies ....................................................................................26-36
Configuring QoS .........................................................................................................26-37
Configuring Global QoS Parameters ..........................................................................26-38
Enabling/Disabling QoS .......................................................................................26-38
Using the QoS Log ...............................................................................................26-38
Setting the Statistics Interval ................................................................................26-41
Returning the Global Configuration to Defaults ..................................................26-41
Verifying Global Settings .....................................................................................26-41
Creating Policies .........................................................................................................26-42
Quick Steps for Creating Policies ........................................................................26-42
ASCII-File-Only Syntax ......................................................................................26-43
Creating Policy Conditions ..................................................................................26-44
Creating Policy Actions .......................................................................................26-45
Creating Policy Rules ...........................................................................................26-46
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
xix
Contents
Creating Policy Lists ............................................................................................26-49
Verifying Policy Configuration ............................................................................26-52
Using Condition Groups in Policies ............................................................................26-53
Sample Group Configuration ...............................................................................26-53
Creating Network Groups ....................................................................................26-54
Creating Services ..................................................................................................26-55
Creating Service Groups ......................................................................................26-56
Creating MAC Groups .........................................................................................26-57
Creating Port Groups ............................................................................................26-58
Verifying Condition Group Configuration ...........................................................26-59
Using Map Groups ......................................................................................................26-60
Sample Map Group Configuration .......................................................................26-60
How Map Groups Work .......................................................................................26-61
Creating Map Groups ...........................................................................................26-61
Verifying Map Group Configuration ...................................................................26-62
Using Access Control Lists .........................................................................................26-63
Layer 2 ACLs .......................................................................................................26-63
Layer 3 ACLs .......................................................................................................26-65
IPv6 ACLs ............................................................................................................26-66
Multicast Filtering ACLs .....................................................................................26-66
Using ACL Security Features ..............................................................................26-67
Applying the Configuration ........................................................................................26-71
Interaction With LDAP Policies ..........................................................................26-72
Verifying the Applied Policy Configuration ........................................................26-73
Policy Applications .....................................................................................................26-74
Basic QoS Policies ...............................................................................................26-75
Redirection Policies ..............................................................................................26-76
Policy Based Mirroring ........................................................................................26-77
ICMP Policy Example ..........................................................................................26-78
802.1p and ToS/DSCP Marking and Mapping ....................................................26-78
Policy Based Routing ...........................................................................................26-79
Chapter 27
Managing Policy Servers ....................................................................................... 27-1
In This Chapter ..............................................................................................................27-1
Policy Server Defaults ...................................................................................................27-2
Policy Server Overview ................................................................................................27-3
Installing the LDAP Policy Server ................................................................................27-3
Modifying Policy Servers .............................................................................................27-4
Modifying LDAP Policy Server Parameters ..........................................................27-4
Disabling the Policy Server From Downloading Policies ......................................27-4
Modifying the Port Number ...................................................................................27-5
Modifying the Policy Server Username and Password ..........................................27-5
Modifying the Searchbase ......................................................................................27-5
Configuring a Secure Socket Layer for a Policy Server ........................................27-6
Loading Policies From an LDAP Server ................................................................27-6
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
xx
Contents
Removing LDAP Policies From the Switch ..........................................................27-6
Interaction With CLI Policies ................................................................................27-7
Verifying the Policy Server Configuration ...................................................................27-7
Chapter 28
Configuring Access Guardian ............................................................................... 28-1
In This Chapter ..............................................................................................................28-2
Access Guardian Defaults .............................................................................................28-3
Access Guardian Global Configuration Defaults ...................................................28-3
Access Guardian Profile Defaults ..........................................................................28-3
Access Guardian UNP Port Defaults .....................................................................28-5
Access Guardian Global AAA Parameter Defaults ...............................................28-6
Access Guardian AAA Profile Defaults .................................................................28-7
Access Guardian Captive Portal Defaults ..............................................................28-8
Access Guardian Captive Portal Profile Defaults ..................................................28-8
Access Guardian QMR Defaults ............................................................................28-9
Quick Steps for Configuring Access Guardian ...........................................................28-10
Access Guardian Overview .........................................................................................28-12
Device Authentication ..........................................................................................28-13
Device Classification ............................................................................................28-14
Role-based Access ................................................................................................28-15
UNP Profiles ........................................................................................................28-16
UNP Ports .............................................................................................................28-21
UNP Classification Rules .....................................................................................28-23
How it Works .......................................................................................................28-25
Interaction With Other Features ..................................................................................28-26
Authentication, Authorization, and Accounting (AAA) ......................................28-26
Bring Your Own Devices (BYOD) ......................................................................28-26
Learned Port Security ...........................................................................................28-26
Multiple VLAN Registration Protocol (MVRP) ..................................................28-27
Quality of Service (QoS) ......................................................................................28-27
Service Assurance Agent .....................................................................................28-28
Service Manager ...................................................................................................28-28
Source Learning ...................................................................................................28-28
Universal Network Profile (UNP) ........................................................................28-28
Configuring Port-Based Network Access Control ......................................................28-31
Setting Authentication Parameters for the Switch ...............................................28-32
Configuring UNP Port-Based Functionality ........................................................28-38
Configuring UNP Profiles ....................................................................................28-51
Configuring the UNP Profile Mapping ................................................................28-54
Configuring QoS Policy Lists ..............................................................................28-61
Configuring UNP Classification Rules ................................................................28-65
OmniAccess Stellar AP Integration ............................................................................28-69
How it Works .......................................................................................................28-69
Configuration Guidelines .....................................................................................28-70
Quick Steps for Configuring OmniSwitch AP Discovery ...................................28-72
Using Captive Portal Authentication ..........................................................................28-76
Configuration Tasks and Guidelines ....................................................................28-77
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
xxi
Contents
Quick Steps for Configuring Captive Portal Authentication ...............................28-78
Using Captive Portal Configuration Profiles .......................................................28-79
Replacing the Captive Portal Certificate ..............................................................28-80
Authenticating with Captive Portal ......................................................................28-80
Using Guest Tunneling ...............................................................................................28-83
Configuration Overview and Guidelines ..............................................................28-84
Quick Steps for Configuring Guest Tunneling ....................................................28-88
Guest Tunneling Configuration Example ............................................................28-90
Using Quarantine Manager and Remediation .............................................................28-93
Access Guardian Application Examples .....................................................................28-95
Application Example 1: Classification (Port Mobility) .......................................28-96
Application Example 2: 802.1X Authentication ..................................................28-97
Application Example 3: Internal Captive Portal Authentication .........................28-99
Application Example 4: Supplicant/Non-supplicant with Captive
Portal Authentication .........................................................................................28-101
Application Example 5: IP Phone (LLDP Network Policy TLV/
Mobile Tag) .......................................................................................................28-104
Application Example 6: Restricted Role (Policy List) Assignment ...................28-106
Verifying Access Guardian Users .............................................................................28-109
Logging Users Out of the Network ....................................................................28-112
Verifying the Access Guardian Configuration ..........................................................28-114
Bring Your Own Devices (BYOD) Overview ..........................................................28-115
Key Components of a BYOD Solution ..............................................................28-116
Configuring OmniSwitch BYOD Support .........................................................28-123
BYOD Authentication Process Overview ..........................................................28-126
Multicast Domain Name System ........................................................................28-127
Simple Service Discovery Protocol ....................................................................28-128
Zero Configuration Networking (mDNS and SSDP) .........................................28-132
BYOD Application Examples ...................................................................................28-144
Application Example 1: 802.1X — OmniSwitch Configuration .......................28-145
Application Example 1: 802.1X — ClearPass Configuration ............................28-146
Application Example 2: IP Phone — OmniSwitch Configuration ....................28-151
Application Example 2: IP Phone — ClearPass Configuration .........................28-152
Application Example 3: Guest — OmniSwitch Configuration ..........................28-155
Application Example 3: Guest — ClearPass Configuration ..............................28-156
Verifying the BYOD Configuration ...................................................................28-161
Chapter 29
Configuring Application Monitoring and Enforcement ................................. 29-1
In This Chapter ..............................................................................................................29-2
AppMon Defaults ..........................................................................................................29-3
Application Monitoring and Enforcement Overview ...................................................29-4
Application Monitoring ..........................................................................................29-4
Application Enforcement .......................................................................................29-5
Quick Steps for Configuring AppMon ...................................................................29-7
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
xxii
Contents
Application Signature File/Kit ......................................................................................29-8
Signature File Update .............................................................................................29-8
Application Flow Database ....................................................................................29-9
Configuring AppMon ..................................................................................................29-10
Configuration Guidelines .....................................................................................29-11
Enabling/Disabling AppMon ...............................................................................29-13
Enabling/Disabling AppMon Per Port or Slot ......................................................29-13
Create Auto-Groups .............................................................................................29-14
Configuring Application Group ...........................................................................29-14
Configuring Application List ...............................................................................29-15
Activate Applications for AppMon ......................................................................29-15
Configuring L3 Mode of Operation .....................................................................29-16
Configuring L4 Mode of Operation .....................................................................29-16
Clearing Flow Table Entries ................................................................................29-17
Configuring Flow Table Statistics Update ...........................................................29-17
Configuring Aging Interval ..................................................................................29-17
Configuring Logging Threshold ...........................................................................29-18
Configuring Sync Interval ....................................................................................29-18
Configuring Force Flow Sync ..............................................................................29-18
Clearing Application List .....................................................................................29-19
Configuring AppMon Enforcement QoS Policy Rules ........................................29-19
Verifying AppMon Configuration ..............................................................................29-20
Chapter 30
Configuring Application Fingerprinting ............................................................ 30-1
In This Chapter ..............................................................................................................30-1
AFP Defaults .................................................................................................................30-2
Default REGEX Application Signatures ................................................................30-2
Quick Steps for Configuring AFP .................................................................................30-4
AFP Overview ...............................................................................................................30-5
Application Fingerprinting Modes .........................................................................30-6
Using the Application REGEX Signature File .......................................................30-7
Application Fingerprinting Database .....................................................................30-8
Interaction With Other Features ....................................................................................30-9
General ...................................................................................................................30-9
QoS .........................................................................................................................30-9
sFLOW ...................................................................................................................30-9
Configuring AFP .........................................................................................................30-10
Configuration Guidelines .....................................................................................30-10
Enabling/Disabling AFP ......................................................................................30-11
Enabling/Disabling Trap Generation ...................................................................30-11
Changing the REGEX Signature Filename ..........................................................30-12
Reloading the REGEX Signature File ..................................................................30-12
Defining Application REGEX Signatures and Groups ........................................30-13
Configuring AFP Port Modes ..............................................................................30-16
Verifying the AFP Configuration ................................................................................30-18
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
xxiii
Contents
Chapter 31
Managing Authentication Servers ...................................................................... 31-1
In This Chapter ..............................................................................................................31-1
Server Defaults ..............................................................................................................31-2
RADIUS Authentication Servers ...........................................................................31-2
TACACS+ Authentication Servers ........................................................................31-2
LDAP Authentication Servers ................................................................................31-2
Quick Steps For Configuring Authentication Servers ..................................................31-4
Server Overview ............................................................................................................31-5
Backup Authentication Servers ..............................................................................31-5
Authenticated Switch Access .................................................................................31-5
RADIUS Servers ...........................................................................................................31-7
RADIUS Server Attributes .....................................................................................31-7
Configuring the RADIUS Client ..........................................................................31-11
Radius over TLS ...................................................................................................31-12
TACACS+ Server .......................................................................................................31-13
TACACS+ Client Limitations ..............................................................................31-13
Configuring the TACACS+ Client .......................................................................31-14
LDAP Servers .............................................................................................................31-15
Setting Up the LDAP Authentication Server .......................................................31-15
LDAP Server Details ............................................................................................31-16
Directory Server Schema for LDAP Authentication ............................................31-21
Configuring the LDAP Authentication Client .....................................................31-25
Verifying the Authentication Server Configuration ....................................................31-27
Chapter 32
Configuring Port Mapping ..................................................................................... 32-1
In This Chapter ..............................................................................................................32-1
Port Mapping Defaults ..................................................................................................32-2
Quick Steps for Configuring Port Mapping ..................................................................32-3
Creating/Deleting a Port Mapping Session ...................................................................32-4
Creating a Port Mapping Session ...........................................................................32-4
Deleting a Port Mapping Session ...........................................................................32-4
Enabling/Disabling a Port Mapping Session .................................................................32-5
Enabling a Port Mapping Session ..........................................................................32-5
Disabling a Port Mapping Session .........................................................................32-5
Disabling the Flooding of Unknown Unicast Traffic .............................................32-5
Configuring a Port Mapping Direction .........................................................................32-5
Configuring Unidirectional Port Mapping .............................................................32-5
Restoring Bidirectional Port Mapping ...................................................................32-5
Sample Port Mapping Configuration ............................................................................32-6
Example Port Mapping Overview ..........................................................................32-6
Example Port Mapping Configuration Steps .........................................................32-7
Verifying the Port Mapping Configuration ...................................................................32-7
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
xxiv
Contents
Chapter 33
Configuring Learned Port Security ...................................................................... 33-1
In This Chapter ..............................................................................................................33-1
Learned Port Security Defaults ....................................................................................33-2
Sample Learned Port Security Configuration ...............................................................33-3
Learned Port Security Overview ...................................................................................33-5
LPS Learning Window ...........................................................................................33-5
MAC Address Types ..............................................................................................33-6
How LPS Authorizes Source MAC Addresses ......................................................33-6
Dynamic Configuration of Authorized MAC Addresses .......................................33-8
Static Configuration of Authorized MAC Addresses ............................................33-8
Understanding the LPS Table ................................................................................33-8
Interaction With Other Features ....................................................................................33-9
Access Guardian .....................................................................................................33-9
Universal Network Profile (UNP) ..........................................................................33-9
Configuring Learned Port Security .............................................................................33-10
Configuring the LPS Port Administrative Status .................................................33-10
Configuring the LPS Learning Window ..............................................................33-12
Configuring Learning Window Parameters .........................................................33-12
Configuring the Number of Bridged MAC Addresses Allowed ..........................33-15
Configuring the Number of Filtered MAC Addresses Allowed ..........................33-16
Configuring an Authorized MAC Address Range ...............................................33-16
Selecting the Security Violation Mode ................................................................33-17
Displaying Learned Port Security Information ...........................................................33-19
Chapter 34
Diagnosing Switch Problems ................................................................................34-1
In This Chapter ..............................................................................................................34-1
Port Mirroring Overview ...............................................................................................34-3
Port Mirroring Defaults ..........................................................................................34-3
Quick Steps for Configuring Port Mirroring ..........................................................34-3
Port Monitoring Overview ............................................................................................34-4
Port Monitoring Defaults .......................................................................................34-4
Quick Steps for Configuring Port Monitoring .......................................................34-4
sFlow Overview ............................................................................................................34-5
sFlow Defaults ........................................................................................................34-5
Quick Steps for Configuring sFlow .......................................................................34-5
Remote Monitoring (RMON) Overview .......................................................................34-7
RMON Probe Defaults ...........................................................................................34-7
Quick Steps for Enabling/Disabling RMON Probes ..............................................34-7
Switch Health Overview ...............................................................................................34-8
Switch Health Defaults ...........................................................................................34-8
Quick Steps for Configuring Switch Health ..........................................................34-8
Port Mirroring ...............................................................................................................34-9
What Ports Can Be Mirrored? ................................................................................34-9
How Port Mirroring Works ....................................................................................34-9
What Happens to the Mirroring Port ....................................................................34-10
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
xxv
Contents
Mirroring on Multiple Ports .................................................................................34-10
Using Port Mirroring with External RMON Probes ............................................34-10
Remote Port Mirroring .........................................................................................34-12
Creating a Mirroring Session ...............................................................................34-13
Unblocking Ports (Protection from Spanning Tree) ............................................34-14
Enabling or Disabling Mirroring Status ...............................................................34-14
Disabling a Mirroring Session (Disabling Mirroring Status) ...............................34-14
Configuring Port Mirroring Direction ..................................................................34-15
Enabling or Disabling a Port Mirroring Session (Shorthand) ..............................34-15
Displaying Port Mirroring Status .........................................................................34-16
Deleting A Mirroring Session ..............................................................................34-16
Configuring Remote Port Mirroring ....................................................................34-17
Port Monitoring ...........................................................................................................34-18
Configuring a Port Monitoring Session ...............................................................34-19
Enabling a Port Monitoring Session .....................................................................34-19
Disabling a Port Monitoring Session ...................................................................34-19
Deleting a Port Monitoring Session .....................................................................34-19
Pausing a Port Monitoring Session ......................................................................34-20
Configuring Port Monitoring Session Persistence ...............................................34-20
Configuring a Port Monitoring Data File .............................................................34-20
Configuring Port Monitoring Direction ...............................................................34-21
Configuring the Capture Type ..............................................................................34-22
Displaying Port Monitoring Status and Data .......................................................34-22
sFlow ...........................................................................................................................34-23
sFlow Manager .....................................................................................................34-23
Receiver ................................................................................................................34-23
Sampler .................................................................................................................34-24
Poller ....................................................................................................................34-24
Configuring a sFlow Session ................................................................................34-24
Configuring a Fixed Primary Address .................................................................34-25
Displaying a sFlow Receiver ................................................................................34-25
Displaying a sFlow Sampler ................................................................................34-26
Displaying a sFlow Poller ....................................................................................34-26
Displaying a sFlow Agent ....................................................................................34-27
Deleting a sFlow Session .....................................................................................34-27
Remote Monitoring (RMON) .....................................................................................34-28
Enabling or Disabling RMON Probes ..................................................................34-30
Displaying RMON Tables ....................................................................................34-31
Monitoring Switch Health ...........................................................................................34-35
Configuring Resource Thresholds ........................................................................34-36
Displaying Health Threshold Limits ....................................................................34-37
Configuring Sampling Intervals ...........................................................................34-38
Viewing Sampling Intervals .................................................................................34-38
Viewing Health Statistics for the Switch .............................................................34-39
Viewing Health Statistics for a Specific Interface ...............................................34-40
Chapter 35
Configuring VLAN Stacking ................................................................................... 35-1
In This Chapter ..............................................................................................................35-1
VLAN Stacking Defaults ..............................................................................................35-2
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
xxvi
Contents
VLAN Stacking Overview ............................................................................................35-3
How VLAN Stacking Works .................................................................................35-5
VLAN Stacking Services .......................................................................................35-6
Interaction With Other Features ....................................................................................35-7
Quick Steps for Configuring VLAN Stacking ..............................................................35-8
Configuring VLAN Stacking Services ........................................................................35-10
Configuring SVLANs ..........................................................................................35-11
Configuring a VLAN Stacking Service ...............................................................35-12
Configuring VLAN Stacking Network Ports .......................................................35-13
Configuring a VLAN Stacking Service Access Point ..........................................35-15
Configuring VLAN Stacking User Ports .............................................................35-16
Configuring the Type of Customer Traffic to Tunnel ..........................................35-16
Configuring a Service Access Point Profile .........................................................35-18
Configuring a UNI Profile ....................................................................................35-19
VLAN Stacking Application Example ........................................................................35-22
VLAN Stacking Configuration Example .............................................................35-23
Verifying the VLAN Stacking Configuration .............................................................35-26
Chapter 36
Using Switch Logging .............................................................................................. 36-1
In This Chapter ..............................................................................................................36-1
Switch Logging Defaults ...............................................................................................36-2
Quick Steps for Configuring Switch Logging ..............................................................36-2
Switch Logging Overview ............................................................................................36-3
Switch Logging Commands Overview .........................................................................36-4
Enabling Switch Logging .......................................................................................36-4
Setting the Switch Logging Severity Level ............................................................36-4
Specifying the Switch Logging Output Device ......................................................36-5
Configuring the Switch Logging File Size .............................................................36-6
Clearing the Switch Logging Files .........................................................................36-6
Displaying Switch Logging Records ......................................................................36-7
Specifying the Switch Logging Format .................................................................36-8
Switch Logging Notifications ................................................................................36-8
Specifying the Switch Logging Record Storage Limit ..........................................36-8
Chapter 37
Configuring Ethernet OAM .................................................................................... 37-1
In This Chapter ..............................................................................................................37-1
Ethernet OAM Defaults ................................................................................................37-2
Ethernet OAM Overview ..............................................................................................37-3
Ethernet Service OAM ...........................................................................................37-3
Quick Steps for Configuring Ethernet OAM ................................................................37-8
Configuring Ethernet OAM ..........................................................................................37-9
Configuring a Maintenance Domain ......................................................................37-9
Configuring a Maintenance Association ..............................................................37-10
Configuring a Maintenance End Point .................................................................37-11
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
xxvii
Contents
Configuring a Virtual Maintenance End Point .....................................................37-11
Configuring Loopback .........................................................................................37-12
Configuring Linktrace ..........................................................................................37-12
Configuring the Fault Alarm Time .......................................................................37-12
Configuring the Fault Reset Time ........................................................................37-12
Configuring Ethernet Frame Delay Measurement ...............................................37-12
Verifying the Ethernet OAM Configuration ...............................................................37-14
Chapter 38
Configuring Service Assurance Agent ................................................................ 38-1
In This Chapter ..............................................................................................................38-1
SAA Defaults ................................................................................................................38-2
Quick Steps for Configuring SAA ................................................................................38-3
Service Assurance Agent Overview ..............................................................................38-4
Configuring Service Assurance Agent ..........................................................................38-4
Configuring an SAA ID .........................................................................................38-5
Configuring SAA SPB Session Parameters ...........................................................38-6
Generating an SAA XML History File ..................................................................38-7
Verifying the SAA Configuration .................................................................................38-9
Appendix A
Software License and Copyright Statements ..................................................... A-1
ALE USA, Inc. License Agreement ............................................................................... A-1
ALE USA, INC. SOFTWARE LICENSE AGREEMENT ..................................... A-1
Third Party Licenses and Notices .................................................................................. A-4
Index ...................................................................................................................... Index-1
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
xxviii
About This Guide
This OmniSwitch AOS Release 8 Network Configuration Guide describes basic attributes of your switch
and basic switch administration tasks. The software features described in this manual are shipped standard
with your switches. These features are used when readying a switch for integration into a live network
environment.
Supported Platforms
The information in this guide applies only to the following products:
• OmniSwitch 9900 Series
• OmniSwitch 6900 Series
• OmniSwitch 6860 Series
• OmniSwitch 6865 Series
• OmniSwitch 6560 Series
Who Should Read this Manual?
The audience for this user guide are network administrators and IT support personnel who need to configure, maintain, and monitor switches and routers in a live network. However, anyone wishing to gain
knowledge on how fundamental software features are implemented in the OmniSwitch Series switches
will benefit from the material in this configuration guide.
When Should I Read this Manual?
Read this guide as soon as your switch is up and running and you are ready to familiarize yourself with
basic software functions. You should have already stepped through the first login procedures and read the
brief software overviews in the appropriate Hardware Users Guide.
You should have already set up a switch password and be familiar with the very basics of the switch software. This manual will help you understand the switch’s directory structure, the Command Line Interface
(CLI), configuration files, basic security features, and basic administrative functions. The features and
procedures in this guide will help form a foundation that will allow you to configure more advanced
switching features later.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
xxi
What is in this Manual?
About This Guide
What is in this Manual?
This configuration guide includes information about the following features:
• Basic switch administrative features, such as file editing utilities, procedures for loading new software,
and setting up system information (name of switch, date, time).
• Configurations files, including snapshots, off-line configuration, time-activated file download.
• The CLI, including on-line configuration, command-building help, syntax error checking, and line edit-
ing.
• Basic security features, such as switch access control and customized user accounts.
• SNMP
• Web-based management (WebView)
What is Not in this Manual?
The configuration procedures in this manual primarily use Command Line Interface (CLI) commands in
examples. CLI commands are text-based commands used to manage the switch through serial (console
port) connections or via Telnet sessions. This guide does include introductory chapters for alternative
methods of managing the switch, such as web-based (WebView) and SNMP management. However the
primary focus of this guide is managing the switch through the CLI.
Further information on WebView can be found in the context-sensitive on-line help available with that
application.
This guide does not include documentation for the OmniVista network management system. However,
OmniVista includes a complete context-sensitive on-line help system.
This guide provides overview material on software features, how-to procedures, and tutorials that will
enable you to begin configuring your OmniSwitch. However, it is not intended as a comprehensive reference to all CLI commands available in the OmniSwitch. For such a reference to all CLI commands,
consult the OmniSwitch AOS Release 8 CLI Reference Guide.
How is the Information Organized?
Each chapter in this guide includes sections that will satisfy the information requirements of casual readers, rushed readers, serious detail-oriented readers, advanced users, and beginning users.
Quick Information. Most chapters include a specifications table that lists RFCs and IEEE specifications
supported by the software feature. In addition, this table includes other pertinent information such as minimum and maximum values and sub-feature support. Some chapters include a defaults table that lists the
default values for important parameters along with the CLI command used to configure the parameter.
Many chapters include Quick Steps sections, which are procedures covering the basic steps required to get
a software feature up and running.
In-Depth Information. All chapters include overview sections on software features as well as on selected
topics of that software feature. Topical sections may often lead into procedure sections that describe how
to configure the feature just described. Many chapters include tutorials or application examples that help
convey how CLI commands can be used together to set up a particular feature.
xxii
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
About This Guide
Documentation Roadmap
Documentation Roadmap
The OmniSwitch user documentation suite was designed to supply you with information at several critical
junctures of the configuration process.The following section outlines a roadmap of the manuals that will
help you at each stage of the configuration process. Under each stage, we point you to the manual or
manuals that will be most helpful to you.
Stage 1: Using the Switch for the First Time
Pertinent Documentation: OmniSwitch Hardware Users Guide
Release Notes
This guide provides all the information you need to get your switch up and running the first time. It
provides information on unpacking the switch, rack mounting the switch, installing NI modules, unlocking
access control, setting the switch’s IP address, and setting up a password. It also includes succinct
overview information on fundamental aspects of the switch, such as hardware LEDs, the software
directory structure, CLI conventions, and web-based management.
At this time you should also familiarize yourself with the Release Notes that accompanied your switch.
This document includes important information on feature limitations that are not included in other user
guides.
Stage 2: Gaining Familiarity with Basic Switch Functions
Pertinent Documentation: OmniSwitch Hardware Users Guide
OmniSwitch AOS Release 8 Switch Management Guide
Once you have your switch up and running, you will want to begin investigating basic aspects of its
hardware and software. Information about switch hardware is provided in the Hardware Guide. This guide
provide specifications, illustrations, and descriptions of all hardware components, such as chassis, power
supplies, Chassis Management Modules (CMMs), Network Interface (NI) modules, and cooling fans. It
also includes steps for common procedures, such as removing and installing switch components.
The OmniSwitch AOS Release 8 Switch Management Guide is the primary users guide for the basic
software features on a single switch. This guide contains information on the switch directory structure,
basic file and directory utilities, switch access security, SNMP, and web-based management. It is
recommended that you read this guide before connecting your switch to the network.
Stage 3: Integrating the Switch Into a Network
Pertinent Documentation: OmniSwitch AOS Release 8 Network Configuration Guide
OmniSwitch AOS Release 8 Advanced Routing Configuration Guide
OmniSwitch AOS Release 8 Data Center Switching Guide
When you are ready to connect your switch to the network, you will need to learn how the OmniSwitch
implements fundamental software features, such as 802.1Q, VLANs, Spanning Tree, and network routing
protocols. The OmniSwitch AOS Release 8 Network Configuration Guide contains overview information,
procedures, and examples on how standard networking technologies are configured on the OmniSwitch.
The OmniSwitch AOS Release 8 Advanced Routing Configuration Guide includes configuration
information for networks using advanced routing technologies (OSPF and BGP) and multicast routing
protocols (DVMRP and PIM-SM).
The OmniSwitch AOS Release 8 Data Center Switching Guide includes configuration information for data
center networks using virtualization technologies (SPBM and UNP), Data Center Bridging protocols
(PFC, ETC, and DCBX), and FCoE/FC gateway functionality.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
xxiii
Documentation Roadmap
About This Guide
Anytime
The OmniSwitch AOS Release 8 CLI Reference Guide contains comprehensive information on all CLI
commands supported by the switch. This guide includes syntax, default, usage, example, related CLI
command, and CLI-to-MIB variable mapping information for all CLI commands supported by the switch.
This guide can be consulted anytime during the configuration process to find detailed and specific
information on each CLI command.
xxiv
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
About This Guide
Related Documentation
Related Documentation
The following are the titles and descriptions of all the related OmniSwitch user manuals:
• OmniSwitch 9900, 6900, 6860, 6865, 6560 Hardware Users Guides
Describes the hardware and software procedures for getting an OmniSwitch up and running as well as
complete technical specifications and procedures for all OmniSwitch chassis, power supplies, fans, and
Network Interface (NI) modules.
• OmniSwitch AOS Release 8 CLI Reference Guide
Complete reference to all CLI commands supported on the OmniSwitch. Includes syntax definitions,
default values, examples, usage guidelines and CLI-to-MIB variable mappings.
• OmniSwitch AOS Release 8 Switch Management Guide
Includes procedures for readying an individual switch for integration into a network. Topics include
the software directory architecture, image rollback protections, authenticated switch access, managing
switch files, system configuration, using SNMP, and using web management software (WebView).
• OmniSwitch AOS Release 8 Network Configuration Guide
Includes network configuration procedures and descriptive information on all the major software
features and protocols included in the base software package. Chapters cover Layer 2 information
(Ethernet and VLAN configuration), Layer 3 information (routing protocols, such as RIP and IPX),
security options (authenticated VLANs), Quality of Service (QoS), link aggregation, and server load
balancing.
• OmniSwitch AOS Release 8 Advanced Routing Configuration Guide
Includes network configuration procedures and descriptive information on all the software features and
protocols included in the advanced routing software package. Chapters cover multicast routing
(DVMRP and PIM-SM), Open Shortest Path First (OSPF), and Border Gateway Protocol (BGP).
• OmniSwitch AOS Release 8 Data Center Switching Guide
Includes an introduction to the OmniSwitch data center switching architecture as well as network
configuration procedures and descriptive information on all the software features and protocols that
support this architecture. Chapters cover Shortest Path Bridging MAC (SPBM), Data Center Bridging
(DCB) protocols, Virtual Network Profile (vNP), and FCoE/FC gateway functionality.
• OmniSwitch AOS Release 8 Transceivers Guide
Includes SFP and XFP transceiver specifications and product compatibility information.
• OmniSwitch AOS Release 8 Specifications Guide
Includes Specifications table information for the features documented in the Switch Management
Guide, Network Configuration Guide, Advanced Routing Guide, and Data Center Switching Guide.
• Technical Tips, Field Notices
Includes information published by Alcatel-Lucent Enterprise’s Customer Support group.
• Release Notes
Includes critical Open Problem Reports, feature exceptions, and other important information on the
features supported in the current release and any limitations to their support.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
xxv
Technical Support
About This Guide
Technical Support
An Alcatel-Lucent Enterprise service agreement brings your company the assurance of 7x24 no-excuses
technical support. You’ll also receive regular software updates to maintain and maximize your AlcatelLucent Enterprise product’s features and functionality and on-site hardware replacement through our
global network of highly qualified service delivery partners.
With 24-hour access to Alcatel-Lucent Enterprise’s Service and Support web page, you’ll be able to view
and update any case (open or closed) that you have reported to Alcatel-Lucent Enterprise’s technical
support, open a new case or access helpful release notes, technical bulletins, and manuals.
Access additional information on Alcatel-Lucent Enterprise’s Service Programs:
Web: support.esd.alcatel-lucent.com
Phone: 1-800-995-2696
Email: ebg_global_supportcenter@al-enterprise.com
xxvi
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
1
Configuring Ethernet Ports
The Ethernet software is responsible for a variety of functions that support Ethernet, Gigabit Ethernet, and
10/40 Gigabit Ethernet ports on OmniSwitch Series switches. These functions include diagnostics,
software loading, initialization, configuration of line parameters, gathering statistics, and responding to
administrative requests from SNMP or CLI.
In This Chapter
This chapter describes the Ethernet port parameters of the switch and how to configure them through the
Command Line Interface (CLI). CLI Commands are used in the configuration examples.
Configuration procedures described in this chapter include:
• “Configuring Ethernet Port Parameters” on page 1-3
• “Clearing Ethernet Port Violations” on page 1-13
• “Link Monitoring” on page 1-14
• “Link Fault Propagation” on page 1-18
• “IEEE 1588 Precision Time Protocol (PTP)” on page 1-21
For more information about using CLI commands to view Ethernet port parameters, see the OmniSwitch
AOS Release 8 CLI Reference Guide.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 1-1
Configuring Ethernet Ports
Ethernet Port Defaults
Ethernet Port Defaults
The following table shows Ethernet port default values:
Parameter Description
Command
Default Value/Comments
Interface Line Speed
interfaces speed
AutoNeg
Interface Duplex Mode
interfaces duplex
AutoNeg
Trap Port Link Messages
interfaces link-trap
Disabled
Interface Configuration
interfaces
Enabled
Peak Flood Rate Configuration
interfaces flood-limit
4 Mbps (10 Ethernet)
49 Mbps (100 Fast Ethernet)
496 Mbps (1 Gigabit Ethernet)
997 Mbps (10 Gigabit Ethernet)
997 Mbps (40 Gigabit Ethernet)
Interface Alias
interfaces alias
None configured
Maximum Frame Size
interfaces max-framesize
1553 (untagged) Ethernet packets
1553 (tagged) Ethernet packets
9216 Gigabit Ethernet packets
Digital Diagnostics Monitoring
(DDM)
interfaces ddm
Disabled
Enhanced Port Performance
(EPP)
interfaces
Disabled
Beacon LED
interfaces beacon
Disabled
Precision Time Protocol (PTP)
time stamping on the switch
interfaces ptp adminstate
Disabled
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 1-2
Configuring Ethernet Ports
Ethernet Ports Overview
Ethernet Ports Overview
This chapter describes the Ethernet software CLI commands used for configuring and monitoring the
Ethernet port parameters of your switch.
Configuring Ethernet Port Parameters
The following sections describe how to use CLI commands to configure ethernet ports.
Enabling and Disabling Autonegotiation
To enable or disable autonegotiation on a single port, a range of ports, or an entire slot, use the interfaces
command. For example:
-> interfaces 2/3 autoneg enable
-> interfaces 2/1-3 autoneg enable
-> interfaces 2 autoneg enable
Configuring Crossover Settings
To configure crossover settings on a single port, a range of ports, or an entire slot, use the interfaces
crossover command. If autonegotiation is disabled, auto MDIX, auto speed, and auto duplex are not
accepted.
Setting the crossover configuration to auto configures the interface or interfaces to automatically detect
crossover settings. Setting crossover configuration to mdix configures the interface or interfaces for
MDIX (Media Dependent Interface with Crossover), which is the standard for hubs and switches. Setting
crossover to mdi configures the interface or interfaces for MDI (Media Dependent Interface), which is the
standard for end stations.
For example:
-> interfaces 2/1 crossover auto
-> interfaces 2/2-5 crossover mdi
-> interfaces 3 crossover mdix
Setting Interface Line Speed
The interfaces speed command is used to set the line speed on a specific port, a range of ports, or all ports
on an entire slot.
For example:
-> interfaces 2/1 speed 100
-> interfaces 2/2-5 speed 1000
-> interfaces 3 speed auto
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 1-3
Configuring Ethernet Ports
Configuring Ethernet Port Parameters
Configuring Duplex Mode
The interfaces duplex command is used to configure the duplex mode on a specific port, a range of ports,
or all ports on a slot to full, half, or auto. (The auto option causes the switch to advertise all available
duplex modes (half/full/both) for the port during autonegotiation.) In full duplex mode, the interface
transmits and receives data simultaneously. In half duplex mode, the interface can only transmit or receive
data at a given time.
For example:
-> interfaces 2/1 duplex half
-> interfaces 2/2-5 duplex auto
-> interfaces 3 duplex full
Setting Trap Port Link Messages
The interfaces link-trap command can be used to enable or disable trap port link messages on a specific
port, a range of ports, or all ports on a slot. When enabled, a trap message is sent to a Network
Management Station (NMS) whenever the port state has changed.
For example:
-> interfaces 2/3 link-trap enable
-> interfaces 2/3-5 link-trap enable
-> interfaces 2 link-trap enable
Resetting Statistics Counters
The clear interfaces command is used to reset all Layer 2 statistics counters on a specific port, a range of
ports, or all ports on a slot. For example:
-> clear interfaces 2/3 l2-statistics
-> clear interfaces 2/1-3 l2-statistics
-> clear interfaces 2 l2-statistics
This command also includes an optional cli parameter. When this parameter is specified, only those
statistics that are maintained by the switch CLI are cleared; SNMP values are not cleared and continue to
maintain cumulative totals. For example:
-> clear interfaces 2/1-3 l2-statistics cli
Note that when the cli parameter is not specified both CLI and SNMP statistics are cleared.
Enabling and Disabling Interfaces
The interfaces command is used to enable or disable a specific port, a range of ports, or all ports on an
entire slot.
-> interfaces 2/3 admin-state disable
-> interfaces 2/1-3 admin-state disable
-> interfaces 2 admin-state disable
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 1-4
Configuring Ethernet Ports
Configuring Ethernet Port Parameters
Configuring a Port Alias
The interfaces alias command is used to configure an alias (i.e., description) for a single port. (You
cannot configure an entire switch or a range of ports.) For example:
-> interfaces 2/3 alias ip_phone1
-> interfaces 2/3 alias “ip phones 1”
Note. Spaces must be contained within quotes.
Configuring Maximum Frame Sizes
The interfaces max-frame-size command can be used to configure the maximum frame size (in bytes) on
a specific port, a range of ports, or all ports on a switch.
For example:
-> interfaces 2/3 max frame 9216
-> interfaces 2/1-3 max frame 9216
-> interfaces 2 max frame 9216
Configuring Digital Diagnostic Monitoring (DDM)
Digital Diagnostics Monitoring allows the switch to monitor the status of a transceiver by reading the
information contained on the transceiver's EEPROM. The transceiver can display Actual, Warning-Low,
Warning-High, Alarm-Low and Alarm-High for the following:
• Temperature
• Supply Voltage
• Current
• Output Power
• Input Power
To enable the DDM capability on the switch use the interfaces ddm command. For example, enter:
-> interfaces ddm enable
Traps can be enabled using the interfaces ddm-trap if any of the above values crosses the pre-defined
low or high thresholds of the transceiver. For example:
-> interfaces ddm-trap enable
Note. In order to take advantage of the DDM capability, the transceiver must support the DDM
functionality. Not all transceivers support DDM; refer to the Transceivers Guide for additional DDM
information.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 1-5
Configuring Ethernet Ports
Configuring Ethernet Port Parameters
Configuring Flood Rate Limiting
The OmniSwitch implementation of storm control supports flood rate limiting for broadcast, unknown
unicast, and multicast traffic. A high threshold rate is configured in megabits-per-second (mbps), packetsper-second (pps), or as a percentage of the port speed. When the threshold value is reached, packets are
dropped.
To configure the flood rate limit threshold, use the interfaces flood-limit command For example:
-> interfaces 2/1/1 flood-limit bcast rate mbps 100
-> interfaces 2/1/2-5 flood-limit uucast rate pps 500
-> interfaces slot 3/1 flood-limit mcast rate cap% 50
Configuring a Flood Rate Limit Action
Configuring a port shutdown or trap action to occur when the rate limit threshold is reached provides a
method for monitoring storm traffic.
• Port shutdown action—port is moved to a STORM violated state and a violation trap is sent.
• Trap action—the storm is controlled through flood rate limiting and a trap is sent. The port is not
moved into a STORM violated state.
To configure the flood rate limit action, use the interfaces flood-limit action command with either the
shutdown or trap option. For example:
-> interfaces 1/1/1 flood-limit bcast action shutdown
-> interfaces 1/1/4 flood-limit uucast action trap
Use the all option with the interfaces flood-limit action command to specify all types of traffic. For
example:
-> interfaces 1/1/11 flood-limit all action shutdown
To set the flood rate limit action back to the default value (no action is taken) use the interfaces floodlimit action command with the default option. For example:
-> interfaces 1/1/14 flood-limit mcast action default
Configuring Auto-Recovery for Port Shutdown Action
When a port is shutdown because of a STORM violated state, an administrator will have to clear the
violation. However, configuring a low threshold value for flood rate limiting can help to automate this
process. When the rate of violating traffic received on the port goes below the low threshold value, the
port is removed from the violating state.
To configure the low threshold value, use the interfaces flood-limit command with the low-threshold
option. For example:
-> interfaces 1/1/1 flood-limit bcast rate mbps 60 low-threshold 40
-> interfaces 1/1/4 flood-limit uucast rate mbps 100 low-threshold 40
-> interfaces 1/1/5 flood-limit mcast rate pps 2000 low-threshold 1000
Configuring Flood Rate Limiting
The following section describes how to apply a flood limit value to broadcast, unicast flooded, or
multicast traffic for a slot, port, or a range of ports. The interfaces flood-limit command can be used to
set limits based on pps, mbps, or a percentage of the port bandwidth.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 1-6
Configuring Ethernet Ports
Configuring Ethernet Port Parameters
For example:
-> interfaces 2/1/1 flood-limit bcast rate mbps 100
-> interfaces 2/1/2-5 flood-limit uucast rate pps 500
-> interfaces slot 3/1 flood-limit mcast rate cap% 50
The auto recovery has to enabled by configuring the low threshold. The high and low threshold when
configured, will have same type [mbps, pps, and percentage].
For example:
-> interfaces 1/1/1 flood-limit bcast rate mbps 60 low-threshold 40
-> interfaces 1/1/4 flood-limit uucast rate mbps 100 low-threshold 40
-> interfaces 1/1/5 flood-limit mcast rate pps 2000 low-threshold 1000
Configuring Flood Rate Limit Action
The following section describes how to apply action, when a port reaches storm violated state. You can set
an “action” for a singe port or a range of ports.
For example:
->
->
->
->
interfaces
interfaces
interfaces
interfaces
1/1/1 flood-limit bcast action shutdown
1/1/4 flood uucast action trap
1/1/11 flood-limit all action shutdown
1/1/14 flood mcast action default
When the action is set as “shutdown”, it specifies that when high threshold is violated, the port needs
to be put in blocked state. When the action is set as “trap”, it specifies that when high threshold is
crossed, the trap will be sent with the violation reason. Similarly, when the action is set as “default”, it
specifies that when traffic reaches high threshold, packets above that rate will be dropped.
Configuring Flow Control
The interfaces pause command is used to configure flow control (pause) settings for ports that run in full
duplex mode. Configuring flow control is done to specify whether or not an interface transmits, honors, or
both transmits and honors PAUSE frames. PAUSE frames are used to temporarily pause the flow of traffic
between two connected devices to help prevent packet loss when traffic congestion occurs between
switches.
Note that if autonegotiation and flow control are both enabled for an interface, then autonegotiation
determines how the interface processes PAUSE frames. If autonegotiation is disabled but flow control is
enabled, then the configured flow control settings apply.
By default, flow control is disabled. To configure flow control for one or more ports, use the interfaces
pause command with one of the following parameters to specify how PAUSE frames are processed:
• tx—Transmit PAUSE frames to peer switches when traffic congestion occurs on the local interface. Do
not honor PAUSE frames from peer switches.
• rx—Allow the interface to honor PAUSE frames from peer switches and temporarily stop sending
traffic to the peer. Do not transmit PAUSE frames to peer switches.
• tx-and-rx—Transmit and honor PAUSE frames when traffic congestion occurs between peer switches.
For example, the following command configures ports 1/1 through 1/10 to transmit and honor PAUSE
frames:
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 1-7
Configuring Ethernet Ports
Configuring Ethernet Port Parameters
-> interfaces 1/1-10 pause tx-and-rx
To disable flow control for one or more ports, specify the disable parameter with the interfaces pause
command. For example:
-> interfaces 1/10 pause disable
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 1-8
Configuring Ethernet Ports
Configuring Ethernet Port Parameters
Enabling and Disabling Enhanced Port Performance (EPP)
EPP can assist in connecting with SFF-8431 non-compliant or electrically deficient devices. EPP can be
used on some links to enhance the receive signal sampling resolution management and help to improve the
link integrity to the link partner. The following steps should be followed to determine if EPP should be
enabled:
1 Check the current link quality - Check the current link quality of the interface.
2 Diagnose any link quality issues - If the Link Quality is not ‘Good’. Perform a few basic
troubleshooting steps to determine if the issue is with the link partner and whether enabling EPP can help
improve the quality.
3 Enable EPP - If it’s determined that the issue is with the link parter, enable EPP.
EPP - Product and Transceiver Support
Only certain transceivers support enabling EPP. Additionally, depending on the revision of the
OmniSwitch, there are port restrictions due to the power requirements of enabling EPP as shown in the
table below.
Product
Rev
EPP Support
OS6900-X20
B11
No restriction
B10 or less
Only 5 ports can have EPP enabled
B11
No restriction
B10 or less
Only 5 ports in 1st group of 20 and 5 ports in 2nd group of 20
Expansion Board
Any
No restrictions
10-Gigabit Transceivers
N/A
Supported
1/40-Gigabit Transceivers
N/A
Not Supported
OS6900-X40
Product/Transceiver Support
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 1-9
Configuring Ethernet Ports
Configuring Ethernet Port Parameters
EPP - Check the Current Link Quality
A Link-Quality parameter has been added to help support EPP functionality. If connectivity issues are
being observed check the current link quality using the interfaces command and observe the EPP output.
For example:
-> show interfaces 2/1
(output truncated)
EPP
: Disabled,
Link-Quality:Fair
Link-Quality
Description
Good
Link is good
Fair
Link may exhibit errors
Poor
Link will exhibit errors and may lose connectivity
N/A
Link does not support EPP
EPP - Diagnose
For ports diagnosed as Fair or Poor, simple steps can be performed to identify the faulty component.
Since the issue could be with the transceiver, cable, fiber, or the link partner, see the table below to help
determine if the issue is with the link partner and if enabling EPP may help.
Media Type
Diagnostic Action
Direct Attached Copper • Disconnect cable from link partner
Cable
• Connect free cable end to unused port of OS6900
• View the Link-Quality
Good - The link partner should be diagnosed and enabling EPP may help.
Fair or Poor - The direct-attached copper cable should be replaced.
SFP+ optical
transceiver
• Replace SFP+ transceiver on OS6900 port
• View the Link-Quality
Good - The original SFP+ transceiver is faulty.
Fair or Poor - The fiber cable or link partner should be diagnosed and
enabling EPP may help.
EPP - Enabling
If after diagnosing the problem it is determined that the issue is with the link partner and the Link-Quality
has been diagnosed to be Fair or Poor, EPP can be enabled allowing the system to operate with the
deficient receive channels. For example:
-> interfaces 2/1 epp enable
After enabling EPP continue to monitor the Link-Quality.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 1-10
Configuring Ethernet Ports
Configuring Ethernet Port Parameters
Configuring Energy Efficient Ethernet (802.3az)
Energy Efficient Ethernet (EEE) is a protocol to allow ports to operate in idle or low power mode when
there is no traffic to send. When EEE is enabled on a port it will advertise its EEE capability to its link
partner. If the partner supports EEE they will operate in EEE mode. If the partner does not support EEE
the ports will operate in legacy mode. This allows EEE capable switches to be deployed in existing
networks avoiding backward compatibility issues.
• EEE is only applicable to 10GBase-T ports.
• The LLDP option in IEEE 802.3az standard is not currently supported.
To enable the EEE capability on the switch use the interfaces eee command. For example, enter:
-> interfaces 1/1 eee enable
Configuring Split-Mode
Some OmniSwitch models support 4X10G splitter cables to allow a 40G port to be configured as four 10G
ports. The interfaces split-mode command is used to configure the mode (auto, 40G, 4X10G).
When a splitter cable is used the port numbering scheme changes to accommodate the four 10G ports by
using letters a, b, c, d to refer to the 10G sub-ports. When referring to a single sub-port the port letter
should be used to differentiate between all the sub-ports. If no letter is given the command assumes port
'a', for example.
-> show interfaces 1/1/1 - refers to interface 1/1/1a
-> show interfaces 1/1/1a - refers to interface 1/1/1a
-> show interfaces 1/1/1d - refers to interface 1/1/1d
When referring to a range of ports the lettered sub-ports are implied, for example:
-> show
2b, 2c,
-> show
-> show
2a.
interfaces 1/1/1-2 - refers to interfaces 1/1/1a, 1b, 1c, 1d and 1/1/2a,
2d
interfaces 1/1/1a-1c - refers to interfaces 1/1/1a, 1b, 1c
interfaces 1/1/1-2a - refers to interfaces 1/1/1a, 1b, 1c, 1d, and 1/1/
Configuring Beacon LED
The Beacon LED feature provides a mechanism to allow an administrator to configure the color and the
mode of a port LED using the interfaces beacon command. This can useful in the following scenarios:
• Port identification: Can help to identify a particular port(s) needing attention or where a cable may
need to be swapped. Manually changing the color or mode of the port LED can help to guide a
technician to a particular port. This can also be helpful in a highly dense mesh of cabling.
• Power Savings: Large Data Centers are looking for ways to reduce power consumption. One way could
be to power off every LED on every node if operating properly and only use the LEDs for indicating
ports that need attention.
• Tracking link activity: Servers are often configured in clusters for certain functions or applications.
Ports could be color coded to differentiate between clusters.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 1-11
Configuring Ethernet Ports
Configuring Ethernet Port Parameters
Note. The beacon LED feature does not affect the normal behavior of switch ports or traffic flow. It only
sets LED colors and behaviors for the uses listed above. If an actual alarm or issue is detected on the switch,
important LED status information related to the issue takes precedence and overrides beacon settings.
Note. The beacon LED feature is not supported on sub-ports 'b', 'c', or 'd' when an interface is operating in
4X10G mode. Additionally, only Solid mode is supported on sub-port 'a' for 4X10G interfaces.
LED Color and Mode Settings
• LED Color - The color of the LED can be changed to yellow, white, red, magenta, green, blue, aqua, or
off.
• Activity Mode - The LED will blink normally based on the port activity but the color of the LED can
be changed.
• Solid Mode - The LED will not blink based on the port activity, it will always be solid. The color of
the LED can be changed.
-> interfaces 1/1/30 beacon admin-status enable
-> interfaces 1/1/30 beacon led-color magenta
-> interfaces 1/1/30 beacon led-mode solid
Beacon settings are saved and can be administratively enabled or disabled as needed at a later time. This
allows administrators to reuse previously configured LED settings without having to start over. Use the
show interfaces beacon command to view the beacon settings.
-> show interfaces beacon
Ch/Slot/Port
Admin-Stat
LED-Color
LED-Mode
------------+-------------+--------------+-----------1/1/1A
Disable
Magenta
Solid
1/1/2A
Disable
Blue
Activity
1/1/30A
Enable
Magenta
Solid
1/1/31A
Enable
Off
Solid
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 1-12
Configuring Ethernet Ports
Clearing Ethernet Port Violations
Clearing Ethernet Port Violations
The following switch applications may trigger a violation condition on one or more ports:
• Learned Port Security (LPS)
• Quality of Service (QoS)
• Network Security
• UniDirectional Link Detection (UDLD)
• Fabric stability related violations
Depending on the application and type of violation, specific actions are taken when a violation is detected
on the port. For example, an application may take one of the following actions when the violation triggers
a port shut down:
• Admin Down—deactivates the physical port.
• Simulated Down—the physical port shows as active but the applications are not allowed to access the
port link. The port is put in a blocking state.
A security violation may occur under the following conditions:
• A port is configured as a secure port and the number of secure MAC addresses learned on the port has
exceeded the maximum value.
• A device with a secure MAC address that is configured or learned on one of the secure ports attempts
to access another secure port.
Consider the following regarding link aggregate security violations:
• When a violation occurs on a physical port that is a member of a link aggregate, the violation affects
the entire link aggregate group. All ports on that link aggregate are either restricted or shut down.
• When the violations are cleared for the entire link aggregate group, the whole link aggregate group is
reactivated.
• When a simulated down violation occurs, toggling the link clears the violation for both the link
aggregates and physical ports.
To view the violation conditions that exist on individual ports or link aggregates, use the show violation
command. For example:
-> show violation
Port
Source
Action
Reason
Timer
------+----------+-------------------+----------------+-------1/1 src lrn
simulated down
lps shutdown
0
1/2 src lrn
simulated down
lps restrict
0
‘ ‘ 2‘‘qos‘ ‘ ‘ ‘ admin down
policy
0
To clear all the MAC address violation logs and activate the port or link aggregate, use the clear violation
command. For example:
-> clear violation port 1/10
-> clear violation linkagg 10-20
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 1-13
Configuring Ethernet Ports
Link Monitoring
Link Monitoring
The Link Monitoring feature is used to monitor interface status to minimize the network protocol reconvergence that can occur when an interface becomes unstable. To track the stability of an interface, this
feature monitors link errors and link flaps during a configured timeframe. If the number of errors or link
flaps exceeds configured thresholds during this time frame, the interface is shut down.
Note. Link Monitoring can be enabled on individual ports that make up a virtual port such as a link
aggregate or VFL, but not on the entire link aggregate or VFL virtual port.
There are no explicit Link Monitoring commands to recover a port from a Link Monitoring shutdown. See
“Clearing Ethernet Port Violations” on page 1-13 for information of clearing port violations.
Monitoring Interface Errors
When physical errors occur on an interface, control and data traffic is dropped causing unnecessary reconvergence for the network protocol running on the interface. The Link Monitoring feature monitors the
physical errors such as CRC, lost frames, error frames and alignment errors. When a configurable number
of errors is detected within the duration of a link monitoring window, the interface is shut down.
To configure the number of errors allowed before the port is shut down, use the interfaces linkmonitoring link-error-threshold command. For example:
-> interfaces 1/1 link-monitoring link-error-threshold 50
In this example, the port is shutdown if the number of link errors exceeds the threshold value of 50 during
the link monitoring window timeframe.
Monitoring Interface Flapping
When physical connectivity errors occur on an interface, the interface becomes unstable and causes
unnecessary re-convergence for the network protocols running on the interface. The Link Monitoring
feature monitors these interface flaps and shuts down the interface when excessive flapping is detected.
• The shutdown action is a physical port shutdown (the PHY and LED are down).
• Whenever an interface comes up and it is not an administrative action (admin-up), the link flap counter
is incremented.
The interfaces link-monitoring link-flap-threshold command is used to configure the number of flaps
allowed before the interface is shutdown. For example:
-> interfaces 1/1 link-monitoring link-flap-threshold 5
In this example, the port is shutdown if the number of link flaps exceeds the threshold value of five during
the link monitoring window timeframe.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 1-14
Configuring Ethernet Ports
Link Monitoring
Monitoring Window
The Link Monitoring window is a per-port configurable timer that is started whenever link-monitoring is
enabled on a port. During this time frame interface receive errors and interface flaps are counted. If either
of the values exceeds the configured thresholds the interface is shut down.
• The timer value can be modified even when the Link Monitoring timer is running and the new value of
timer will take effect after the current running timer expires.
• The threshold values for link errors and link flaps can also be modified when link-monitoring timer is
running; if the new threshold value is less than the current link-flap or link-error counter value, then the
interface will be shutdown immediately.
The interfaces link-monitoring time-window command is used to configure the monitoring window
timer. For example:
-> interfaces 1/1 link-monitoring time-window 500
In this example, link monitoring will monitor port 1/1 for 500 seconds.
Starting a Link Monitoring Session
The Link Monitoring window timer is started when the feature is enabled on an interface using the
interfaces link-monitoring admin-status command. For example:
-> interfaces 1/1 link-monitoring admin-status enable
All the statistics (link errors and link flaps) for a port are reset to zero when Link Monitoring is enabled on
that port.
Stopping a Link Monitoring Session
The Link Monitoring window timer is stopped when one of the following occurs:
• The interfaces link-monitoring admin-status command is used to disable the feature on the port. For
example:
-> interfaces 1/1 link-monitoring admin-status enable
• The port is shutdown by any feature, such as Link Monitoring, UDLD, or Link Fault Propagation.
Configuring the Wait-to-Restore Timer
The wait-to-restore (WTR) timer is used to implement a delay before an interface is made operational for
other features. Only after the timer has expired will the interface become active allowing network
protocols to converge more gracefully. The timer value is configured on a per-port basis and is started
whenever one of the following link-up events occurs:
• An interface is administratively downed followed by administratively up.
• The interfaces split-mode command is used.
• An interface recovers from a violation due to the automatic recovery timer mechanism.
• An interface is made operationally up when the cable is plugged in.
Consider the following when configuring the wait-to-restore timer:
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 1-15
Configuring Ethernet Ports
Link Monitoring
• If the interface goes down again while the WTR timer is still running, the WTR timer is stopped.
Otherwise, the interface is recovered after the time expires.
• The WTR timer functionality has no impact on link-error or link-flap detection; these features are
configurable even when the WTR timer is disabled.
• The timer value can be modified when the WTR timer is running; however, the new timer value does
not take effect until after the current running timer expires.
• The WTR timer is reset on every link up event that is detected.
• The WTR timer is stopped on detection of every link down event.
• When the WTR timer is running, the interface is physically up but the link status is down.
The interfaces wait-to-restore command is used to configure the WTR timer value, in multiples of 5. For
example, the following commands set the WTR timer value to 300 seconds:
-> interfaces 1/1 wait-to-restore 300
To disable the WTR timer mechanism, set the timer value to zero. For example:
-> interfaces 1/1 wait-to-restore 0
By default, the WTR time is disabled.
Configuring the Wait-to-Shutdown Timer
The wait-to-shutdown (WTS) timer is used to implement a delay before an interface is made nonoperational for other applications such as data, control and management. Only after the timer has expired
will the interface become disabled allowing network protocols to converge more gracefully. The timer
value is configured on a per-port basis and is started whenever one of the following link-up events occurs:
• An interface is administratively brought down.
• An interface is shutdown from a violation.
• An interface is made operationally down when the cable is unplugged in.
When the interface goes down, the WTS timer will be started. If the interface comes back up while the
WTS timer is running, then WTS timer will be stopped and no link down event will be sent. Otherwise,
after the WTS timer expiries a link-down event will be sent to all the relevant applications.
Consider the following when configuring the wait-to-shutdown timer:
• If the interface comes back up while the WTS timer is still running, the WTS timer is stopped and no
link down event is sent to other switch applications.
• The WTR timer functionality has no impact on link-error or link-flap detection; these features are
configurable even when the WTS timer is disabled.
• The timer value can be modified when the WTS timer is running; however, the new timer value does
not take effect until after the current running timer expires.
• When the wait-to-shutdown timer is running there would be packet loss on that interface. This is
because the port is physical down and only the link-down event is not being communicated to the
switch applications which will continue to send packets to the interface.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 1-16
Configuring Ethernet Ports
Link Monitoring
• The link-status of the remote connected port will be down when the WTS timer is running since the
port is physically down.
The interfaces wait-to-shutdown command is used to configure the WTS timer value, in multiples of 10
milliseconds. For example, the following commands set the WTR timer value to 30 seconds:
-> interfaces 1/1 wait-to-shutdown 30000
To disable the WTR timer mechanism, set the timer value to zero. For example:
-> interfaces 1/1 wait-to-shutdown 0
By default, the WTS time is disabled.
Displaying Link Monitoring Information
Use the following show commands to display Link Monitoring statistics and configuration information:
show interfaces linkmonitoring statistics
Displays Link Monitoring statistics, such as the link flap and error
counts and the port state (shutdown, down, up).
show interfaces linkmonitoring config
Displays the Link Monitoring configuration, such as the monitoring
status, monitoring window time, and the link flap and error thresholds.
show interfaces
Displays the administrative status, link status, violations, recovery
time, maximum recovery attempts and the value of the wait-to-restore
timer.
For more information about the resulting displays from these commands, see the OmniSwitch AOS
Release 8 CLI Reference Guide.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 1-17
Configuring Ethernet Ports
Link Fault Propagation
Link Fault Propagation
The Link Fault Propagation (LFP) feature provides a mechanism to propagate a local interface failure into
another local interface. In many scenarios, a set of ports provide connectivity to the network. If all these
ports go down, the connectivity to the network is lost. However, the remote end remains unaware of this
loss of connectivity and continues to send traffic that is unable to reach the network. To solve this
problem, LFP does the following:
• Monitors a group of interfaces (configured as source ports).
• If all the source ports in the group go down, LFP waits a configured amount of time then shuts down
another set of interfaces (configured as destination ports) that are associated with the same group.
• When any one of the source ports comes back up, all of the destination ports are brought back up and
network connectivity is restored.
The LFP source and destination ports can be physical or link aggregation ports. If the destination port is a
link aggregation port the shutdown consists of shutting down all members of the link aggregation group
(physically down). However, the link aggregation group remains administratively enabled.
Interaction With Interfaces Violation Recovery
• The clear violation command will clear the LFP violations and mark the interfaces as up even if the
violation condition still exists.
• An admin down followed by an admin up will clear the LFP violation and mark the interfaces as up
even if the violation condition still exists.
• When the destination port is a link aggregate, the shutdown action does not shutdown the link
aggregation. Instead, all the ports that are members of the link aggregation at the time of the violation
are shutdown.
• A link aggregate port remains in a violation state even if the port leaves the link aggregate.
• If a port that is not a member of a link aggregate at the time a violation occurred is added to a link
aggregate, the switch will not shut down the port.
• SNMP traps cannot be configured for LFP. The interface violation recovery mechanism will be
responsible for sending traps when a port is shutdown or recovered by LFP.
• If the wait-to-restore (WTR) timer is configured on the source ports of a LFP group with link
monitoring enabled, the state of the destination ports of the group will be determined by the link state
of the ports after the WTR timer has expired.
See “Clearing Ethernet Port Violations” on page 1-13 for information of clearing port violations.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 1-18
Configuring Ethernet Ports
Link Fault Propagation
Configuring Link Fault Propagation
Configuring LFP requires the following steps:
1 Create an LFP group. This type of group identifies the source ports to monitor and the destination
ports to bring down when all of the source ports go down. To create an LFP group, use the link-faultpropagation group command. For example:
-> link-fault-propagation group 1
2 Associate source ports with the LFP group. To associate source ports to an LFP group, use the link-
fault-propagation group source command. For example:
-> link-fault-propagation group 1 source port 1/2-5 2/3
3 Associate destination ports with the LFP group. To associate destination ports with an LFP group,
use the link-fault-propagation group destination command. For example:
-> link-fault-propagation group 1 destination port 1/5-8 2/3
4 Configure the LFP wait-to-shutdown timer. This timer specifies the amount of time that LFP will
wait before shutting down all the destination ports. To configure this timer value, use the link-faultpropagation group wait-to-shutdown command. For example:
-> link-fault-propagation group 1 wait-to-shutdown 70
Note. Optional. To verify the LFP configuration, use the show link-fault-propagation group command.
For example:
-> show link-fault-propagation group
Group Id : 2
Source Port(s)
: 0/1-2 1/1-5 1/7,
Destination Port(s)
: 0/3 1/10-13,
Group-Src-Ports Status : up,
Admin Status
: enable,
Wait To Shutdown
: 10
Group Id : 6
Source Port(s)
Destination Port(s)
Group-Src-Ports Status
Admin Status
Wait To Shutdown
:
:
:
:
:
1/2 1/6 1/9,
1/10-11 1/13,
down,
disable,
5
-> show link-fault-propagation group 2
Group Id : 2
Source Port(s)
: 0/1-2 1/1-5 1/7,
Destination Port(s)
: 0/3 1/10-13,
Group-Src-Ports Status : up,
Admin Status
: enable,
Wait To Shutdown
: 10
See the OmniSwitch AOS Release 8 CLI Reference Guide for more information about LFP commands.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 1-19
Configuring Ethernet Ports
Link Fault Propagation
LFP Application Example
This section provides an example of using LFP in a layer 2 network configuration, as shown in the
following sample topology:
OS-1
2/1
1
1/1
Access
3/1
DHL
1
LACP 1
Stby
L2 Network
1
Link Fault Propagation - Application Example
In this example:
• When interfaces 2/1 and 3/1 on OS-1 are down, the access switch will keep interface 1/1 as active and
traffic will still be forwarded to OS-1 even though it has no network connectivity.
• To allow the switch to use the standby interface the link on OS-1 would need to be disabled so that
interface 1/1 on the access switch leaves the LACP group.
-> link-fault-propagation group 1 source port 2/1 3/1 destination linkagg 1
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 1-20
Configuring Ethernet Ports
IEEE 1588 Precision Time Protocol (PTP)
IEEE 1588 Precision Time Protocol (PTP)
The Precision Time Protocol (PTP) is a protocol used to synchronize clocks throughout a computer
network. On a local area network, it achieves clock accuracy in the sub-microsecond range, making it
suitable for measurement and control systems.
The PTP function requires a time source device and a time receiver device to provide the time
synchronization between the devices. The time source is called master and time receiver is known as
slave. Apart from this master and slave clock devices, there are intermediate switches in the network
through which the packets would be transmitted. On transmitting through these devices, a transmission
delay would be introduced on each of the switches placed between the master and the slave. To maintain
the accuracy of time synchronization between the master and the slave, it is important to take into
consideration these transmit times taken by the PTP frames when passing along the intermediary nodes.
The intermediate switches must have the ability to support PTP and thereby update the link and/or
residency time of frames in these switches - a concept knows as transparent clocking. There are two types
of transparent clocks, end-2-end transparent clock and peer-2-peer transparent clock.
OmniSwitch supports one step End-2-End transparent clock as defined in IEEE 1588 v2 Precision Time
Protocol standard (supports both 1588v1/v2 transparent clock).
Enabling/Disabling PTP Time Stamping
The interfaces ptp admin-state command can be used to enable or disable IEEE 1588 PTP time stamping
on the switch, and set the internal priority for the incoming PTP packet.
-> interfaces ptp admin-state enable
-> interfaces ptp admin-state disable
The below command sets the internal priority for the incoming PTP packet as 4.
-> interfaces ptp admin-state enable priority 4
To set the internal priority to the default value 7, use the default keyword.
-> interfaces ptp admin-state enable priority default
Use show interfaces ptp config command to view the current PTP status on the switch.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 1-21
2
Configuring UDLD
UniDirectional Link Detection (UDLD) is a protocol for detecting and disabling unidirectional Ethernet
fiber or copper links caused by mis-wiring of fiber strands, interface malfunctions, media converter faults,
and so on. The UDLD protocol operates at Layer 2 in conjunction with the IEEE 802.3 - Layer 1 fault
detection mechanisms.
UDLD is a lightweight protocol that can be used to detect and disable one-way connections before they
create dangerous situations such as Spanning Tree loops or other protocol malfunctions. The protocol is
mainly used to advertise the identities of all the UDLD-capable devices attached to the same LAN
segment and to collect the information received on the ports of each device to determine whether or not
the Layer 2 communication is functioning properly. All connected devices must support UDLD for the
protocol to successfully identify and disable unidirectional links. When UDLD detects a unidirectional
link, the protocol administratively shuts down the affected port and generates a trap to alert the user.
In This Chapter
This chapter describes how to configure UDLD parameters through the Command Line Interface (CLI).
CLI commands are used in the configuration examples; for more details about the syntax of commands,
see the OmniSwitch AOS Release 8 CLI Reference Guide.
Configuration procedures described in this chapter include the following:
• “Configuring UDLD” on page 2-6.
• “Configuring the Operational Mode” on page 2-7.
• “Configuring the Probe-Timer” on page 2-7.
• “Configuring the Echo-Wait-Timer” on page 2-7.
• “Clearing UDLD Statistics” on page 2-8.
• “Verifying the UDLD Configuration” on page 2-8.
• “Verifying the UDLD Configuration” on page 2-8.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 2-1
Configuring UDLD
UDLD Defaults
UDLD Defaults
Parameter Description
Command
Default
UDLD administrative state
udld
Disabled
UDLD status of a port
udld port
Disabled
UDLD operational mode
udld mode
Normal
Probe-message advertisement timer
udld probe-timer
15 seconds
Echo-based detection timer
udld echo-wait-timer
8 seconds
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 2-2
Configuring UDLD
Quick Steps for Configuring UDLD
Quick Steps for Configuring UDLD
1 To enable the UDLD protocol on a switch, use the udld command. For example:
-> udld enable
2 To enable the UDLD protocol on a port, use the udld port command by entering udld port, followed
by the slot and port number, and enable. For example:
-> udld port 1/6 enable
3 Configure the operational mode of UDLD by entering udld port, followed by the slot and port
number, mode, and the operational mode. For example:
-> udld port 1/6 mode aggressive
4 Configure the probe-message advertisement timer on port 6 of slot 1 as 17 seconds using the following
command:
-> udld port 1/6 probe-timer 17
Note. Optional. Verify the UDLD global configuration by entering the show udld configuration command
or verify the UDLD configuration on a port by entering the show udld configuration port command. For
example:
-> show udld configuration
Global UDLD Status : Disabled
-> show udld configuration port 1/6
Global UDLD Status: enabled
Port UDLD Status: enabled
Port UDLD State: bidirectional
UDLD Op-Mode: normal
Probe Timer (Sec): 20,
Echo-Wait Timer (Sec): 10
To verify the UDLD statistics of a port, use the show udld statistics port command. For example:
-> show udld statistics port 1/42
UDLD Port Statistics
Hello Packet Send
:8,
Echo Packet Send
:8,
Flush Packet Recvd
:0
UDLD Neighbor Statistics
Neighbor ID
Hello Pkts Recv
Echo Pkts Recv
--------------+--------------------+-------------1
8
15
2
8
15
3
8
21
4
8
14
5
8
15
6
8
20
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 2-3
Configuring UDLD
UDLD Overview
UDLD Overview
UDLD is a Layer 2 protocol used to examine the physical configuration connected through fiber-optic or
twisted-pair Ethernet cables. When a port is affected and only a unidirectional link is working, UDLD
detects and administratively shuts down the affected port, and alerts the user. Unidirectional links can
create hazardous situations such as Spanning-Tree topology loops caused, for instance, by unwiring of
fiber strands, interface malfunctions, faults of the media converter, and so on.
The UDLD feature is supported on the following port types:
• Copper ports
• Fiber ports
UDLD Operational Mode
UDLD supports two modes of operation:
• Normal mode
• Aggressive mode
UDLD works with the Layer 1 mechanisms to determine the physical status of a link. A unidirectional link
occurs whenever the traffic sent from a local device is received by its neighbor; but the traffic from the
neighbor is not received by the local device.
Normal Mode
In this mode, the protocol depends on explicit information instead of implicit information. If the protocol
is unable to retrieve any explicit information, the port is not put in the shutdown state; instead, it is marked
as Undetermined. The port is put in the shutdown state only when:
• It is explicitly determined that the link is defective
• When it is determined on the basis of UDLD-PDU processing that link has become unidirectional.
In any such state transition, a trap is raised.
Aggressive Mode
In this mode, UDLD checks whether the connections are correct and the traffic is flowing bidirectionally
between the respective neighbors. The loss of communication with the neighbor is considered an event to
put the port in shutdown state. Thus, if the UDLD PDUs are not received before the expiry of a timer, the
port is put in the UDLD-shutdown state. Since the lack of information is not always due to a defective
link, this mode is optional and is recommended only for point-to-point links.
UDLD shuts down the affected interface when one of these problems occurs:
• On fiber-optic or twisted-pair links, one of the interfaces cannot send or receive traffic.
• On fiber-optic or twisted-pair links, one of the interfaces is down while the other is up.
• One of the fiber strands in the cable is disconnected.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 2-4
Configuring UDLD
UDLD Overview
Mechanisms to Detect Unidirectional Links
The UDLD protocol is implemented to correct certain assumptions made by other protocols and to help
the Spanning Tree Protocol to function properly to avoid dangerous Layer 2 loops.
UDLD uses two basic mechanisms:
• It advertises the identity of a port and learns about its neighbors. This information about the neighbors
is maintained in a cache table.
• It sends continuous echo messages in certain circumstances that require fast notifications or fast re-
synchronization of the cached information.
Neighbor database maintenance
UDLD learns about other UDLD neighbors by periodically sending a Hello packet (also called an
advertisement or probe) on every active interface to inform each device about its neighbors.
When the switch receives a Hello message, the switch caches the information until the age time expires. If
the switch receives a new Hello message before the aging of an older cache entry, the switch replaces the
older entry with the new one.
Whenever an interface is disabled and UDLD is running, or UDLD is disabled on an interface, or the
switch is reset, UDLD clears all the existing cache entries for the interfaces that are affected by the
configuration change. UDLD sends a message to the neighbors to flush the part of their caches affected by
the status change. This UDLD message is intended to synchronize the caches.
Echo detection
UDLD depends on an echo-detection mechanism. UDLD restarts the detection window on its side of the
connection and sends echo messages in response to the request, whenever a UDLD device learns about a
new neighbor or receives a re-synchronization request from an out-of-sync neighbor. This behavior is the
same on all UDLD neighbors because the sender of the echoes expects to receive an echo as a response.
If the detection window ends and no valid response is received, the link is shut down, depending on the
UDLD mode. When UDLD is in normal mode, the link is considered to be undetermined and is not shut
down. When UDLD is in aggressive mode, the link is considered to be unidirectional, and the interface is
shut down.
In normal mode, if UDLD is in the advertisement or in the detection phase and all the neighbor cache
entries are aged out, UDLD restarts the link-up sequence to re-synchronize with potentially out-of-sync
neighbors.
In aggressive mode, if UDLD is in the advertisement or in the detection phase and all the neighbors of a
port are aged out, UDLD restarts the link-up sequence to re-synchronize with potentially out-of-sync
neighbors. UDLD shuts down the port, after the continuous messages, if the link state is undetermined.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 2-5
Configuring UDLD
Configuring UDLD
Configuring UDLD
This section describes how to use Command Line Interface (CLI) commands to do the following:
• “Enabling and Disabling UDLD” on page 2-6.
• “Configuring the Operational Mode” on page 2-7.
• “Configuring the Probe-Timer” on page 2-7.
• “Configuring the Echo-Wait-Timer” on page 2-7.
• “Clearing UDLD Statistics” on page 2-8.
• “Verifying the UDLD Configuration” on page 2-8.
Note. See the “UDLD Commands” chapter in the OmniSwitch AOS Release 8 CLI Reference Guide for
complete documentation of UDLD CLI commands.
Enabling and Disabling UDLD
By default, UDLD is disabled on all switch ports. To enable UDLD on a switch, use the udld command.
For example, the following command enables UDLD on a switch:
-> udld enable
To disable UDLD on a switch, use the udld command with the disable parameter. For example, the
following command disables UDLD on a switch:
-> udld disable
Enabling UDLD on a Port
By default, UDLD is disabled on all switch ports. To enable UDLD on a port, use the udld port
command. For example, the following command enables UDLD on port 3 of slot 1:
-> udld port 1/3 enable
To enable UDLD on multiple ports, specify a range of ports. For example:
-> udld port 1/6-10 enable
To disable UDLD on a port, use the udld port command with the disable parameter. For example, the
following command disables UDLD on a range of ports:
-> udld port 5/21-24 disable
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 2-6
Configuring UDLD
Configuring UDLD
Configuring the Operational Mode
To configure the operational mode, use the udld mode command as shown:
-> udld mode aggressive
For example, to configure the mode for port 4 on slot 2, enter:
-> udld port 2/4 mode aggressive
To configure the mode for multiple ports, specify a range of ports. For example:
-> udld port 2/7-18 mode normal
Configuring the Probe-Timer
To configure the probe-message advertisement timer, use the udld probe-timer command as shown:
-> udld probe-timer 20
For example, to configure the probe-timer for port 3 on slot 6, enter:
-> udld port 6/3 probe-timer 18
To configure the probe-timer for multiple ports, specify a range of ports. For example:
-> udld port 1/8-21 probe-timer 18
Use the no form of this command to reset the timer. For example, the following command resets the timer
for port 4 of slot 6:
-> no udld port 6/4 probe-timer
The following command resets the timer for multiple ports:
-> no udld port 1/8-21 probe-timer
Configuring the Echo-Wait-Timer
To configure the echo-based detection timer, use the udld echo-wait-timer command as shown:
-> udld echo-wait-timer 9
For example, to configure the echo-wait-timer for port 5 on slot 6, enter:
-> udld port 6/5 echo-wait-timer 12
To configure the echo-wait-timer for multiple ports, specify a range of ports. For example:
-> udld port 1/8-21 echo-wait-timer 9
Use the no form of this command to reset the timer. For example, the following command resets the timer
for port 6 of slot 4:
-> no udld port 4/6 echo-wait-timer
The following command resets the timer for multiple ports:
-> no udld port 1/8-21 echo-wait-timer
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 2-7
Configuring UDLD
Verifying the UDLD Configuration
Clearing UDLD Statistics
To clear the UDLD statistics, use the clear udld statistics port command. For example, to clear the
statistics for port 4 on slot 1, enter:
-> clear udld statistics port 1/4
To clear the UDLD statistics on all the ports, enter:
-> clear udld statistics
Verifying the UDLD Configuration
To display UDLD configuration and statistics information, use the show commands listed below:
show udld configuration
Displays the global status of UDLD configuration.
show udld configuration port
Displays the configuration information for all UDLD ports or for
a particular UDLD port on the switch.
show udld statistics port
Displays the UDLD statistics for a specific port.
show udld neighbor port
Displays the UDLD neighbor ports.
show udld status port
Displays the UDLD status for all ports or for a specific port.
For more information about the resulting display from these commands, see the OmniSwitch AOS Release
8 CLI Reference Guide. An example of the output for the show udld configuration port and show udld
statistics port commands is also given in “Quick Steps for Configuring UDLD” on page 2-3.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 2-8
3
Managing Source
Learning
Transparent bridging relies on a process referred to as source learning to handle traffic flow. Network
devices communicate by sending and receiving data packets that each contain a source MAC address and a
destination MAC address. When packets are received on switch network interface (NI) module ports,
source learning examines each packet and compares the source MAC address to entries in a MAC address
database table. If the table does not contain an entry for the source address, then a new record is created
associating the address with the port it was learned on. If an entry for the source address already exists in
the table, a new one is not created.
Packets are also filtered to determine if the source and destination address are on the same LAN segment.
If the destination address is not found in the MAC address table, then the packet is forwarded to all other
switches that are connected to the same LAN. If the MAC address table does contain a matching entry for
the destination address, then there is no need to forward the packet to the rest of the network.
In This Chapter
This chapter describes how to manage source learning entries in the switch MAC address table (often
referred to as the forwarding or filtering database) through the Command Line Interface (CLI). CLI
commands are used in the configuration examples; for more details about the syntax of commands, see the
OmniSwitch AOS Release 8 CLI Reference Guide.
Configuration procedures described in this chapter include:
• “Using Static MAC Addresses” on page 3-3.
• “Using Static Multicast MAC Addresses” on page 3-5.
• “Configuring MAC Address Table Aging Time” on page 3-7.
• “Configuring the Source Learning Status” on page 3-8.
• “Increasing the MAC Address Table Size” on page 3-9.
• “Displaying Source Learning Information” on page 3-10.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 3-1
Managing Source Learning
Source Learning Defaults
Source Learning Defaults
Parameter Description
Command
Default
Static MAC address operating mode
mac-learning static mac-address
bridging
MAC address aging timer
mac-learning aging-time
300 seconds
MAC source learning status per port
mac-learning
enabled
MAC source learning mode
mac-learning mode
centralized
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 3-2
Managing Source Learning
MAC Address Table Overview
MAC Address Table Overview
Source learning builds and maintains the MAC address table on each switch. New MAC address table
entries are created in one of two ways: they are dynamically learned or statically assigned. Dynamically
learned MAC addresses are those that are obtained by the switch when source learning examines data
packets and records the source address and the port and VLAN it was learned on. Static MAC addresses
are user defined addresses that are statically assigned to a port and VLAN using the mac-learning static
mac-address command.
Accessing MAC Address Table entries is useful for managing traffic flow and troubleshooting network
device connectivity problems. For example, if a workstation connected to the switch is unable to
communicate with another workstation connected to the same switch, the MAC address table might show
that one of these devices was learned on a port that belonged to a different VLAN or the source MAC
address of one of the devices do not appear at all in the address table.
Using Static MAC Addresses
Static MAC addresses are configured using the mac-learning static mac-address command. These
addresses direct network traffic to a specific port and VLAN. They are particularly useful when dealing
with silent network devices. These types of devices do not send packets, so their source MAC address is
never learned and recorded in the MAC address table. Assigning a MAC address to the silent device’s port
creates a record in the MAC address table and ensures that packets destined for the silent device are
forwarded out that port.
When defining a static MAC address for a particular slot/port and VLAN, consider the following:
• Configuring static MAC addresses is only supported on fixed ports.
• The specified slot/port must already belong to the specified VLAN. Use the vlan members untagged
command to assign a port to a VLAN before you configure the static MAC address.
• Only traffic from other ports associated with the same VLAN is directed to the static MAC address
slot/port.
• Static MAC addresses are permanent addresses. This means that a static MAC address remains in use
even if the MAC ages out or the switch is rebooted.
• There are two types of static MAC address behavior supported: bridging (default) or filtering. Enter
filtering to set up a denial of service to block potential hostile attacks. Traffic sent to or from a filtered
MAC address is dropped. Enter bridging for regular traffic flow to or from the MAC address.
• If a packet received on a port associated with the same VLAN contains a source address that matches a
static MAC address, the packet is discarded. The same source address on different ports within the
same VLAN is not supported.
• If a static MAC address is configured on a port link that is down or disabled, an asterisk appears to the
right of the MAC address in the display output. The asterisk indicates that this is an invalid MAC
address. When the port link comes up, however, the MAC address is then considered valid and the
asterisk no longer appears next to the address in the display.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 3-3
Managing Source Learning
Using Static MAC Addresses
Configuring Static MAC Addresses
To configure a permanent, bridging static MAC address, see the example below:
-> mac-learning vlan 1 port 1/1 static mac-address 00:00:02:CE:10:37 bridging
Use the no form of this command to clear MAC address entries from the table:
-> no mac-learning vlan 1 port 1/1 static mac-address 00:00:02:CE:10:37 bridging
To verify static MAC address configuration and other table entries, use the show mac-learning command.
For more information about this command, see the OmniSwitch AOS Release 8 CLI Reference Guide.
Static MAC Addresses on Link Aggregate Ports
Static MAC Addresses are not assigned to physical ports that belong to a link aggregate. Instead, they are
assigned to a link aggregate ID that represents a collection of physical ports. This ID is specified at the
time the link aggregate of ports is created.
To configure a static MAC address on a link aggregate ID 1 belong to VLAN 1 see the example below:
-> mac-learning vlan 1 linkagg 1 static mac-address 00:00:02:CE:10:37 bridging
For more information about configuring a link aggregate of ports, see Chapter 8, “Configuring Static Link
Aggregation” and Chapter 9, “Configuring Dynamic Link Aggregation.”
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 3-4
Managing Source Learning
Using Static Multicast MAC Addresses
Using Static Multicast MAC Addresses
Using static multicast MAC addresses allows you to send traffic intended for a single destination multicast
MAC address to selected switch ports within a given VLAN. To specify which ports receive the multicast
traffic, a static multicast address is assigned to each selected port for a given VLAN. The ports associated
with the multicast address are then identified as egress ports. When traffic received on ports within the
same VLAN is destined for the multicast address, the traffic is forwarded only on the egress ports that are
associated with the multicast address.
The mac-learning multicast mac-address command is used to configure a static multicast MAC address.
When defining this type of static MAC address for a particular port and VLAN, consider the following:
• A MAC address is considered a multicast MAC address if the least significant bit of the most
significant octet of the address is enabled. For example, MAC addresses with a prefix of 01, 03, 05, 13,
etc., are multicast MAC addresses.
• If a multicast prefix value is not present, then the address is treated as a regular MAC address and not
allowed with the mac-learning vlan multicast mac-address command.
• The multicast addresses within the following ranges are not supported:
01:00:5E:00:00:00 to 01:00:5E:7F:FF:FF
01:80:C2:XX.XX.XX
33:33:XX:XX:XX:XX
• In addition to configuring the same static multicast address for multiple ports within a given VLAN, it
is also possible to use the same multicast address across multiple VLANs.
• The specified port or link aggregate ID must already belong to the specified VLAN.
Configuring Static Multicast MAC Addresses
The mac-learning multicast mac-address command is used to define a destination multicast MAC
address and assign the address to one or more egress ports within a specified VLAN. For example, the
following command assigns the multicast address 01:25:9a:5c:2f:10 to port 1/24 in VLAN 20:
-> mac-learning vlan 20 port 1/1 multicast mac-address 01:25:9a:5c:2f:10
Use the no form of the mac-learning multicast mac-address command to delete static multicast MAC
address entries:
-> no mac-learning vlan 20 port 1/1 multicast mac-address 01:25:9a:5c:2f:10
If a MAC address, slot/port and VLAN ID are not specified with this form of the command, then all static
multicast addresses are deleted. For example, the following command deletes all static MAC addresses,
regardless of their slot/port or VLAN assignments:
-> no mac-learning multicast
To verify the static MAC address configuration and other table entries, use the show mac-learning and
show mac-learning commands. For more information about these commands, see the OmniSwitch AOS
Release 8 CLI Reference Guide.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 3-5
Managing Source Learning
Using Static Multicast MAC Addresses
Static Multicast MAC Addresses on Link Aggregate Ports
Static multicast MAC addresses are not assigned to physical ports that belong to a link aggregate. Instead,
they are assigned to a link aggregate ID that represents a collection of physical ports. This ID is specified
at the time the link aggregate of ports is created and when using the mac-address-table static-multicast
command.
To configure a static multicast MAC address on a link aggregate ID, use the mac-learning multicast
mac-address command with the linkagg keyword to specify the link aggregate ID. For example, the
following command assigns a static multicast MAC address to link aggregate ID 2 associated with VLAN
455:
-> mac-learning vlan 455 linkagg 2 multicast mac-address 01:95:2A:00:3E:4c
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 3-6
Managing Source Learning
Configuring MAC Address Table Aging Time
Configuring MAC Address Table Aging Time
Source learning also tracks MAC address age and removes addresses from the MAC address table that
have aged beyond the aging timer value. When a device stops sending packets, source learning keeps track
of how much time has passed since the last packet was received on the switch port of the device. When
this amount of time exceeds the aging time value, the MAC is aged out of the MAC address table. Source
learning always starts tracking MAC address age from the time since the last packet was received.
For example, the following sets the aging time for all VLANs to 1200 seconds (20 minutes):
-> mac-learning aging-time 1200
A MAC address learned on any VLAN port ages out when the time since a packet with the particular
address was last seen on the port exceeds 1200 seconds.
Note. An inactive MAC address can take up to twice as long as the aging time value specified to age out of
the MAC address table. For example, if an aging time of 60 seconds is specified, the MAC ages out any
time between 60 and 120 seconds of inactivity.
To set the aging time back to the default value, use the default parameter. For example, the following sets
the aging time for all VLANs back to the default value:
-> mac-learning aging-time default
To display the aging time value use the show mac-learning aging-time command. For more information
about this command, see the OmniSwitch AOS Release 8 CLI Reference Guide.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 3-7
Managing Source Learning
Configuring the Source Learning Status
Configuring the Source Learning Status
The source learning status for a port or link aggregate of ports is configurable using the mac-learning
command. For example:
-> mac-learning port 1/10 disable
-> mac-learning port 1/15-20 disable
-> mac-learning linkagg 10 disable
To enable the source learning status for a port or link aggregate, use the source-learning command with
the enable option. For example:
-> mac-learning port 1/10 enable
-> mac-learning port 1/15-20 enable
-> mac-learning linkagg 10 enable
Disabling source learning on a port or link aggregate is useful on a ring configuration, where a switch
within the ring does not need to learn the MAC addresses that the same switch is forwarding to another
switch within the ring,. This functionality is also useful in Transparent LAN Service configurations, where
the service provider device does not need to learn the MAC addresses of the customer network.
Configuring the source learning status is not allowed on the following types of switch ports:
• Ports enabled with Learned Port Security (LPS).
• Ports enabled with Universal Network Profile (UNP) functionality.
• Member ports of a link aggregate.
Consider the following guidelines when changing the source learning status for a port or link aggregate:
• Disabling source learning on a link aggregate disables MAC address learning on all member ports of
the link aggregate.
• MAC addresses dynamically learned on a port or aggregate are cleared when source learning is
disabled.
• Statically configured MAC addresses are not cleared when source learning is disabled for the port or
aggregate. In addition, configuring a new static MAC address is allowed even when source learning is
disabled.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 3-8
Managing Source Learning
Increasing the MAC Address Table Size
Increasing the MAC Address Table Size
There are two source learning modes available for the OmniSwitch: centralized and distributed. Enabling
the distributed mode for the switch increases the table size for the switch.
To enable the distributed MAC source learning mode for the chassis, use the mac-learning mode
command. When this mode is disabled, the switch operates in the centralized MAC source learning mode
(the default).
Enabling or disabling the distributed MAC source learning mode requires the following three steps:
1 Set the mode.
2 Enter the write memory command to save the switch configuration.
3 Reboot the switch.
For example:
-> mac-learning mode distributed
WARNING: Source Learning mode has changed - must do write memory and reload
-> write memory
-> reload
Note. All three of the above configuration steps are required to enable or disable the MAC mode. If any of
the above steps are skipped, the status of the mode is not changed.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 3-9
Managing Source Learning
Displaying Source Learning Information
Displaying Source Learning Information
To display MAC Address Table entries, statistics, and aging time values, use the show commands listed
below:
show mac-learning
Displays a list of all MAC addresses known to the MAC address
table, including static and multicast MAC addresses.
show mac-learning aging-time
Displays the current MAC address aging timer value by switch or
VLAN.
show mac-learning mode
Displays the current status of the distributed MAC source learning
mode.
For more information about the resulting displays from these commands, see the OmniSwitch AOS
Release 8 CLI Reference Guide.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 3-10
4
Configuring VLANs
In a flat bridged network, a broadcast domain is confined to a single LAN segment or even a specific
physical location, such as a department or building floor. In a switch-based network, such as one
comprised of OmniSwitch systems, a broadcast domain, or VLAN can span multiple physical switches
and can include ports from a variety of media types. For example, a single VLAN could span three
different switches located in different buildings and include a variety of Ethernet port configurations, such
as 802.1q tagged VLAN member ports and/or a link aggregate of ports.
In This Chapter
This chapter describes how to define and manage VLAN configurations through the Command Line
Interface (CLI). CLI commands are used in the configuration examples; for more details about the syntax
of commands, see the OmniSwitch AOS Release 8 CLI Reference Guide.
Configuration procedures described in this chapter include:
• “Creating/Modifying VLANs” on page 4-4.
• “Assigning Ports to VLANs” on page 4-6.
• “Enabling/Disabling Spanning Tree for a VLAN” on page 4-9.
• “Enabling/Disabling Source Learning” on page 4-9.
• “Configuring VLAN IP Interfaces” on page 4-10.
• “Bridging VLANs Across Multiple Switches” on page 4-11.
• “Verifying the VLAN Configuration” on page 4-13.
• “Using Private VLANs” on page 4-15.
For information about Spanning Tree, see Chapter 6, “Configuring Spanning Tree Parameters.”
For information about routing, see Chapter 15, “Configuring IP.”
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 4-1
Configuring VLANs
VLAN Defaults
VLAN Defaults
Parameter Description
Command
Default
VLAN identifier (VLAN ID)
vlan
VLAN 1 predefined on each
switch.
VLAN administrative state
vlan
Enabled
VLAN description
vlan name
VLAN ID
VLAN Spanning Tree state
spantree vlan admin-state
Enabled
VLAN IP router interface
ip interface
None
VLAN port associations
vlan members untagged
All ports are initially associated
with default VLAN 1.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 4-2
Configuring VLANs
Sample VLAN Configuration
Sample VLAN Configuration
The following steps provide a quick tutorial to create VLAN 100. Also included are steps to define a
VLAN description, IP router interface, and static switch port assignments.
Note. Optional. Creating a new VLAN involves specifying a VLAN ID that is not already assigned to an
existing VLAN. To determine if a VLAN already exists in the switch configuration, enter show vlan. If
VLAN 100 does not appear in the show vlan output, then it does not exist on the switch. For example:
-> show vlan
vlan type admin oper ip
mtu
name
-----+------+-----+-----+-----+-----+-----------1
std
Ena
Dis
Dis 1500
VLAN 1
1 Create VLAN 100 with a description (for example, Finance IP Network) using the following
command:
-> vlan 100 name “Finance IP Network”
2 Define an IP interface using the following command to assign an IP host address of 21.0.0.10 to VLAN
100 that enables forwarding of VLAN traffic to other subnets:
-> ip interface vlan_100_ip address 21.0.0.10 vlan 100
3 Assign switch ports 2 through 4 on slot 3 to VLAN 100 using the following command:
-> vlan 100 members port 3/2-4 untagged
Note. Optional. To verify the VLAN 100 configuration, use the show vlan command. For example:
-> show vlan 100
Name
Type
Administrative State
Operational State
IP Router Port
IP MTU
:
:
:
:
:
:
Finance IP Network,
Static Vlan,
Enabled,
Disabled,
21.0.0.10 255.0.0.0
1500
forward
e2,
To verify that ports 3/2-4 were assigned to VLAN 100, use the show vlan members command. For
example:
-> show vlan 100 members
port
type
status
--------+---------+-------------3/2
default
inactive
3/3
default
inactive
3/4
default
inactive
To verify the details about the specific VLAN port 3/2, use the show vlan members command with the
port keyword and port number. For example:
-> show vlan
type
:
status
:
vlan admin :
vlan oper :
100 members port 3/2
default,
inactive,
disabled,
disabled,
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 4-3
Configuring VLANs
VLAN Management Overview
VLAN Management Overview
One of the main benefits of using VLANs to segment network traffic, is that VLAN configuration and port
assignment is handled through switch software. This eliminates the need to physically change a network
device connection or location when adding or removing devices from the VLAN broadcast domain. The
OmniSwitch VLAN management software handles the following VLAN configuration tasks:
• Creating or modifying VLANs.
• Assigning or changing default VLAN port associations (VPAs).
• Enabling or disabling VLAN participation in the current Spanning Tree algorithm.
• Displaying VLAN configuration information.
In addition to the above tasks, VLAN management software tracks and reports the following information
to other switch software applications:
• VLAN configuration changes, such as adding or deleting VLANs, modifying the status of VLAN
properties (for example, administrative, Spanning Tree, and authentication status), changing the VLAN
description, or configuring VLAN router interfaces.
• VLAN port associations triggered by VLAN management and other switch software applications, such
as 802.1Q VLAN tagging.
• The VLAN operational state, which is inactive until at least one active switch port is associated with
the VLAN.
Creating/Modifying VLANs
The initial configuration for all OmniSwitch consists of a default VLAN 1 and all switch ports are initially
assigned to this VLAN. When a switching module is added to the switch, the physical ports are also
assigned to VLAN 1. If additional VLANs are not configured on the switch, then the entire switch is
treated as one large broadcast domain. All ports receive traffic from all other ports.
In compliance with the IEEE 802.1Q standard, each VLAN is identified by a unique number, referred to
as the “VLAN ID”. The user specifies a VLAN ID to create, modify or remove a VLAN and to assign
switch ports to a VLAN. When a packet is received on a port, the VLAN ID of the port is inserted into the
packet. The packet is then bridged to other ports that are assigned to the same VLAN ID. In essence, the
VLAN broadcast domain is defined by a collection of ports and packets assigned to its VLAN ID.
The operational status of a VLAN remains inactive until at least one active switch port is assigned to the
VLAN. This means that VLAN properties, such as Spanning Tree or router interfaces, also remain
inactive. Ports are considered active if they are connected to an active network device. Non-active port
assignments are allowed, but do not change the operational state of the VLAN.
Ports can be statically assigned to VLANs. When a port is assigned to a VLAN, a VLAN port association
(VPA) is created and tracked by VLAN management switch software. For more information about VPAs,
see “Assigning Ports to VLANs” on page 4-6.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 4-4
Configuring VLANs
Creating/Modifying VLANs
Adding/Removing a VLAN
To add a VLAN to the switch configuration, enter vlan followed by a unique VLAN ID, an optional
administrative status, and an optional description. For example, the following command creates VLAN
755 with a description:
-> vlan 755 name “IP Finance Network”
By default, administrative status and Spanning Tree are enabled when the VLAN is created. The name
parameter for a VLAN is optional.
Note. Quotation marks are required if the description contains multiple words separated by spaces. If the
description consists of only one word or multiple words separated by another character, such as a hyphen,
then quotes are not required.
You can also specify a contiguous range of VLAN IDs by using a hyphen with the vlan command. For
example, the following commands create VLANs 10 through 15 and 100 through 105 on the switch:
-> vlan 10-15 name “Marketing Network”
-> vlan 100-105 name “Marketing Network”
To remove a VLAN from the switch configuration, use the no form of the vlan command.
-> no vlan 200
-> no vlan 100-105
-> no vlan 10-15
When a VLAN is deleted, any router interfaces defined for the VLAN are removed and all VLAN port
associations are dropped. If the VLAN deleted is the default VLAN for a port, the port returns to default
VLAN 1. If the VLAN deleted is not a default VLAN, then the ports are directly detached from the
VLAN. For more information about VLAN router interfaces, see “Configuring VLAN IP Interfaces” on
page 4-10.
To view a list of VLANs already configured on the switch, use the show vlan command. See “Verifying
the VLAN Configuration” on page 4-13 for more information.
Enabling/Disabling the VLAN Administrative Status
To enable or disable the administrative status for an existing VLAN, enter vlan followed by an existing
VLAN ID and either enable or disable.
-> vlan 7 admin-state disable
-> vlan 1 admin-state enable
When the administrative status for a VLAN is disabled, VLAN port assignments are retained but traffic is
not forwarded on these ports.
Modifying the VLAN Description
To change the description for a VLAN, enter vlan followed by an existing VLAN ID and the keyword
name followed by the new description. For example, the following command changes the description for
VLAN 455 to “Marketing IP Network”:
-> vlan 455 name “Marketing IP Network”
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 4-5
Configuring VLANs
Assigning Ports to VLANs
Assigning Ports to VLANs
The OmniSwitch supports static assignment of physical switch ports to a VLAN. Once the assignment
occurs, a VLAN port association (VPA) is created and tracked by VLAN management software on each
switch. To view current VLAN port assignments in the switch configuration, use the show vlan members
command.
Methods for statically assigning ports to VLANs include the following:
• Using the vlan members untagged command to define a new configured default VLAN for fixed
ports. See “Changing the Default VLAN Assignment for a Port” on page 4-6.
• Using the vlan members tagged command to define 802.1Q-tagged VLANs for fixed ports. This
method allows the switch to bridge traffic for multiple VLANs over one physical port connection. See
“Using 802.1Q Tagging” on page 4-7.
• Configuring ports as members of a link aggregate that is assigned to a configured default VLAN. (See
Chapter 8, “Configuring Static Link Aggregation,” for more information.)
Changing the Default VLAN Assignment for a Port
Initially all switch ports are assigned to VLAN 1, which is also their configured default VLAN. When
additional VLANs are created on the switch, ports are assigned to the VLANs so that traffic from devices
connected to these ports is bridged within the VLAN domain.
To assign a switch port to a new default VLAN, use the vlan members untagged command. For example,
the following command assigns port 5 on slot 2 to VLAN 955:
-> vlan 955 members port 2/5 untagged
When the vlan members command is used, the port’s default VLAN assignment is changed to the
specified VLAN. The previous default VLAN assignment for the port (for example, VLAN 1, VLAN 10
or VLAN 200) is dropped.
The vlan members command is also used to change the default VLAN assignment for an aggregate of
ports. The link aggregate control number is specified instead of a slot and port. For example, the following
command assigns link aggregate 10 to VLAN 755:
-> vlan 755 members linkagg 10 untagged
For more information about configuring an aggregate of ports, see Chapter 8, “Configuring Static Link
Aggregation.”
Use the no form of the vlan members command to remove a default VPA. When this is done, VLAN 1 is
restored as the default VLAN for the port.
-> no vlan 955 members port 2/5
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 4-6
Configuring VLANs
Assigning Ports to VLANs
Using 802.1Q Tagging
Another method for assigning ports to VLANs involves configuring a switch port or link aggregate to
process 802.1Q-tagged frames that contain a specific VLAN ID designation. This method, referred to as
802.1Q tagging (or trunking), allows a single network link to carry traffic for multiple VLANs.
The OmniSwitch implements the IEEE 802.1Q standard for sending frames through the network tagged
with VLAN identification. This section details procedures for configuring and monitoring 802.1Q tagging
on a single switch port or link aggregate group.
“Tagged” refers to four bytes of reserved space in the header of the packet. The four bytes of “tagging” are
broken down as follows: the first two bytes indicate whether the packet is an 802.1Q packet, and the next
two bytes carry the VLAN identification (VID) and priority.
When packets ingress the switch, they are classified into a VLAN based on their 802.1Q tag information.
• If the packet contains an 802.1Q tag, the VLAN ID in the tag must match either the default VLAN ID
for the port or a VLAN ID for which the port is tagged. If there is no match, the packet is dropped.
• If the packet is not tagged at all, the packet is placed into the default VLAN to which the port that
received the packet is assigned.
The following diagram illustrates a simple network by using tagged and untagged traffic:
VLAN 1
untagged
VLAN 1
untagged
Switch 1
VLAN 2
tagged
port 4/3
Switch 2
VLAN 2
tagged
port 2/1
VLAN 3
tagged
VLAN 3
tagged
Tagged and Untagged Traffic Network
Switch 1 and 2 have three VLANs, one for untagged traffic and two for tagged traffic. The ports
connecting Switch 1 and 2 are configured in such a manner that the ports accept both tagged traffic for
VLANS 2 and 3 and untagged traffic for VLAN 1.
A port can only be assigned to one untagged VLAN (in every case, this is the default VLAN
configuration). In this example the default VLAN for port 2/1 and port 4/3 is VLAN 1. The port can be
assigned to as many 802.1Q-tagged VLANs as necessary.
Configuring 802.1Q Tagging
To set a port to be a tagged port, use the vlan members tagged command and specify a VLAN
identification (VID) number and a port number. For example, to configure port 3/4 to carry traffic for
VLAN 5, enter the following command at the CLI prompt:
-> vlan 5 members port 4/3 tagged
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 4-7
Configuring VLANs
Assigning Ports to VLANs
Port 4/3 is now configured to carry packets tagged with VLAN 5, even though VLAN 5 is not the default
VLAN for the port.
To enable tagging on link aggregation groups, enter the link aggregation group identification number in
place of the slot and port number, as shown:
-> vlan 5 members linkagg 8 tagged
(For further information on creating link aggregation groups, see Chapter 8, “Configuring Static Link
Aggregation,” or Chapter 9, “Configuring Dynamic Link Aggregation.”)
To remove 802.1Q tagging from a selected port or link aggregate, use the untagged parameter.
-> vlan 5 members linkagg 8 untagged
To display all VLANs, enter the following command:
-> show vlan port
Note. The link aggregation group must be created first before it can be set to use 802.1Q tagging.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 4-8
Configuring VLANs
Enabling/Disabling Spanning Tree for a VLAN
Enabling/Disabling Spanning Tree for a VLAN
The Spanning Tree operating mode for the switch determines how VLAN ports are evaluated to identify
redundant data paths. If the Spanning Tree switch operating mode is set to flat, then VLAN port
connections are checked against other VLAN port connections for redundant data paths.
Note. The single flat mode STP instance is referred to as the CIST (Common and Internal Spanning Tree)
instance.
In the flat mode, if the CIST instance is disabled, then it is disabled for all configured VLANs. However,
disabling STP on an individual VLAN excludes only those VLAN ports from the flat STP algorithm.
If the Spanning Tree operating mode is set to per-vlan mode, there is a single Spanning Tree instance for
each VLAN broadcast domain. Enabling or disabling STP on a VLAN in this mode includes or excludes
the VLAN from the per-vlan STP algorithm.
The spantree vlan admin-state command is used to enable or disable a Spanning Tree instance for an
existing VLAN. In the following examples, Spanning Tree is disabled on VLAN 255 and enabled on
VLAN 755:
-> spantree vlan 255 admin-state disable
-> spantree vlan 755 admin-state enable
STP does not become operationally active on a VLAN unless the VLAN is operationally active, which
occurs when at least one active port is assigned to the VLAN. Also, STP is enabled/disabled on individual
ports. So even if STP is enabled for the VLAN, a port assigned to that VLAN must also have STP
enabled. See Chapter 6, “Configuring Spanning Tree Parameters.”
Enabling/Disabling Source Learning
Source learning can be disabled on a VLAN. Disabling source learning can be beneficial in a ring
topology. There is no limit on the number of ports that can belong to a VLAN that has source learning
disabled, but it is recommended to include only the two ports connecting the switch to a ring.
To enable or disable source learning on a VLAN, use the mac-learning static mac-address command.
For example, the following commands disable and enabled source learning on VLAN 10:
-> mac-learning vlan 10 disable
-> mac-learning vlan 10 enable
Disabling source learning on a VLAN causes the VLAN to be flooded with unknown unicast traffic.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 4-9
Configuring VLANs
Configuring VLAN IP Interfaces
Configuring VLAN IP Interfaces
Network device traffic is bridged (switched) at the Layer 2 level between ports that are assigned to the
same VLAN. However, if a device needs to communicate with another device that belongs to a different
VLAN, then Layer 3 routing is necessary to transmit traffic between the VLANs. Bridging makes the
decision on where to forward packets based on the destination MAC address of the packet; routing makes
the decision on where to forward packets based on the IP network address assigned to the packet (for
example, 21.0.0.10).
The OmniSwitch supports the routing of IP traffic. A VLAN is available for routing when at least one IP
interface is defined for that VLAN and at least one active port is associated with the VLAN. Up to eight IP
interfaces can be configured for each VLAN.
If a VLAN does not have an IP interface, the ports associated with that VLAN are in essence firewalled
from other VLANs. For information about configuring IP interfaces, see Chapter 15, “Configuring IP.”
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 4-10
Configuring VLANs
Bridging VLANs Across Multiple Switches
Bridging VLANs Across Multiple Switches
To create a VLAN bridging domain that extends across multiple switches:
1 Create a VLAN on each switch with the same VLAN ID number (for example, VLAN 10).
2 On each switch, assign the ports that provide connections to other switches to the VLAN created in
Step 1.
3 On each switch, assign the ports that provide connections to end user devices (for example,
workstations) to the VLAN created in Step 1.
4 Connect switches and end user devices to the assigned ports.
The following diagram shows the physical configuration of an example VLAN bridging domain:
Switch B
Switch C
138.0.0.3
138.0.0.4
3/10
2/2
VLAN 10
VLAN 10
2/1
3/7
VLAN 10
VLAN 10
VLAN 10
VLAN 10
2/3
3/9
2/10
3/2
VLAN 10
VLAN 10
VLAN 10
VLAN 10
2/9
3/1
VLAN 10
VLAN 10
3/3
3/8
Switch A
Switch D
138.0.0.5
138.0.0.2
VLAN Bridging Domain: Physical Configuration
In the above diagram, VLAN 10 exists on all four switches and the connection ports between these
switches are assigned to VLAN 10. The workstations can communicate with each other because the ports
to which they are connected are also assigned to VLAN 10. It is important to note that connection cables
do not have to connect to the same port on each switch. The key is that the port must belong to the same
VLAN on each switch. To carry multiple VLANs between switches across a single physical connection
cable, use the 802.1Q tagging feature (see “Using 802.1Q Tagging” on page 4-7).
The connection between Switch C and D is shown with a broken line because the ports that provide this
connection are in a blocking state. Spanning Tree is active by default on all switches, VLANs and ports.
The Spanning Tree algorithm determined that if all connections between switches were active, a network
loop would exist that could cause unnecessary broadcast traffic on the network. The path between Switch
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 4-11
Configuring VLANs
Bridging VLANs Across Multiple Switches
C and D was shut down to avoid such a loop. See Chapter 6, “Configuring Spanning Tree Parameters,” for
information about how Spanning Tree configures network topologies that are loop free.
The following diagram shows the same bridging domain example as seen by the end user workstations.
Because traffic between these workstations is bridged across physical switch connections within the
VLAN 10 domain, the workstations are basically unaware that the switches even exist. Each workstation
believes that the others are all part of the same VLAN, even though they are physically connected to
different switches.
VLAN 10
138.0.0.3
138.0.0.4
138.0.0.2
138.0.0.5
VLAN Bridging Domain: Logical View
Creating a VLAN bridging domain across multiple switches allows VLAN members to communicate with
each other, even if they are not connected to the same physical switch. This is how a logical grouping of
users can traverse a physical network setup without routing and is one of the many benefits of using
VLANs.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 4-12
Configuring VLANs
Verifying the VLAN Configuration
Verifying the VLAN Configuration
To display information about the VLAN configuration for a single switch use the show commands listed
below:
show vlan
Displays a list of all VLANs configured on the switch and the status of
related VLAN properties (for example, admin and Spanning Tree status
and router port definitions).
show vlan members
Displays a list of VLAN port assignments.
show ip interface
Displays VLAN IP router interface information.
Understanding Port Output Display
Each line of the show vlan members output display corresponds to a single VLAN port association
(VPA). In addition to showing the VLAN ID and slot/port number, the VPA type and current status of
each association are also provided.
The VPA type indicates that one of the following methods was used to create the VPA:
Type
Description
default
The port was statically assigned to the VLAN using the vlan members
untagged command. The VLAN is now the configured default VLAN for
the port.
qtagged
The port was statically assigned to the VLAN using the vlan members
tagged command. The VLAN is a static secondary VLAN for the 802.1Q
tagged port.
mirror
The port is assigned to the VLAN because it is configured to mirror another
port that is assigned to the same VLAN. For more information about the
Port Mirroring feature, see Chapter 34, “Diagnosing Switch Problems.”
The VPA status indicates one of the following:
Status
Description
inactive
Port is not active (administratively disabled, down, or nothing connected to
the port) for the VPA.
blocking
Port is active, but not forwarding traffic for the VPA.
forwarding
Port is forwarding all traffic for the VPA.
filtering
Mobile port traffic is filtered for the VPA; only traffic received on the port
that matches VLAN rules is forwarded. Occurs when a mobile port’s
VLAN is administratively disabled or the port’s default VLAN status is
disabled. Does not apply to fixed ports.
The following example displays the VPA information for all ports in VLAN 200:
-> show vlan 200 members
port
type
status
--------+---------+-------------3/24
default
inactive
5/12
qtagged
blocking
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 4-13
Configuring VLANs
Verifying the VLAN Configuration
The above example output provides the following information:
• VLAN 200 is the configured default VLAN for port 3/24, which is currently not active.
• VLAN 200 is an 802.1Q-tagged VLAN for port 5/12, which is an active port but currently blocked
from forwarding traffic.
For more information about the resulting displays from these commands, see the OmniSwitch AOS
Release 8 CLI Reference Guide.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 4-14
Configuring VLANs
Using Private VLANs
Using Private VLANs
The Private VLAN (PVLAN) feature provides the ability to isolate Layer 2 data between devices that are
on the same VLAN. This type of data isolation improves security and simplifies system configuration.
A standard VLAN usually represents a single broadcast domain, but a PVLAN divides a VLAN (Primary)
into sub-VLANs (Secondary). The single broadcast domain is partitioned into smaller broadcast subdomains while keeping the existing Layer 3 configuration. When a VLAN is configured as a PVLAN, the
PVLAN is referred to as the Primary VLAN, and any subsequent VLANs that are associated with the
Primary VLAN are referred to as Secondary VLANs.
For example, consider an example where a single switch is used by different work groups. The users from
different work groups are all connected to the same VLAN. Having all the users operating in the same
VLAN domain can lead to compromise in data security and complexity in managing them.
To isolate the users from each other, Secondary VLANs can be created for each work group under the
Primary VLAN. The following diagram represents the scenario where W1, W2, and W3 are three different
work groups sharing the same PVLAN. To isolate them from communicating with each other, they are
assigned to individual Secondary VLANs. These Secondary VLANs cannot communicate with each other,
except the PVLAN port. The PVLAN communicates with the promiscuous port and exchanges data with
the respective Secondary VLANs.
Router
Promiscuous Port
PVLAN
OmniSwitch
Secondary
VLAN
W1:A
W1:B
Community VLAN
W2:A
W2:B
Isolated VL.AN
W3:A
W3:B
W3:C
Community VLAN
There are two types of Secondary VLANs:
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 4-15
Configuring VLANs
Using Private VLANs
• Isolated VLAN—In an Isolated VLAN, all hosts connected to a member port are Isolated at Layer 2.
They can communicate only with the promiscuous port of the Primary VLAN. There can be only one
Isolated VLAN within one Primary VLAN.
• Community VLAN—A Community VLAN is associated to a group of ports that connect to a certain
“community” of end devices with mutual trust relationships. Any switch port associated with a
common Community VLAN can communicate with each other and with the promiscuous ports of the
Primary VLAN but not with any other Secondary VLAN. There can be multiple distinct Community
VLANs within one Primary VLAN.
Private VLAN Ports
The ports with respect to PVLANs have different characteristics. The PVLAN port types are:
• PVLAN Isolated Port—An isolated port cannot communicate with any other port in the PVLAN
except for promiscuous ports. This is a physical port or link aggregation port that is associated with an
Isolated Secondary VLAN at the port level.
• PVLAN Community Port—A community port can only communicate with a promiscuous port and
other ports that are part of the same Community VLAN in the same Primary VLAN. This is a physical
port or link aggregation port that is associated with only one Community Secondary VLAN at the port
level.
• PVLAN Promiscuous Port—The promiscuous port can communicate with all the isolated ports and
community ports in the Primary VLAN. This is a physical port or link aggregation that is associated
with only one Primary VLAN at the port level.
• PVLAN ISL Port—An inter-switch link port that extends a PVLAN domain across different switches
by connecting Primary VLANs that belong to the same PVLAN domain. The ISL port carries both
non-PVLAN traffic and Primary VLAN traffic between switches.
Quick Steps for Configuring PVLANs
The following steps provide a quick tutorial that creates a PVLAN. Also included are steps to define a
Secondary VLAN for the PVLAN and assign ports to the PVLAN.
1 Create a PVLAN. Creating a PVLAN involves specifying a VLAN ID that is not already assigned to
an existing VLAN. The specified VLAN ID will become the Primary VLAN for the PVLAN. For
example, to create PVLAN 200 with the name “Corporate PVLAN” enter:
-> pvlan 200 name “Corporate PVLAN”
2 Enable the administrative state of PVLAN 200 by entering:
-> pvlan 200 admin-state enable
3 Create a Secondary VLAN and associate it to the Primary VLAN. Creating a Secondary VLAN
involves specifying a VLAN ID that is not already assigned to an existing VLAN. The Secondary VLAN
can be an Isolated VLAN or a Community VLAN depending on network requirements. For example, to
create Isolated VLAN 250 and Community VLAN 251 and associate them to Primary VLAN 200, enter:
-> pvlan 200 secondary 250 type isolated
-> pvlan 200 secondary 251 type community
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 4-16
Configuring VLANs
Using Private VLANs
4 Associate the ports that will be part of the PVLAN. For example, to tag ports with Primary VLAN 200
and Secondary VLANs 250 and 251, enter:
-> pvlan 200 members port 1/1/1-3 tagged
-> pvlan 250 members port 1/1/10-12 tagged
-> pvlan 251 members port 1/1/20-22 tagged
Note. Optional. To verify the PVLAN configuration, use the show pvlan command. For example:
-> show pvlan
pvlan
type
admin
oper
mtu
name
------+----------+-------+------+------+-----------------200
Primary
Ena
Dis
1500
PVLAN 200
250
Isolated
Ena
Dis
1500
PVLAN 250
251
Community Ena
Dis
1500
PVLAN 251
To verify the mapping of Secondary VLANs to a Primary VLAN, use the show pvlan mapping command.
For example:
-> show pvlan mapping
Primary
Secondary
VLAN
VLAN
Type
----------+----------+-----------200
250
Isolated
200
251
Community
To verify the port assignments for the PVLAN, use the show pvlan members command. For example:
-> show pvlan members
pvlan
port
type
status
port-type
-------+---------+------------------+------------+-----------200
1/1
qtagged
inactive
promiscuous
200
1/2
qtagged
inactive
promiscuous
200
1/3
qtagged
inactive
promiscuous
250
1/10
qtagged
inactive
isolated
250
1/11
qtagged
inactive
isolated
250
1/12
qtagged
inactive
isolated
251
1/20
qtagged
inactive
community
251
1/21
qtagged
inactive
community
251
1/22
qtagged
inactive
community
PVLAN Management Overview
The PVLAN feature provides the ability to create Secondary VLANs within a Primary VLAN. A regular
VLAN usually represents a single broadcast domain. However, a PVLAN divides a VLAN (Primary) into
sub-VLANs (Secondary) to partition the single broadcast domain into smaller broadcast sub-domains
while keeping the existing Layer 3 configuration.
The ports can be isolated from each other at the data link layer to improve security and performance and
also simplify IP address assignment. The following PVLAN configuration tasks can be performed on the
switch:
• Create a Primary VLAN, see page 4-18.
• Create Secondary VLANs (Community or Isolated) to associate with a Primary VLAN, see page 4-19.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 4-17
Configuring VLANs
Using Private VLANs
• Configure a user port or a link aggregate as a promiscuous port or ISL port for a Primary VLAN, see
page 4-20.
• Associate the Secondary VLANs to user ports or link aggregates, see page 4-21.
• Verify the PVLAN configuration, see page 4-25.
Creating PVLANs
Before creating a PVLAN, consider the following points:
• A Primary VLAN ID is created first and represents the PVLAN domain. When any Secondary VLANs
are created, the Primary VLAN ID must be specified to identify the PVLAN to which the Secondary
VLAN is assigned.
• The VLAN ID that is specified to create a Primary VLAN must not already exist in the system.
• The following values are configurable only on the Primary VLAN but are also applied to all the
Secondary VLANs that are associated with the Primary VLAN:
– The administrative status for the PVLAN (enabled by default). When the status is changed for the
Primary VLAN ID, the change is automatically applied to the Secondary VLANs.
– The Spanning Tree status for the PVLAN (enabled by default). When the status is changed for the
Primary VLAN ID, the change is automatically applied to the Secondary VLANs.
– IP configuration for the PVLAN. An IP interface is configured on the Primary VLAN but is not
configurable on Secondary VLANs.
• Specifying a description for Primary and Secondary VLANs is optional. If one is not specified, then
the VLAN ID is used as the description.
• MVRP cannot be enabled on the PVLAN.
To create a Primary VLAN for the PVLAN, enter pvlan followed by a unique VLAN ID, an optional
administrative status, and an optional description. For example, the following command creates Primary
VLAN 200 with a description:
-> pvlan 200 admin-state enable name “Corporate PVLAN”
When configuring a description that contains multiple words that are separated by spaces, quotations
marks are required. If the description consists of only one word or multiple words separated by another
character (such as a hyphen), then quotation marks are not required.
You can also specify a range of VLAN IDs with the pvlan command. Use a hyphen to indicate a
contiguous range. For example, the following commands create Primary VLANs 10 through 15 and 100
through 105 on the switch:
-> pvlan 10-15 100-105 name “Corporate PVLAN”
-> pvlan 100-105 name “Corporate PVLAN”
The maximum transfer unit (MTU) size can also be configured for the PVLAN when the PVLAN is
created. For example, to set an MTU size of 64 KB for PVLAN 200, enter the following:
-> pvlan 200 mtu-ip 64
To remove a PVLAN from the switch configuration, use the no form of the pvlan command. For example,
to remove PVLANs 10-15, 100-105, and 200, enter:
-> no pvlan 10-15
-> no pvlan 100-105
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 4-18
Configuring VLANs
Using Private VLANs
-> no pvlan 200
When the Primary VLAN for a PVLAN is deleted, any router interfaces defined for the PVLAN are
removed and all VLAN port associations are dropped.
To view a list of PVLANs already configured on the switch, use the show pvlan command. See
“Verifying the PVLAN Configuration” on page 4-25 for more information.
Enabling/Disabling the PVLAN Administrative Status
The administrative state of a PVLAN is enabled by default. To enable or disable the administrative status
for an existing PVLAN, enter pvlan followed by an existing Primary VLAN ID and either admin-state
enable or admin-state disable. For example:
-> pvlan 200 admin-state enable
-> pvlan 200 admin-state disable
When the administrative status for the Primary VLAN of a PVLAN is changed, the following occurs:
• The change is automatically made to any Secondary VLANs associated with the Primary VLAN.
• PVLAN port assignments are retained but traffic is not forwarded on these ports if the administrative
status is disabled.
Modifying the PVLAN Description
To change the description for the Primary VLAN of a PVLAN, enter pvlan followed by an existing
VLAN ID and the keyword name followed by the new description (up to 32 characters). For example, the
following command changes the description for Primary VLAN 200 to “Corporate IP Network”:
-> pvlan 455 name “Corporate IP Network”
Creating Secondary VLANs
Before creating Secondary VLANs for a PVLAN, consider the following points:
• The VLAN ID used to configure the Secondary VLAN must not already exist in the system.
• The Secondary VLAN can be created only after the Primary VLAN for the PVLAN is created.
• There are two types of Secondary VLANs: Isolated and Community. Only one Isolated VLAN can be
associated with a Primary VLAN, but multiple Community VLANs can be associated with the same
Primary VLAN.
• The administrative state of Secondary VLANs is derived from the administrative state of the Primary
VLAN.
• The Spanning Tree state of Secondary VLANs is derived from the Spanning Tree state of the
associated Primary VLAN.
• MVRP cannot be enabled on a Secondary VLAN.
To create and associate a Secondary VLAN to a Primary VLAN, use the pvlan secondary command. For
example, the following commands create Isolated and Community VLANs for Primary VLAN 200:
-> pvlan 200 secondary 250 type isolated
-> pvlan 200 secondary 251 type community
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 4-19
Configuring VLANs
Using Private VLANs
By default, the administrative status and the Spanning Tree status of the associated Primary VLAN is
applied to both of the configured Secondary VLANs.
You can also specify a range of Secondary VLAN IDs when creating Community VLANs. Use a hyphen
to indicate a contiguous range and a space to separate multiple VLAN ID entries. For example, the
following command creates and associates Community VLANs 20 through 25 to Primary VLAN 200 on
the switch:
-> pvlan 200 secondary 20-25 type community
Specifying a range of Secondary VLAN IDs is not allowed when creating Isolated VLANs. There is only
one Isolated VLAN allowed for each Primary PVLAN.
To remove a Secondary VLAN from the PVLAN, use the no form of the pvlan secondary command. For
example:
-> no pvlan 200 secondary 251
When a Secondary VLAN is deleted, the VLAN ID is removed and all VLAN port associations for that
VLAN are dropped.
To view the PVLAN mapping of Secondary VLANs configured on the switch, use the show pvlan
mapping command. See “Verifying the PVLAN Configuration” on page 4-25 for more information.
Assigning Ports to PVLANs
PVLAN offers Layer 2 data isolation between the devices on the same VLAN. For a PVLAN to operate,
ports or link aggregates must be assigned to the PVLAN. The following port types are configurable for
PVLANs:
• Promiscuous Port
• ISL Port
• Isolated Port
• Community Port
An ISL port can only be assigned to a Primary VLAN. The other port types are determined based on the
type of VLAN associated with the PVLAN to which the port is assigned. For example:
• Ports assigned to a Primary PVLAN are designated as promiscuous ports.
• Ports assigned to a Secondary VLAN configured as a Community VLAN are designated as community
ports.
• Ports assigned to a Secondary VLAN configured as an Isolated VLAN are designated as isolated ports.
The following table defines the communication criteria between the PVLAN port types:
Port Types
Isolated
Promiscuous
Community
ISL
Isolated
Deny
Permit
Deny
Permit
Promiscuous
Permit
Permit
Permit
Permit
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 4-20
Configuring VLANs
Using Private VLANs
Community
Deny
Permit
Deny, except for
ports that belong
to the same
Community.
Permit
ISL
Only PVLAN
packets
Permit
Only PVLAN
packets and the
same Community
VLAN packets
Permit
Configuring Promiscuous Ports
A PVLAN must have one promiscuous port associated with the Primary VLAN to communicate with all
the community ports, isolated ports, and ISL ports.
A promiscuous port can be tagged or untagged based on the network requirements.
To configure a promiscuous port, use the pvlan members command to assign a port or link aggregate as a
tagged or untagged member of the Primary VLAN. For example:
-> pvlan 200 members port 1/1/1 tagged
In this example, the port 1/1/1 is assigned to Primary PVLAN 200, so the port is designated as a
promiscuous port. When only a tagged VLAN-port association (VPA) is configured, then all untagged
traffic is dropped on the port.
To remove a promiscuous port from the Primary VLAN, use the no form of the pvlan members
command. For example:
-> no pvlan 200 members port 1/1/1
Configuring ISL Ports
An Inter-Switch-Link (ISL) port connects a Primary VLAN on one switch to a Primary VLAN on another
switch to extend the PVLAN domain across multiple switches. The ISL port carries Primary and
Secondary VLAN traffic between switches throughout the PVLAN domain. Make sure that the Primary
and Secondary VLAN configuration is the same across all the switches to ensure the traffic is forwarded
correctly over the ISL connections.
To configure an ISL port, use the pvlan members command with the isl parameter option. For example,
the following command configures port 1/1/2 as an ISL port for Primary VLAN 200:
-> pvlan 200 members port 1/1/2 isl
Note. An ISL port can be configured only on the Primary VLAN, but the ISL port carries traffic for all
VLANs associated with the PVLAN (Primary and Secondary).
To remove an ISL port from the Primary VLAN, use the no form of the pvlan members command. For
example:
-> no pvlan 200 members port 1/1/2
Configuring Secondary VLAN Ports
The Secondary VLAN ports are defined as isolated or community ports based on the type of Secondary
VLAN ID to which the ports are assigned.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 4-21
Configuring VLANs
Using Private VLANs
• If a port is assigned to an Isolated Secondary VLAN, the port is designated as an isolated port.
• If a port is assigned to a Community Secondary VLAN, the port is designated as a community port.
To configure an isolated port, use the pvlan members command to assign a port or link aggregate as a
tagged or untagged member of an Isolated Secondary VLAN. For example, the following commands
create Isolated VLAN 250 as a Secondary VLAN to Primary VLAN 200 and then assign port 1/2/2 and
link aggregate 10 to VLAN 250:
-> pvlan 200 secondary 250 type isolated
-> pvlan 250 members port 1/2/2 tagged
-> pvlan 250 members linkagg 10 untagged
To configure a community port, use the pvlan members command to assign a port or link aggregate as a
tagged or untagged member of a Community Secondary VLAN. For example, the following commands
create Community VLAN 251 as a Secondary VLAN to Primary VLAN 200 and then assign port 1/2/5
and link aggregate 15 to VLAN 251:
-> pvlan 200 secondary 251 type isolated
-> pvlan 251 members port 1/2/5 tagged
-> pvlan 251 members linkagg 15 untagged
To remove a port from a Secondary VLAN, use the no form of the pvlan members command. For
example, the following commands remove a port and link aggregate from Secondary VLAN 250 and 251:
-> no pvlan 250 members port 1/2/2
-> no pvlan 251 members linkagg 15
Assigning UNP Ports to Secondary VLANs
Universal Network Profile (UNP) ports can also be assigned to Secondary VLANs (isolated or community
ports). The UNP ports are designated as isolated or community ports during runtime based on the first
MAC address learned on the port.
• If the first MAC address is learned on a UNP port is classified into an Isolated VLAN, the port is
designated as an isolated port.
• If the first MAC address is learned on a UNP port is classified into a Community VLAN, the port is
designated as a community port.
• If the first MAC address learned on the a UNP port is classified into any standard VLAN (non-
PVLAN), then the UNP port cannot be designated as an isolated or community port.
Protocol Configuration Requirements for PVLAN
This section contains important information about configuring other protocols to interact with PVLANs.
For more information about each protocol, refer the related chapters in the OmniSwitch AOS Release 8
CLI Reference Guide and the OmniSwitch AOS Release 8 Network Configuration Guide.
Enabling DHCP Snooping for PVLANs
DHCP Snooping can be enabled only on the Primary VLAN of a PVLAN configuration. When enabled on
the Primary VLAN, the configuration will be applied to the Secondary VLANs associated with the
Primary VLAN.
If the DHCP Snooping server is on another chassis, then the ISL port configured for communication must
be configured as a trusted port.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 4-22
Configuring VLANs
Using Private VLANs
Enabling Ingress Source Filtering (ISF) for PVLANs
ISF can be enabled only on the Primary VLAN of a PVLAN configuration. When enabled on the Primary
VLAN, the configuration will be applied to the Secondary VLANs associated with the Primary VLAN.
Enabling IPMS for PVLANs
IPMS can be enabled only on the Primary VLAN of a PVLAN configuration.
Enabling STP for PVLANs
STP can be enabled only on the Primary VLAN of a PVLAN configuration. When enabled on the Primary
VLAN, the configuration will be applied to the Secondary VLANs associated to the Primary VLAN.
Note. The PVLAN feature is supported only when the switch is running in the flat (MSTP) Spanning Tree
mode; it is not supported in the per-VLAN mode.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 4-23
Configuring VLANs
Using Private VLANs
Sample PVLAN Use Case
PVLAN Spanning across Multiple Systems
The following diagram shows how using a PVLAN configuration allows the traffic to be segmented at the
Layer 2 level, thus limiting the broadcast domain and extending it across multiple switches.
Community VLAN
115, 100
VLAN 50
1
Isolated VLAN
55, 50
P
2
3
4
VLAN 100
VLAN 50
OmniSwitch-1
L
VLAN 50
Isolated VLAN
120, 100
Community VLAN
115, 100
1
2
3
VLAN 100
L
P
L
OmniSwitch-3
P
L
VLAN 100
OmniSwitch-2
Isolated VLAN
120, 100
L Inter-Switch Link Port
P Promiscuous Port
1
2
Community VLAN Ports
3
4
Isolated VLAN Ports
The individual switches are separately configured with the PVLAN setup. IP interfaces are configured on
the Primary VLAN, and the hosts in both the Isolated and Community VLAN can share the IP addresses
from the same subnet but still remain isolated.
In this use case example, there are two Primary VLANs (100, 50) spanning across multiple OmniSwitch
systems:
Primary VLAN: 100 (IP subnet: 10.10.100.x)
• Community VLAN: 115
• Isolated VLAN: 120
Primary VLAN: 50 (IP subnet: 10.10.50.x)
• Isolated VLAN: 55
All the isolated, community, and promiscuous ports can be untagged or tagged. Since the PVLAN domain
spans across multiple switches, an Inter-Switch Link (ISL) port is configured for each Primary VLAN on
each switch to connect and carry traffic forwarded on the Primary VLANs.
The PVLAN traffic flow in this scenario is as follows:
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 4-24
Configuring VLANs
Using Private VLANs
• Untagged traffic is passed into an untagged Secondary (community) port 1 on OmniSwitch-1.
– The traffic will be tagged with the PVID of the port which is Secondary VLAN.
– The ISL port will then carry the tagged traffic into the community port on the other switch
(OmniSwitch-2:1, OmniSwitch-2:2).
– Traffic outgoing through the promiscuous port (OmniSwitch-3: P: 100) will modify the tag to
Primary VLAN.
• Tagged traffic is passed into an untagged Secondary (community) port
– If the tag matches the PVID of the port, it will be allowed.
– The ISL port will then carry the tagged traffic into the community port on the other switch
(OmniSwitch-2:1, OmniSwitch-2:2).
– Traffic outgoing through promiscuous port (OmniSwitch-3: P: 100) will modify the tag to Primary
VLAN.
• Untagged traffic passed into a tagged Secondary (community) port is dropped.
• Tagged traffic passed into a tagged Secondary (community) port is dropped if the VLAN tag of the
traffic does not match the VLAN tag of the port.
Verifying the PVLAN Configuration
To display information about the PVLAN configuration, use the show commands listed below:
show pvlan
Displays a list of PVLANs configured on the switch.
show pvlan mapping
Displays Primary PVLAN and Secondary PVLAN mapping.
show pvlan members
Displays port associations (VPAs) for all or specific PVLANs.
Use the show configuration snapshot command with the pvlan option to display the PVLAN
configuration. For example:
-> show configuration snapshot pvlan
! PVLAN:
pvlan 300 admin-state enable
pvlan 300 secondary 20-25 type community
pvlan 300 members port 1/3/10 tagged
pvlan 300 members linkagg 10 tagged
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 4-25
5
Configuring High
Availability VLANs
High availability (HA) VLANs, unlike standard VLANs, allow you to send traffic intended for a single
destination MAC address to multiple switch ports. These high availability VLANs can be used to manage
server clusters.
In This Chapter
This chapter describes the basic components of high availability VLANs and how to configure them
through the Command Line Interface (CLI). CLI commands are used in the configuration examples; for
more details about the syntax of commands, see the OmniSwitch AOS Release 8 CLI Reference Guide.
Configuration procedures described in this chapter include:
• Creating a VLAN on page 5-6.
• Adding and Removing Server Cluster Ports to a HA VLAN on page 5-7.
• Assigning and Modifying Server Cluster Mode on page 5-7.
• Assigning and Removing MAC addresses to a HA VLAN on page 5-8.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 5-1
Configuring High Availability VLANs
High Availability Default Values
High Availability Default Values
The table below lists default values for high availability VLAN software.
Parameter Description
Command
Default Value/Comments
Server cluster admin state of the
server cluster
server-cluster
admin-state - enable
Server cluster id and mode
server-cluster
mode - L2
Mac address of the server cluster
server-cluster mac-address
None
IP address of the server cluster
server-cluster ip
IP address is configurable only
for L3 clusters.
Configure the port/linkagg of a
server cluster
server-cluster port
server-cluster linkagg
None
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 5-2
Configuring High Availability VLANs
Quick Steps for Creating High Availability VLANs
Quick Steps for Creating High Availability VLANs
Follow the steps below for a quick tutorial on configuring high availability (HA) VLANs. Additional
information on how to configure each command is given in the sections that follow.
1 Create a server cluster that will become the HA VLAN by using the command server-cluster and
configure the mode. For example:
-> server-cluster 1 name l2_cluster mode l2
2 Create a default VLAN for the HA VLAN ports with the vlan command as shown below:
-> vlan 10
3 Assign member ports to the new default VLAN with the vlan members untagged command as shown
below:
-> vlan 10 members port 1/3 untagged
-> vlan 10 members port 1/4 untagged
-> vlan 10 members port 1/5 untagged
4 Assign mac-address for the new server cluster by using the command server-cluster mac-address. For
example:
-> server-cluster 1 vlan 10 port 1/3-5 mac-address 01:00:11:22:33:44
Note. Optional. You can display the configuration of high availability VLANs with the show servercluster command. For example:
-> show server-cluster 1
Cluster Id : 1,
Cluster Name : L2-cluster,
Cluster Mode : L2,
Cluster Mac-address : 01:10:11:22:33:44,
Cluster Vlan : 12,
Administrative State: Enabled,
Operational State : Disabled,
Operational Flag : VPA is not forwarding
An example of what these commands look like entered sequentially on the command line:
->
->
->
->
->
->
server-cluster 1 mode L2
vlan 10
vlan 10 members port 1/3
vlan 10 members port 1/4
vlan 10 members port 1/5
server-cluster 1 vlan 10
untagged
untagged
untagged
port 1/3-5 mac-address 01:00:11:22:33:44
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 5-3
Configuring High Availability VLANs
High Availability VLAN Overview
High Availability VLAN Overview
High availability (HA) VLANs send traffic intended for a single destination MAC address to multiple
switch ports. An HA VLAN is configured by creating a standard VLAN and then assigning ports to the
VLAN. Once these types of ports are assigned, the standard VLAN automatically becomes an HA VLAN.
When this occurs, standard VLAN commands no longer apply.
Destination MAC addresses (unicast and multicast) are also assigned to high availability VLANs. These
addresses identify ingress port traffic that the switch will send out on all egress ports that belong to the
same VLAN
In addition to assigning ingress and egress ports, tagging inter-switch link ports with an HA VLAN ID is
allowed. Ingress port traffic destined for an HA VLAN MAC address is sent out on all egress and interswitch link ports that belong to the same VLAN. Traffic forwarded on inter-switch link ports is done so in
accordance with the Spanning Tree state of the port.
A high availability VLAN hosts multiple instances of applications like e-commerce applications, critical
databases, business applications etc and supports redundancy. Each instance may get all the service
requests and based on a shared algorithm, HA VLAN decides on which requests a particular node has to
handle. Apart from service request paths, the nodes are internally connected to share information related to
the service load information, service request data and service availability on other nodes.
The HA VLAN feature on the OmniSwitch provides an elegant and flexible way to connect the server
cluster nodes directly to the ingress network. This involves multicasting the service requests on the
configured ports. The multicast criteria is configurable based on destination MAC and destination IP
address. Egress ports can be statically configured on a server cluster or they can be registered by IGMP
reports. The server cluster feature on the OmniSwitch multicast the incoming packets based on the server
cluster configuration on the ports associated with the server cluster.
High Availability VLAN Operational Mode
There are typically two modes of implementation of server clusters in HA VLAN.
• Layer 2 - The server cluster is attached to a L2 switch on which the frames destined to the cluster MAC
address are to be flooded on all interfaces. For more information see “Example 1: Layer 2 Server
Cluster” on page 5-9
• Layer 3 - The server cluster is attached to a L3 switch on which the frames destined to the server
cluster IP address are to be routed to the server cluster IP and then flooded on all interfaces. For more
information see “Example 2: Layer 3 Server Cluster” on page 5-11.
Note. The L2 mode is currently supported in AOS using the static mac-address command and L3 mode by
the static ARP command.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 5-4
Configuring High Availability VLANs
High Availability VLAN Overview
Traffic Flows in High Availability VLAN
The figure below shows how ingress traffic is handled by high availability VLANs.
OmniSwitch
OmniSwitch 7800
MAC Address:
01:20:da:05:f5:2a
MAC Address:
00:95:2a:05:ff:4a
High
Availability
VLAN
MAC Address:
00:95:2a:05:ff:4a
Ingress
Ports
Egress
Ports
Example of an L2 server cluster - Ingress to Egress Port Flow
In the above example, packets received on the ingress ports that are destined for the high availability
VLAN MAC address are sent out the egress ports that are members of the same VLAN. The MAC address
is virtual to the server cluster, individual servers may have different physical MAC address.Since all three
servers are connected to egress ports, they all receive the ingress port traffic. This provides a high level of
availability in that if one of the server connections goes down, the other connections still forward traffic to
one of the redundant servers.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 5-5
Configuring High Availability VLANs
Configuring High Availability VLANs on a Switch
Configuring High Availability VLANs on a Switch
This section describes how to use the Command Line Interface (CLI) commands to configure high
availability (HA) VLANs on a switch. For a brief tutorial on configuring HA VLANs, see “Quick Steps
for Creating High Availability VLANs” on page 5-3.
When configuring HA VLANs, you must perform the following steps:
1 Create a VLAN. To create a VLAN use the vlan command, which is described in “Creating and
Deleting VLANs” on page 5-6.
2 Assign VLAN member ports. To assign member ports to the VLAN, use the vlan members
untagged command which is described in “Changing the Default VLAN Assignment for a Port” on
page 4-6.
3 Create a server cluster and configure the mode. To create a server cluster and configure the cluster
mode, use the server-cluster command which is described in “Adding and Removing Server Cluster
Ports” on page 5-7.
4 Assign MAC Addresses. To assign MAC addresses to the HA VLAN server cluster, use the server-
cluster mac-address command, which is described in “Assigning and Removing MAC Addresses” on
page 5-8.
Note. Use the show server-cluster command to verify the HA VLAN configuration on the switch. See
“Displaying High Availability VLAN Status” on page 5-16 for more information.
Creating and Deleting VLANs
The following subsections describe how to create and delete a VLAN with the vlan command.
Note. This section provides only a basic description of creating and deleting VLANs. For a complete
description of configuring and monitoring VLANs on a switch, please refer to Chapter 4, “Configuring
VLANs.”
Creating a VLAN
To create a new VLAN use the vlan command by entering vlan followed by the VLAN ID number. For
example, to create a VLAN with a VLAN ID number of 10 enter:
-> vlan 10
You can also specify the administrative status and a name for the VLAN with the vlan command. For
example, to administratively enable (the default) a VLAN when you configure it enter vlan followed by
the VLAN ID number and enable.
For example, to create VLAN 10 and administratively enable it enter:
-> vlan 10 enable
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 5-6
Configuring High Availability VLANs
Configuring High Availability VLANs on a Switch
Deleting a VLAN
To delete a VLAN use the no form of the vlan command by entering no vlan followed by the VLAN’s ID
number. For example, to delete high availability VLAN 10 enter:
-> no vlan 10
Adding and Removing Server Cluster Ports
The following subsections describe how to assign to and remove ingress ports from a high availability
VLAN with the server-cluster port command.
Assigning Ports to a Server Cluster
To assign server cluster ports to a high availability VLAN use the server-cluster port/linkagg command.
For example, to assign port 1/21 to server cluster “1”, enter the commands as:
-> server-cluster 1 port 1/21
To assign linkagg “1” to server cluster “3’, enter the commands as:
-> server-cluster 3 linkagg 1
Removing Ports from a Server Cluster
To remove server cluster ports from a high availability VLAN use the no form of server-cluster port/
linkagg command. For example,
-> no server-cluster 1 port 1/21
-> no server-cluster 3 linkagg 1
Assigning and Modifying Server Cluster Mode
The following subsections describe how to assign to and remove egress ports from a high availability
VLAN with the server-cluster command.
Assigning L2 Mode to a Server Cluster
To assign L2 mode to a high availability VLAN use the server-cluster id command. For example, to
assign “L2” mode to the server cluster “1”, enter the command as:
-> server-cluster 1 mode l2
If you want a name to be assigned along with the cluster mode, enter the commands as:
-> server-cluster 1 name l2_cluster mode l2
Assigning L3 Mode to a Server Cluster
A cluster can be assigned an IP address and an ARP entry mac-address. Each cluster should have a unique
IP-address. IP address is configurable only for L3 clusters.
To assign L3 mode to a high availability VLAN use the server-cluster id command. For example, to
assign “L3” mode to the server cluster “2”, enter the command as:
-> server-cluster 2 mode l3
-> server-cluster 5 port all
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 5-7
Configuring High Availability VLANs
Configuring High Availability VLANs on a Switch
To assign L3 mode to linkaggs, enter the commands as:
-> server-cluster 3 linkagg 1
-> server-cluster 4 linkagg 1-3
To remove server cluster from a high availability VLAN, use the no form of the command. For example,
-> no server-cluster 1
-> no server-cluster 2
Assigning and Removing MAC Addresses
The following subsections describe how to assign and remove MAC addresses from a high availability
VLAN with the server-cluster mac-address command. Traffic that is received on ingress ports that
contains a destination MAC address that matches the high availability VLAN address is sent out all egress
ports that belong to the high availability VLAN.
Assigning MAC Addresses
To assign a MAC address to a high availability VLAN, use the server-cluster mac-address command by
entering server-cluster mac-address, followed by the VLAN’s ID number, mac, and the MAC address.
Note that both unicast and multicast addresses are supported.
For example, to assign the MAC address 00:25:9a:5c:2f:10 to high availability VLAN 20, enter the
command as:
-> server-cluster mac-address vlan 20 mac 00:25:9a:5c:2f:10
To add more than one MAC address to a high availability VLAN, enter each address on the same
command line separated by a space. For example, to assign MAC addresses 00:25:9a:5c:2f:11,
00:25:9a:5c:12, and 01:00:00:3f:4c:10, to high availability VLAN 30, enter the command as:
-> server-cluster mac-address vlan 30 mac 00:25:9a:5c:2f:11 00:25:9a:5c:12
01:00:00:3f:4c:10.
Removing MAC Addresses
To remove a MAC address associated with a high availability VLAN, use the no form of the servercluster mac-address command. For example, the following command removes MAC address
00:25:9a:5c:2f:10 from VLAN 20:
-> no server-cluster mac-address vlan 20 no mac 00:25:9a:5c:2f:10
To remove more than one MAC address from a high availability VLAN using a single command, enter
each address on the same command line separated by a space. For example, to remove MAC addresses
00:25:9a:5c:2f:11, 00:25:9a:5c:12, and 01:00:00:3f:4c:10, from high availability VLAN 30, enter the
command as:
-> server-cluster mac-address vlan 30 no mac 00:25:9a:5c:2f:11 00:25:9a:5c:12
01:00:00:3f:4c:10.
Note. Removing the last MAC address from an HA VLAN is not allowed. Deleting the VLAN is required
when there is only one MAC address left.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 5-8
Configuring High Availability VLANs
Application Examples
Application Examples
This section contains the following HAVLAN application examples:
• “Example 1: Layer 2 Server Cluster” on page 5-9.
• “Example 2: Layer 3 Server Cluster” on page 5-11.
• “Example 3: Layer 3 Server Cluster with IP Multicast Address to Cluster (IGMP)” on page 5-13.
Example 1: Layer 2 Server Cluster
In the following example, the MAC address can be unicast or L2 multicast or IP multicast.
Switch connected to an L2 server cluster through 3 ports (1/3, 1/4, 1/5)
• A server cluster can be configured with a unique MAC address and a VLAN with a port list
• The traffic which ingresses on 1/1 or 1/2 destined to the server cluster MAC address and the VLAN is
forwarded to all the egress ports configured.(1/3,1/4,1/5).
• Here the ingress ports must be in the same VLAN as the server cluster VLAN and egress ports and
other traffic must be switched according to the normal switching logic.
Configuration Example
In this example, a packet can be an L2 or IP switched packet and Egress port can also be a linkagg port.
1 Create a server cluster that will become the HA VLAN by using the command server-cluster and
configure the mode. For example:
-> server-cluster 1 mode l2 admin-state enable
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 5-9
Configuring High Availability VLANs
Application Examples
2 Create a default VLAN for the HA VLAN ports with the vlan command as shown below:
-> vlan 10
3 Assign member ports to the new default VLAN with the vlan members untagged and server-cluster
commands as shown below:
->
->
->
->
->
->
vlan 10 members port 1/3 untagged
vlan 10 members port 1/4 untagged
vlan 10 members port 1/5 untagged
server-cluster 1 port 1/3
server-cluster 1 port 1/4
server-cluster 1 port 1/5
4 Assign mac-address for the new server cluster by using the command server-cluster mac-address. For
example:
-> server-cluster 1 vlan 10 port mac-address 01:00:11:22:33:44
Note. Optional. You can display the configuration of high availability VLANs with the show servercluster command. For example:
-> show server-cluster 1
Cluster Id : 1,
Cluster Name : L2-cluster,
Cluster Mode : L2,
Cluster Mac-address : 01:10:11:22:33:44,
Cluster Vlan : 12,
Administrative State: Enabled,
Operational State : Disabled,
Operational Flag : VPA is not forwarding
An example of what these commands look like entered sequentially on the command line:
->
->
->
->
->
->
->
->
->
server-cluster 1 mode L2 admin-state enable
vlan 10
vlan 10 members port 1/3 untagged
vlan 10 members port 1/4 untagged
vlan 10 members port 1/5 untagged
server-cluster 1 port 1/3
server-cluster 1 port 1/4
server-cluster 1 port 1/5
server-cluster 1 vlan 10 port 1/3-5 mac-address 01:00:11:22:33:44
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 5-10
Configuring High Availability VLANs
Application Examples
Example 2: Layer 3 Server Cluster
In this example, A server cluster is configured with a unique IP address and a static ARP entry (cluster
MAC) and a port list. Here, the server cluster IP address must be a unicast address.
Switch connected to an L3 server cluster through 3 ports (1/3,1/4,1/5)
• The traffic which ingresses on 1/1 or 1/2 destined to the server cluster IP is routed to all the egress
ports configured (1/3,1/4,1/5). The ingress ports are on a different VLAN as the server cluster IP
interface.
• However, all the egress ports need to be in the same VLAN as the IP interface of server cluster. The
other traffic must be switched according to the normal switching/routing logic.
• Egress port can be a linkagg port as well.
Configuration Example
In this example, a packet is an L3 or IP switched packet.
1 Create a server cluster that will become the HA VLAN by using the command server-cluster and
configure the mode. For example:
-> server-cluster 2 mode L3 admin-state enable
2 Create a default VLAN for the HA VLAN ports with the vlan command as shown below:
-> vlan 12
3 Assign member ports to the new default VLAN with the vlan members untagged and server-cluster
commands as shown below:
-> vlan 12 members port 1/3 untagged
-> vlan 12 members port 1/4 untagged
-> vlan 12 members port 1/5 untagged
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 5-11
Configuring High Availability VLANs
Application Examples
-> server-cluster 2 port 1/3
-> server-cluster 2 port 1/4
-> server-cluster 2 port 1/5
4 Assign an IP address for the by using the ip interface command. For example:
-> ip interface "vlan 12"
-> ip interface "vlan 12" address 10.135.33.13/24 vlan 12
5 Assign mac-address for the new server cluster by using the command server-cluster mac-address. For
example:
-> server-cluster 2 ip 10.135.33.12 mac-address static 01:00:5e:22:33:44
Note. Optional. You can display the configuration of high availability VLANs with the show servercluster command. For example:
-> show server-cluster 2
Cluster Id : 2,
Cluster Name : L3-cluster,
Cluster Mode : L3,
Cluster Mac-address : 01:10:11:22:33:44,
Cluster Vlan : 12,
Administrative State: Enabled,
Operational State : Enabled,
Operational Flag : -
An example of what these commands look like entered sequentially on the command line:
->
->
->
->
->
->
->
->
->
->
->
server-cluster 2 mode L3 admin-state enable
vlan 12
vlan 12 members port 1/3 tagged
vlan 12 members port 1/4 tagged
vlan 12 members port 1/5 tagged
server-cluster 2 port 1/3
server-cluster 2 port 1/4
server-cluster 2 port 1/5
ip interface "vlan 12"
ip interface "vlan 12" address 10.135.33.13/24 vlan 12
server-cluster 2 ip 10.135.33.12 mac-address static 01:00:5e:22:33:44
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 5-12
Configuring High Availability VLANs
Application Examples
Example 3: Layer 3 Server Cluster with IP Multicast Address to
Cluster (IGMP)
This example shows that a server cluster can be configured with a unique IP address and a IP multicast
address. For this scenario, the server cluster IP address needs to be a unicast address and the MAC address
(ARP entry) can be unicast or L2 multicast or IP multicast. The MAC address must be configured through
CLI ARP resolution to a server cluster MAC, and must be configured before actual routing
.
Switch connected to an L3 server cluster (IGMP) through 3 ports (1/3,1/4,1/5)
• There is no provision for port list configuration and Ports are derived dynamically using the IGMP
snooping of the reports from the server cluster (IGMP v2 reports).
• The traffic which ingresses on 1/1 or 1/2 destined to the server cluster IP is routed to all the ports
which are members of the IP multicast group of the server cluster.
• The ingress ports is on a different VLAN as the server cluster IP interface. Join and Leave messaged
keep updating the egress port list. However all the egress ports need to be in the same VLAN as the IP
interface of server cluster.
• The other traffic is switched according to the normal switching/routing logic.
• Egress port can be a linkagg port as well.
Note. When a server cluster tries to send a bridged or routed packet to itself, a copy of the packet goes back
to the sender’s (server cluster) port.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 5-13
Configuring High Availability VLANs
Application Examples
Configuration Example
In this example, a packet is an L3 IP switched packet and Egress port can also be a linkagg port.
1 Create a server cluster that will become the HA VLAN by using the command server-cluster and
configure the mode. For example:
-> server-cluster 3 mode L3 admin-state enable
2 Create a default VLAN for the HA VLAN ports with the vlan command as shown below:
-> vlan 12
3 Assign member ports to the new default VLAN with the vlan members untagged and server-cluster
commands as shown below:
->
->
->
->
->
->
vlan 12 members port 1/3 untagged
vlan 12 members port 1/4 untagged
vlan 12 members port 1/5 untagged
server-cluster 3 port 1/3
server-cluster 3 port 1/4
server-cluster 3 port 1/5
4 Assign mac-address for the new server cluster by using the command server-cluster mac-address. For
example:
-> server-cluster 3 ip 10.135.33.12 mac-address static 01:00:11:22:33:44
5 If you want to assign a dynamic mac-address for the server cluster, enter the command as follows:
-> server-cluster 3 ip 10.135.33.12 mac-address dynamic
6 Enable the admin state of the IP multicast by using the ip multicast admin-state enable command. IP
multicast admin state should be enabled for the IGMP reports to be processed., else the cluster will be
operationally down.
-> ip multicast admin-state enable
-> server-cluster 3 igmp-mode enable
-> server-cluster 3 ip-multicast 225.0.0.23
When IGMP mode is enabled for the server cluster, all static ports will be reset in igmp mode.
Note. Optional. You can display the configuration of high availability VLANs with the show servercluster command. For example:
-> show server-cluster 3
Cluster Id
: 3,
Cluster Name
: -,
Cluster Mode
: L3,
Cluster IP
: 10.135.33.12,
Cluster Mac-Address
: 01:00:11:22:33:44,
Cluster Mac Type
: Static,
IGMP-Mode
: Enabled,
Cluster Multicast IP
: 225.0.0.23,
Administrative State
: Enabled,
Operational State
: Disabled,
Operational Flag
: No IGMP members
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 5-14
Configuring High Availability VLANs
Application Examples
An example of what these commands look like entered sequentially on the command line:
->
->
->
->
->
->
->
->
->
->
->
->
server-cluster 3 mode L3 admin-state enable
vlan 12
vlan 12 members port 1/3 untagged
vlan 12 members port 1/4 untagged
vlan 12 members port 1/5 untagged
server-cluster 3 port 1/3
server-cluster 3 port 1/4
server-cluster 3 port 1/5
server-cluster 3 ip 10.135.33.12 mac-address static 01:00:11:22:33:44
ip multicast admin-state enable
server-cluster 3 igmp-mode enable
server-cluster 3 ip-multicast 225.0.0.23
Note. In order to process IGMP reports, it is required to enable IP mulitcast by using the ip multicast
admin-state enable command.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 5-15
Configuring High Availability VLANs
Displaying High Availability VLAN Status
Displaying High Availability VLAN Status
You can use CLI show commands to display the current configuration and statistics of high availability
VLANs on a switch. These commands include the following:
show server-cluster
Displays the server clusters configured in the system.
show vlan
Displays a list of all VLANs configured on the switch and the status of
related VLAN properties (e.g., admin and Spanning Tree status and
router port definitions).
show vlan members
Displays a list of VLAN port assignments.
To display the status and configuration of high availability VLANs you use the show server-cluster
command. To display the status and configuration of all high availability VLANs on a switch, enter the
following command:
-> show server-cluster
A screen similar to the following will be displayed:
-> show server-cluster
Legend: * = not valid
Cluster Mode Vlan Mac Address Ip Address IGMP Address Name
---------+-----+-----+-------------------+---------------+-------------+----------* 10 L2 100 01:10:11:22:33:44
- cluster1
11 L2 100 01:10:11:22:33:44
- cluster2
12 L2 100 01:10:11:22:33:44
- - 13 L3 - 01:12:11:22:33:44 10.135.33.203 - * 14 L3 - 01:12:11:22:33:45 10.135.33.203 -15 L3 - 01:00:5e:00:00:44 10.135.33.203
225.0.1.2 cluster-igmp
To display the status and configuration of a single high availability VLAN cluster enter show servercluster followed by the server cluster ID number. For example, to display the status and configuration of
high availability server cluster id “1”, enter the following command:
-> show server-cluster 1
A screen similar to the following will be displayed:
-> show server-cluster 1
Cluster Id : 1,
Cluster Name : L2-cluster,
Cluster Mode : L2,
Cluster Mac-address : 01:10:11:22:33:44,
Cluster Vlan : 12,
Administrative State: Enabled,
Operational State : Disabled,
Operational Flag : VPA is not forwarding
Note. For more information on the CLI commands, See the OmniSwitch AOS Release 8 CLI Reference
Guide.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 5-16
6
Configuring Spanning Tree
Parameters
The Spanning Tree Algorithm and Protocol (STP) is a self-configuring algorithm that maintains a loopfree topology on a network. STP helps to provide data path redundancy and network scalability. The
OmniSwitch STP implementation, based on the IEEE 802.1D standard, distributes the Spanning Tree load
between the primary management module and the network interface modules. This functionality improves
network robustness by providing a Spanning Tree that continues to respond to BPDUs (Bridge Protocol
Data Unit) and port link up and down states in the event of a fail over to a backup management module or
switch.
The OmniSwitch implementation also incorporates the following Spanning Tree features:
• Configures a physical topology into a single Spanning Tree to ensure that there is only one data path
between any two switches.
• Supports fault tolerance within the network topology. The Spanning Tree is reconfigured in the event
of a data path or bridge failure or when a new switch is added to the topology.
• Supports two Spanning Tree operating modes: flat (single STP instance per switch) and per-VLAN
(single STP instance per VLAN). The per-VLAN mode can be configured to interoperate with the
proprietary Per-Vlan Spanning Tree (PVST+) feature of Cisco.
• Supports three Spanning Tree Algorithms; 802.1D (STP), 802.1w (RSTP), and 802.1Q 2005 (MSTP).
• Allows 802.1Q tagged ports and link aggregate logical ports to participate in the calculation of the STP
topology.
• Provides loop-guard security to prevent network loops caused due to inconsistencies in data traffic.
The Distributed Spanning Tree software is active on all switches by default. As a result, a loop-free
network topology is automatically calculated based on default Spanning Tree bridge, VLAN, and port
parameter values. It is only necessary to configure the Spanning Tree parameters to change how the
topology is calculated and maintained.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-1
Configuring Spanning Tree Parameters
In This Chapter
In This Chapter
This chapter provides an overview about how Spanning Tree works and how to configure Spanning Tree
parameters through the Command Line Interface (CLI). CLI commands are used in the configuration
examples; for more details about the syntax of commands, see the OmniSwitch AOS Release 8 CLI
Reference Guide.
Configuration procedures described in this chapter include:
• Selecting the Spanning Tree operating mode (flat or per-VLAN) on page 6-20.
• Configuring Spanning Tree bridge parameters on page 6-26.
• Configuring Spanning Tree port parameters on page 6-33.
• Configuring an example Spanning Tree topology on page 6-43.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-2
Configuring Spanning Tree Parameters
Spanning Tree Bridge Parameter Defaults
Spanning Tree Bridge Parameter Defaults
Parameter Description
Command
Default
Spanning Tree operating mode
spantree mode
Per-VLAN (a separate Spanning
Tree instance for each VLAN)
PVST+ status
spantree pvst+compatibility
Disabled
Spanning Tree status for a
VLAN instance
spantree vlan admin-state
Enabled
Spanning Tree protocol
spantree protocol
RSTP (802.1w)
BPDU switching status
spantree bpdu-switching
Disabled
Priority value for the Spanning
Tree instance
spantree priority
32768
Hello time interval between each spantree hello-time
BPDU transmission
2 seconds
Maximum aging time allowed
for Spanning Tree information
learned from the network
spantree max-age
20 seconds
Spanning Tree port state
transition time
spantree forward-delay
15 seconds
Path cost mode
spantree path-cost-mode
Auto (16-bit in per-VLAN mode
and STP or RSTP flat mode, 32bit in MSTP flat mode)
Automatic VLAN Containment
spantree auto-vlan-containment
Disabled
Spanning Tree loop-guard
spantree loop-guard
Disabled
Spanning Tree Port Parameter Defaults
Parameter Description
Command
Default
Status for a specific VLAN instance
spantree vlan
Enabled
Path cost for a specific VLAN instance
spantree vlan path-cost
0
Port state management mode
spantree cist mode
spantree loop-guard
Dynamic (Spanning Tree
Algorithm determines port
state)
Port priority value
spantree priority
7
Port connection type for a specific
VLAN instance
spantree vlan connection
auto point to point
Type of BPDU to be used on a port when spantree
per vlan PVST+ mode is enabled
pvst+compatibility
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
auto (IEEE BPDUs are used
until a PVST+ BPDU is
detected)
page 6-3
Configuring Spanning Tree Parameters
Multiple Spanning Tree (MST) Region Defaults
Multiple Spanning Tree (MST) Region Defaults
Although the following parameter values are specific to MSTP, they are configurable regardless of which
mode (flat or per-VLAN) or protocol is active on the switch.
Parameter Description
Command
Default
The MST region name
spantree mst region name
blank
The revision level for the MST region
spantree mst region
revision-level
0
The maximum number of hops
authorized for the region
spantree mst region maxhops
20
The number of Multiple Spanning Tree
Instances (MSTI)
spantree msti
0 (flat mode instance)
The VLAN to MSTI mapping
spantree msti vlan
All VLANs are mapped to the
Common Internal Spanning
Tree (CIST) instance
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-4
Configuring Spanning Tree Parameters
Spanning Tree Overview
Spanning Tree Overview
The OmniSwitch supports the use of the 802.1D Spanning Tree Algorithm and Protocol (STP), the 802.1w
Rapid Spanning Tree Algorithm and Protocol (RSTP), and the 802.1Q 2005 Multiple Spanning Tree
Protocol (MSTP).
RSTP expedites topology changes by allowing blocked ports to transition directly into a forwarding state,
bypassing listening and learning states. This provides rapid reconfiguration of the Spanning Tree in the
event of a network path or device failure.
The 802.1w standard is an amendment to the 802.1D document, thus RSTP is based on STP. Regardless
of which one of these two protocols a switch or VLAN is running, it can successfully interoperate with
other switches or VLANs.
802.1Q 2005 is a new version of MSTP that combines the 802.1D 2004 and 802.1S protocols. This
implementation of 802.1Q 2005 also includes improvements to edge port configuration and provides
administrative control to restrict port role assignment and the propagation of topology change information
through bridge ports.
MSTP is an enhancement to the 802.1Q Common Spanning Tree (CST), which is provided when a switch
is running in the flat Spanning Tree operating mode. The flat mode applies a single spanning tree instance
across all VLAN port connections on a switch. MSTP allows the configuration of Multiple Spanning Tree
Instances (MSTIs) in addition to the CST instance. Each MSTI is mapped to a set of VLANs. As a result,
the flat mode can now support the forwarding of VLAN traffic over separate data paths.
This section provides a Spanning Tree overview based on RSTP operation and terminology. Although
MSTP is based on RSTP, see “MST General Overview” on page 6-12 for specific information about
configuring MSTP.
How the Spanning Tree Topology is Calculated
The tree consists of links and bridges that provide a single data path that spans the bridged network. At the
base of the tree is a root bridge. One bridge is elected by all the bridges participating in the network to
serve as the root of the tree. After the root bridge is identified, STP calculates the best path that leads from
each bridge back to the root and blocks any connections that would cause a network loop.
To determine the best path to the root, STP uses the path cost value, which is associated with every port
on each bridge in the network. This value is a configurable weighted measure that indicates the
contribution of the port connection to the entire path leading from the bridge to the root.
In addition, a root path cost value is associated with every bridge. This value is the sum of the path costs
for the port that receives frames on the best path to the root (this value is zero for the root bridge). The
bridge with the lowest root path cost becomes the designated bridge for the LAN, as it provides the
shortest path to the root for all bridges connected to the LAN.
During the process of calculating the Spanning Tree topology, each port on every bridge is assigned a port
role based on how the port and/or its bridge participates in the active Spanning Tree topology.
The following table provides a list of port role types and the port and/or bridge properties that the
Spanning Tree Algorithm examines to determine which role to assign to the port.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-5
Configuring Spanning Tree Parameters
Spanning Tree Overview
Role
Port/Bridge Properties
Root Port
Port connection that provides the shortest path (lowest path cost value) to the
root. The root bridge does not have a root port.
Designated Port
The designated bridge provides the LAN with the shortest path to the root. The
designated port connects the LAN to this bridge.
Backup Port
Any operational port on the designated bridge that is not a root or designated
port. Provides a backup connection for the designated port. A backup port can
only exist when there are redundant designated port connections to the LAN.
Alternate Port
Any operational port that is not the root port for its bridge and its bridge is not
the designated bridge for the LAN. An alternate port offers an alternate path to
the root bridge if the root port on its own bridge goes down.
Disabled Port
Port is not operational. If an active connection does come up on the port, it is
assigned an appropriate role.
Note. The distinction between a backup port and an alternate port was introduced with the IEEE 802.1w
standard to help define rapid transition of an alternate port to a root port.
The role a port plays or can potentially play in the active Spanning Tree topology determines the port
operating state; discarding, learning, or forwarding. The port state is also configurable and it is possible
to enable or disable the administrative status of a port and/or specify a forwarding or blocking state that is
only changed through user intervention.
The Spanning Tree Algorithm only includes ports in its calculations that are operational (link is up) and
have an enabled administrative status. The following table compares and defines 802.1D and 802.1w port
states and their associated port roles:
STP Port State
RSTP Port State
Port State Definition
Port Role
Disabled
Discarding
Port is down or administratively disabled
and is not included in the topology.
Disabled
Blocking
Discarding
Frames are dropped, nothing is learned or
forwarded on the port. Port is temporarily
excluded from topology.
Alternate, Backup
Learning
Learning
Port is learning MAC addresses that are seen Root, Designated
on the port and adding them to the bridge
forwarding table, but not transmitting any
data. Port is included in the active topology.
Forwarding
Forwarding
Port is transmitting and receiving data and is Root, Designated
included in the active topology.
Once the Spanning Tree is calculated, there is only one root bridge, one designated bridge for each LAN,
and one root port on each bridge (except for the root bridge). Data travels back and forth between bridges
over forwarding port connections that form the best, non-redundant path to the root. The active topology
ensures that network loops do not exist.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-6
Configuring Spanning Tree Parameters
Spanning Tree Overview
Bridge Protocol Data Units (BPDU)
Switches send layer 2 frames, referred to as Configuration Bridge Protocol Data Units (BPDU), to relay
information to other switches. The information in these BPDU is used to calculate and reconfigure the
Spanning Tree topology. A Configuration BPDU contains the following information that pertains to the
bridge transmitting the BPDU:
Root ID
The Bridge ID for the bridge that this bridge believes is the root.
Root Path Cost The sum of the Path Costs that lead from the root bridge to this bridge port.
The Path Cost is a configurable parameter value. The IEEE 802.1D standard specifies a
default value that is based on port speed. See “Configuring Port Path Cost” on
page 6-36 for more information.
Bridge ID
An eight-byte hex value that identifies this bridge within the Spanning Tree. The first
two bytes contain a configurable priority value and the remaining six bytes contain a
bridge MAC address. See “Configuring the Bridge Priority” on page 6-28 for more
information.
Each switch chassis is assigned a dedicated base MAC address. This is the MAC
address that is combined with the priority value to provide a unique Bridge ID for the
switch. For more information about the base MAC address, see the appropriate
Hardware Users Guide for the switch.
Port ID
A 16-bit hex value that identifies the bridge port that transmitted this BPDU. The first 4
bits contain a configurable priority value and the remaining 12 bits contain the physical
switch port number. See “Configuring Port Priority” on page 6-35 for more
information.
The sending and receiving of Configuration BPDU between switches participating in the bridged network
constitute the root bridge election; the best path to the root is determined and then advertised to the rest of
the network. BPDU provide enough information for the STP software running on each switch to determine
the following:
• Which bridge serves as the root bridge.
• The shortest path between each bridge and the root bridge.
• Which bridge serves as the designated bridge for the LAN.
• Which port on each bridge serves as the root port.
• The port state (forwarding or discarding) for each bridge port based on the role the port plays in the
active Spanning Tree topology.
The following events trigger the transmitting and/or processing of BPDU in order to discover and
maintain the Spanning Tree topology:
• When a bridge first comes up, it assumes it is the root and starts transmitting Configuration BPDU on
all its active ports advertising its own bridge ID as the root bridge ID.
• When a bridge receives BPDU on its root port that contains more attractive information (higher
priority parameters and/or lower path costs), it forwards this information on to other LANs to which it
is connected for consideration.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-7
Configuring Spanning Tree Parameters
Spanning Tree Overview
• When a bridge receives BPDU on its designated port that contains information that is less attractive
(lower priority values and/or higher path costs), it forwards its own information to other LANs to
which it is connected for consideration.
STP evaluates BPDU parameter values to select the best BPDU based on the following order of
precedence:
1 The lowest root bridge ID (lowest priority value, then lowest MAC address).
2 The best root path cost.
3 If root path costs are equal, the bridge ID of the bridge sending the BPDU.
4 If the previous three values tie, then the port ID (lowest priority value, then lowest port number).
Topology Change Notification
When a topology change occurs, such as when a link goes down or a switch is added to the network, the
affected bridge sends a Topology Change Notification (TCN) BPDU to the designated bridge for its LAN.
The designated bridge then forwards the TCN to the root bridge. The root then sends out a Configuration
BPDU and sets a Topology Change (TC) flag within the BPDU to notify other bridges that there is a
change in the configuration information. Once this change is propagated throughout the Spanning Tree
network, the root stops sending BPDU with the TC flag set and the Spanning Tree returns to an active,
stable topology.
Note. You can restrict the propagation of TCNs on a port. See “Restricting TCN Propagation” on page 6-42
for more information.
Detecting the Source of Topology Changes
The following information and logging mechanisms are available on each switch to help identify the
source of topology changes within an active network:
• The port on which the last TCN was received on the local switch. The “Topology Change Port” field of
the show spantree vlan, show spantree cist, and show spantree msti commands displays the switch
port on which the last TCN was received. This information can be used to track down the switch that
triggered the topology change in an active RSTP or MSTP topology (not supported for STP
topologies).
• Switch logging entries to identify root port and root bridge changes for all Spanning Tree protocols
(STP, RSTP, and MSTP). For example:
2014 May 19 15:26:44 U28E_7_12_7 swlogd: stpCmm _TRPt info(5) TRAP:newRoot stp=0
2014 May 19 15:39:54 U28E_7_12_7 swlogd: stpCmm _TRPt info(5) TRAP:newRootPort
stp=0 port=101005
For more information about the switch logging utility, see Chapter 36, “Using Switch Logging.”
• Topology change storm detection to identify excessive topology changes for all Spanning Tree
protocols (STP, RSTP, and MSTP). The switch uses internal calculations based on the number of
topology changes within a specific period of time to determine if the number of topology changes
exceeds a specific threshold. When this threshold value is reached, switch logging entries are triggered
as a warning of potential instability within the network. For example:
For Flat + MSTP CIST instance:
2014 May 19 15:26:44 U28E_7_12_7 swlogd: stpCmm _STPt warn(4) TCN Storm detected
on port 1/1/1 for Cist
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-8
Configuring Spanning Tree Parameters
Spanning Tree Overview
For Flat + MSTP MSTI instance
2014 May 19 15:26:44 U28E_7_12_7 swlogd: stpCmm _STPt warn(4) TCN Storm detected
on port 0/10 for Msti 1001
For Flat + RSTP instance:
2014 May 19 15:26:44 U28E_7_12_7 swlogd: stpCmm _STPt warn(4) TCN Storm detected
on port 1/1/1
For Per VLAN + RSTP instance
2014 May 19 15:26:44 U28E_7_12_7 swlogd: stpCmm _STPt warn(4) TCN Storm detected
on port 1/1/1 for VLAN 1001
For more information about the switch logging utility, see Chapter 36, “Using Switch Logging.”
Loop-guard on OmniSwitch
STP relies on continuous reception or transmission of BPDUs based on the port role. The designated port
or primary port transmits BPDUs, and the non-designated ports receive BPDUs. When one of the nondesignated ports in a spanning tree network stop receiving BPDUs, then the STP conceives that the
network is loop free. However, when a non-designated (Alternate, Root, or Backup) port becomes designated and moves to a forwarding state, a loop is created in the network.
With Loop Guard, if a switch stops receiving BPDUs on a non-designated port, the switch places the port
into the STP loop-inconsistent blocking state thus preventing the occurrence of loop in the network.
Loop-guard can be configured on individual ports on per-port or per-VLAN basis. A port can have both
roles:
• Designated
• Non-designated for mutually exclusive set of VLANs or MSTP-instances (in MSTP mode)
If loop-guard is enabled on the port, it does not affect the forward or blocking state for a designated port.
In case of BPDU timeout, if a loop-guard enabled port fails to receive three consecutive BPDUs, STP
converts the port explicitly to a blocked port.
When loop-guard is enabled, if a switch stops receiving BPDUs on a non-designated port, the switch
places the port into the STP loop-inconsistent blocking state.
By default, loop-guard is disabled on all the switch ports. User can configure loop-guard on any port
irrespective of its STP state or role. However, the feature functions only on non-designated (Alternate,
Root, or Backup) STP ports.
Notes:
• In the flat mode, as there is a single STP instance on all the VLANs, the loop-guard state of the ports is
same across all the VLANs on the switch.
• In MSTP mode, there is a single STP instance for each MSTI instance. In this case, loop-guard state of
port is same across all the VLANs of a given MSTP instance. Hence if a loop-guard error occurs on
any single port, it affects all the other ports related to the MSTI.
• In 1X1 mode, there is a single STP instance assigned for each VLAN. Hence if a loop-guard error
occurs on any single VLAN, it does not affect the other VLANs.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-9
Configuring Spanning Tree Parameters
Spanning Tree Overview
Topology Examples
The following diagram shows an example of a physical network topology that incorporates data path
redundancy to ensure fault tolerance. These redundant paths, however, create loops in the network
configuration. If a device connected to Switch A sends broadcast packets, Switch A floods the packets out
all of its active ports. The switches connected to Switch A in turn floods the broadcast packets out their
active ports, and Switch A eventually receives the same packets back and the cycle starts over again. This
causes severe congestion on the network, often referred to as a broadcast storm.
Switch C
Switch D
Switch A
Switch B
Physical Topology Example
The Spanning Tree Algorithm prevents network loops by ensuring that there is always only one active link
between any two switches. This is done by transitioning one of the redundant links into a blocking state,
leaving only one link actively forwarding traffic. If the active link goes down, then the Spanning Tree will
transition one of the blocked links to the forwarding state to take over for the downed link. If a new switch
is added to the network, the Spanning Tree topology is automatically recalculated to include the
monitoring of links to the new switch.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-10
Configuring Spanning Tree Parameters
Spanning Tree Overview
The following diagram shows the logical connectivity of the same physical topology as determined by the
Spanning Tree Algorithm:
Switch C
Switch D
(Root Bridge)
2/3
PC=4
3/8
Bridge ID
10, 00:00:00:00:00:01
Bridge ID
13, 00:00:00:00:00:04
2/2
PC=19
3/9
2/1
3/10
PC=100
PC=19
3/2
2/10
Bridge ID
11, 00:00:00:00:00:02
Bridge ID
12, 00:00:00:00:00:03
PC=19
2/9
Switch A
(Designated Bridge)
Forwarding
Blocking
3/1
Switch B
Root Port
Designated Port
PC
Path Cost
Active Spanning Tree Topology Example
In the above active Spanning Tree topology example, the following configuration decisions were made as
a result of calculations performed by the Spanning Tree Algorithm:
• Switch D is the root bridge because its bridge ID has a priority value of 10 (the lower the priority
value, the higher the priority the bridge has in the Spanning Tree). If all four switches had the same
priority, then the switch with the lowest MAC address in its bridge ID would become the root.
• Switch A is the designated bridge for Switch B, because it provides the best path for Switch B to the
root bridge.
• Port 2/9 on Switch A is a designated port, because it connects the LAN from Switch B to Switch A.
• All ports on Switch D are designated ports, because Switch D is the root and each port connects to a
LAN.
• Ports 2/10, 3/1, and 3/8 are the root ports for Switches A, B, and C, respectively, because they offer the
shortest path towards the root bridge.
• The port 3/9 connection on Switch C to port 2/2 on Switch D is in a discarding (blocking) state, as the
connection these ports provides is redundant (backup) and has a higher path cost value than the 2/3 to
3/8 connection between the same two switches. As a result, a network loop is avoided.
• The port 3/2 connection on Switch B to port 3/10 on Switch C is also in a discarding (blocking) state,
as the connection these ports provides has a higher path cost to root Switch D than the path between
Switch B and Switch A. As a result, a network loop is avoided.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-11
Configuring Spanning Tree Parameters
MST General Overview
MST General Overview
The Multiple Spanning Tree (MST) feature allows for the mapping of one or more VLANs to a single
Spanning Tree instance, referred to as a Multiple Spanning Tree Instance (MSTI), when the switch is
running in the flat Spanning Tree mode. MST uses the Multiple Spanning Tree Algorithm and Protocol
(MSTP) to define the Spanning Tree path for each MSTI. In addition, MSTP provides the ability to group
switches into MST Regions. An MST Region appears as a single, flat Spanning Tree instance to switches
outside the region.
This section provides an overview of the MST feature that includes the following topics:
• “How MSTP Works” on page 6-12.
• “Comparing MSTP with STP and RSTP” on page 6-15.
• “What is a Multiple Spanning Tree Instance (MSTI)” on page 6-15.
• “What is a Multiple Spanning Tree Region” on page 6-16.
• “What is the Internal Spanning Tree (IST) Instance” on page 6-17.
• “What is the Common and Internal Spanning Tree Instance” on page 6-17.
• “MST Configuration Overview” on page 6-17.
How MSTP Works
MSTP, as defined in the IEEE 802.1Q 2005 standard, is an enhancement to the IEEE 802.1Q Common
Spanning Tree (CST). The CST is a single spanning tree that uses 802.1D (STP) or 802.1w (RSTP) to
provide a loop-free network topology.
The OmniSwitch flat spanning tree mode applies a single CST instance on a per switch basis. The perVLAN mode is an OmniSwitch proprietary implementation that applies a single spanning tree instance on
a per VLAN basis. MSTP is only supported in the flat mode and allows for the configuration of additional
Spanning Tree instances instead of just the one CST.
On an MSTP flat mode OmniSwitch, the CST is represented by the Common and Internal Spanning Tree
(CIST) instance 0 and exists on all switches. Up to 17 instances, including the CIST, are supported. Each
additional instance created is referred to as a Multiple Spanning Tree Instance (MSTI). An MSTI
represents a configurable association between a single Spanning Tree instance and a set of VLANs.
Note. Although MSTP provides the ability to define MSTIs while running in the flat mode, port state and
role computations are automatically calculated by the CST algorithm across all MSTIs. However, it is
possible to configure the priority and/or path cost of a port for a particular MSTI so that a port remains in a
forwarding state for an MSTI instance, even if it is blocked as a result of automatic CST computations for
other instances.
The following diagrams help to further explain how MSTP works by comparing how port states are
determined on per-VLAN STP/RSTP mode, flat mode STP/RSTP, and flat mode MSTP switches.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-12
Configuring Spanning Tree Parameters
MST General Overview
VLAN 100
3/1
2/1
4/2
5/1
VLAN 200
4/8
||
VLAN 100
VLAN 200
5/2
Per-VLAN Mode STP/RSTP
In the above per-VLAN mode example:
• Both switches are running in the per-VLAN mode (one Spanning Tree instance per VLAN).
• VLAN 100 and VLAN 200 are each associated with their own Spanning Tree instance.
• The connection between 3/1 and 2/1 is left in a forwarding state because it is part of the VLAN 100
Spanning Tree instance and is the only connection for that instance.
Note. If additional switches containing a VLAN 100 are connected to the switches in this diagram, then the
3/1 to 2/1 port connection gets into blocking state. The port connection is converted to blocking state, only
if the VLAN 100 Spanning Tree instance determines it is required, to avoid a network loop.
• The connections between 4/8 and 5/2 and 4/2 and 5/1 are seen as redundant because they are both
controlled by the VLAN 200 Spanning Tree instance and connect to the same switches. The VLAN
200 Spanning Tree instance determines which connection provides the best data path and transitions
the other connection to a blocking state.
VLAN 100
3/1
4/2
VLAN 200
4/8
2/1
||
||
VLAN 100
5/1
VLAN 200
5/2
Flat Mode STP/RSTP (802.1D/802.1w)
In the above flat mode STP/RSTP example:
• Both switches are running in the flat mode. As a result, a single flat mode Spanning Tree instance
applies to the entire switch and compares port connections across VLANs to determine which
connection provides the best data path.
• The connection between 3/1 and 2/1 is left forwarding because the flat mode instance determined that
this connection provides the best data path between the two switches.
• The 4/8 to 5/2 connection and the 4/2 to 5/1 connection are considered redundant connections so they
are both blocked in favor of the 3/1 to 2/1 connection.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-13
Configuring Spanning Tree Parameters
VLAN 100
MST General Overview
3/1
2/1
4/2
||
5/1
||
5/2
||
3/6
VLAN 100
CIST-0
CIST-0
VLAN 150
VLAN 200
4/8
VLAN 150
VLAN 200
MSTI-2
MSTI-2
VLAN 250
2/12
VLAN 250
Flat Mode MSTP
In the above flat mode MSTP example:
• Both switches are running in the flat mode and using MSTP.
• VLANs 100 and 150 are not associated with an MSTI. They are controlled by the default CIST
instance 0 that exists on every switch.
• VLANs 200 and 250 are associated with MSTI 2 so their traffic can traverse a path different from that
determined by the CIST.
• Ports are blocked the same way they were blocked in the flat mode STP/RSTP example; all port
connections are compared to each other across VLANs to determine which connection provides the
best path.
However, because VLANs 200 and 250 are associated to MSTI 2, it is possible to change the port path
cost for ports 2/12, 3/6, 4/8 and/or 5/2 so that they provide the best path for MSTI 2 VLANs, but do not
carry CIST VLAN traffic or cause CIST ports to transition to a blocking state.
Another alternative is to assign all VLANs to an MSTI, leaving no VLANs controlled by the CIST. As
a result, the CIST BPDU contains only MSTI information.
See “Sample MSTI Configuration” on page 6-48 for more information about how to direct VLAN traffic
over separate data paths using MSTP.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-14
Configuring Spanning Tree Parameters
MST General Overview
Comparing MSTP with STP and RSTP
Using MSTP has the following items in common with STP (802.1D) and RSTP (802.1w) protocols:
• Each protocol ensures one data path between any two switches within the network topology. This
prevents network loops from occurring while at the same time allowing for redundant path
configuration.
• Each protocol provides automatic reconfiguration of the network Spanning Tree topology in the event
of a connection failure and/or when a switch is added to or removed from the network.
• All three protocols are supported in the flat Spanning Tree operating mode.
• The flat mode CST instance automatically determines port states and roles across VLAN port and
MSTI associations. This is because the CST instance is active on all ports and only one BPDU is used
to forward information for all MSTIs.
• MSTP is based on RSTP.
Using MSTP differs from STP and RSTP as follows:
• MSTP is only supported when the switch is running in the flat Spanning Tree mode. STP and RSTP
are supported in both the per-VLAN and flat modes.
• MSTP allows for the configuration of up to 16 Multiple Spanning Tree Instances (MSTI) in addition to
the CST instance. Flat mode STP and RSTP protocols only use the single CST instance for the entire
switch. See “What is a Multiple Spanning Tree Instance (MSTI)” on page 6-15 for more information.
• MSTP applies a single Spanning Tree instance to an MSTI ID number that represents a set of VLANs;
a one to many association. STP and RSTP in the flat mode apply one Spanning Tree instance to all
VLANs; a one to all association. STP and RSTP in the per-VLAN mode apply a single Spanning Tree
instance to each existing VLAN; a one to one association.
• The port priority and path cost parameters are configurable for an individual MSTI that represents the
VLAN associated with the port.
• The flat mode 802.1D or 802.1w CST is identified as instance 1. When using MSTP, the CST is
identified as CIST (Common and Internal Spanning Tree) instance 0. See “What is the Common and
Internal Spanning Tree Instance” on page 6-17 for more information.
• MSTP allows the segmentation of switches within the network into MST regions. Each region is seen
as a single virtual bridge to the rest of the network, even though multiple switches can belong to the
one region. See “What is a Multiple Spanning Tree Region” on page 6-16 for more information.
• MSTP has lower overhead than a per-VLAN configuration. In per-VLAN mode, because each VLAN
is assigned a separate Spanning Tree instance, BPDUs are forwarded on the network for each VLAN.
MSTP only forwards one BPDU for the CST that contains information for all configured MSTI on the
switch.
What is a Multiple Spanning Tree Instance (MSTI)
An MSTI is a single Spanning Tree instance that represents a group of VLANs. The OmniSwitch supports
up to 16 MSTIs on one switch. This number is in addition to the Common and Internal Spanning Tree
(CIST) instance 0, which is also known as MSTI 0. The CIST instance exists on every switch. By default,
all VLANs not mapped to an MSTI are associated with the CIST instance. See “What is the Common and
Internal Spanning Tree Instance” on page 6-17 for more information.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-15
Configuring Spanning Tree Parameters
MST General Overview
What is a Multiple Spanning Tree Region
A Multiple Spanning Tree region represents a group of MSTP switches. An MST region appears as a
single, flat mode instance to switches outside the region. A switch can belong to only one region at a time.
The region a switch belongs to is identified by the following configurable attributes, as defined by MSTP.
• Region name – An alphanumeric string up to 32 characters.
• Region revision level – A numerical value between 0 and 65535.
• VLAN to MSTI table – Generated when VLANs are associated with MSTIs. Identifies the VLAN to
MSTI mapping for the switch.
Switches that share the same values for the configuration attributes described above belong to the same
region. For example, in the diagram below:
• Switches A, B, and C all belong to the same region because they all are configured with the same
region name, revision level, and have the same VLANs mapped to the same MSTI.
• The CST for the entire network sees Switches A, B, and C as one virtual bridge that is running a single
Spanning Tree instance. As a result, CST blocks the path between Switch C and Switch E instead of
blocking a path between the MST region switches to avoid a network loop.
• The paths between Switch A and Switch C and the redundant path between Switch B and Switch C
were blocked as a result of the Internal Spanning Tree (IST) computations for the MST Region. See
“What is the Internal Spanning Tree (IST) Instance” on page 6-17 for more information.
Switch D
Switch A
||
IST
CST
||
||
Switch B
Switch C
MST Region
Switch E
SST Switches (STP or RSTP)
In addition to the attributes described above, the MST maximum hops parameter defines the number of
bridges authorized to propagate MST BPDU information. In essence, this value defines the size of the
region in that once the maximum number of hops is reached, the BPDU is discarded.
The maximum number of hops for the region is not one of the attributes that defines membership in the
region. See “Sample MST Region Configuration” on page 6-46 for a tutorial on how to configure MST
region parameters.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-16
Configuring Spanning Tree Parameters
MST General Overview
What is the Common Spanning Tree
The Common Spanning Tree (CST) is the overall network Spanning Tree topology resulting from STP,
RSTP, and/or MSTP calculations to provide a single data path through the network. The CST provides
connectivity between MST regions and other MST regions and/or Single Spanning Tree (SST) switches.
For example, in the above diagram, CST calculations detected a network loop created by the connections
between Switch D, Switch E, and the MST Region. As a result, one of the paths was blocked.
What is the Internal Spanning Tree (IST) Instance
The IST instance determines and maintains the CST topology between MST switches that belong to the
same MST region. In other words, the IST is simply a CST that only applies to MST Region switches
while at the same time representing the region as a single Spanning Tree bridge to the network CST.
As shown in the above diagram, the redundant path between Switch B and Switch C is blocked and the
path between Switch A and Switch C is blocked. These blocking decisions were based on the IST
computations within the MST region. IST sends and receives BPDU to/from the network CST. MSTI
within the region do not communicate with the network CST. As a result, the CST only sees the IST
BPDU and treats the MST region as a single Spanning Tree bridge.
What is the Common and Internal Spanning Tree Instance
The Common and Internal Spanning Tree (CIST) instance is the Spanning Tree calculated by the MST
region IST and the network CST. The CIST is represented by the single Spanning Tree flat mode instance
that is available on all switches. By default, all VLANs are associated to the CIST until they are mapped
to an MSTI.
When using STP (802.1D) or RSTP (802.1w). When using MSTP, the CIST is also known as instance 0 or
MSTI 0.
Note. When MSTP is the active flat mode protocol, explicit Spanning Tree bridge commands are required
to configure parameter values. Implicit commands are for configuring parameters when the STP or RSTP
protocols are in use. See “Using Spanning Tree Configuration Commands” on page 6-26 for more
information.
MST Configuration Overview
The following general steps are required to set up a Multiple Spanning Tree (MST) configuration:
• Select the flat Spanning Tree mode – Each switch runs in the default mode. MSTP is only supported
on a flat mode switch. See “Spanning Tree Operating Modes” on page 6-20 for more information.
• Select the MSTP protocol – Each switch uses the default protocol. Selecting MSTP activates the
Multiple Spanning Tree. See “How MSTP Works” on page 6-12 for more information.
• Configure an MST region name and revision level – Switches that share the same MST region
name, revision level, and VLAN to Multiple Spanning Tree Instance (MSTI) mapping belong to the
same MST region. See “What is a Multiple Spanning Tree Region” on page 6-16 for more information.
• Configure MSTIs – Every switch has a default Common and Internal Spanning Tree (CIST) instance
0, which is also referred to as MSTI 0. Configuration of additional MSTI is required to segment switch
VLANs into separate instances. See “What is a Multiple Spanning Tree Instance (MSTI)” on page 6-15
for more information.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-17
Configuring Spanning Tree Parameters
MST General Overview
• Map VLANs to MSTI – All existing VLANs are mapped to the default CIST instance 0. Associating
a VLAN to an MSTI specifies which Spanning Tree instance determines the best data path for traffic
carried on the VLAN. In addition, the VLAN-to-MSTI mapping is also one of three MST
configuration attributes used to determine that the switch belongs to a particular MST region.
For a tutorial on setting up an example MST configuration, see “Sample MST Region Configuration” on
page 6-46 and “Sample MSTI Configuration” on page 6-48.
MST Interoperability and Migration
Connecting an MSTP switch to a non-MSTP flat mode switch is supported. Since the Common and
Internal Spanning Tree (CIST) controls the flat mode instance on both switches, STP or RSTP can remain
active on the non-MSTP switch within the network topology.
An MSTP switch is part of a Multiple Spanning Tree (MST) Region, which appears as a single, flat mode
instance to the non-MSTP switch. The port that connects the MSTP switch to the non-MSTP switch is
referred to as a boundary port. When a boundary port detects an STP (802.1D) or RSTP (802.1w) BPDU,
it responds with the appropriate protocol BPDU to provide interoperability between the two switches. This
interoperability also serves to indicate the edge of the MST region.
Interoperability between MSTP switches and per-VLAN mode switches is not recommended. The perVLAN mode is a proprietary implementation that creates a separate Spanning Tree instance for each
VLAN configured on the switch. The MSTP implementation is in compliance with the IEEE standard and
is only supported on flat mode switches.
Tagged BPDUs transmitted from a per-VLAN switch are ignored by a flat mode switch. This can cause a
network loop to go undetected. Although it is not recommended, you can also connect a per-VLAN switch
to a flat mode switch temporarily until migration to MSTP is complete. When a per-VLAN switch is
connected to a flat mode switch, configure only a fixed, untagged connection between VLAN 1 on both
switches.
Migrating from Flat Mode STP/RSTP to Flat Mode MSTP
Migrating an STP/RSTP flat mode switch to MSTP is relatively transparent. When STP or RSTP is the
active protocol, the Common and Internal Spanning Tree (CIST) controls the flat mode instance. If on the
same switch the protocol is changed to MSTP, the CIST still controls the flat mode instance.
Note the following when converting a flat mode STP/RSTP switch to MSTP:
• Making a backup copy of the switch boot.cfg file before changing the protocol to MSTP is highly
recommended. Having a backup copy makes it easier to revert to the non-MSTP configuration. Once
MSTP is active, commands are written in their explicit form and not compatible with previous releases
of Spanning Tree.
• When converting multiple switches, change the protocol to MSTP first on every switch before starting
to configure Multiple Spanning Tree Instances (MSTI).
• Once the protocol is changed, MSTP features are available for configuration. Multiple Spanning Tree
Instances (MSTI) are now configurable for defining data paths for VLAN traffic. See “How MSTP
Works” on page 6-12 for more information.
• Using explicit Spanning Tree commands to define the MSTP configuration is required. Implicit
commands are for configuring STP and RSTP. See “Using Spanning Tree Configuration Commands”
on page 6-26 for more information.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-18
Configuring Spanning Tree Parameters
MST General Overview
• STP and RSTP use a 16-bit port path cost (PPC) and MSTP uses a 32-bit PPC. When the protocol is
changed to MSTP, the bridge priority and PPC values for the flat mode CIST instance are reset to their
default values.
• It is possible to configure the switch to use 32-bit PPC value for all protocols (see the spantree path-
cost-mode command page for more information). If this is the case, then the PPC for the CIST is not
reset when the protocol is changed to/from MSTP.
• This implementation of MSTP is compliant with the IEEE 802.1Q 2005 standard and thus provides
interconnectivity with MSTP compliant systems.
Migrating from Per-VLAN Mode to Flat Mode MSTP
As previously described, the per-VLAN mode is an OmniSwitch proprietary implementation that applies
one Spanning Tree instance to each VLAN. For example, if five VLANs exist on the switch, then their are
five Spanning Tree instances active on the switch, unless Spanning Tree is disabled on one of the VLANs.
Note the following when converting a per-VLAN mode STP/RSTP switch to flat mode MSTP:
• Making a backup copy of the switch boot.cfg file before changing the protocol to MSTP is highly
recommended. Having a backup copy makes it easier to revert to the non-MSTP configuration. Once
MSTP is active, commands are written in their explicit form and not compatible with previous releases
of Spanning Tree.
• Using MSTP requires changing the switch mode from per-VLAN to flat. When the mode is changed
from per-VLAN to flat, ports still retain their VLAN associations but are now part of a single, flat
mode Spanning Tree instance that spans across all VLANs. As a result, a path that was forwarding
traffic in the per-VLAN mode transitions to a blocking state after the mode is changed to flat.
• Once the protocol is changed, MSTP features are available for configuration. Multiple Spanning Tree
Instances (MSTI) are now configurable for defining data paths for VLAN traffic. See “How MSTP
Works” on page 6-12 for more information.
• Note that STP/RSTP use a 16-bit port path cost (PPC) and MSTP uses a 32-bit PPC. When the
protocol is changed to MSTP, the bridge priority and PPC values for the flat mode CIST instance are
reset to their default values.
• It is possible to configure the switch to use 32-bit PPC value for all protocols (see the spantree path-
cost-mode command page for more information). If this is the case, then the PPC for the CIST is not
reset when the protocol is changed to/from MSTP.
• This implementation of MSTP is compliant with the IEEE 802.1Q 2005 standard and thus provides
interconnectivity with MSTP compliant systems.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-19
Configuring Spanning Tree Parameters
Spanning Tree Operating Modes
Spanning Tree Operating Modes
The switch can operate in one of two Spanning Tree modes: flat and per-VLAN. Both modes apply to the
entire switch and determine whether a single Spanning Tree instance is applied across multiple VLANs
(flat mode) or a single instance is applied to each VLAN (per-VLAN mode). A switch runs on the default
mode when it is first turned on.
Use the spantree mode command to select the Flat or Per-VLAN Spanning Tree mode.The switch
operates in one mode or the other, however, it is not necessary to reboot the switch when changing modes.
Using Flat Spanning Tree Mode
Before selecting the flat Spanning Tree mode, consider the following:
• If STP (802.1D) is the active protocol, then there is one Spanning Tree instance for the entire switch;
port states are determined across VLANs. If MSTP (802.1s) is the active protocol, then multiple
instances up to a total of 17 are allowed. Port states, however, are still determined across VLANs.
• Multiple connections between switches are considered redundant paths even if they are associated with
different VLANs.
• Spanning Tree parameters are configured for the single flat mode instance. For example, if Spanning
Tree is disabled on VLAN 1, then it is disabled for all VLANs. Disabling STP on any other VLAN,
however, only exclude ports associated with that VLAN from the Spanning Tree Algorithm.
• Fixed (untagged) and 802.1Q tagged ports are supported in each VLAN. BPDU, however, are always
untagged.
• When the Spanning Tree mode is changed from per-VLAN to flat, ports still retain their VLAN
associations but are now part of a single Spanning Tree instance that spans across all VLANs. As a
result, a path that was forwarding traffic in the per-VLAN mode can transition to a blocking state after
the mode is changed to flat.
To change the Spanning Tree operating mode to flat, enter the following command:
-> spantree mode flat
The following diagram shows a flat mode switch with STP (802.1D) as the active protocol. All ports,
regardless of their default VLAN configuration or tagged VLAN assignments, are considered part of one
Spanning Tree instance. To see an example of a flat mode switch with MSTP (802.1s) as the active
protocol, see “MST General Overview” on page 6-12.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-20
Configuring Spanning Tree Parameters
Spanning Tree Operating Modes
Flat STP
Switch
Port 8/3
Default VLAN 2
Port 1/2
Default VLAN 5
VLAN 10 (tagged)
Port 10/5
Default VLAN 20
Port 2/5
Default VLAN 5
VLAN 6 (tagged)
Flat Spanning Tree Example
In the above example, if port 8/3 connects to another switch and port 10/5 connects to that same switch,
the Spanning Tree Algorithm would detect a redundant path and transition one of the ports into a blocking
state. The same holds true for the tagged ports.
Using Per-VLAN Spanning Tree Mode
Before selecting the Per-VLAN Spanning Tree operating mode, consider the following:
• A single Spanning Tree instance is enabled for each VLAN configured on the switch. For example, if
there are five VLANs configured on the switch, then there are five separate Spanning Tree instances,
each with its own root VLAN. In essence, a VLAN is a virtual bridge. The VLAN has its own bridge
ID and configurable STP parameters, such as protocol, priority, hello time, max age, and forward
delay.
• Port state is determined on a per VLAN basis. For example, port connections in VLAN 10 are only
examined for redundancy within VLAN 10 across all switches. If a port in VLAN 10 and a port in
VLAN 20 both connect to the same switch within their respective VLANs, they are not considered
redundant data paths and STP does not block them. However, if two ports within VLAN 10 both
connect to the same switch, then the STP transition one of these ports to a blocking state.
• Fixed (untagged) ports participate in the single Spanning Tree instance that applies to their configured
default VLAN.
• 802.1Q tagged ports participate in an 802.1Q Spanning Tree instance that allows the Spanning Tree to
extend across tagged VLANs. As a result, a tagged port can participate in more than one Spanning Tree
instance; one for each VLAN that the port carries.
• If a VLAN contains both fixed and tagged ports, then a hybrid of the two Spanning Tree instances
(single and 802.1Q) is applied. If a VLAN appears as a tag on a port, then the BPDU for that VLAN
are also tagged. However, if a VLAN appears as the configured default VLAN for the port, then BPDU
are not tagged and the single Spanning Tree instance applies.
To change the Spanning Tree operating mode to per-VLAN, enter the following command:
-> spantree mode per-vlan
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-21
Configuring Spanning Tree Parameters
Spanning Tree Operating Modes
The following diagram shows a switch running in the per-VLAN Spanning Tree mode and shows
Spanning Tree participation for both fixed and tagged ports.
STP 2
STP 3
STP 4
Switch
Port 1/5
Default VLAN 10
VLAN 2 (tagged)
Port 1/3
Default VLAN 5
Port 2/5
Default VLAN 2
VLAN 10 (tagged)
Port 2/3
Default VLAN 5
Port 1/4
Default VLAN 2
Port 2/4
Default VLAN 2
Per VLAN (single and 802.1Q) Spanning Tree Example
In the above example, STP2 is a single Spanning Tree instance since VLAN 5 contains only fixed ports.
STP 3 and STP 4 are a combination of single and 802.1Q Spanning Tree instances because VLAN 2
contains both fixed and tagged ports. On ports where VLAN 2 is the default VLAN, BPDU are not tagged.
on ports where VLAN 2 is a tagged VLAN, BPDU are also tagged.
Using Per-VLAN Spanning Tree Mode with PVST+
In order to interoperate with Cisco's proprietary Per Vlan Spanning Tree (PVST+) mode, the OmniSwitch
per-VLAN Spanning Tree mode allows OmniSwitch ports to transmit and receive either the standard
IEEE BPDUs or Cisco's proprietary PVST+ BPDUs. When the PVST+ mode is enabled, a user port
operates in the default mode initially until it detects a PVST+ BPDU, which automatically enables the port
to operate in the Cisco PVST+ compatible mode.
The PVST+ compatibility mode allows OmniSwitch ports to operate in the per-VLAN mode when
connected to another OmniSwitch or in the Cisco PVST+ mode when connected to a Cisco switch. As a
result, both the OmniSwitch per-VLAN and Cisco PVST+ modes can co-exist on the same OmniSwitch
and interoperate correctly with a Cisco switch using the standard Spanning Tree protocols (STP or RSTP).
Note. In the flat Spanning Tree mode, both the OmniSwitch and Cisco switches can interoperate seamlessly
using the standard MSTP protocol.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-22
Configuring Spanning Tree Parameters
Spanning Tree Operating Modes
OmniSwitch PVST+ Interoperability
Native VLAN and OmniSwitch Default VLAN
Cisco uses the standard IEEE BPDU format for the native VLAN (VLAN 1) over an 802.1Q trunk. Thus,
by default the Common Spanning Tree (CST) instance of the native VLAN 1 for all Cisco switches and
the STP instance for the default VLAN of a port on an OmniSwitch interoperates and successfully creates
a loop-free topology.
802.1Q Tagged VLANs
For 802.1Q tagged VLANs, Cisco uses a proprietary frame format which differs from the standard IEEE
BPDU format used by the OmniSwitch per-VLAN mode, thus preventing Spanning Tree topologies for
tagged VLANs from interoperating over the 802.1Q trunk.
In order to interoperate with Cisco PVST+ mode, the current OmniSwitch per-VLAN mode has an option
to recognize Cisco's proprietary PVST+ BPDUs. This allows any user port on an OmniSwitch to send and
receive PVST+ BPDUs, so that loop-free topologies for the tagged VLANs can be created between
OmniSwitch and Cisco switches.
Configuration Overview
The spantree pvst+compatibility command is used to enable or disable the PVST+ interoperability mode
globally for all switch ports and link aggregates or on a per-port/link aggregate basis. By default, PVST+
compatibility is disabled.
To globally enable or disable PVST+ interoperability, enter the following commands:
-> spantree pvst+compatibility enable
-> spantree pvst+compatibility disable
To enable or disable PVST+ interoperability for a specific port or link aggregate, use the spantree
pvst+compatibility command with the port or linkagg parameter. For example:
->
->
->
->
spantree
spantree
spantree
spantree
pvst+compatibility
pvst+compatibility
pvst+compatibility
pvst+compatibility
port 1/3 enable
port 2/24 disable
linkagg 3 enable
linkagg 10 disable
The following causes a port to exit from the enabled state:
• The link status of the port changes.
• The administrative status of the port changes.
• The PVST+ status of the port is disabled or set to auto.
To configure a port or link aggregate to automatically detect
The spantree pvst+compatibility command also provides an auto option to configure the port to handle
IEEE BPDUs initially (i.e., disable state). Once a PVST+ BPDU is received, it handles the PVST+
BPDUs and IEEE BPDUs for a Cisco native VLAN. For example:
-> spantree pvst+compatibility port 1/3 auto
-> spantree pvst+compatibility linkagg 3 auto
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-23
Configuring Spanning Tree Parameters
Spanning Tree Operating Modes
The following show command displays the PVST+ status.
-> show spantree mode
Spanning Tree Global Parameters
Current Running Mode : per-vlan,
Current Protocol
: N/A (Per VLAN),
Path Cost Mode
: 32 BIT,
Auto Vlan Containment : N/A
Cisco PVST+ mode
: Enabled
Vlan Consistency check: Disabled
BPDU Processing in PVST+ Mode
An OmniSwitch port operating in PVST+ mode processes BPDUs as follows:
If the default VLAN of a port is VLAN 1 then:
• Send and receive IEEE untagged BPDUs for VLAN 1
• Don't send and receive PVST+ tagged BPDUs for VLAN 1
• Send and receive tagged PVST+ BPDUs for other tagged VLANs.
If the default VLAN of a port is not VLAN 1 then:
• Send and receive IEEE untagged BPDUs for VLAN 1
• Don't send and receive PVST+ tagged BPDUs for VLAN 1
• Send and receive untagged PVST+ BPDUs for the port's default VLAN
• Send and receive tagged PVST+ BPDUs for other tagged VLANs
Recommendations and Requirements for PVST+ Configurations
• It is mandatory that all the Cisco switches have the MAC Reduction Mode feature enabled in order to
interoperate with an OmniSwitch in PVST+ mode. This avoids any unexpected election of a root
bridge.
• You can assign the priority value only in the multiples of 4096 to be compatible with the Cisco MAC
Reduction mode; any other values result in an error message. Also, the existing per vlan priority values
are restored when changing from PVST+ mode back to per-VLAN mode. For more information on
priority, refer to “Configuring the Bridge Priority” on page 6-28.
• In a mixed OmniSwitch and Cisco environment, it is highly recommended to enable PVST+ mode on
all OmniSwitches in order to maintain the same root bridge for the topology. It is possible that the new
root bridge might be elected as a result of inconsistencies of MAC reduction mode when connecting an
OmniSwitch that does not support Cisco PVST+ mode to an OmniSwitch with the PVST+ mode
enabled. In this case, the root bridge priority must be changed manually to maintain the same root
bridge. For more information on priority, refer to “Configuring the Bridge Priority” on page 6-28.
• A Cisco switch running in PVST mode (another Cisco proprietary mode prior to 802.1q standard) is
not compatible with an OmniSwitch running in per-VLAN PVST+ mode.
• Both Cisco and OmniSwitch support two default path cost modes; long or short. It is recommended
that the same default path cost mode be configured in the same way on all switches so that the path
costs for similar interface types are consistent when connecting ports between OmniSwitch and Cisco
Switches. For more information on path cost mode, refer to “Configuring the Path Cost Mode” on
page 6-31.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-24
Configuring Spanning Tree Parameters
Spanning Tree Operating Modes
• Dynamic aggregate link (LACP) functions properly between OmniSwitch and Cisco switches. The
Cisco switches send the BPDUs only on one physical link of the aggregate, similar to the OmniSwitch
Primary port functionality. The path cost assigned to the aggregate link is not the same between
OmniSwitch and Cisco switches since vendor-specific formulas are used to derive the path cost.
Manual configuration is recommended to match the Cisco path cost assignment for an aggregate link.
For more information on the configuration of path cost for aggregate links, refer to “Path Cost for Link
Aggregate Ports” on page 6-38.
The table below shows the default Spanning Tree values.
Parameters
OmniSwitch
Cisco
Mac Reduction Mode
Enabled
Disabled
Bridge Priority
32768
32768
Port Priority
128
32 (catOS) / 128 (IOS)
Port Path Cost
IEEE Port Speed Table
IEEE Port Speed Table
Aggregate Path Cost
Proprietary Table
Avg Path Cost / NumPorts
Default Path Cost Mode
Short (16-bit)
Short (16-bit)
Max Age
20
20
Hello Time
2
2
Forward Delay Time
15
15
Default Protocol
RSTP (1w) Per Vlan
PVST+ (1d) Per Switch
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-25
Configuring Spanning Tree Parameters
Using Spanning Tree Configuration Commands
Using Spanning Tree Configuration Commands
The OmniSwitch Spanning Tree implementation uses commands that contain one of the following
keywords to specify the type of Spanning Tree instance to modify:
• cist – command applies to the Common and Internal Spanning Tree instance. The CIST is the single
Spanning Tree flat mode instance that is available on all switches. When using STP or RSTP, the CIST
is also known as instance 1 or bridge 1.
• msti – command applies to the specified Multiple Spanning Tree Instance. When using MSTP
(802.1s), the CIST instance is also known as MSTI 0.
• vlan – command applies to the specified VLAN instance.
These commands (referred to as explicit commands) allow the configuration of a particular Spanning Tree
instance independent of which mode and/or protocol is currently active on the switch. The configuration,
however, does not go active until the switch is changed to the appropriate mode. For example, if the
switch is running in the per-VLAN mode, the following explicit command changes the MSTI 3 priority to
12288:
-> spantree msti 3 priority 12288
Even though the above command is accepted in the per-VLAN mode, the new priority value does not take
effect until the switch mode is changed to flat mode.
Note. When a snapshot is taken of the switch configuration, the explicit form of all Spanning Tree
commands is captured. For example, if the priority of MSTI 2 was changed from the default value to a
priority of 16384, then spantree msti 2 priority 16384 is the command captured to reflect this in the
snapshot file. In addition, explicit commands are captured for both flat and per-VLAN mode
configurations.
Configuring STP Bridge Parameters
The Spanning Tree software is active on all switches by default and uses default bridge and port parameter
values to calculate a loop free topology. It is only necessary to configure these parameter values if it is
necessary to change how the topology is calculated and maintained.
Note the following when configuring Spanning Tree bridge parameters:
• When a switch is running in the per-VLAN Spanning Tree mode, each VLAN is in essence a virtual
bridge with its own Spanning Tree instance and configurable bridge parameters.
• When the switch is running in the flat mode and STP (802.1D) or RSTP (802.1w) is the active
protocol, bridge parameter values are only configured for the flat mode instance.
• If MSTP (802.1s) is the active protocol, then the priority value is configurable for each Multiple
Spanning Tree Instance (MSTI). All other parameters, however, are still only configured for the flat
mode instance and are applied across all MSTIs.
• Bridge parameter values for a VLAN instance are not active unless Spanning Tree is enabled on the
VLAN and at least one active port is assigned to the VLAN. Use the spantree vlan admin-state
command to enable or disable a VLAN Spanning Tree instance.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-26
Configuring Spanning Tree Parameters
Configuring STP Bridge Parameters
• If Spanning Tree is disabled on a VLAN, active ports associated with that VLAN are excluded from
Spanning Tree calculations and remain in a forwarding state.
• Note that when a switch is running in the flat mode, disabling Spanning Tree on VLAN 1 disables the
instance for all VLANs and all active ports are then excluded from any Spanning Tree calculations and
remain in a forwarding state.
The following is a summary of Spanning Tree bridge configuration commands. For more information
about these commands, see the OmniSwitch AOS Release 8 CLI Reference Guide.
Commands
Used for ...
spantree protocol
Configuring the protocol for the flat mode CIST instance or a perVLAN mode VLAN instance.
spantree priority
Configuring the priority value for the flat mode CIST instance, a
Multiple Spanning Tree Instance (MSTI), or a per-VLAN mode
VLAN instance.
spantree hello-time
Configuring the hello time value for the flat mode CIST instance or
a per-VLAN mode VLAN instance.
spantree max-age
Configuring the maximum age time value for the flat mode CIST
instance or a per-VLAN mode VLAN instance.
spantree forward-delay
Configuring the forward delay time value for the flat mode CIST
instance or a per-VLAN mode VLAN instance.
spantree bpdu-switching
Configuring the BPDU switching status for a VLAN.
spantree path-cost-mode
Configuring the automatic selection of a 16-bit path cost for STP/
RSTP ports and a 32-bit path cost for MSTP ports or sets all path
costs to use a 32-bit value.
spantree auto-vlancontainment
Enables or disables Auto VLAN Containment (AVC) for 802.1s
instances.
spantree pvst+compatibility
Enables or disables PVST+ mode on the switch.
The following sections provide information and procedures for using the bridge configuration commands
and also includes command examples.
Selecting the Spantree Protocol
The switch supports three Spanning Tree protocols: STP, RSTP (the default), MSTP. To configure the
Spanning Tree protocol for a VLAN instance regardless of which mode (per-VLAN or flat) is active for
the switch, use the spantree protocol command with the vlan parameter. For example, the following
command changes the protocol to RSTP for VLAN 455:
-> spantree vlan 455 protocol rstp
Note. When configuring the protocol value for a VLAN instance, MSTP is not an available option. This
protocol is only supported on the flat mode instance.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-27
Configuring Spanning Tree Parameters
Configuring STP Bridge Parameters
To configure the protocol for the flat mode CIST instance, use either the spantree protocol command or
the spantree protocol command with the cist parameter. Note that both commands are available when the
switch is running in either mode (per-VLAN or flat). For example, the following commands configure the
protocol for the flat mode instance to MSTP:
-> spantree cist protocol mstp
-> spantree protocol mstp
Configuring the Bridge Priority
A bridge is identified within the Spanning Tree by its bridge ID (an eight byte hex number). The first two
bytes of the bridge ID contain a priority value and the remaining six bytes contain a bridge MAC address.
The bridge priority is used to determine which bridge serves as the root of the Spanning Tree. The lower
the priority value, the higher the priority. If more than one bridge have the same priority, then the bridge
with the lowest MAC address becomes the root.
Note. Configuring a Spanning Tree bridge instance with a priority value that causes the instance to become
the root is recommended, instead of relying on the comparison of switch base MAC addresses to determine
the root.
If the switch is running in the per-VLAN Spanning Tree mode, then a priority value is assigned to each
VLAN instance. If the switch is running in the flat Spanning Tree mode, the priority is assigned to the flat
mode instance or a Multiple Spanning Tree Instance (MSTI). In both cases, the default priority value is
assigned. Note that priority value for an MSTI must be a multiple of 4096.
To change the bridge priority value for a VLAN instance regardless of which mode (per-VLAN or flat) is
active for the switch, use the spantree priority command with the vlan parameter. For example, the
following command changes the priority for VLAN 455 to 25590:
-> spantree vlan 455 priority 25590
Note. If PVST+ mode is enabled on the switch, then the priority values can be assigned only in the
multiples of 4096 to be compatible with the Cisco MAC Reduction mode; any other values result in an
error message.
To change the bridge priority value for the flat mode CIST instance, use either the spantree priority
command or the spantree priority command with the cist parameter. Note that both commands are
available when the switch is running in either mode (per-VLAN or flat). For example, the following
commands change the bridge priority value for the flat mode instance to 12288:
-> spantree cist priority 12288
-> spantree priority 12288
The bridge priority value is also configurable for a Multiple Spanning Tree Instance (MSTI). To configure
this value for an MSTI, use the spantree priority command with the msti parameter and specify a priority
value that is a multiple of 4096. For example, the following command configures the priority value for
MSTI 10 to 61440:
-> spantree msti 10 priority 61440
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-28
Configuring Spanning Tree Parameters
Configuring STP Bridge Parameters
Configuring the Bridge Hello Time
The bridge hello time interval is the number of seconds a bridge waits between transmissions of
Configuration BPDU. When a bridge is attempting to become the root or if it has become the root or a
designated bridge, it sends Configuration BPDU out all forwarding ports once every hello time value.
The hello time propagated in a root bridge Configuration BPDU is the value used by all other bridges in
the tree for their own hello time. Therefore, if this value is changed for the root bridge, all other bridges
associated with the same STP instance adopt this value as well.
Note. Lowering the hello time interval improves the robustness of the Spanning Tree algorithm. Increasing
the hello time interval lowers the overhead of Spanning Tree processing.
If the switch is running in the per-VLAN Spanning Tree mode, then a hello time value is defined for each
VLAN instance. If the switch is running in the flat Spanning Tree mode, then a hello time value is defined
for the single flat mode instance. In both cases, the default hello time value is used.
To change the bridge hello time value for a VLAN instance regardless of which mode (per-VLAN or flat)
is active for the switch, use the spantree hello-time command with the vlan parameter. For example, the
following command changes the hello time for VLAN 455 to 5 seconds:
-> spantree vlan 455 hello-time 5
To change the bridge hello time value for the flat mode CIST instance, use either the spantree hello-time
command or the spantree hello-time command with the cist parameter. Note that both commands are
available when the switch is running in either mode (per-VLAN or flat). For example, the following
commands change the hello time value for the flat mode instance to 10:
-> spantree hello-time 10
-> spantree cist hello-time 10
Note that the bridge hello time is not configurable for Multiple Spanning Tree Instances (MSTI). These
instances inherit the hello time from the flat mode instance (CIST).
Configuring the Bridge Max-Age Time
The bridge max-age time specifies how long, in seconds, the bridge retains Spanning Tree information it
receives from Configuration BPDU. When a bridge receives a BPDU, it updates its configuration
information and the max age timer is reset. If the max age timer expires before the next BPDU is received,
the bridge attempts to become the root, designated bridge, or change its root port.
The max-age time propagated in a root bridge Configuration BPDU is the value used by all other bridges
in the tree for their own max-age time. Therefore, if this value is changed for the root bridge, all other
VLANs associated with the same instance adopt this value as well.
If the switch is running in the per-VLAN Spanning Tree mode, then a max-age time value is defined for
each VLAN instance. If the switch is running in the flat Spanning Tree mode, then the max-age value is
defined for the flat mode instance. In both cases, the default max-age time is used.
Note. Configuring a low max-age time can cause Spanning Tree to reconfigure the topology more often.
To change the bridge max-age time value for a VLAN instance regardless of which mode (per-VLAN or
flat) is active for the switch, use the spantree max-age command with the vlan parameter. For example,
the following command changes the max-age time for VLAN 455 to 10 seconds:
-> spantree vlan 455 max-age 10
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-29
Configuring Spanning Tree Parameters
Configuring STP Bridge Parameters
To change the max-age time value for the flat mode CIST instance, use either the spantree max-age
command or the spantree max-age command with the cist parameter. Note that both commands are
available when the switch is running in either mode (per-VLAN or flat). For example, the following
commands change the max-age time value for the flat mode instance to 10:
-> spantree max-age 10
-> spantree cist max-age 10
Note. The max-age time is not configurable for Multiple Spanning Tree Instances (MSTI). These instances
inherit the max-age time from the flat mode instance (CIST).
Configuring the Forward Delay Time for the Switch
The bridge forward delay time specifies how long, in seconds, a port remains in the learning state while it
is transitioning to a forwarding state. In addition, when a topology change occurs, the forward delay time
value is used to age out all dynamically learned addresses in the MAC address forwarding table. For more
information about the MAC address table, see Chapter 3, “Managing Source Learning.”
The forward delay time propagated in a root bridge Configuration BPDU is the value used by all other
bridges in the tree for their own forward delay time. Therefore, if this value is changed for the root bridge,
all other bridges associated with the same instance adopt this value as well.
If the switch is running in the per-VLAN Spanning Tree mode, then a forward delay time value is defined
for each VLAN instance. If the switch is running in the flat Spanning Tree mode, then the forward delay
time value is defined for the flat mode instance. In both cases, the default forward delay time is used.
Note. Specifying a low forward delay time can cause temporary network loops, because packets can get
forwarded before Spanning Tree configuration or change notices have reached all nodes in the network.
To change the bridge forward delay time value for a VLAN instance regardless of which mode (perVLAN or flat) is active for the switch, use the spantree forward-delay command with the vlan
parameter. For example, the following command changes the forward delay time for VLAN 455 to 10
seconds:
-> spantree vlan 455 forward-delay 10
To change the forward-delay time value for the flat mode CIST instance, use either the spantree forwarddelay command or the spantree forward-delay command with the cist parameter. Note that both
commands are available when the switch is running in either mode (per-VLAN or flat). For example, the
following commands change the forward-delay time value for the flat mode instance to 10:
-> spantree forward-delay 10
-> spantree cist forward-delay 10
Note. The forward delay time is not configurable for Multiple Spanning Tree Instances (MSTI). These
instances inherit the forward delay time from the flat mode instance (CIST).
Enabling/Disabling the VLAN BPDU Switching Status
BPDU are not switched on ports associated with VLANs that have Spanning Tree disabled. This can result
in a network loop if the VLAN has redundant paths to one or more other switches. Allowing VLANs that
have Spanning Tree disabled to forward BPDU to all ports in the VLAN, can help to avoid this problem.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-30
Configuring Spanning Tree Parameters
Configuring STP Bridge Parameters
To enable or disable the switching of Spanning Tree BPDU for all VLAN and CIST instances when the
switch is running in the per-VLAN mode, use the spantree bpdu-switching command:
-> spantree bpdu-switching enable
-> spantree bpdu-switching disable
To enable or disable the switching of Spanning Tree BPDU for only the CIST instance when the switch is
running in the flat mode, use the spantree bpdu-switching command:
-> spantree cist bpdu-switching enable
-> spantree cist bpdu-switching disable
To enable or disable BPDU switching on a VLAN, use the vlan parameter along with spantree bpduswitching command.For example, the following commands enable BPDU switching on VLAN 10 and
disable it on VLAN 20:
-> spantree vlan 10 bpdu-switching enable
-> spantree vlan 20 bpdu-switching disable
Note. Disabling BPDU switching on a Spanning Tree disabled VLAN must not cause network loops to go
undetected.
Configuring the Path Cost Mode
The path cost mode controls whether the switch uses a 16-bit port path cost (PPC) or a 32-bit PPC. When
a 32-bit PPC switch connects to a 16-bit PPC switch, the 32-bit switch has a higher PPC value that
advertises an inferior path cost to the 16-bit switch. In this case, it is desirable to set the 32-bit switch to
use STP or RSTP with a 16-bit PPC value.
The path cost mode is automatically set to use a 16-bit value for all ports that are associated with an STP
instance or an RSTP instance and a 32-bit value for all ports associated with an MSTP value. It is also
possible to set the path cost mode to always use a 32-bit regardless of which protocol is active.
To change the path cost mode, use the spantree path-cost-mode command and specify either auto (uses
PPC value based on protocol) or 32bit (always use a 32-bit PPC value). For example, the following
command changes the default path cost mode from auto to 32-bit:
-> spantree path-cost-mode 32bit
Note. Cisco supports two default path cost modes: long or short just like in OmniSwitch per-VLAN
implementation. If you have configured PVST+ mode in the OmniSwitch, it is recommended that the same
default path cost mode must be configured in the same way in all the switches, so that, the path costs for
similar interface types are consistent when connecting ports between OmniSwitch and Cisco switches.
Using Automatic VLAN Containment
In a Multiple Spanning Tree (MST) configuration, it is possible for a port that belongs to a VLAN that is
not a member of an instance to become the root port for that instance. This can cause a topology change
that could lead to a loss of connectivity between VLANs/switches. Enabling Automatic VLAN
Containment (AVC) helps to prevent this from happening by making such a port an undesirable choice for
the root.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-31
Configuring Spanning Tree Parameters
Configuring STP Bridge Parameters
When AVC is enabled, it identifies undesirable ports and automatically configures them with an infinite
path cost value. For example, in the following diagram a link exists between VLAN 2 on two different
switches. The ports that provide this link belong to default VLAN 1 but are tagged with VLAN 2. In
addition, VLAN 2 is mapped to MSTI 1 on both switches.
VLAN 1
VLAN 1
4/2
MSTI-1
5/1
802.1q tag
VLAN 2
VLAN 2
MSTI-1
In the above diagram, port 4/2 is the Root port and port 5/1 is a Designated port for MSTI 1. AVC is not
enabled. If another link with the same speed and lower port numbers is added to default VLAN 1 on both
switches, the new link becomes the root for MSTI 1 and the tagged link between VLAN 2 is blocked, as
shown below:
3/1
2/1
VLAN 1
VLAN 1
||
MSTI-1
VLAN 2
4/2
802.1q tag
5/1
VLAN 2
MSTI-1
If AVC was enabled in the above example, AVC would have assigned the new link an infinite path cost
value that would make this link undesirable as the root for MSTI 1.
Balancing VLANs across links according to their Multiple Spanning Tree Instance (MSTI) grouping is
highly recommended to ensure that there is not a loss of connectivity during any possible topology
changes. Enabling AVC on the switch is another way to prevent undesirable ports from becoming the root
for an MSTI.
To change the default status of the AVC on the switch and to globally enable this feature for all MSTIs,
use the spantree auto-vlan-containment command. Once AVC is globally enabled, then it is possible to
disable AVC for individual MSTIs using the same command. For example, the following commands
globally enable AVC and then disable it for MSTI 10:
-> spantree auto-vlan-containment enable
-> spantree msti 10 auto-vlan-containment disable
Note. An administratively set port path cost takes precedence and prevents AVC configuration of the path
cost. The exception to this is if the port path cost is administratively set to zero, which resets the path cost to
the default value. In addition, AVC does not have any effect on root bridges.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-32
Configuring Spanning Tree Parameters
Configuring STP Port Parameters
Configuring STP Port Parameters
The following sections provide information and procedures for using CLI commands to configure STP
port parameters. These parameters determine the behavior of a port for a specific Spanning Tree instance.
When a switch is running in the per-VLAN STP mode, each VLAN is in essence a virtual STP bridge with
its own STP instance and configurable parameters. To change STP port parameters while running in this
mode, a VLAN ID is specified to identify the VLAN STP instance associated with the specified port.
When a switch is running in the flat Spanning Tree mode, VLAN 1 is specified for the VLAN ID.
Only bridged ports participate in the Spanning Tree Algorithm. A port is considered bridged if it meets all
the following criteria:
• Port is either a fixed (non-mobile) port, an 802.1Q tagged port, or a link aggregate logical port.
• Spanning tree is enabled on the port.
• Port is assigned to a VLAN that has Spanning Tree enabled.
• Port state (forwarding or blocking) is dynamically determined by the Spanning Tree Algorithm, not
manually set.
The following is a summary of Spanning Tree port configuration commands. For more information about
these commands, see the OmniSwitch AOS Release 8 CLI Reference Guide.
Commands
Used for ...
spantree cist
Configuring the port Spanning Tree status for the single flat mode
instance.
spantree vlan
Configuring the port Spanning Tree status for a VLAN instance.
spantree priority
Configuring the priority value for the flat mode CIST instance, a
Multiple Spanning Tree Instance (MSTI), or a per-VLAN mode
VLAN instance.
spantree loop-guard
Enables or disables the STP loop-guard on a port or link aggregate.
spantree cist path-cost
Configuring the port path cost value for the single flat mode
instance.
spantree msti path-cost
Configuring the port path cost value for a Multiple Spanning Tree
Instance (MSTI).
spantree vlan path-cost
Configuring the port path cost value for a VLAN instance.
spantree cist mode
Configuring the port Spanning Tree mode (dynamic or manual) for
the single flat mode instance.
spantree loop-guard
Configuring the port Spanning Tree mode (dynamic or manual) for
a VLAN instance.
spantree cist connection
Configuring the port connection type for the single flat mode
instance.
spantree vlan connection
Configuring the port connection type for a VLAN instance.
spantree cist admin-edge
Configures the connection type for a port or an aggregate of ports
for the flat mode Common and Internal Spanning Tree (CIST).
spantree vlan admin-edge
Configures the connection type for a port or an aggregate of ports
for a per-VLAN mode VLAN instance.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-33
Configuring Spanning Tree Parameters
Configuring STP Port Parameters
Commands
Used for ...
spantree cist auto-edge
Configures a port or an aggregate of ports for the flat mode
Common and Internal Spanning Tree (CIST) as an edge port,
automatically.
spantree vlan auto-edge
Configures a port or an aggregate of ports for the per-VLAN mode
VLAN instance as an edge port, automatically.
spantree cist restricted-role
Configures the restricted role status for a port or an aggregate of
ports for the flat mode Common and Internal Spanning Tree
(CIST) as a restricted role port.
spantree vlan restricted-role
Configures a port or an aggregate of ports for the per-VLAN mode
VLAN instance as a restricted role port.
spantree cist restricted-tcn
Configures a port or an aggregate of ports for the flat mode
Common and Internal Spanning Tree (CIST) to support the
restricted TCN capability.
spantree vlan restricted-tcn
Configures a port or an aggregate of ports for the per-VLAN mode
VLAN instance to support the restricted TCN capability.
spantree cist txholdcount
Limits the transmission of BPDU through a given port for the flat
mode Common and Internal Spanning Tree (CIST).
spantree vlan txholdcount
Limits the transmission of BPDU through a given port for the perVLAN mode VLAN instance.
spantree pvst+compatibility
Configures the type of BPDU to be used on a port when PVST+
mode is enabled.
The following sections provide information and procedures for using Spanning Tree port configuration
commands and also includes command examples.
Enabling/Disabling Spanning Tree on a Port
Spanning Tree is automatically enabled on all eligible ports. When Spanning Tree is disabled on a port,
the port is put in a forwarding state for the specified instance. For example, if a port is associated with
both VLAN 10 and VLAN 20 and Spanning Tree is disabled on the port for VLAN 20, the port state is set
to forwarding for VLAN 20. However, the VLAN 10 instance still controls the port state as it relates to
VLAN 10. This example assumes the switch is running in the per-VLAN Spanning Tree mode.
If the switch is running in the flat Spanning Tree mode, then disabling the port Spanning Tree status
applies across all VLANs associated with the port. The flat mode instance is specified as the instance
associated with the port, even if the port is associated with multiple VLANs.
To change the port Spanning Tree status for a VLAN instance regardless of which mode (per-VLAN or
flat) is active for the switch, use the spantree vlan command. For example, the following commands
enable Spanning Tree on port 8/1 for VLAN 10 and disable STP on port 6/2 for VLAN 20:
-> spantree vlan 10 port 8/1 enable
-> spantree vlan 20 port 6/2 disable
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-34
Configuring Spanning Tree Parameters
Configuring STP Port Parameters
To change the port Spanning Tree status for the flat mode instance, use the spantree cist command. Note
that this command is available when the switch is running in either mode (per-VLAN or flat). For
example, the following command disables the Spanning Tree status on port 1/24 for the flat mode
instance:
-> spantree cist port 1/24 disable
Spanning Tree on Link Aggregate Ports
Physical ports that belong to a link aggregate do not participate in the Spanning Tree Algorithm. Instead,
the algorithm is applied to the aggregate logical link (virtual port) that represents a collection of physical
ports.
To enable or disable the Spanning Tree status for a link aggregate, use the spantree vlan or spantree cist
commands described above but specify a link aggregate control (ID) number instead of a slot and port. For
example, the following command disables Spanning Tree for the link aggregate 10 association with
VLAN 755:
-> spantree vlan 755 linkagg 10 disable
For more information about configuring an aggregate of ports, see Chapter 8, “Configuring Static Link
Aggregation,” and Chapter 9, “Configuring Dynamic Link Aggregation.”
Enabling/Disabling Loop-guard
By default, loop-guard is disabled on ports associated with VLANs that have Spanning Tree enabled. This
feature, when enabled prevents inconsistencies that cause network loops.
Use the spantree loop-guard command to enable or disable loop-guard on a port or link aggregate. For
example, the following commands enable and disable loop-guard on port 1/2 of chassis 1:
-> spantree port 1/1/2 loop-guard enable
-> spantree port 1/1/2 loop-guard disable
To enable or disable loop-guard on a link aggregate:
-> spantree linkagg 1 loop-guard enable
-> spantree linkagg 1 loop-guard disable
Note. Use the show spantree and related commands to view the loop-guard related information for perport, per-VLAN, CIST or MSTI instances.
Configuring Port Priority
A bridge port is identified within the Spanning Tree by its Port ID (a 16-bit or 32-bit hex number). The
first 4 bits of the Port ID contain a priority value and the remaining 12 bits contain the physical switch port
number. The port priority is used to determine which port offers the best path to the root when multiple
paths have the same path cost. The port with the highest priority (lowest numerical priority value) is
selected and the others are put into a blocking state. If the priority values are the same for all ports in the
path, then the port with the lowest physical switch port number is selected.
Spanning Tree is automatically enabled on a port and the default port priority value is set. If the switch is
running in the per-VLAN Spanning Tree mode, then the port priority applies to the specified VLAN
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-35
Configuring Spanning Tree Parameters
Configuring STP Port Parameters
instance associated with the port. If the switch is running in the flat Spanning Tree mode, then the port
priority applies across all VLANs associated with the port. The flat mode instance is specified as the port
instance, even if the port is associated with multiple VLANs.
To change the port priority value for a VLAN regardless of which mode (per-VLAN or flat) is active for
the switch, use the spantree priority command with the vlan and port parameters. For example, the
following command sets the priority value as 3 for the port 10/1 association with VLAN ID 10:
-> spantree vlan 10 port 10/1 priority 3
To change the port priority value for the flat mode instance, use the spantree priority command with the
cist and port parameters. Note that this command is available when the switch is running in either perVLAN or flat mode. An instance number is not required. For example, the following command changes
the priority value for port 1/24 for the flat mode instance to 15:
-> spantree cist port 1/24 priority 15
The port priority value is also configurable for a Multiple Spanning Tree Instance (MSTI). To configure
this value for an MSTI, use the spantree priority command with the msti and port parameters. For
example, the following command configures the priority value for port 1/12 for MSTI 10 to 5:
-> spantree msti 10 port 1/12 priority 5
Note that configuring the port priority value for a MSTI is allowed in both modes (per-VLAN and flat)
only when the Spanning Tree protocol is set to MSTP.
Port Priority on Link Aggregate Ports
Physical ports that belong to a link aggregate do not participate in the Spanning Tree Algorithm. Instead,
the algorithm is applied to the aggregate logical link (virtual port) that represents a collection of physical
ports.
To change the priority for a link aggregate, use the spantree priority command with the cist, msti, or
vlan parameters, as described above but specify a link aggregate control number instead of a slot and port
number. For example, the following command sets the priority for the link aggregate 10 association with
VLAN 755 to 9:
-> spantree vlan 755 linkagg 10 priority 9
For more information about configuring an aggregate of ports, see Chapter 8, “Configuring Static Link
Aggregation,” and Chapter 9, “Configuring Dynamic Link Aggregation.”
Configuring Port Path Cost
The path cost value specifies the contribution of a port to the path cost towards the root bridge that
includes the port. The root path cost is the sum of all path costs along this same path and is the value
advertised in Configuration BPDU transmitted from active Spanning Tree ports. The lower the cost value,
the closer the switch is to the root.
The type of path cost value used depends on which path cost mode is active (automatic or 32-bit). If the
path cost mode is set to automatic, a 16-bit value is used when STP or RSTP is the active protocol and a
32-bit value is used when MSTP is the active protocol. If the mode is set to 32-bit, then a 32-bit path cost
value is used regardless of which protocol is active. See “Configuring the Path Cost Mode” on page 6-31
for more information.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-36
Configuring Spanning Tree Parameters
Configuring STP Port Parameters
If a 32-bit path cost value is in use and the path_cost is set to zero, the following IEEE 802.1Q 2005
recommended default path cost values based on link speed are used:
Link Speed
IEEE 802.1D
Recommended Value
10 MB
2,000,000
100 MB
200,000
1 GB
20,000
10 Gbps
2,000
Is a 16-bit path cost value is in use and the path_cost is set to zero, the following IEEE 802.1D
recommended default path cost values based on link speed are used:
Link Speed
IEEE 802.1D
Recommended Value
4 Mbps
250
10 Mbps
100
16 Mbps
62
100 Mbps
19
1 Gbps
4
10 Gbps
2
Spanning Tree is automatically enabled on a port and the path cost is set to the default value. If the switch
is running in the per-VLAN Spanning Tree mode, then the port path cost applies to the specified VLAN
instance associated with the port. If the switch is running in the flat Spanning Tree mode, then the port
path cost applies across all VLANs associated with the port. The flat mode instance is specified as the port
instance, even if the port is associated with other VLANs.
The spantree vlan path-cost command configures the port path cost value for a VLAN instance when the
switch is running in either mode (per-VLAN or flat). For example, the following command configures a
16-bit path cost value for port 8/1 for VLAN 10 to 19 (the port speed is 100 MB, 19 is the recommended
value):
-> spantree vlan 10 port 8/1 path-cost 19
To change the port path cost value for the flat mode instance regardless of which mode (per-VLAN or flat)
is active for the switch, use the spantree cist path-cost command. For example, the following command
configures a 32-bit path cost value for port 1/24 for the flat mode instance to 20,000 (the port speed is 1
GB, 20,000 is the recommended value):
-> spantree cist port 1/24 path-cost 20000
The port path cost value is also configurable for a Multiple Spanning Tree Instance (MSTI). To configure
this value for an MSTI, use the spantree msti path-cost command and specify the MSTI ID for the
instance number. For example, the following command configures the path cost value for port 1/12 for
MSTI 10 to 19:
-> spantree msti 10 port 1/12 path-cost 19
Note that configuring the port path cost value for a MSTI is allowed in both modes (per-VLAN and flat)
only when the Spanning Tree protocol is set to MSTP.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-37
Configuring Spanning Tree Parameters
Configuring STP Port Parameters
Path Cost for Link Aggregate Ports
Physical ports that belong to a link aggregate do not participate in the Spanning Tree Algorithm. Instead,
the algorithm is applied to the aggregate logical link (virtual port) that represents a collection of physical
ports. Spanning Tree is automatically enabled on the aggregate logical link and the path cost value is set to
the default value.
If a 32-bit path cost value is in use and the path_cost for a link aggregate is set to zero, the following
default values based on link speed and link aggregate size are used:
Link Speed
Aggregate Size
(number of links)
Default Path
Cost Value
10 MB
2
1,200,000
4
800,000
8
600,000
2
120,000
4
80,000
8
60,000
2
12,000
4
8,000
8
6,000
2
1,200
4
800
8
600
100 MB
1 GB
10 GB
If a 16-bit path cost value is in use and the path_cost for a link aggregate is set to zero, the following
default values based on link speed and link aggregate size are used. Note that for Gigabit ports the
aggregate size is not applicable in this case:
Link Speed
Aggregate Size
(number of links)
Default Path
Cost Value
10 MB
2
60
4
40
8
30
2
12
4
9
8
7
1 GB
N/A
3
10 GB
N/A
1
100 MB
To change the path cost value for a link aggregate, use the spantree cist path cost, spantree msti path
cost, or spantree vlan path cost command with the linkagg parameter and a link aggregate control (ID)
number. For example, the following command sets the path cost for link aggregate 10 associated with
VLAN 755 to 19:
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-38
Configuring Spanning Tree Parameters
Configuring STP Port Parameters
-> spantree vlan 755 linkagg 10 path-cost 19
For more information about configuring an aggregate of ports, see Chapter 8, “Configuring Static Link
Aggregation,” and Chapter 9, “Configuring Dynamic Link Aggregation.”
Configuring Port Mode
There are two port modes supported: manual and dynamic. Manual mode indicates that the port was set by
the user to a forwarding or blocking state. The port operates in the state selected until the state is manually
changed again or the port mode is changed to dynamic. Ports operating in a manual mode state do not
participate in the Spanning Tree Algorithm. Dynamic mode indicates that the active Spanning Tree
Algorithm determines port state.
Spanning Tree is automatically enabled on the port and the port operates in the default mode. If the switch
is running in the per-VLAN Spanning Tree mode, then the port mode applies to the specified VLAN
instance associated with the port. If the switch is running in the flat Spanning Tree mode, then the port
mode applies across all VLANs associated with the port. The flat mode instance is specified as the port
instance, even if the port is associated with other VLANs.
To change the port Spanning Tree mode for a VLAN instance regardless of which mode (per-VLAN or
flat) is active for the switch, use the spantree loop-guard command. For example, the following
command sets the mode for port 8/1 for VLAN 10 to forwarding.
-> spantree vlan 10 port 8/1 mode forwarding
To change the port Spanning Tree mode for the flat mode instance, use the spantree cist mode command.
Note that the command is available when the switch is running in either mode (per-VLAN or flat) and an
instance number is not required. For example, the following command configures the Spanning Tree mode
on port 1/24 for the flat mode instance:
-> spantree cist port 1/24 mode blocking
Mode for Link Aggregate Ports
Physical ports that belong to a link aggregate do not participate in the Spanning Tree Algorithm. Instead,
the algorithm is applied to the aggregate logical link (virtual port) that represents a collection of physical
ports.
To change the port mode for a link aggregate, use the spantree vlan mode or the spantree cist mode
command described above, but specify a link aggregate control (ID) number instead of a slot and port. For
example, the following command sets the port mode for link aggregate 10 associated with VLAN 755 to
blocking:
-> spantree vlan 755 linkagg 10 mode blocking
For more information about configuring an aggregate of ports, see Chapter 8, “Configuring Static Link
Aggregation,” and Chapter 9, “Configuring Dynamic Link Aggregation.”
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-39
Configuring Spanning Tree Parameters
Configuring STP Port Parameters
Configuring Port Connection Type
Specifying a port connection type is done when using the Rapid Spanning Tree Algorithm and Protocol
(RSTP), as defined in the IEEE 802.1w standard. RSTP transitions a port from a blocking state directly to
forwarding, bypassing the listening and learning states, to provide a rapid reconfiguration of the Spanning
Tree in the event of a path or root bridge failure. Rapid transition of a port state depends on the
configurable connection type of the port. These types are defined as follows:
• Point-to-point LAN segment (port connects directly to another switch).
• No point-to-point shared media LAN segment (port connects to multiple switches).
• Edge port (port is at the edge of a bridged LAN, does not receive BPDU and has only one MAC
address learned). Edge ports, however, will operationally revert to a point to point or a no point to
point connection type if a BPDU is received on the port.
A port is considered connected to a point-to-point LAN segment if the port belongs to a link aggregate of
ports, or if auto negotiation determines if the port must run in full duplex mode, or if full duplex mode was
administratively set. Otherwise, that port is considered connected to a no point-to-point LAN segment.
Rapid transition of a designated port to forwarding can only occur if the port connection type is defined as
a point to point or an edge port. Defining a port connection type as a point to point or as an edge port
makes the port eligible for rapid transition, regardless of what actually connects to the port. However, an
alternate port is always allowed to transition to the role of root port regardless of the alternate port
connection type.
Note. Configure ports that will connect to a host (PC, workstation, server, etc.) as edge ports so that these
ports will transition directly to a forwarding state and not trigger an unwanted topology change when a
device is connected to the port. If a port is configured as a point to point or no point to point connection
type, the switch will assume a topology change when this port goes active and will flush and relearn all
learned MAC addresses for the port’s assigned VLAN.
If the switch is running in the per-VLAN Spanning Tree mode, then the connection type applies to the
specified VLAN instance associated with the port. If the switch is running in the flat Spanning Tree mode,
then the connection type applies across all VLANs associated with the port. The flat mode instance is
referenced as the port instance, even if the port is associated with other VLANs.
By default, Spanning Tree is automatically enabled on the port, the connection type is set to auto point-topoint, and auto edge port detection is enabled. The auto point-to-point setting determines the connection
type based on the operational status of the port. The auto edge port setting determines the operational edge
port status for the port.
The spantree vlan connection and spantree cist connection commands are used to configure the port
connection type for a VLAN instance or the CIST instance. See “Configuring the Edge Port Status” on
page 6-41 for information about configuring the auto edge port status for a port.
To change the port connection type for a VLAN instance regardless of which mode (per-VLAN or flat) is
active for the switch, use the spantree vlan connection command. For example, the following command
defines the connection type for port 8/1 associated with VLAN 10.
-> spantree vlan 10 port 8/1 connection autoptp
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-40
Configuring Spanning Tree Parameters
Configuring STP Port Parameters
To change the port Spanning Tree mode for the flat mode instance regardless of which mode (per-VLAN
or flat) is active for the switch, use the spantree cist connection command. For example, the following
command configures the connection type for port 1/24 for the flat mode instance:
-> spantree cist port 1/24 connection ptp
Note. The spantree vlan connection and spantree cist connection commands only configure one port at a
time.
Connection Type on Link Aggregate Ports
Physical ports that belong to a link aggregate do not participate in the Spanning Tree Algorithm. Instead,
the algorithm is applied to the aggregate logical link (virtual port) that represents a collection of physical
ports. To change the port connection type for a link aggregate, use the spantree vlan connection or the
spantree cist connection command described above, but specify a link aggregate control (ID) number
instead of a slot and port. For example, the following command defines the connection type for the link
aggregate 10 association with VLAN 755:
-> spantree vlan 755 linkagg 10 connection autoptp
For more information about configuring an aggregate of ports, see Chapter 8, “Configuring Static Link
Aggregation,” and Chapter 9, “Configuring Dynamic Link Aggregation.”
Configuring the Edge Port Status
There are two methods for determining the edge port status for a port or link aggregate:
• Configuring the automatic edge (auto edge) port status. The status (enabled or disabled) of this
Spanning Tree port parameter specifies whether or not the Spanning Tree automatically determines the
operational edge port status for a port. This method is enabled by default.
• Configuring the administrative edge (admin edge) port status. The status (enabled or disabled) of this
Spanning Tree port parameter is used to determine the edge port status when the auto edge port status
is disabled. This method is disabled by default.
To configure the edge port status for the flat mode instance regardless of which mode (per-VLAN or flat)
is active for the switch, use the spantree cist auto-edge command or the spantree cist admin-edge
command. For example:
-> spantree cist port 8/23 auto-edge enable
-> spantree cist port 8/23 admin-edge disable
To configure the edge port status for a VLAN instance regardless of which mode (per-VLAN or flat) is
active for the switch, use the spantree vlan auto-edge command or the spantree vlan admin-edge
command. For example:
-> spantree vlan 10 port 8/23 auto-edge enable
-> spantree vlan 10 port 8/23 admin-edge disable
Note. If auto-edge is enabled on a port, then the admin-edge value is overridden.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-41
Configuring Spanning Tree Parameters
Configuring STP Port Parameters
Restricting Port Roles (Root Guard)
All ports are automatically eligible for root port selection. A port in a CIST/MSTI instance or per-VLAN
instance can be prevented from becoming the root port by restricting the role of the port (also referred to
as enabling root guard). This is done using the spantree cist restricted-role command or the spantree
vlan restricted-role command regardless of which mode (per-VLAN or flat) is active for the switch. For
example:
->
->
->
->
spantree
spantree
spantree
spantree
cist
cist
vlan
vlan
port 1/2 restricted-role enable
linkagg 10 restricted-role enable
100 port 8/1 restricted-role enable
20 linkagg 1 restricted-role enable
Note that the above commands also provide optional syntax; restricted-role or root-guard. For example,
the following two commands perform the same function:
-> spantree vlan port 2/1 restricted-role enable
-> spantree vlan port 2/1 root-guard enable
When root guard is enabled for a port, it cannot become the root port, even if it is the most likely
candidate for becoming the root port. However, this same port is designated as the alternate port when the
root port is selected.
Enabling the restricted role status is used by network administrators to prevent bridges external to the core
region of the network from influencing the Spanning Tree topology. However, note that enabling the
restricted role status for a port may impact connectivity within the network.
Restricting TCN Propagation
All ports automatically propagate Topology Change Notifications (TCN) or Topology Changes (TC) to
other ports. To restrict a port from propagating topology changes and notifications, use the spantree cist
restricted-tcn command or the spantree vlan restricted-tcn command regardless of which mode (perVLAN or flat) is active for the switch. For example:
->
->
->
->
spantree
spantree
spantree
spantree
cist
cist
vlan
vlan
port 2/2 restricted-tcn enable
linkagg 5 restricted-tcn enable
10 port 1/5 restricted-tcn enable
20 linkagg 1 restricted-tcn enable
Enabling the restricted TCN status is used by network administrators to prevent bridges external to the
core region of the network from causing unnecessary MAC address flushing in that region. However, note
that enabling the restricted TCN status for a port may impact Spanning Tree connectivity.
Limiting BPDU Transmission
The number of BPDUs to be transmitted per port per second can be limited using the spantree cist
txholdcount command for a CIST instance or the spantree vlan txholdcount command for a per-VLAN
instance. Both of these commands apply to all ports and link aggregates and are supported when the
switch is running in either the per-VLAN mode or the flat mode. For example:
-> spantree cist txholdcount 5
-> spantree vlan 10 txholdcount 5
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-42
Configuring Spanning Tree Parameters
Sample Spanning Tree Configuration
Sample Spanning Tree Configuration
This section provides an example network configuration in which the Spanning Tree Algorithm and
Protocol has calculated a loop-free topology. In addition, a tutorial is also included that provides steps on
how to configure the example network topology using the Command Line Interface (CLI).
Note that the following example network configuration illustrates using switches operating in the perVLAN Spanning Tree mode and using RSTP (802.1w) to calculate a single data path between VLANs.
See “MST General Overview” on page 6-12 for an overview and examples of using MSTP (802.1s).
Example Network Overview
The following diagram shows a four-switch network configuration with an active Spanning Tree topology,
which was calculated based on both configured and default Spanning Tree parameter values:
Switch C
Switch D
(Root Bridge)
VLAN 255 Bridge ID
10, 00:d0:95:00:00:01
2/1
2/3
PC=4
3/8
2/2
PC=19
3/9
VLAN 255 Bridge ID
32768, 00:d0:95:00:00:04
3/10
PC=19
PC=4
3/2
2/10
VLAN 255 Bridge ID
32768, 00:d0:95:00:00:02
2/8
PC=4
3/3
2/9
PC=4
3/1
VLAN 255 Bridge ID
32768, 00:d0:95:00:00:03
Switch A
(Designated Bridge)
Switch B
Forwarding
Blocking
Root Port
Designated Port
PC
Path Cost
Example Active Spanning Tree Topology
In the above example topology:
• Each switch is operating in the per-VLAN Spanning Tree mode by default.
• Each switch configuration has a VLAN 255 defined. The Spanning Tree administrative status for this
VLAN was enabled by default when the VLAN was created.
• VLAN 255 on each switch is configured to use the 802.1w (rapid reconfiguration) Spanning Tree
Algorithm and Protocol.
• Ports 2/1-3, 2/8-10, 3/1-3, and 3/8-10 provide connections to other switches and are all assigned to
VLAN 255 on their respective switches. The Spanning Tree administrative status for each port is
enabled by default.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-43
Configuring Spanning Tree Parameters
Sample Spanning Tree Configuration
• The path cost for each port connection defaults to a value based on the link speed. For example, the
connection between Switch B and Switch C is a 100 Mbps link, which defaults to a path cost of 19.
• VLAN 255 on Switch D is configured with a Bridge ID priority value of 10, which is less than the
same value for VLAN 255 configured on the other switches. As a result, VLAN 255 was elected the
Spanning Tree root bridge for the VLAN 255 broadcast domain.
• A root port is identified for VLAN 255 on each switch, except the root VLAN 255 switch. The root
port identifies the port that provides the best path to the root VLAN.
• VLAN 255 on Switch A was elected the designated bridge because it offers the best path cost for
Switch B to the root VLAN 255 on Switch D.
• Port 2/9 on Switch A is the designated port for the Switch A to Switch B connection because Switch A
is the designated bridge for Switch B.
• Redundant connections exist between Switch D and Switch C. Ports 2/2 and 3/9 are in a discarding
(blocking) state because this connection has a higher path cost than the connection provided through
ports 2/3 and 3/8. As a result, a network loop condition is avoided.
• Redundant connections also exist between Switch A and Switch B. Although the path cost value for
both of these connections is the same, ports 2/8 and 3/3 are in a discarding state because their port
priority values (not shown) are higher than the same values for ports 2/10 and 3/1.
• The ports that provide the connection between Switch B and Switch C are in a discarding (blocking)
state, because this connection has a higher path cost than the other connections leading to the root
VLAN 255 on Switch D. As a result, a network loop is avoided.
Example Network Configuration Steps
The following steps provide a quick tutorial that configures the active Spanning Tree network topology
shown in the diagram on page 6-43.
1 Create VLAN 255 on Switches A, B, C, and D with “Marketing IP Network” for the VLAN
description on each switch using the following command:
-> vlan 255 name "Marketing IP Network"
2 Assign the switch ports that provide connections between each switch to VLAN 255. For example, the
following commands entered on Switches A, B, C, and D, respectively, assign the ports shown in the
example network diagram on page 6-43 to VLAN 255:
->
->
->
->
vlan
vlan
vlan
vlan
255
255
255
255
members
members
members
members
port
port
port
port
2/8-10 untagged
3/1-3 untagged
3/8-10 untagged
2/1-3 untagged
3 Change the Spanning Tree protocol for VLAN 255 to RSTP (Rapid Spanning Tree Protocol) on each
switch using the following command:
-> spantree vlan 255 protocol rstp
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-44
Configuring Spanning Tree Parameters
Sample Spanning Tree Configuration
4 Change the bridge priority value for VLAN 255 on Switch D to 10 using the following command
(leave the priority for VLAN 255 on the other three switches set to the default value):
-> spantree vlan 255 priority 10
VLAN 255 on Switch D has the lowest Bridge ID priority value of all four switches, which qualifies it as
the Spanning Tree root VLAN for the VLAN 255 broadcast domain.
Note. To verify the VLAN 255 Spanning Tree configuration on each switch use the following show
commands. The following outputs are for example purposes only and not match values shown in the sample
network configuration:
-> show spantree vlan 255
Spanning Tree Parameters for Vlan 255
Spanning Tree Status :
ON,
Protocol
:
IEEE Rapid STP,
mode
: Per VLAN (1 STP per Vlan),
Priority
:
32768 (0x8000),
Bridge ID
:
8000-00:e0:b1:e7:09:a3,
Designated Root
:
8000-00:e0:b1:e7:09:a3,
Cost to Root Bridge :
8,
Root Port
:
1/1/48,
TxHoldCount
:
3,
Topology Changes
:
101,
Topology age
:
01:05:30,
Topology Change Port :
1/1/48,
Current Parameters (seconds)
Max Age
=
20,
Forward Delay
=
15,
Hello Time
=
2
Parameters system uses when attempting to become root
System Max Age
=
20,
System Forward Delay =
15,
System Hello Time
=
2
-> show spantree vlan 255 ports
Spanning Tree Port Summary for Vlan 1
Oper Path
Desig
Prim. Op Op Loop
Port
St
Cost
Cost Role Port Cnx Edg Guard Desig Bridge ID
Note
-------+----+-------+-----+----+-----+---+---+-----+----------------------+----1/1/1 FORW
100
8 DESG 1/1/1 PTP NO DIS 8000-e8:e7:32:a4:63:21
1/1/2 DIS
0
0 DIS 1/1/2 NS NO DIS 0000-00:00:00:00:00:00
1/1/4 DIS
0
0 DIS 1/1/4 NS NO DIS 0000-00:00:00:00:00:00
1/1/5 DIS
0
0 DIS 1/1/5 NS NO DIS 0000-00:00:00:00:00:00
1/1/6 DIS
0
0 DIS 1/1/6 NS NO DIS 0000-00:00:00:00:00:00
1/1/7 DIS
0
0 DIS 1/1/7 NS NO DIS 0000-00:00:00:00:00:00
1/1/8 DIS
0
0 DIS 1/1/8 NS NO DIS 0000-00:00:00:00:00:00
1/1/9 DIS
0
0 DIS 1/1/9 NS NO DIS 0000-00:00:00:00:00:00
1/1/12 DIS
0
0 DIS 1/1/12 NS NO DIS 0000-00:00:00:00:00:00
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-45
Configuring Spanning Tree Parameters
Sample MST Region Configuration
Sample MST Region Configuration
An MST region identifies a group of MSTP switches that is seen as a single, flat mode instance by other
regions and/or non-MSTP switches. A region is defined by three attributes: name, revision level, and a
VLAN-to-MSTI mapping. Switches configured with the same value for all three of these attributes belong
to the same MST region.
Note. An additional configurable MST region parameter defines the maximum number of hops authorized
for the region but is not considered when determining regional membership.The maximum hops value is
the value used by all bridges within the region when the bridge is acting as the root of the MST region.
This section provides a tutorial for defining a sample MST region configuration, as shown in the diagram
below:
Switch D
Switch A
||
CST
IST
||
||
Switch B
Switch C
Switch E
MST Region
SST Switches (STP or RSTP)
In order for switches A, B, and C in the above diagram to belong to the same MST region, they must all
share the same values for region name, revision level, and configuration digest (VLAN-to-MSTI
mapping).
The following steps are performed on each switch to define ALE Marketing as the MST region name,
2000 as the MST region revision level, map exiting VLANs to existing MSTIs, and 3 as the maximum
hops value for the region:
1 Configure an MST Region name using the spantree mst region name command. For example:
-> spantree mst region name “ALE Marketing”
2 Configure the MST Region revision level using the spantree mst region revision-level command. For
example:
-> spantree mst region revision-level 2000
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-46
Configuring Spanning Tree Parameters
Sample MST Region Configuration
3 Map VLANs 100 and 200 to MSTI 2 and VLANs 300 and 400 to MSTI 4 using the spantree msti
vlan command to define the configuration digest. For example:
-> spantree msti 2 vlan 100 200
-> spantree msti 4 vlan 300 400
See the “Sample MSTI Configuration” on page 6-48 for a tutorial on how to create and map MSTIs to
VLANs.
4 Configure 3 as the maximum number of hops for the region using the spantree mst region max-hops
command. For example:
-> spantree mst region max-hops 3
Note. (Optional) Verify the MST region configuration on each switch with the show spantree mst
command. For example:
-> show spantree mst region
Configuration Name
= ALE Marketing,
Revision Level
= 2000,
Configuration Digest
= 0x922fb3f 31752d68 67fe1155 d0ce8380,
Revision Max hops
= 3,
Cist Instance Number
= 0
All switches configured with the exact same values as shown in the above example are considered members
of the ALE Marketing MST region.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-47
Configuring Spanning Tree Parameters
Sample MSTI Configuration
Sample MSTI Configuration
By default, the Spanning Tree software is active on all switches and operating in the per-VLAN mode
using 802.1w RSTP. A loop-free network topology is automatically calculated based on default 802.1w
RSTP switch, bridge, and port parameter values.
Using Multiple Spanning Tree (MST) requires configuration changes to the default Spanning Tree values
(mode and protocol) as well as defining specific MSTP parameters and instances.
The following steps provide a tutorial for setting up a sample MSTP configuration, as shown in the
diagram below:
3/1
VLAN 100
2/1
VLAN 100
CIST-0
CIST-0
4/2
VLAN 150
4/8
VLAN 200
||
5/1
||
5/2
||
3/6
VLAN 150
VLAN 200
MSTI-1
MSTI-1
2/12
VLAN 250
VLAN 250
Switch A
Switch B
Flat Mode MSTP Quick Steps Example
1 Change the Spanning Tree operating mode, if necessary, on Switch A and Switch B from per-VLAN to
flat mode using the spantree mode command. For example:
-> spantree mode flat
Note that defining an MSTP configuration requires the use of explicit Spanning Tree commands,
which are available in both the flat and per-VLAN mode. As a result, this step is optional. See “Using
Spanning Tree Configuration Commands” on page 6-26 for more information.
2 Change the Spanning Tree protocol to MSTP using the spantree protocol command. For example:
-> spantree protocol mstp
3 Create VLANs 100, 200, 300, and 400 using the vlan command. For example:
->
->
->
->
vlan
vlan
vlan
vlan
100
150
200
250
4 Assign switch ports to VLANs, as shown in the above diagram, using the vlan members untagged
command. For example, the following commands assign ports 3/1, 4/2, 4/8, and 2/12 to VLANs 100, 150,
200, and 250 on Switch A:
->
->
->
->
vlan
vlan
vlan
vlan
100
150
200
250
members
members
members
members
port
port
port
port
3/1 untagged
4/2 untagged
4/8 untagged
2/12 untagged
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-48
Configuring Spanning Tree Parameters
Sample MSTI Configuration
The following commands assign ports 2/1, 5/1, 5/2, and 3/6 to VLANs 100, 150, 200, and 250 on
Switch B:
->
->
->
->
vlan
vlan
vlan
vlan
100
150
200
250
members
members
members
members
port
port
port
port
2/1
5/1
5/2
3/6
untagged
untagged
untagged
untagged
5 Create one MSTI using the spantree msti command. For example:
-> spantree msti 1
6 Assign VLANs 200 and 250 to MSTI 1. For example:
-> spantree msti 1 vlan 100 200
All VLANs are associated with the CIST instance. As a result, VLANs 100 and 150 do not require any
configuration to map them to the CIST instance.
7 Configure the port path cost (PPC) for all ports on both switches associated with MSTI 1 to a PPC
value that is lower than the PPC value for the ports associated with the CIST instance using the spantree
msti path-cost command. For example, the PPC for ports associated with the CIST instance is set to the
default of 200,000 for 100 MB connections. The following commands change the PPC value for ports
associated with the MSTI 1 to 20,000:
->
->
->
->
spantree
spantree
spantree
spantree
msti
msti
msti
msti
1
1
1
1
port
port
port
port
4/8 path-cost 20000
2/12 path-cost 20000
5/2 path-cost 20000
3/6 path-cost 20000
Note. In this example, port connections between VLANs 150, 200, and 250 are blocked on each switch
initially, as shown in the diagram on page 6-48. This is because in flat mode MSTP, each instance is active
on all ports resulting in a comparison of connections independent of VLAN and MSTI associations.
To avoid this and allow VLAN traffic to flow over separate data paths based on MSTI association, Step 7
of this tutorial configures a superior port path cost value for ports associated with MSTI 1. As a result,
MSTI 1 selects one of the data paths between its VLANs as the best path, rather than the CIST data paths,
as shown in the diagram on page 6-50.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-49
Configuring Spanning Tree Parameters
Sample MSTI Configuration
.
VLAN 100
3/1
2/1
VLAN 100
CIST-0
CIST-0
VLAN 150
VLAN 200
4/2
||
5/1
4/8
5/2
2/12
3/6
VLAN 150
VLAN 200
MSTI-1
MSTI-1
VLAN 250
||
VLAN 250
Switch A
Switch B
Flat Mode MSTP with Superior MSTI 1 PPC Values
Note. Of the two data paths available to MSTI 1 VLANs, one is blocked because it is seen as redundant for
that instance. In addition, the CIST data path remains available for CIST VLAN traffic.
Another solution to this scenario is to assign all VLANs to an MSTI, leaving no VLANs controlled by the
CIST. As a result, the CIST BPDU contains only MSTI information. See “How MSTP Works” on
page 6-12 for more information.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-50
Configuring Spanning Tree Parameters
Verifying the Spanning Tree Configuration
Verifying the Spanning Tree Configuration
To display information about the Spanning Tree configuration on the switch, use the show commands
listed below:
show spantree cist
Displays the Spanning Tree bridge configuration for the flat mode
Common and Internal Spanning Tree (CIST) instance.
show spantree msti
Displays Spanning Tree bridge information for a Multiple Spanning
Tree Instance (MSTI).
show spantree vlan
Displays the Spanning Tree bridge information for a VLAN instance.
show spantree cist ports
Displays Spanning Tree port information for the flat mode Common and
Internal Spanning Tree (CIST) instance.
show spantree msti ports
Displays Spanning Tree port information for a flat mode Multiple
Spanning Tree Instance (MSTI).
show spantree vlan ports
Displays Spanning Tree port information for a VLAN instance.
show spantree mst
Displays the Multiple Spanning Tree (MST) information for a MST
region or the specified port or link aggregate on the switch.
show spantree cist vlan-map
Displays the range of VLANs associated with the flat mode Common
and Internal Spanning Tree (CIST) instance.
show spantree msti vlan-map
Displays the range of VLANs associated with the specified Multiple
Spanning Tree Instance (MSTI).
show spantree map-msti
Displays the Multiple Spanning Tree Instance (MSTI) that is associated
to the specified VLAN.
show spantree mode
Displays the current global Spanning Tree mode parameter values for
the switch, such as the current running mode (per-VLAN or flat) for the
switch
For more information about the resulting displays from these commands, see the OmniSwitch AOS
Release 8 CLI Reference Guide. An example of the output for the show spantree vlan and show spantree
vlan ports commands is also given in “Example Network Configuration Steps” on page 6-44.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 6-51
7
Configuring Loopback
Detection
Loopback Detection (LBD) automatically detects the loop and shutdown the port involved in the loop.
This prevents forwarding loops on ports that have forwarded network traffic which has looped back to the
originating switch. LBD detects and prevents Layer 2 forwarding loops on a port either in the absence of
other loop detection mechanisms such as STP/RSTP/MSTP, or when these mechanisms cannot detect it
(for example, a client's equipment may drop BPDUs, or the STP protocol may be restricted to the network
edge).
A provider network with a set of multiple switches interconnected together can be logically viewed as a
large single switch. The large single switch provides service access points to customers' networks.
Configuration faults in customer networks can result in loops spanning both provider and customer
networks. This can result in broadcast storms. In order to protect provider's network from broadcast
storms, loops that involve SAP ports need to be detected and broken.
The LBD can detect and break loops created on the service-access interface.
For a service-access interface, LBD can be enabled for a specific port or linkagg. LBD for service-access
points allows shutting down only the specific interface of the link involved in the loop.
The switch can be configured to process LBD frames received from a different or remote system. The port
of the remote system is shut down, rather than passing it as invalid LBD frames.
When loopback occurs, a trap is sent and the event is logged. The port which is shutdown due to LBD is
automatically recovered if autorecovery-timer is set or the port can manually be enabled again when the
problem is resolved.
In This Chapter
This chapter describes the LBD feature and how to configure it through the Command Line Interface
(CLI). CLI commands are used in the configuration examples; for more details about the syntax of
commands, see the OmniSwitch AOS Release 8 CLI Reference Guide. This chapter provides an overview
of LBD and includes the following information:
• “Quick Steps for Configuring LBD” on page 7-3
• “LBD Overview” on page 7-4
• “Configuring LBD” on page 7-7
• “LBD for Service Access Interface” on page 7-8
• “Verifying the LBD Configuration” on page 7-13
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 7-1
Configuring Loopback Detection
LBD Defaults
LBD Defaults
The following table shows LBD default values.
Parameter Description
Command
Default Value/Comments
LBD administrative state
loopback-detection
Disabled
LBD remote-origin
administrative state
loopback-detection
Disabled
LBD status of a port
loopback-detection port
Disabled
Remote-origin LBD status of a
port
loopback-detection port
Disabled
LBD service-access state
loopback-detection serviceaccess
Disabled
Transmission time is the time
period between LBD packet
transmissions.
loopback-detection serviceaccess
30 seconds
Autorecovery time is the time
period in which the switch is
recovered from the shutdown
state.
loopback-detection
autorecovery-timer
300 seconds
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 7-2
Configuring Loopback Detection
Quick Steps for Configuring LBD
Quick Steps for Configuring LBD
The following steps provide a quick tutorial on how to configure LBD. Each step describes a specific
operation and provides the CLI command syntax for performing that operation.
1 To enable the LBD protocol on a switch, use the loopback-detection command. For example:
-> loopback-detection enable
2 To enable the LBD protocol on a port, use the loopback-detection port command. For example:
-> loopback-detection port 1/1/2 enable
Note. Once the default LBD is enabled on the switch, the remote-origin LBD can be configured. It can be
enabled globally or on a per port using the loopback-detection command with the remote-origin
parameter. For example:
-> loopback-detection remote-origin enable
-> loopback-detection port 1/1/2 remote-origin enable
3 Configure the LBD transmission timer by using the loopback-detection transmission-timer
command. For example:
-> loopback-detection transmission-timer 200
4 To change the auto-recovery timer for Loopback detection, use the command loopback-detection
autorecovery-timer. By default, the violation recovery time is 300 seconds.
-> loopback-detection autorecovery-timer 600
Note. Optional. To verify the LBD global configuration use the show loopback-detection command or to
verify the LBD configuration on a port use the show loopback-detection port command. For example:
-> show loopback-detection
Global LBD Status
Global Remote-origin LBD Status
Global LBD Transmission Timer
Global LBD Auto-recovery Timer
:
:
:
:
enabled,
enabled,
200 sec,
600 sec,
-> show loopback-detection port 1/1/2
Global LBD Status
: enabled,
Global Remote-origin LBD Status
: enabled,
Global LBD Transmission Timer
: 200 sec,
Global LBD Auto-recovery Timer
: 600 sec,
Port LBD Status
: enabled,
Port Remote-origin LBD Status
: enabled,
Port LBD State
: Inactive,
Port LBD Type
: normal-edge,
To verify the LBD statistics of a port, use the show loopback-detection statistics port command. For
example:
-> show loopback-detection statistics port 1/1/2
LBD Port Statistics
LBD Packet Send
: 1
Invalid LBD Packet Received
: 0
Member of Link Aggregation
: -
See the OmniSwitch AOS Release 8 CLI Reference Guide for information about the fields in this display.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 7-3
Configuring Loopback Detection
LBD Overview
LBD Overview
Loopback Detection (LBD) automatically detects and prevents L2 forwarding loops on a port. LBD
operates in addition to STP which detects forwarding loops. When a loopback is detected, the port is
disabled and goes into a shutdown state. A trap is sent and the event is logged.
When enabling and configuring Loopback Detection:
• Enable Loopback Detection globally on the switch.
• Enable Loopback Detection on edge port.
The switch periodically sends out LBD frame from loopback detection enabled port and concludes that the
port is looped back if it receives the frame on any of the loop-back detection enabled ports.
Remote-origin LBD can be enabled and configured per port to process the LBD frames received from a
remote system.
For service-access ports, LBD detects the loop for all the LBD edge ports involved.
Transmission Timer
Transmission timer is the time duration in seconds at which the port sends LBD frame on the link. When
any port is getting blocked due to loopback detection, there will be no further transmission and receiving
of any traffic on the blocked port. The port will be go to shutdown state.
By default, the transmission timer for loopback detection is 30 seconds.
Remote-origin LBD Overview
The remote-origin LBD processes the LBD frames originating from a remote system. The frame is
processed and the receiving port is moved to shut down state.
The remote-origin LBD is functional, only if both default LBD and remote-origin LBD are enabled
globally and at interface level. For the remote-origin LBD to operate:
• Default LBD must be enabled globally
• Remote-origin LBD must be enabled globally
• Default LBD must be configured on the interface
• Remote-origin LBD must be configured on the LBD enabled interface
The following scenario shows the operation of the remote-origin LBD functionality:
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 7-4
Configuring Loopback Detection
Remote-origin LBD Overview
VC1
Corporate
Network
LBD and
Remote-origin
LBD disabled.
LBD frames
are dropped
and counted as
invalid.
3/4
3/1
VC2
1/1
1/4
LBD and
Remote-origin LBD
enabled globally
and on port.
LBD frames are
processed and
port is moved to
shut down state
In the two systems VC1 and VC2, VC1 has both default LBD and remote origin LBD enabled globally
and at the interface level (3/4). On VC2 only the default LBD is enabled globally and at interface level.
When LBD frame is transmitted from VC2 (1/4) to VC1 (3/4) the remote LBD frame is processed in VC1,
the MAC address of the transmitting system is recorded and the receiving port (3/4) is moved to shut
down.
When LBD frame is transmitted from VC1 (3/1) to VC2 (1/1) the LBD frame is dropped as the remoteorigin LBD is not enabled.
Note. In case, if remote-origin LBD is enabled on both the systems, the system which receives the first
remote LBD frame will shut down the port.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 7-5
Configuring Loopback Detection
Interaction With Other Features
Interaction With Other Features
This section contains important information about how other OmniSwitch features interact with LBD.
Refer to the specific chapter for each feature to get more detailed information about how to configure and
use the feature.
Spanning Tree Protocol
• If the STP mode is set to Multiple Spanning Tree, Loopback Detection can only be enabled on
interfaces where STP is disabled.
• LBD frame are sent untagged regardless of the spanning tree state on the port.
Link Aggregation
When loopback is detected on any one of the Linkagg port, all the ports of the linkagg will be shutdown
due to loopback detection.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 7-6
Configuring Loopback Detection
Configuring LBD
Configuring LBD
This section describes how to use the OmniSwitch Command Line Interface (CLI) commands to configure
LBD on a switch.
• Enable LBD on a switch or port (see “Enabling LBD” on page 7-7)
• Enable remote-origin LBD on a switch or port (see“Enabling Remote-origin LBD” on page 7-7)
• Configure the LBD transmission timer (see “Configuring the LBD Transmission Timer” on page 7-8)
• View the LBD statistics on a port (see “Viewing LBD Statistics” on page 7-8)
• Recover a port from LBD shutdown (see “Recovering a Port from LBD Shutdown” on page 7-8)
• Configuring Autorecovery-timer (see “Configuring Autorecovery-timer for LBD shutdown ports” on
page 7-8)
• Enable LBD on Service Access Interface (see “Enabling LBD on Service-access Interface” on
page 7-9)
Enabling LBD
By default, LBD is disabled on the switch. To enable LBD on a switch, use the loopback-detection
command. For example, the following command enables LBD on a switch:
-> loopback-detection enable
Enabling LBD on a Port
By default, LBD is disabled on all switch ports. To enable LBD on a port, use the loopback-detection
port command. For example, the following command enables LBD in chassis 1 on port 1 of slot 1:
-> loopback-detection port 1/1/1 enable
To enable LBD on multiple ports, specify a range of ports. For example:
-> loopback-detection port 1/1/1-8 enable
Enabling Remote-origin LBD
By default, remote-origin LBD is disabled on the switch. To enable remote-origin LBD on a switch, use
the loopback-detection command with the remote-origin parameter. For example, the following
command enables remote-origin LBD on a switch:
-> loopback-detection remote-origin enable
Enabling Remote-origin LBD on a port
By default, remote-origin LBD is disabled on all switch ports. To enable remote-origin LBD on a port, use
the loopback-detection port command with the remote-origin parameter. For example, the following
command enables remote-origin LBD in chassis 3 on port 1 of slot 1:
-> loopback-detection port 3/1/1 remote-origin enable
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 7-7
Configuring Loopback Detection
LBD for Service Access Interface
To enable remote-origin LBD on multiple ports, specify a range of ports. For example:
-> loopback-detection port 3/1/1-8 remote-origin enable
Note. See “Remote-origin LBD Overview” on page 7-4 for more details.
Configuring the LBD Transmission Timer
To configure the transmission time period between LBD packet transmissions, use the loopbackdetection service-access command. For example:
-> loopback-detection transmission-timer 200
Viewing LBD Statistics
To view the LBD statistics on a specific port, use the show loopback-detection statistics port command.
For example, to view the statistics for port 1 on slot 1 of chassis 1, enter:
-> show loopback-detection statistics port 1/1/1
Recovering a Port from LBD Shutdown
To bring a port out of the shutdown state, use the clear violation command. For example, to bring the
chassis 1, port 5 on slot 1 out of the shutdown state, enter:
-> clear-violation port 1/1/5
To bring multiple ports out of the shutdown state, enter:
-> clear-violation port 1/5/5-10
Configuring Autorecovery-timer for LBD shutdown ports
The port which is shutdown due to LBD can be automatically recovered if autorecovery-timer is set for
the switch. To set the autorecovery-timer, use the loopback-detection autorecovery-timer command. For
example, to set a autorecovery-timer of 200 sec for the switch, enter:
-> loopback-detection autorecovery-timer 200
LBD for Service Access Interface
A provider network with a set of multiple switches interconnected together can be logically viewed as a
large single switch. The large single switch provides service access points to customers' networks.
Configuration faults in customer networks can result in loops spanning both provider and customer
networks. This can result in broadcast storms. In order to protect provider's network from broadcast
storms, loops that involve SAP ports need to be detected and broken.
The LBD can detect and break loops created on the service-access interface.
For a service-access interface, LBD can be enabled for a specific port or linkagg. LBD for service-access
points allows shutting down only the specific interface of the link involved in the loop.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 7-8
Configuring Loopback Detection
LBD for Service Access Interface
Enabling LBD on Service-access Interface
By default, LBD is disabled for the switch and on all service-access ports. To globally enable LBD for the
switch, use the loopback-detection command. For example:
-> loopback-detection enable
To enable LBD on a service-access port, use the loopback-detection service-access command. For
example:
-> loopback-detection service-access port 1/1/1 enable
LBD can also be enabled on link aggregates that are configured as service-access aggregates. For example,
the following command enables LBD on link aggregate1:
-> loopback-detection service-access linkagg 1 enable
Few things to be considered while configuring LBD on linkagg:
• The link aggregate must be formed by ports with same path cost.
• LBD cannot be configured on linkagg which has member ports running LBD configuration and vice
versa.
• When a linkagg is in violation or shutdown state, the member ports cannot be deleted from the linkagg.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 7-9
Configuring Loopback Detection
LBD for Service Access Interface
Note. Before configuring the LBD using the “service-access” option, the port or link aggregate must be
configured for service access. Use the service access command, to configure the port or link aggregate for
service access. When LBD is enabled on ports without the 'service-access' keyword, the LBD behaves as
normal LBD feature.
LBD Packet Processing Mechanism for LBD Service Access Ports
The LBD packets on the service access ports are processed as follows:
1 If Virtual Private (VP) or Virtual Forwarding Instance (VFI) information is present in the packet
driver, then the LBD packet is processed else the packet is dropped.
2 The initiator session identifier (ISID) of the packet is extracted from the VP or VFI information and
compared with the LBD packet TLV ISID. If the ISID does not match, the packet is dropped.
3 If ISID matches, then the LBD packet TLV path cost is compared with the receiving LBD service
access port path cost. If the LBD path cost is lesser, the receiving access port is shut down. If LBD path
cost is higher, then the packet is dropped.
4 If path costs are equal, then LBD packet bridge MAC and receiving access port bridge MAC is
compared. If LBD packet bridge MAC is lesser, then the receiving access port is shutdown. If LBD Bridge
MAC is higher, then the packet is dropped.
5 If LBD packet bridge MAC and receiving access port bridge MAC are same (that is, same switch),
then LBD packet port ID and access port ID is compared. If LBD packet port ID is lesser, then the
receiving access port is shutdown. If LBD packet port ID is higher, then the packet is dropped.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 7-10
Configuring Loopback Detection
LBD for Service Access Interface
Sample Scenarios
Scenario 1
• Switch A and B are AOS switches running loopback-detection.
• Switch C is a legacy switch or a non AOS switch or a hub.
• 1/2 and 2/2 are SAP ports having same ISID and path cost.
• Loopback-detection is enabled with the service-access option on ports 1/2 and 2/2; traffic loops
through 1/2 and 2/2.
• Port 2/2 is shutdown in case B has higher bridge identifier, since 1/2 and 2/2 has equal path costs.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 7-11
Configuring Loopback Detection
LBD for Service Access Interface
Scenario 2
• Switch A and B are AOS switches running loopback-detection.
• Switch C is a legacy switch or a non AOS switch or a hub.
• 1/2 and 1/3 are SAP ports having same ISID and path cost.
• Loopback-detection is enabled with the service-access option on ports 1/2 and 1/3; traffic loops
through 1/2 and 1/3.
• Port 1/3 is shutdown as the interface has higher port identifier, since 1/2 and 1/3 has equal path costs.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 7-12
Configuring Loopback Detection
Verifying the LBD Configuration
Verifying the LBD Configuration
To display LBD configuration and statistics information, use the show commands listed below:
loopback-detection autorecovery- Displays the global LBD configuration information for the switch.
timer
show loopback-detection port
Displays LBD configuration information for all ports on the switch.
show loopback-detection statistics Displays LBD statistics information for a specific port on the switch.
port
For more information about the resulting display from these commands, see the OmniSwitch AOS Release
8 CLI Reference Guide.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 7-13
8
Configuring Static Link
Aggregation
The OmniSwitch implementation of static link aggregation software allows you to combine several
physical links into one large virtual link known as a link aggregation group. Using link aggregation
provides the following benefits:
• Scalability. It is possible to configure a maximum number of link aggregation groups as mentioned in
the “Network Configuration Specifications” chapter of the OmniSwitch AOS Release 8 Specifications
Guide.
• Reliability. A link aggregate can operate even if one of the physical links, that is part of the link
aggregate group, gets disabled.
• Ease of Migration. Link aggregation can ease the transition to higher bandwidth backbones.
In This Chapter
This chapter describes the basic components of static link aggregation and how to configure them through
the Command Line Interface (CLI). CLI commands are used in the configuration examples; for more
details about the syntax of commands, see the OmniSwitch AOS Release 8 CLI Reference Guide.
Configuration procedures described in this chapter include:
• “Configuring Static Link Aggregation Groups” .
• “Adding and Deleting Ports in a Static Aggregate Group”.
• “Modifying Static Aggregation Group Parameters”.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 8-1
Configuring Static Link Aggregation
Static Link Aggregation Default Values
Static Link Aggregation Default Values
The table below lists default values and the commands to modify them for static aggregate groups.
Parameter Description
Command
Administrative State
linkagg static agg admin-state enabled
Group Name
linkagg static agg name
OmniSwitch AOS Release 8 Network Configuration Guide
Default Value/Comments
September 2017
No name configured
page 8-2
Configuring Static Link Aggregation
Quick Steps for Configuring Static Link Aggregation
Quick Steps for Configuring Static Link
Aggregation
Follow the steps below for a quick tutorial on configuring a static aggregate link between two switches.
Additional information on how to configure each command is given in the subsections that follow.
1 Create the static aggregate link on the local switch with the linkagg static agg size command. For
example:
-> linkagg static agg 1 size 4
2 Assign all the necessary ports with the linkagg static port agg command. For example:
-> linkagg static port 1/1-4 agg 1
3 Create a VLAN for this static link aggregate group with the vlan members command. For example:
-> vlan 10 members port 1
4 Create the equivalent static aggregate link on the remote switch with the linkagg static agg size
command. For example:
-> linkagg static agg 1 size 4
5 Assign all the necessary ports with the linkagg static port agg command. For example:
-> linkagg static port 1/9-12 agg 1
6 Create a VLAN for this static link aggregate group with the vlan members command. For example:
-> vlan 10 members default 1
Note. Optional. You can verify your static link aggregation settings with the linkagg range command
along with the agg keyword and aggregate group ID. For example:
-> show linkagg agg 1
Static Aggregate
SNMP Id
: 40000001,
Aggregate Number
: 1,
SNMP Descriptor
: Omnichannel Aggregate Number 1 ref 40000001 size 4,
Name
: ,
Admin State
: ENABLED,
Operational State
: UP,
Aggregate Size
: 4,
Number of Selected Ports : 4,
Number of Reserved Ports : 4,
Number of Attached Ports : 4,
Primary Port
: 1/1
You can also use the show linkagg port port command to display information on specific ports. See
“Displaying Static Link Aggregation Configuration and Statistics” on page 8-11 for more information on
the show commands.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 8-3
Configuring Static Link Aggregation
Quick Steps for Configuring Static Link Aggregation
An example of what these commands look like entered sequentially on the command line on the local
switch:
-> linkagg static agg 1 size 4
-> linkagg static port 1/1-4 agg 1
-> vlan 10 port default 1
And an example of what these commands look like entered sequentially on the command line on the
remote switch:
-> linkagg static agg 1 size 4
-> linkagg static port 1/9-12 agg 1
-> vlan 10 port default 1
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 8-4
Configuring Static Link Aggregation
Static Link Aggregation Overview
Static Link Aggregation Overview
Link aggregation allows you to combine physical connections into large virtual connections known as link
aggregation groups.
You can create Virtual LANs (VLANs), 802.1Q framing, configure Quality of Service (QoS) conditions,
and other networking features on link aggregation groups because the OmnniSwitch AOS software treats
these virtual links just like physical links. (See “Relationship to Other Features” on page 8-6 for more
information on how link aggregation interacts with other software features.)
Load balancing for Layer 2 non-IP packets is on a MAC address basis. However when IP packets are
transmitted, the balancing algorithm uses the IP address. Ports must be of the same speed within the same
link aggregate group.
The OmniSwitch implementation of link aggregation software allows you to configure the following two
different types of link aggregation groups:
• Static link aggregate groups
• Dynamic link aggregate groups
This chapter describes static link aggregation. For information on dynamic link aggregation, please refer
to Chapter 9, “Configuring Dynamic Link Aggregation.”
Static Link Aggregation Operation
Static link aggregate groups are virtual links between two nodes consisting multiple physical links.
Static aggregate groups can be created between OmniSwitch platforms.
Note. Static aggregate groups cannot be created between an OmniSwitch and some switches from other
vendors.
The figure below shows a static aggregate group that has been configured between Switch A and Switch
B. The static aggregate group links four ports on a single NI on Switch A to two ports each on separate
NIs on Switch B. The network administrator has created a separate VLAN for this group so users can use
this high speed link.
Switch B
Switch A
Switch software treats the
static aggregate groups as
one large virtual link.
Static Group
Example of a Static Link Aggregate Group Network
See “Configuring Static Link Aggregation Groups” on page 8-6 for information on using Command Line
Interface (CLI) commands to configure static aggregate groups and see “Displaying Static Link
Aggregation Configuration and Statistics” on page 8-11 for information on using CLI to monitor static
aggregate groups.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 8-5
Configuring Static Link Aggregation
Configuring Static Link Aggregation Groups
Relationship to Other Features
Link aggregation groups are supported by other switch software features. The following features have CLI
commands or command parameters that support link aggregation:
• VLANs. For more information on VLANs see Chapter 4, “Configuring VLANs.”
• 802.1Q. For more information on configuring and monitoring 802.1Q see Chapter 4, “Configuring
VLANs.”
• Spanning Tree. For more information on Spanning Tree see Chapter 8, “Configuring Static Link
Aggregation.”
Note. See “Application Example” on page 8-10 for tutorials on using link aggregation with other features.
Configuring Static Link Aggregation Groups
This section describes how to use OmniSwitch Command Line Interface (CLI) commands to configure
static link aggregate groups. See “Configuring Mandatory Static Link Aggregate Parameters” on page 8-6
for more information.
Note. See “Quick Steps for Configuring Static Link Aggregation” on page 8-3 for a brief tutorial on
configuring these mandatory parameters.
The OmniSwitch implementation of link aggregation software is preconfigured with the default values for
static aggregate groups as shown in the table in “Static Link Aggregation Default Values” on page 8-2. If
you need to modify any of these parameters, please see “Modifying Static Aggregation Group Parameters”
on page 8-9 for more information.
Note. See the “Link Aggregation Commands” chapter in the OmniSwitch AOS Release 8 CLI Reference
Guide for complete documentation of CLI commands for link aggregation.
Configuring Mandatory Static Link Aggregate Parameters
When configuring static link aggregates on a switch you must perform the following steps:
1 Create the Static Aggregate Group on the Local and Remote Switches. To create a static aggregate
group use the linkagg static agg size command, which is described in “Creating and Deleting a Static
Link Aggregate Group” on page 8-7.
2 Assign Ports on the Local and Remote Switches to the Static Aggregate Group. To assign ports to
the static aggregate group you use the linkagg static port agg command, which is described in “Adding
and Deleting Ports in a Static Aggregate Group” on page 8-7.
Note. Depending on the needs of your network you need to configure additional parameters. Commands to
configure optional static aggregate parameters are described in “Modifying Static Aggregation Group
Parameters” on page 8-9.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 8-6
Configuring Static Link Aggregation
Configuring Static Link Aggregation Groups
Creating and Deleting a Static Link Aggregate Group
The following subsections describe how to create and delete static link aggregate groups with the linkagg
static agg size command.
Creating a Static Aggregate Group
To create a static aggregate group on a switch, enter linkagg static agg followed by the user-specified
aggregate number, size, and the number of links in the static aggregate group:
For example, to create static aggregate group 5 that consists of eight links, on a switch, enter:
-> linkagg static agg 5 size 8
Note. The number of links assigned to a static aggregate group must always be close to the number of
physical links that you plan to use. For example, if you are planning to use 2 physical links you should
create a group with a size of 2 and not 4 or 8.
As an option you can also specify a name and/or the administrative status of the group by entering linkagg
static agg followed by the user-specified aggregate number, size, the number of links in the static
aggregate group, name, the optional name, admin-state, and either enable or disable (the default is
enable).
For example, to create static aggregate group 5 called “static1” consisting of eight links that is
administratively disabled enter:
-> linkagg static agg 5 size 8 name static1 admin-state disable
Note. If you want to specify spaces within a name for a static aggregate group the name must be specified
within quotes (for example, “Static Aggregate Group 5”).
Deleting a Static Aggregate Group
To delete a static aggregation group from a switch use the no form of the linkagg static agg size
command by entering no linkagg static agg followed by the number that identifies the group. For
example, to remove static aggregate group 5 from the switch configuration, enter:
-> no linkagg static agg 5
Note. You must delete any attached ports with the linkagg static port agg command before you can delete
a static link aggregate group.
Adding and Deleting Ports in a Static Aggregate Group
The following subsections describe how to add and delete ports in a static aggregate group with the
linkagg static port agg command.
Adding Ports to a Static Aggregate Group
The number of ports assigned in a static aggregate group can be less than or equal to the maximum size
you specified in the linkagg static agg size command. To assign a port to a static aggregate group you use
the linkagg static port agg command by entering linkagg static port followed by the slot number, a slash
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 8-7
Configuring Static Link Aggregation
Configuring Static Link Aggregation Groups
(/), the port number, agg, and the number or ID of the static aggregate group.
For example, to assign ports 1, 2, and 3 in slot 1 to static aggregate group 10 (which has a size of 4), enter:
-> linkagg static port 1/1-3 agg 10
-> linkagg static port 1/2 agg 10
-> linkagg static port 1/3 agg 10
Note. A port belongs to only one aggregate group.
For example, to assign port 1 in slot 1 to static aggregate group 10, enter:
-> linkagg static port 1/1 agg 10
Removing Ports from a Static Aggregate Group
To remove a port from a static aggregate group you use the no form of the linkagg static port agg
command by entering no linkagg static port followed by the slot number, a slash (/), and the port
number. For example, to remove port 4 in slot 1 from a static aggregate group, enter:
-> no linkagg static port 1/4
Ports must be deleted in the reverse order in which they were assigned. For example, if port 9 through 16
were assigned to static aggregate group 2 you must first delete port 16, then port 15, and so forth. The
following is an example of how to delete ports in the proper sequence from the console:
-> no linkagg static port 1/24
-> no linkagg static port 1/23
-> no linkagg static port 1/22
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 8-8
Configuring Static Link Aggregation
Modifying Static Aggregation Group Parameters
Modifying Static Aggregation Group Parameters
This section describes how to modify the following static aggregate group parameters:
• Static aggregate group name (see “Modifying the Static Aggregate Group Name” on page 8-9)
• Static aggregate group administrative state (see “Modifying the Static Aggregate Group Administrative
State” on page 8-9)
Modifying the Static Aggregate Group Name
The following subsections describe how to modify the name of the static aggregate group with the linkagg
static agg name command.
Creating a Static Aggregate Group Name
To create a name for a static aggregate group by entering linkagg static agg followed by the number of
the static aggregate group, name, and the user-specified name of the group. For example, to configure
static aggregate group 4 with the name “Finance”, enter:
-> linkagg static agg 4 name Finance
Note. If you want to specify spaces within a name for a static aggregate group the name must be specified
within quotes (for example, “Static Aggregate Group 4”).
Deleting a Static Aggregate Group Name
To remove a name from a static aggregate group, use the no form of the linkagg static agg name
command by entering no linkagg static agg followed by the number of the static aggregate group and
name. For example, to remove any user-specified name from static aggregate group 4, enter:
-> no linkagg static agg 4 name
Modifying the Static Aggregate Group Administrative State
By default, the administrative state for a static aggregate group is enabled. The following subsections
describe how to enable and disable the administrative state with the linkagg static agg admin-state
command.
Enabling the Static Aggregate Group Administrative State
To enable a static aggregate group, enter linkagg static agg followed by the number of the group and
admin-state enable. For example, to enable static aggregate group 1, enter:
-> linkagg static agg 1 admin-state enable
Disabling the Static Aggregate Group Administrative State
To disable a static aggregate group by entering linkagg static agg followed by the number of the group
and admin-state disable. For example, to disable static aggregate group 1, enter:
-> linkagg static agg 1 admin-state disable
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 8-9
Configuring Static Link Aggregation
Application Example
Application Example
Static link aggregation groups are treated by the switch software the same way it treats individual physical
ports. This section demonstrates this by providing a sample network configuration that uses static link
aggregation along with other software features. In addition, a tutorial is provided that shows how to
configure this sample network using Command Line Interface (CLI) commands.
The figure below shows VLAN 8, which has been configured on static aggregate 1 and uses 802.1Q
tagging. The actual physical links connect ports 4/1, 4/2, 4/3, and 4/4 on Switch A to port 2/41, 2/42, 2/43,
and 2/44 on Switch B.
Switch B
Switch A
Static Aggregate Group 1
VLAN 8 with 802.1Q tagging has
been configured to use this group.
Sample Network Using Static Link Aggregation
Follow the steps below to configure this network:
Note. Only the steps to configure the local (i.e., Switch A) switch are provided here since the steps to
configure the remote (i.e., Switch B) switch are similar.
1 Configure static aggregate group 1 by entering linkagg static agg 1 size 4 as shown below:
-> linkagg static agg 1 size 4
2 Assign ports 4/1, 4/2, 4/3, and 4/4 to static aggregate group 1 by entering:
-> linkagg static port 4/1-4 agg 1
3 Create VLAN 8 by entering:
-> vlan 8
4 Configure 802.1Q tagging with a tagging ID of 8 on static aggregate group 1 (on VLAN 8) by
entering:
-> vlan 8 members linkagg 1 tagged
5 Repeat steps 1 through 4 on Switch B. Substitute the port numbers of the commands with the
appropriate port numbers of Switch B.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 8-10
Configuring Static Link Aggregation
Displaying Static Link Aggregation Configuration and Statistics
Displaying Static Link Aggregation Configuration
and Statistics
You can use Command Line Interface (CLI) show commands to display the current configuration and
statistics of link aggregation. These commands include the following:
linkagg range
Displays information on link aggregation groups.
show linkagg port
Displays information on link aggregation ports.
When you use the show linkagg command without specifying the link aggregation group number and
when you use the show linkagg port command without specifying the slot and port number these
commands provide a “global” view of switch-wide link aggregate group and link aggregate port
information, respectively.
For example, to display global statistics on all link aggregate groups (both static and dynamic), enter:
-> show linkagg
Number Aggregate SNMP Id Size Admin State Oper State Att/Sel Ports
-------+--------+--------+-----+-----------+----------+-------+-----+
1
Static
40000001 4
ENABLED
DOWN
0
0
2
Static
40000002 8
ENABLED
DOWN
0
0
10
Dynamic 40000010 8
ENABLED
DOWN
0
0
For example, to display global statistics on all ports associated with link aggregate groups (both static and
dynamic), enter:
-> show linkagg port
Slot/Port Aggregate SNMP Id Status
Agg Oper Link Prim
---------+----------+--------+--------+---+----+----+----2/1
Static
2001
ATTACHED 1
UP
UP
YES
When you use the show linkagg agg command with the link aggregation group number and when you use
the show linkagg port command with the slot and port number these commands provide detailed views of
link aggregate group and link aggregate port information, respectively. These detailed views provide
excellent tools for diagnosing and troubleshooting problems.
For example, to display detailed statistics for port 1 in slot 2 that is attached to static link aggregate group
1, enter:
-> show linkagg port 4/1
Static Aggregable Port
SNMP Id
:
Slot/Port
:
Administrative State
:
Operational State
:
Port State
:
Link State
:
Selected Agg Number
:
Port position in the aggregate:
Primary port
:
2001,
4/1,
ENABLED,
UP,
ATTACHED,
UP,
1,
0,
YES
See the “Link Aggregation Commands” chapter in the OmniSwitch AOS Release 8 CLI Reference Guide
for complete documentation of show commands for link aggregation.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 8-11
9
Configuring Dynamic Link
Aggregation
The OmniSwitch implementation of dynamic link aggregation software allows you to combine several
physical links into one large virtual link known as a link aggregation group. Using link aggregation
provides the following benefits:
• Scalability. It is possible to configure a maximum number of link aggregation groups as mentioned in
the “Network Configuration Specifications” chapter of the OmniSwitch AOS Release 8 Specifications
Guide.
• Reliability. If one of the physical links in a link aggregate group goes down (unless it is the last one)
the link aggregate group can still operate.
• Ease of Migration. Link aggregation can ease the transition to higher bandwidth backbones.
In This Chapter
This chapter describes the basic components of dynamic link aggregation and how to configure them
through the Command Line Interface (CLI). CLI commands are used in the configuration examples; for
more details about the syntax of commands, see the OmniSwitch AOS Release 8 CLI Reference Guide.
Configuration procedures described in this chapter include:
• Configuring dynamic link aggregation groups on “Configuring Dynamic Link Aggregate Groups” on
page 9-7.
• Configuring ports so they can be aggregated in dynamic link aggregation groups on “Configuring Ports
to Join and Removing Ports in a Dynamic Aggregate Group” on page 9-9.
• Modifying dynamic link aggregation parameters on “Modifying Dynamic Link Aggregate Group
Parameters” on page 9-11.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 9-1
Configuring Dynamic Link Aggregation
Dynamic Link Aggregation Default Values
Dynamic Link Aggregation Default Values
The table below lists default values for dynamic aggregate groups.
Parameter Description
Command
Default Value/Comments
Group Administrative State
linkagg lacp agg admin-state
enabled
Group Name
linkagg lacp agg name
No name configured
Group Actor Administrative Key
linkagg lacp agg actor admin-key
0
Group Actor System Priority
linkagg lacp agg actor systempriority
0
Group Actor System ID
linkagg lacp agg actor system-id
00:00:00:00:00:00
Group Partner System ID
linkagg lacp agg partner system-id
00:00:00:00:00:00
Group Partner System Priority
linkagg lacp agg partner systempriority
0
Group Partner Administrative Key
linkagg lacp agg partner admin-key 0
Actor Port Administrative State
linkagg lacp agg admin-state
active timeout aggregate
Actor Port System ID
linkagg lacp agg actor system-id
00:00:00:00:00:00
Partner Port System Administrative linkagg lacp agg partner adminState
state
active timeout aggregate
Partner Port Admin System ID
linkagg lacp port partner admin
system-priority
00:00:00:00:00:00
Partner Port Administrative Key
linkagg lacp agg partner admin-key 0
Partner Port Admin System Priority linkagg lacp agg partner systempriority
0
Actor Port Priority
linkagg lacp port actor port priority 0
Partner Port Administrative Port
linkagg lacp port partner adminport
0
Partner Port Priority
linkagg lacp port partner admin
port-priority
0
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 9-2
Configuring Dynamic Link Aggregation
Quick Steps for Configuring Dynamic Link Aggregation
Quick Steps for Configuring Dynamic Link
Aggregation
Follow the steps below for a quick tutorial on configuring a dynamic aggregate link between two switches.
Additional information on how to configure each command is given in the subsections that follow.
1 Create the dynamic aggregate group on the local (actor) switch with the linkagg lacp agg size
command as shown below:
-> linkagg lacp agg 2 size 8 actor admin-key 5
2 Configure ports (the number of ports must be less than or equal to the size value set in step 1) with the
same actor administrative key (which allows them to be aggregated) with the linkagg lacp agg actor
admin-key command. For example:
->
->
->
->
->
->
->
linkagg
linkagg
linkagg
linkagg
linkagg
linkagg
linkagg
lacp
lacp
lacp
lacp
lacp
lacp
lacp
port
port
port
port
port
port
port
1/1 actor admin-key 5
1/4 actor admin-key 5
3/3 actor admin-key 5
5/4 actor admin-key 5
6/1-2 actor admin-key 5
7/3 actor admin-key 5
8/1 actor admin-key 5
3 Create a VLAN for this dynamic link aggregate group with the vlan command. For example:
-> vlan 2 members port 2/3 untagged
4 Create the equivalent dynamic aggregate group on the remote (partner) switch with the linkagg lacp
agg size command as shown below:
-> linkagg lacp agg 2 size 8 actor admin-key 5
5 Configure ports (the number of ports must be less than or equal to the size value set in step 4) with the
same actor administrative key (which allows them to be aggregated) with the linkagg lacp agg actor
admin-key command. For example:
->
->
->
->
->
->
->
->
linkagg
linkagg
linkagg
linkagg
linkagg
linkagg
linkagg
linkagg
lacp
lacp
lacp
lacp
lacp
lacp
lacp
lacp
port
port
port
port
port
port
port
port
2/1
3/1
3/3
3/6
5/1
5/6
8/1
8/3
actor
actor
actor
actor
actor
actor
actor
actor
admin-key
admin-key
admin-key
admin-key
admin-key
admin-key
admin-key
admin-key
5
5
5
5
5
5
5
5
6 Create a VLAN for this dynamic link aggregate group with the vlan command. For example:
-> vlan 2 members linkagg 2
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 9-3
Configuring Dynamic Link Aggregation
Quick Steps for Configuring Dynamic Link Aggregation
Note. As an option, you can verify your dynamic aggregation group settings with the linkagg range
command on either the actor or the partner switch. For example:
-> show linkagg agg 2
Dynamic Aggregate
SNMP Id
:
Aggregate Number
:
SNMP Descriptor
:
Name
:
Admin State
:
Operational State
:
Aggregate Size
:
Number of Selected Ports :
Number of Reserved Ports :
Number of Attached Ports :
Primary Port
:
LACP
MACAddress
:
Actor System Id
:
Actor System Priority
:
Actor Admin Key
:
Actor Oper Key
:
Partner System Id
:
Partner System Priority :
Partner Admin Key
:
Partner Oper Key
:
40000002,
2,
Dynamic Aggregate Number 2 ref 40000002 size 8,
,
ENABLED,
UP,
8,
8,
8,
8,
1/1,
[00:1f:cc:00:00:00],
[00:20:da:81:d5:b0],
0,
5,
0,
[00:20:da:81:d5:b1],
0,
5,
0
When multi-chassis link aggregation feature is activated on the switch, the show linkagg agg command
displays the output as MC-Dynamic aggregate.
You can also use the show linkagg port port command to display information on specific ports. See
“Displaying Dynamic Link Aggregation Configuration and Statistics” on page 9-28 for more information
on show commands.
An example of what these commands look like entered sequentially on the command line on the actor
switch:
->
->
->
->
->
->
->
->
->
linkagg lacp agg 2 size 8 actor admin-key 5
linkagg lacp port 1/1 actor admin-key 5
linkagg lacp port 1/4 actor admin-key 5
linkagg lacp port 3/3 actor admin-key 5
linkagg lacp port 5/4 actor admin-key 5
linkagg lacp port 6/1-2 actor admin-key 5
linkagg lacp port 7/3 actor admin-key 5
linkagg lacp port 8/1 actor admin-key 5
vlan 2 port default 2
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 9-4
Configuring Dynamic Link Aggregation
Dynamic Link Aggregation Overview
An example of what these commands look like entered sequentially on the command line on the partner
switch:
->
->
->
->
->
->
->
->
->
->
linkagg lacp agg 2 size 8 actor admin-key 5
linkagg lacp port 2/1 actor admin-key 5
linkagg lacp port 3/1 actor admin-key 5
linkagg lacp port 3/3 actor admin-key 5
linkagg lacp port 3/6 actor admin-key 5
linkagg lacp port 5/1 actor admin-key 5
linkagg lacp port 5/6 actor admin-key 5
linkagg lacp port 8/1 actor admin-key 5
linkagg lacp port 8/3 actor admin-key 5
vlan 2 port default 2
Dynamic Link Aggregation Overview
Link aggregation allows you to combine physical connections into large virtual connections known as link
aggregation groups.
You can create Virtual LANs (VLANs), 802.1Q framing, configure Quality of Service (QoS) conditions,
and other networking features on link aggregation groups because switch software treats these virtual links
just like physical links. (See “Relationship to Other Features” on page 9-7 for more information on how
link aggregation interacts with other software features.)
Link aggregation groups are identified by unique MAC addresses, which are created by the switch but can
be modified by the user at any time. Load balancing for Layer 2 non-IP packets is on a MAC address basis
and for IP packets the balancing algorithm uses the IP address as well. Ports must be of the same speed
within the same aggregate group.
The OmniSwitch implementation of link aggregation software allows you to configure the following two
different types of link aggregation groups:
• Static link aggregate groups
• Dynamic link aggregate groups
This chapter describes dynamic link aggregation. For information on static link aggregation, please refer
to Chapter 8, “Configuring Static Link Aggregation.”
Dynamic Link Aggregation Operation
Dynamic aggregate groups are virtual links between two nodes consisting of physical links. Dynamic
aggregate groups use the standard IEEE 802.3ad Link Aggregation Control Protocol (LACP) to
dynamically establish the best possible configuration for the group. This task is accomplished by special
Link Aggregation Control Protocol Data Unit (LACPDU) frames that are sent and received by switches on
both sides of the link to monitor and maintain the dynamic aggregate group.
The figure on the following page shows a dynamic aggregate group that has been configured between
Switch A and Switch B. The dynamic aggregate group links four ports on Switch A to four ports on
Switch B.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 9-5
Configuring Dynamic Link Aggregation
Dynamic Link Aggregation Overview
Local (Actor) Switch
Remote (Partner) Switch
1. Local (actor) switch sends
requests to establish a
dynamic aggregate group link
to the remote (partner)
switch.
2. Partner switch acknowledges that it can accept this
dynamic group.
3. Actor and partner switches
negotiate parameters for the
dynamic group, producing
optimal settings.
Dynamic Group
4. Actor and partner switches
establish the dynamic aggregate group. LACPDU messages are sent back and forth
to monitor and maintain the
group.
Example of a Dynamic Aggregate Group Network
See “Configuring Dynamic Link Aggregate Groups” on page 9-7 for information on using Command Line
Interface (CLI) commands to configure dynamic aggregate groups and see “Displaying Dynamic Link
Aggregation Configuration and Statistics” on page 9-28 for information on using the CLI to monitor
dynamic aggregate groups.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 9-6
Configuring Dynamic Link Aggregation
Configuring Dynamic Link Aggregate Groups
Relationship to Other Features
Link aggregation groups are supported by other switch software features. For example, you can configure
802.1Q tagging on link aggregation groups in addition to configuring it on individual ports. The following
features have CLI commands or command parameters that support link aggregation:
• VLANs. For more information on VLANs, see Chapter 4, “Configuring VLANs.”
• 802.1Q. For more information on configuring and monitoring 802.1Q, see Chapter 4, “Configuring
VLANs.”
• Spanning Tree. For more information on Spanning Tree, see Chapter 6, “Configuring Spanning Tree
Parameters.”
Note. See “Application Examples” on page 9-25 for tutorials on using link aggregation with other features.
Configuring Dynamic Link Aggregate Groups
This section describes how to use Command Line Interface (CLI) commands to create, modify, and delete
dynamic aggregate groups. See “Configuring Mandatory Dynamic Link Aggregate Parameters” on
page 9-8 for more information.
Note. See “Quick Steps for Configuring Dynamic Link Aggregation” on page 9-3 for a brief tutorial on
configuring these mandatory parameters.
The OmniSwitch implementation of link aggregation software is preconfigured with the default values for
dynamic aggregate groups and ports shown in the table in “Dynamic Link Aggregation Default Values”
on page 9-2. For most configurations, using only the steps described in “Creating and Deleting a Dynamic
Aggregate Group” on page 9-8 is necessary to configure a dynamic link aggregate group. However, if you
need to modify any of the parameters listed in the table on page 9-2, please see “Modifying Dynamic Link
Aggregate Group Parameters” on page 9-11 for more information.
Note. See the “Link Aggregation Commands” chapter in the OmniSwitch AOS Release 8 CLI Reference
Guide for complete documentation of show commands for link aggregation.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 9-7
Configuring Dynamic Link Aggregation
Configuring Dynamic Link Aggregate Groups
Configuring Mandatory Dynamic Link Aggregate Parameters
When configuring LACP link aggregates on a switch you must perform the following steps:
1 Create the Dynamic Aggregate Groups on the Local (Actor) and Remote (Partner) Switches. To
create a dynamic aggregate group use the linkagg lacp agg size command, which is described in “Creating and Deleting a Dynamic Aggregate Group” on page 9-8.
2 Configure the Same Administrative Key on the Ports You Want to Join the Dynamic Aggregate
Group. To configure ports with the same administrative key (which allows them to be aggregated), use
the linkagg lacp agg actor admin-key command, which is described in “Configuring Ports to Join and
Removing Ports in a Dynamic Aggregate Group” on page 9-9.
Note. Depending on the needs of your network you need to configure additional parameters. Commands to
configure optional dynamic link aggregate parameters are described in “Modifying Dynamic Link
Aggregate Group Parameters” on page 9-11.These commands must be executed after you create a dynamic
aggregate group.
Creating and Deleting a Dynamic Aggregate Group
The following subsections describe how to create and delete dynamic aggregate groups with the linkagg
lacp agg size command.
Creating a Dynamic Aggregate Group
To configure a dynamic aggregate group, enter linkagg lacp agg followed by the user-configured
dynamic aggregate number, size, and the maximum number of links that belong to this dynamic aggregate
group. For example, to configure the dynamic aggregate group 2 consisting of eight links enter:
-> linkagg lacp agg 2 size 8
You can create link aggregation (both static and dynamic) groups for a standalone or a chassis-based
switch. In addition, you can also specify optional parameters shown in the table below. These parameters
must be entered after size and the user-specified number of links.
linkagg lacp agg size keywords
name
actor system-priority
partner system-priority
admin state enable
admin state disable
actor system-id
partner admin-key
actor admin-key
partner system-id
For example, assigning the actor admin key when you create the dynamic aggregate group is
recommended to help ensure that ports are assigned to the correct group. To create a dynamic aggregate
group with aggregate number 3 consisting of two ports with an admin actor key of 10, for example, enter:
-> linkagg lacp agg 3 size 2 actor admin-key 10
Note. The optional keywords for this command can be entered in any order as long as they are entered after
size and the user-specified number of links.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 9-8
Configuring Dynamic Link Aggregation
Configuring Dynamic Link Aggregate Groups
Deleting a Dynamic Aggregate Group
To remove a dynamic aggregation group configuration from a switch use the no form of the linkagg lacp
agg size command by entering no linkagg lacp agg followed by its dynamic aggregate group number.
For example, to delete dynamic aggregate group 2 from the switch configuration, enter:
-> no linkagg lacp agg 2
Note. You cannot delete a dynamic aggregate group if it has any attached ports. To remove attached ports
you must disable the dynamic aggregate group with the linkagg lacp agg admin-state command, which is
described in “Disabling a Dynamic Aggregate Group” on page 9-12.
Configuring Ports to Join and Removing Ports in a Dynamic
Aggregate Group
The following subsections describe how to configure ports with the same administrative key (which
allows them to be aggregated) or to remove them from a dynamic aggregate group with the linkagg lacp
agg actor admin-key command.
Configuring Ports To Join a Dynamic Aggregate Group
To configure ports with the same administrative key (which allows them to be aggregated) enter lacp port
followed by the slot number, a slash (/), the port number, actor admin-key, and the user-specified actor
administrative key. Ports must be of the same speed.
For example, to configure ports 1, 2, and 3 in slot 4 with an administrative key of 10, enter:
-> linkagg lacp port 4/1-3 actor admin-key 10
Note. A port can belong to only one aggregate group.
You must execute the linkagg lacp port actor admin-key command on all ports in a dynamic aggregate
group. If not, the ports are unable to join the group.
In addition, you can also specify optional parameters shown in the table below. These keywords must be
entered after the actor admin-key and the user-specified actor administrative key value.
lacp agg actor admin-key
keywords
actor admin-state
actor system-priority
partner admin-system-priority
partner admin port-priority
partner admin-state
partner admin system-id
actor port-priority
actor system-id
partner admin-key
partner admin-port
Note. The actor admin-state and partner admin-state keywords have additional parameters, which are
described in “Modifying the Actor Port System Administrative State” on page 9-16 and “Modifying the
Partner Port System Administrative State” on page 9-20, respectively.
All of the optional keywords listed above for this command can be entered in any order as long as they
appear after the actor admin-key keywords and their user-specified value.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 9-9
Configuring Dynamic Link Aggregation
Configuring Dynamic Link Aggregate Groups
For example, to configure actor administrative key of 10, a local system ID (MAC address) of
00:20:da:06:ba:d3, and a local priority of 65535 to slot 4 port 1, enter:
-> linkagg lacp port 4/1 actor admin-key 10 actor system-id 00:20:da:06:ba:d3
actor system-priority 65535
For example, to configure an actor administrative key of 10 to slot 4 port 1, enter:
-> linkagg lacp port 4/1 actor admin-key 10
Removing Ports from a Dynamic Aggregate Group
To remove a port from a dynamic aggregate group, use the no form of the linkagg lacp agg actor adminkey command by entering linkagg lacp port followed by the slot number, a slash (/), and the port number.
For example, to remove port 4 in slot 4 from any dynamic aggregate group, enter:
-> no linkagg lacp port 4/4
Ports must be deleted in the reverse order in which they were configured. For example, if port 4/4 through
4/6 were configured to join dynamic aggregate group 2 you must first delete port 4/6, then port 4/5, and so
forth. The following is an example of how to delete ports in the proper sequence from the console:
-> no linkagg lacp port 4/6
-> no linkagg lacp port 4/5
-> no linkagg lacp port 4/4
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 9-10
Configuring Dynamic Link Aggregation
Modifying Dynamic Link Aggregate Group Parameters
Modifying Dynamic Link Aggregate Group
Parameters
The table on page 9-2 lists default group and port settings for the OmniSwitch implementation of Dynamic
Link Aggregation. These parameters ensure compliance with the IEEE 802.3ad specification. For most
networks, these default values need not be modified or can be modified automatically by the switch
software. However, if you need to modify any of these default settings, see the following sections to
modify the parameters for:
• Dynamic aggregate groups on page 9-11
• Dynamic aggregate actor ports on page 9-16
• Dynamic aggregate partner ports on page 9-19
Note. You must create a dynamic aggregate group before you can modify group or port parameters. See
“Configuring Dynamic Link Aggregate Groups” on page 9-7 for more information.
Modifying Dynamic Aggregate Group Parameters
This section describes how to modify the following dynamic aggregate group parameters:
• Group name (see “Modifying the Dynamic Aggregate Group Name” on page 9-12)
• Group administrative state (see “Modifying the Dynamic Aggregate Group Administrative State” on
page 9-12)
• Group local (actor) switch actor administrative key (see “Configuring and Deleting the Dynamic
Aggregate Group Actor Administrative Key” on page 9-13)
• Group local (actor) switch system priority (see “Modifying the Dynamic Aggregate Group Actor
System Priority” on page 9-13)
• Group local (actor) switch system ID (see “Modifying the Dynamic Aggregate Group Actor System
ID” on page 9-14)
• Group remote (partner) administrative key (see “Modifying the Dynamic Aggregate Group Partner
Administrative Key” on page 9-14)
• Group remote (partner) system priority (see “Modifying the Dynamic Aggregate Group Partner System
Priority” on page 9-15)
• Group remote (partner) switch system ID (see “Modifying the Dynamic Aggregate Group Partner
System ID” on page 9-15)
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 9-11
Configuring Dynamic Link Aggregation
Modifying Dynamic Link Aggregate Group Parameters
Modifying the Dynamic Aggregate Group Name
The following subsections describe how to configure and remove a dynamic aggregate group name with
the linkagg lacp agg name command.
Configuring a Dynamic Aggregate Group name
To configure a dynamic aggregate group name, enter linkagg lacp agg followed by the dynamic aggregate
group number, name, and the user-specified name.
For example, to name dynamic aggregate group 4 “Engineering”, enter:
-> linkagg lacp agg 4 name Engineering
Note. If you want to specify spaces within a name, the name must be enclosed in quotes. For example:
-> linkagg lacp agg 4 name "Engineering Lab"
Deleting a Dynamic Aggregate Group Name
To remove a dynamic aggregate group name from the configuration of a switch, use the no form of the
linkagg lacp agg name command by entering linkagg lacp agg followed by the dynamic aggregate group
number and no name.
For example, to remove any user-configured name from dynamic aggregate group 4, enter:
-> no linkagg lacp agg 4 name
Modifying the Dynamic Aggregate Group Administrative State
By default, the dynamic aggregate group administrative state is enabled. The following subsections
describe how to enable and disable the administrative state of a dynamic aggregate group with the linkagg
lacp agg admin-state command.
Enabling a Dynamic Aggregate Group
To enable the dynamic aggregate group administrative state, enter linkagg lacp agg followed by the
dynamic aggregate group number and admin-state enable. For example, to enable dynamic aggregate
group 4, enter:
-> linkagg lacp agg 4 admin-state enable
Disabling a Dynamic Aggregate Group
To disable the administrative state of a dynamic aggregate group, use the linkagg lacp agg admin-state
command by entering linkagg lacp agg followed by the dynamic aggregate group number and adminstate disable.
For example, to disable dynamic aggregate group 4, enter:
-> linkagg lacp agg 4 admin-state disable
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 9-12
Configuring Dynamic Link Aggregation
Modifying Dynamic Link Aggregate Group Parameters
Configuring and Deleting the Dynamic Aggregate Group Actor
Administrative Key
The following subsections describe how to configure and delete a dynamic aggregate group actor
administrative key with the linkagg lacp agg actor admin-key command.
Configuring a Dynamic Aggregate Actor Administrative Key
To configure the dynamic aggregate group actor switch administrative key, enter linkagg lacp agg
followed by the dynamic aggregate group number, actor admin-key, and the value for the administrative
key.
For example, to configure dynamic aggregate group 4 with an administrative key of 10, enter:
-> linkagg lacp agg 4 actor admin-key 10
Deleting a Dynamic Aggregate Actor Administrative Key
To remove an actor switch administrative key from the configuration of a dynamic aggregate group, use
the no form of the linkagg lacp agg actor admin-key command by entering linkagg lacp agg followed
by the dynamic aggregate group number and the actor admin-key parameter.
For example, to remove an administrative key from dynamic aggregate group 4, enter:
-> no linkagg lacp agg 4 actor admin-key
Modifying the Dynamic Aggregate Group Actor System Priority
By default, the dynamic aggregate group actor system priority is 0. The following subsections describe
how to configure a user-specified value and how to restore the value to its default value with the linkagg
lacp agg actor system-priority command.
Configuring a Dynamic Aggregate Group Actor System Priority
You can configure a user-specified dynamic aggregate group actor system priority value by entering
linkagg lacp agg followed by the dynamic aggregate group number, actor system-priority, and the new
priority value.
For example, to change the actor system priority of dynamic aggregate group 4 to 2000, enter:
-> linkagg lacp agg 4 actor system-priority 2000
Restoring the Dynamic Aggregate Group Actor System Priority
To restore the dynamic aggregate group actor system priority to its default (0) value use the no form of the
linkagg lacp agg actor system-priority command by entering no linkagg lacp agg followed by the
dynamic aggregate group number and no actor system priority.
For example, to restore the actor system priority to its default value on dynamic aggregate group 4, enter:
-> no linkagg lacp agg 4 actor system-priority
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 9-13
Configuring Dynamic Link Aggregation
Modifying Dynamic Link Aggregate Group Parameters
Modifying the Dynamic Aggregate Group Actor System ID
By default, the dynamic aggregate group actor system ID (MAC address) is 00:00:00:00:00:00. The
following subsections describe how to configure a user-specified value and how to restore the value to its
default value with the linkagg lacp agg actor system-id command.
Configuring a Dynamic Aggregate Group Actor System ID
You can configure a user-specified dynamic aggregate group actor system ID by entering linkagg lacp
agg followed by the dynamic aggregate group number, actor system-id, and the user-specified MAC
address (in the hexadecimal format of xx:xx:xx:xx:xx:xx), which is used as the system ID.
For example, to configure the system ID on dynamic aggregate group 4 as 00:20:da:81:d5:b0, enter:
-> linkagg lacp agg 4 actor system-id 00:20:da:81:d5:b0
Restoring the Dynamic Aggregate Group Actor System ID
To remove the user-configured actor switch system ID from the configuration of a dynamic aggregate
group, use the no form of the linkagg lacp agg actor system-id command by entering linkagg lacp agg
followed by the dynamic aggregate group number and actor system-id.
For example, to remove the user-configured system ID from dynamic aggregate group 4, enter:
-> no linkagg lacp agg 4 actor system-id
Modifying the Dynamic Aggregate Group Partner Administrative Key
By default, the dynamic aggregate group partner administrative key (the administrative key of the partner
switch) is 0. The following subsections describe how to configure a user-specified value and how to
restore the value to its default value with the linkagg lacp agg partner admin-key command.
Configuring a Dynamic Aggregate Group Partner Administrative Key
You can modify the dynamic aggregate group partner administrative key to a value ranging from 0 to
65535 by entering linkagg lacp agg followed by the dynamic aggregate group number, partner adminkey parameter, and the value for the administrative key.
For example, to set the partner administrative key to 4 on dynamic aggregate group 4, enter:
-> linkagg lacp agg 4 partner admin-key 10
Restoring the Dynamic Aggregate Group Partner Administrative Key
To remove a partner administrative key from the configuration of a dynamic aggregate group, use the no
form of the linkagg lacp agg partner admin-key command by entering no linkagg lacp agg followed by
the dynamic aggregate group number and the partner admin-key parameter.
For example, to remove the user-configured partner administrative key from dynamic aggregate group 4,
enter:
-> no linkagg lacp agg 4 partner admin-key
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 9-14
Configuring Dynamic Link Aggregation
Modifying Dynamic Link Aggregate Group Parameters
Modifying the Dynamic Aggregate Group Partner System Priority
By default, the dynamic aggregate group partner system priority is 0. The following subsections describe
how to configure a user-specified value and how to restore the value to its default value with the linkagg
lacp agg partner system-priority command.
Configuring a Dynamic Aggregate Group Partner System Priority
You can modify the dynamic aggregate group partner system priority to a value by entering linkagg lacp
agg followed by the dynamic aggregate group number, partner system-priority, and the new priority
value.
For example, to set the partner system priority on dynamic aggregate group 4 to 2000, enter:
-> linkagg lacp agg 4 partner system-priority 2000
Restoring the Dynamic Aggregate Group Partner System Priority
To restore the dynamic aggregate group partner system priority to its default (0) value use the no form of
the linkagg lacp agg partner system-priority command by entering no linkagg lacp agg followed by the
dynamic aggregate group number and partner system-priority.
For example, to reset the partner system priority of dynamic aggregate group 4 to its default value, enter:
-> no linkagg lacp agg 4 partner system-priority
Modifying the Dynamic Aggregate Group Partner System ID
By default, the dynamic aggregate group partner system ID is 00:00:00:00:00:00. The following
subsections describe how to configure a user-specified value and how to restore it to its default value with
the linkagg lacp agg partner system-id command.
Configuring a Dynamic Aggregate Group Partner System ID
You can configure the dynamic aggregate group partner system ID by entering linkagg lacp agg followed
by the dynamic aggregate group number, partner system-id, and the user-specified MAC address (in the
hexadecimal format of xx:xx:xx:xx:xx:xx), which is used as the system ID.
For example, to configure the partner system ID as 00:20:da:81:d5:b0 on dynamic aggregate group 4,
enter:
-> linkagg lacp agg 4 partner system-id 00:20:da:81:d5:b0
Restoring the Dynamic Aggregate Group Partner System ID
To remove the user-configured partner switch system ID from the configuration of a dynamic aggregate
group, use the no form of the linkagg lacp agg partner system-id command by entering no linkagg lacp
agg followed by the dynamic aggregate group number and the partner system-id parameter.
For example, to remove the user-configured partner system ID from dynamic aggregate group 4, enter:
-> no linkagg lacp agg 4 partner system-id
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 9-15
Configuring Dynamic Link Aggregation
Modifying Dynamic Link Aggregate Group Parameters
Modifying Dynamic Link Aggregate Actor Port Parameters
This section describes how to modify the following dynamic aggregate actor port parameters:
• Actor port administrative state (see “Modifying the Actor Port System Administrative State” on
page 9-16)
• Actor port system ID (see “Modifying the Actor Port System ID” on page 9-17)
• Actor port system priority (see “Modifying the Actor Port System Priority” on page 9-18)
• Actor port priority (see “Modifying the Actor Port Priority” on page 9-19)
Notes.
• See “Configuring Ports to Join and Removing Ports in a Dynamic Aggregate Group” on page 9-9 for
information on modifying a dynamic aggregate group administrative key.
• A port can belong to only one aggregate group.
Modifying the Actor Port System Administrative State
The system administrative state of a dynamic aggregate group actor port is indicated by bit settings in
Link Aggregation Control Protocol Data Unit (LACPDU) frames sent by the port. By default, bits 0
(indicate that the port is active), 1 (indicate that short timeouts are used for LACPDU frames), and 2
(indicate that this port is available for aggregation) are set in LACPDU frames.
The following subsections describe how to configure user-specified values and how to restore them to
their default values with the linkagg lacp agg admin-state command.
Configuring Actor Port Administrative State Values
To configure the system administrative state values of the LACP actor port, enter linkagg lacp port, the
slot number, a slash (/), the port number, actor admin-state, and one or more of the keywords shown in
the table below or use the none keyword:
linkagg lacp agg actor
admin-state Keyword
Definition
active
Specifies that bit 0 in LACPDU frames is set, which indicates that the
link is able to exchange LACPDU frames. By default, this bit is set.
timeout
Specifies that bit 1 in LACPDU frames is set, which indicates that a
short time-out is used for LACPDU frames. When this bit is disabled, a
long time-out is used for LACPDU frames. By default, this bit is set.
aggregate
Specifies that bit 2 in LACPDU frames is set, which indicates that the
system considers this link to be a potential candidate for aggregation. If
this bit is not set, the system considers the link to be individual (it can
only operate as a single link). By default, this bit is set.
synchronize
Specifying this keyword has no effect because the system always
determines its value. When this bit (bit 3) is set by the system, the port
is allocated to the correct dynamic aggregation group. If this bit is not
set by the system, the port is not allocated to the correct dynamic
aggregation group.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 9-16
Configuring Dynamic Link Aggregation
linkagg lacp agg actor
admin-state Keyword
Modifying Dynamic Link Aggregate Group Parameters
Definition
collect
Specifying this keyword has no effect because the system always
determines its value. When this bit (bit 4) is set by the system,
incoming LACPDU frames are collected from the individual ports that
make up the dynamic aggregate group.
distribute
Specifying this keyword has no effect because the system always
determines its value. When this bit (bit 5) is set by the system,
distributing outgoing frames on the port is disabled.
default
Specifying this keyword has no effect because the system always
determines its value. When this bit (bit 6) is set by the system, it
indicates that the actor is using defaulted partner information
administratively configured for the partner.
expire
Specifying this keyword has no effect because the system always
determines its value. When this bit (bit 7) is set by the system, the actor
cannot receive LACPDU frames.
Note. Specifying none removes all administrative states from the LACPDU configuration. For example:
-> linkagg lacp port 5/49 actor admin-state none
For example, to set bits 0 (active) and 2 (aggregate) on dynamic aggregate actor port 49 in slot 5 you
would enter:
-> linkagg lacp port 5/49 actor admin-state active aggregate
For example, to set bits 0 (active) and 2 (aggregate) on dynamic aggregate actor port 49 in slot 5, enter:
-> linkagg lacp port 5/49 actor admin-state active aggregate
Restoring Actor Port Administrative State Values
To restore LACPDU bit settings to their default values, use the no form of the linkagg lacp port actor
admin-state command by entering the active, timeout, and aggregate keywords.
For example, to restore bits 0 (active) and 2 (aggregate) to their default settings on dynamic aggregate
actor port 2 in slot 5, enter:
-> no linkagg lacp port 5/2 actor admin-state active aggregate
Note. Since individual bits with the LACPDU frame are set with the linkagg lacp agg actor admin-state
command you can set some bits on and restore other bits within the same command. For example, if you
wanted to restore bit 2 (aggregate) to its default settings and set bit 0 (active) on dynamic aggregate actor
port 49 in slot 5 you would enter:
-> no linkagg lacp agg 5/49 actor admin-state active aggregate
Modifying the Actor Port System ID
By default, the actor port system ID ( the MAC address used as the system ID on dynamic aggregate actor
ports) is 00:00:00:00:00:00. The following subsections describe how to configure a user-specified value
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 9-17
Configuring Dynamic Link Aggregation
Modifying Dynamic Link Aggregate Group Parameters
and how to restore the value to its default value with the linkagg lacp port actor system-id command.
Configuring an Actor Port System ID
You can configure the actor port system ID by entering linkagg lacp port, the slot number, a slash (/), the
port number, actor system-id, and the user specified actor port system ID ( MAC address) in the
hexadecimal format of xx:xx:xx:xx:xx:xx.
For example, to modify the system ID of the dynamic aggregate actor port 3 in slot 7 to
00:20:da:06:ba:d3, enter:
-> linkagg lacp port 7/3 actor system-id 00:20:da:06:ba:d3
For example, to modify the system ID of the dynamic aggregate actor port 3 in slot 7 to
00:20:da:06:ba:d3 and document that the port is 10 Mbps Ethernet you would enter:
-> linkagg lacp port 7/3 actor system-id 00:20:da:06:ba:d3
Restoring the Actor Port System ID
To remove a user-configured system ID from a dynamic aggregate group actor port configuration, use the
no form of the linkagg lacp port actor system-id command by entering no linkagg lacp agg, the slot
number, a slash (/), the port number, and actor system-id keyword.
For example, to remove a user-configured system ID from dynamic aggregate actor port 3 in slot 7, enter:
-> linkagg lacp port 7/3 actor system-id
Modifying the Actor Port System Priority
By default, the actor system priority is 0. The following subsections describe how to configure a userspecified value and how to restore the value to its default value with the linkagg lacp port actor systempriority command.
Configuring an Actor Port System Priority
You can configure the actor system priority to a value by entering lacp agg, the slot number, a slash (/),
the port number, actor system priority, and the user-specified actor port system priority.
For example, to modify the system priority of dynamic aggregate actor port 5 in slot 2 to 200 you would
enter:
-> linkagg lacp port 2/5 actor system-priority 200
For example, to modify the system priority of dynamic aggregate actor port 5 in slot 2 to 200, enter:
-> linkagg lacp port 2/5 actor system-priority 200
Restoring the Actor Port System Priority
To remove a user-configured actor port system priority from a dynamic aggregate group actor port
configuration use the no form of the linkagg lacp port actor system-priority command by entering no
linkagg lacp agg, the slot number, a slash (/), the port number, and actor system priority.
For example, to remove a user-configured system priority from dynamic aggregate actor port 5 in slot 2
you would enter:
-> no linkagg lacp port 2/5 actor system-priority
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 9-18
Configuring Dynamic Link Aggregation
Modifying Dynamic Link Aggregate Group Parameters
Modifying the Actor Port Priority
By default, the actor port priority (used to converge dynamic key changes) is 0. The following subsections
describe how to configure a user-specified value and how to restore the value to its default value with the
linkagg lacp port actor port priority command.
Configuring the Actor Port Priority
You can configure the actor port priority to a value by entering linkagg lacp agg, the slot number, a slash
(/), the port number, actor port-priority, and the user-specified actor port priority.
For example, to modify the actor port priority of dynamic aggregate actor port 1 in slot 2 to 100 you
would enter:
-> linkagg lacp port 2/1 actor port-priority 100
For example, to modify the actor port priority of dynamic aggregate actor port 1 in slot 2 to 100, enter:
-> linkagg lacp port 2/1 actor port-priority 100
Restoring the Actor Port Priority
To remove a user configured actor port priority from a dynamic aggregate group actor port configuration
use the no form of the linkagg lacp port actor port priority command by entering no linkagg lacp agg,
the slot number, a slash (/), the port number, and no actor port priority.
For example, to remove a user-configured actor priority from dynamic aggregate actor port 1 in slot 2 you
would enter:
-> no linkagg lacp port 2/1 actor port-priority
Modifying Dynamic Aggregate Partner Port Parameters
This section describes how to modify the following dynamic aggregate partner port parameters:
• Partner port system administrative state (see “Modifying the Partner Port System Administrative State”
on page 9-20)
• Partner port administrative key (see “Modifying the Partner Port Administrative Key” on page 9-21)
• Partner port system ID (see “Modifying the Partner Port System ID” on page 9-22)
• Partner port system priority (see “Modifying the Partner Port System Priority” on page 9-22)
• Partner port administrative state (see “Modifying the Partner Port Administrative Status” on page 9-23)
• Partner port priority (see “Modifying the Partner Port Priority” on page 9-23)
See Chapter 1, “Configuring Ethernet Ports,” for information on configuring Ethernet ports.
Note. A port can belong to only one aggregate group.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 9-19
Configuring Dynamic Link Aggregation
Modifying Dynamic Link Aggregate Group Parameters
Modifying the Partner Port System Administrative State
The system administrative state of a dynamic aggregate group partner ( remote switch) port is indicated by
bit settings in Link Aggregation Control Protocol Data Unit (LACPDU) frames sent by this port. By
default, bits 0 (indicating that the port is active), 1 (indicating that short timeouts are used for LACPDU
frames), and 2 (indicating that this port is available for aggregation) are set in LACPDU frames.
The following subsections describe how to configure user-specified values and how to restore them to
their default values with the linkagg lacp agg partner admin-state command.
Configuring Partner Port System Administrative State Values
To configure the system administrative state values for the port on the dynamic aggregate partner, enter
linkagg lacp port, the slot number, a slash (/), the port number, partner admin-state, and one or more of
the keywords shown in the table below or none:
Keyword
Definition
active
Specifies that bit 0 in LACPDU frames is set, which indicates that the
link is able to exchange LACPDU frames. By default, this bit is set.
timeout
Specifies that bit 1 in LACPDU frames is set, which indicates that a
short time-out is used for LACPDU frames. When this bit is disabled, a
long time-out is used for LACPDU frames. By default, this bit is set.
aggregate
Specifies that bit 2 in LACPDU frames is set, which indicates that the
system considers this link to be a potential candidate for aggregation. If
this bit is not set, the system considers the link to be individual (it can
only operate as a single link). By default, this bit is set.
synchronize
Specifies that bit 3 in the partner state octet is enabled. When this bit is
set, the port is allocated to the correct dynamic aggregation group. If
this bit is not enabled, the port is not allocated to the correct
aggregation group. By default, this value is disabled.
collect
Specifying this keyword has no effect because the system always
determines its value. When this bit (bit 4) is set by the system,
incoming LACPDU frames are collected from the individual ports that
make up the dynamic aggregate group.
distribute
Specifying this keyword has no effect because the system always
determines its value. When this bit (bit 5) is set by the system,
distributing outgoing frames on the port is disabled.
default
Specifying this keyword has no effect because the system always
determines its value. When this bit (bit 6) is set by the system, it
indicates that the partner is using defaulted actor information
administratively configured for the partner.
expire
Specifying this keyword has no effect because the system always
determines its value. When this bit (bit 7) is set by the system, the actor
cannot receive LACPDU frames.
Note. Specifying none removes all administrative states from the LACPDU configuration. For example:
-> linkagg lacp port 7/49 partner admin-state none
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 9-20
Configuring Dynamic Link Aggregation
Modifying Dynamic Link Aggregate Group Parameters
For example, to set bits 0 (active) and 2 (aggregate) on dynamic aggregate partner port 49 in slot 7, enter:
-> linkagg lacp port 7/49 partner admin-state active aggregate
For example, to set bits 0 (active) and 2 (aggregate) on dynamic aggregate partner port 49 in slot 7 and
document that the port is a Gigabit Ethernet port, enter:
-> linkagg lacp port 7/49 partner admin-state active aggregate
Restoring Partner Port System Administrative State Values
To restore LACPDU bit settings to their default values use the no form of the linkagg lacp agg partner
admin-state command and enter the active, timeout, aggregate, or synchronize keywords.
For example, to restore bits 0 (active) and 2 (aggregate) to their default settings on dynamic aggregate
partner port 1 in slot 7, enter:
-> no linkagg lacp port 7/1 partner admin-state active aggregate
Note. Since individual bits with the LACPDU frame are set with the linkagg lacp port partner admin
state command you can set some bits on and restore other bits to default values within the same command.
For example, if you wanted to restore bit 2 (aggregate) to its default settings and set bit 0 (active) on
dynamic aggregate partner port 1 in slot 7, enter:
-> no linkagg lacp port 7/1 partner admin-state active aggregate
Modifying the Partner Port Administrative Key
By default, the “administrative key” of the dynamic aggregate partner port is 0. The following subsections
describe how to configure a user-specified value and how to restore the value to its default value with the
linkagg lacp agg partner admin-key command.
Configuring the Partner Port Administrative Key
You can configure the administrative key for the dynamic aggregate partner port to a value ranging from 0
to 65535 enter linkagg lacp port, the slot number, a slash (/), the port number, partner admin-key, and
the user-specified partner port administrative key.
For example, to modify the administrative key of a dynamic aggregate group partner port 1 in slot 6 to
1000 enter:
-> linkagg lacp port 6/1 partner admin-key 1000
For example, to modify the administrative key of a dynamic aggregate group partner port 1 in slot 6, enter:
-> linkagg lacp port 6/1 partner admin-key 1000
Restoring the Partner Port Administrative Key
To remove a user-configured administrative key from the configuration set on a dynamic aggregate group
partner port, use the no form of the linkagg lacp agg partner admin-key command by entering no
linkagg lacp agg, the slot number, a slash (/), the port number, and partner admin-key keyword.
For example, to remove the user-configured administrative key from dynamic aggregate partner port 1 in
slot 6, enter:
-> no linkagg lacp port 6/1 partner admin-key
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 9-21
Configuring Dynamic Link Aggregation
Modifying Dynamic Link Aggregate Group Parameters
Modifying the Partner Port System ID
By default, the partner port system ID ( the MAC address used as the system ID on dynamic aggregate
partner ports) is 00:00:00:00:00:00. The following subsections describe how to configure a user-specified
value and how to restore the value to its default value with the linkagg lacp port partner admin systemid command.
Configuring the Partner Port System ID
You can configure the partner port system ID by entering linkagg lacp port, the slot number, a slash (/),
the port number, partner admin system-id, and the user-specified partner administrative system ID (the
MAC address in hexadecimal format).
For example, to modify the system ID of dynamic aggregate partner port 49 in slot 6 to
00:20:da:06:ba:d3, enter:
-> linkagg lacp port 6/49 partner admin system-id 00:20:da:06:ba:d3
For example, to modify the system ID of dynamic aggregate partner port 49 in slot 6 to
00:20:da:06:ba:d3, enter:
-> linkagg lacp port 6/49 partner admin system-id 00:20:da:06:ba:d3
Restoring the Partner Port System ID
To remove a user-configured system ID from a dynamic aggregate group partner port configuration use
the no form of the linkagg lacp port partner admin system-id command by entering linkagg lacp agg,
the slot number, a slash (/), the port number, and the partner admin system-id parameters.
For example, to remove a user-configured system ID from dynamic aggregate partner port 2 in slot 6,
enter:
-> no linkagg lacp port 6/2 partner admin system-id
Modifying the Partner Port System Priority
By default, the administrative priority of a dynamic aggregate group partner port is 0. The following
subsections describe how to configure a user-specified value and how to restore the value to its default
value with the linkagg lacp agg partner system-priority command.
Configuring the Partner Port System Priority
You can configure the administrative priority of a dynamic aggregate group partner port to a value ranging
from 0 to 255 by entering linkagg lacp port, the slot number, a slash (/), the port number, partner
admin-system-priority, and the user-specified administrative system priority.
For example, to modify the administrative priority of a dynamic aggregate partner port 49 in slot 4 to 100,
enter:
-> linkagg lacp port 4/49 partner admin-system-priority 100
For example, to modify the administrative priority of dynamic aggregate partner port 49 in slot 4 to 100
and specify that the port is a Gigabit Ethernet port, enter:
-> linkagg lacp port 4/49 partner admin-system-priority 100
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 9-22
Configuring Dynamic Link Aggregation
Modifying Dynamic Link Aggregate Group Parameters
Restoring the Partner Port System Priority
To remove a user-configured system priority from a dynamic aggregate group partner port configuration
use the no form of the linkagg lacp agg partner system-priority command by entering lacp port, the
slot number, a slash (/), the port number, and partner admin-system-priority.
For example, to remove a user-configured system ID from dynamic aggregate partner port 3 in slot 4,
enter:
-> no linkagg lacp port 4/3 partner admin-system-priority
Modifying the Partner Port Administrative Status
By default, the administrative status of a dynamic aggregate group partner port is 0. The following
subsections describe how to configure a user-specified value and how to restore the value to its default
value with the linkagg lacp port partner admin-port command.
Configuring the Partner Port Administrative Status
You can configure the administrative status of a dynamic aggregate group partner port by entering linkagg
lacp port, the slot number, a slash (/), the port number, partner admin-port, and the user-specified
partner port administrative status.
For example, to modify the administrative status of dynamic aggregate partner port 1 in slot 7 to 200 you
would enter:
-> linkagg lacp port 7/1 partner admin-port 200
For example, to modify the administrative status of dynamic aggregate partner port 1 in slot 7 to 200,
enter:
-> linkagg lacp port 7/1 partner admin-port 200
Restoring the Partner Port Administrative Status
To remove a user-configured administrative status from a dynamic aggregate group partner port
configuration use the no form of the linkagg lacp port partner admin-port command by entering no
linkagg lacp agg, the slot number, a slash (/), the port number, and partner admin-port.
For example, to remove a user-configured administrative status from dynamic aggregate partner port 1 in
slot 7 you would enter:
-> no linkagg lacp port 7/1 partner admin-port
Modifying the Partner Port Priority
The default partner port priority is 0. The following subsections describe how to configure a user-specified
value and how to restore the value to its default value with the linkagg lacp port partner admin portpriority command.
Configuring the Partner Port Priority
To configure the partner port priority, enter lacp agg, the slot number, a slash (/), the port number,
partner admin-port priority, and the user-specified partner port priority.
For example, to modify the port priority of dynamic aggregate partner port 3 in slot 4 to 100 you would
enter:
-> linkagg lacp port 4/3 partner admin-port priority 100
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 9-23
Configuring Dynamic Link Aggregation
Modifying Dynamic Link Aggregate Group Parameters
For example, to modify the port priority of dynamic aggregate partner port 3 in slot 4 to 100, enter:
-> linkagg lacp port 4/3 partner admin-port priority 100
Restoring the Partner Port Priority
To remove a user-configured partner port priority from a dynamic aggregate group partner port
configuration use the no form of the linkagg lacp port partner admin port-priority command by
entering no linkagg lacp port, the slot number, a slash (/), the port number, partner admin-port
priority.
For example, to remove a user-configured partner port priority from dynamic aggregate partner port 3 in
slot 4 you would enter:
-> no linkagg lacp port 4/3 partner admin-port priority
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 9-24
Configuring Dynamic Link Aggregation
Application Examples
Application Examples
Dynamic link aggregation groups are treated by the software on the switch as similar to individual
physical ports. This section demonstrates the dynamic link aggregation feature by providing sample
network configurations that use dynamic aggregation along with other software features. In addition,
tutorials are provided that show how to configure these sample networks by using Command Line
Interface (CLI) commands.
Sample Network Overview
The figure below shows two VLANs on Switch A that use two different link aggregation groups. VLAN
10 has been configured on dynamic aggregate group 5 with Spanning Tree Protocol (STP) with the highest
priority (15) possible. And VLAN 12 has been configured on dynamic aggregate group 7 with 802.1Q
tagging and 802.1p priority bit settings.
Switch B
Switch A
Dynamic Aggregate
Group 5
VLAN 10 has been configured to
use this group with Spanning
Tree with a priority of 15.
Switch C
Dynamic Aggregate
Group 7
VLAN 12 with 802.1Q tagging
using 802.1p priority has been
configured to use this group.
Sample Network Using Dynamic Link Aggregation
The steps to configure VLAN 10 (Spanning Tree example) are described in “Link Aggregation and
Spanning Tree Example” on page 9-26. The steps to configure VLAN 12 (802.1Q and 802.1p example)
are described in “Link Aggregation and QoS Example” on page 9-27.
Note. Although you need to configure both the local ( Switch A) and remote ( Switches B and C) switches,
only the steps to configure the local switch are provided since the steps to configure the remote switches are
similar.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 9-25
Configuring Dynamic Link Aggregation
Application Examples
Link Aggregation and Spanning Tree Example
As shown in the figure on page 9-25, VLAN 10, which uses the Spanning Tree Protocol (STP) with a
priority of 15, has been configured to use dynamic aggregate group 7. The actual physical links connect
ports 3/9 and 3/10 on Switch A to ports 1/1 and 1/2 on Switch B. Follow the steps below to configure this
network:
Note. Only the steps to configure the local (Switch A) are provided here since the steps to configure the
remote (Switch B) are similar.
1 Configure dynamic aggregate group 5 by entering:
-> linkagg lacp agg 5 size 2
2 Configure ports 5/5 and 5/6 with the same actor administrative key (5) by entering:
-> linkagg lacp port 5/5-6 actor admin-key 5
3 Create VLAN 10 by entering:
-> vlan 10
4 If the Spanning Tree Protocol (STP) has been disabled on this VLAN (STP is enabled by default),
enable it on VLAN 10 by entering:
-> vlan 10 stp enable
Note. Optional. Use the show spantree ports command to determine if the STP is enabled or disabled and
to display other STP parameters. For example:
-> show spantree vlan 10 ports
Spanning Tree Port Summary for Vlan 10 AdmOper Man. Path Desig FwPrim.AdmOp
Port Pri St St
mode Cost Cost
Role Tx Port Cnx Cnx Desig Bridge ID
-----+---+---+----+----+-----+-----+----+---+-----+---+---+--------------------3/13
7 ENA FORW No
100 0
DESG 1
3/13EDG NPT 000A-00:d0:95:6b:0a:c0
2/10
7 ENA FORW No
19
0
DESG 1
2/10PTP PTP 000A-00:d0:95:6b:0a:c0
5/2
7 ENA DIS No
0
0
DIS
0
5/2 EDG
NPT 0000-00:00:00:00:00:00
0/5
7 ENA FORW No
4
0
DESG 1
0/10PTP PTP 000A-00:d0:95:6b:0a:c0
In the example above the link aggregation group is indicated by the “0” for the slot number.
5 Configure VLAN 10 (which uses dynamic aggregate group 5) to the highest (15) priority possible by
entering:
-> spantree vlan 10 linkagg 5 priority 15
6 Repeat steps 1 through 5 on Switch B. Substitute the port numbers of the commands with the
appropriate port numbers of Switch B.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 9-26
Configuring Dynamic Link Aggregation
Application Examples
Link Aggregation and QoS Example
As shown in the figure on page 9-25, VLAN 12, which uses 802.1Q frame tagging and 802.1p
prioritization, has been configured to use dynamic aggregate group 7. The actual physical links connect
ports 4/1, 4/2, 4/3, and 4/4 on Switch A to ports 1/1, 1/2, 1/3, and 1/4 on Switch C. Follow the steps below
to configure this network:
Note. Only the steps to configure the local ( Switch A) switch are provided here since the steps to configure
the remote (Switch C) switch would not be significantly different.
1 Configure dynamic aggregate group 7 by entering:
-> linkagg lacp agg 7 size 4
2 Configure ports 4/1, 4/2, 4/3, and 4/4 the same actor administrative key (7) by entering:
-> lacp agg 4/1-4 actor admin-key 7
3 Create VLAN 12 by entering:
-> vlan 12
4 Configure 802.1Q tagging with a tagging ID ( VLAN ID) of 12 on dynamic aggregate group 7 by
entering:
-> vlan 12 members 7
5 If the QoS Manager has been disabled (it is enabled by default) enable it by entering:
-> qos enable
Note. Optional. Use the show qos config command to determine if the QoS Manager is enabled or
disabled.
6 Configure a policy condition for VLAN 12 called “vlan12_condition” by entering:
-> policy condition vlan12_condition destination vlan 12
7 Configure an 802.1p policy action with the highest priority possible ( 7) for VLAN 12 called
“vlan12_action” by entering:
-> policy action vlan12_action 802.1P 7
8 Configure a QoS rule called “vlan12_rule” by using the policy condition and policy rules you
configured in steps 8 and 9 above by entering:
-> policy rule vlan12_rule enable condition vlan12_condition action
vlan12_action
9 Enable your 802.1p QoS settings by entering qos apply as shown below:
-> qos apply
10 Repeat steps 1 through 9 on Switch C. Use the same commands as mentioned in the previous steps.
Substitute the port numbers of the commands with the appropriate port numbers of Switch C.
Note. If you do not use the qos apply command any QoS policies previously configured, are lost on the
next switch reboot.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 9-27
Configuring Dynamic Link Aggregation
Displaying Dynamic Link Aggregation Configuration and Statistics
Displaying Dynamic Link Aggregation
Configuration and Statistics
You can use Command Line Interface (CLI) show commands to display the current configuration and
statistics of link aggregation. These commands include the following:
linkagg range
Displays information on link aggregation groups.
show linkagg port
Displays information on link aggregation ports.
When you use the show linkagg command without specifying the link aggregation group number and
when you use the show linkagg port command without specifying the slot and port number, these
commands provide a “global” view of switch-wide link aggregate group and link aggregate port
information, respectively.
For example, to display global statistics on all link aggregate groups (both dynamic and static), enter:
-> show linkagg agg
A screen similar to the following would be displayed:
Number Aggregate SNMP Id Size Admin State Oper State
Att/Sel Ports
-------+----------+--------+----+-------------+-------------+------------1
Static
40000001
8
ENABLED
UP
2 2
2
Dynamic
40000002
4
ENABLED
DOWN
0 0
3
Dynamic
40000003
8
ENABLED
DOWN
0 2
4
Static
40000005
2
DISABLED
DOWN
0 0
When you use the show linkagg command with the agg keyword and the link aggregation group number
and when you use the show linkagg port command with the slot and port number, these commands
provide detailed views of the link aggregate group and port information, respectively. These detailed
views provide excellent tools for diagnosing and troubleshooting problems.
For example, to display detailed statistics for port 1 in slot 2 that is attached to dynamic link aggregate
group 1, enter:
-> show linkagg port 2/1
A screen similar to the following would be displayed:
Dynamic Aggregable Port
SNMP Id
Slot/Port
Administrative State
Operational State
Port State
Link State
Selected Agg Number
Primary port
LACP
Actor System Priority
Actor System Id
Actor Admin Key
Actor Oper Key
Partner Admin System Priority
Partner Oper System Priority
Partner Admin System Id
Partner Oper System Id
:
:
:
:
:
:
:
:
2001,
2/1,
ENABLED,
DOWN,
CONFIGURED,
DOWN,
NONE,
UNKNOWN,
:
:
:
:
:
:
:
:
10,
[00:d0:95:6a:78:3a],
8,
8,
20,
20,
[00:00:00:00:00:00],
[00:00:00:00:00:00],
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 9-28
Configuring Dynamic Link Aggregation
Partner Admin Key
Partner Oper Key
Attached Agg Id
Actor Port
Actor Port Priority
Partner Admin Port
Partner Oper Port
Partner Admin Port Priority
Partner Oper Port Priority
Actor Admin State
Actor Oper State
Partner Admin State
Partner Oper State
Displaying Dynamic Link Aggregation Configuration and Statistics
:
:
:
:
:
:
:
:
:
:
:
:
:
8,
0,
0,
7,
15,
0,
0,
0,
0,
act1.tim1.agg1.syn0.col0.dis0.def1.exp0,
act1.tim1.agg1.syn0.col0.dis0.def1.exp0,
act0.tim0.agg1.syn1.col1.dis1.def1.exp0,
act0.tim0.agg1.syn0.col1.dis1.def1.exp0
See the “Link Aggregation Commands” chapter in the OmniSwitch AOS Release 8 CLI Reference Guide
for complete documentation of show commands for link aggregation.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 9-29
10
Configuring Dual-Home
Links
Dual-Home Link (DHL) is a high availability feature that provides fast failover between core and edge
switches without implementing Spanning Tree. The OmniSwitch provides the following method for
implementing a DHL solution:
DHL Active-Active—an edge technology that splits a number of VLANs between two active links. The
forwarding status of each VLAN is modified by DHL to prevent network loops and maintain connectivity
to the core when one of the links fails. This solution does not require link aggregation.
In This Chapter
This chapter describes the basic components of DHL solutions and how to configure them through the
Command Line Interface (CLI). CLI commands are used in the configuration examples; for more details
about the syntax of commands, see the OmniSwitch AOS Release 8 CLI Reference Guide.
Information and procedures described in this chapter include:
• “Dual-Home Link Active-Active Defaults” on page 10-2
• “Dual-Home Link Active-Active” on page 10-3.
• “Configuring DHL Active-Active” on page 10-6.
• “Dual-Home Link Active-Active Example” on page 10-8.
• “Displaying the Dual-Home Link Configuration” on page 10-12
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 10-1
Configuring Dual-Home Links
Dual-Home Link Active-Active Defaults
Dual-Home Link Active-Active Defaults
The table below lists default values for dual-home link aggregate groups.
Parameter Description
Command
Default Value/Comments
DHL session ID
dhl name
If a name is not assigned to a
DHL session, the session is
configured as DHL-1
Admin state of DHL session
dhl num admin-state
disable
Configure a port/link agg as DHL
dhl num linka linkb
NA
Configure a VLAN-MAP
dhl num vlan-map linkb
NA
Pre-emption timer for the DHL
session
dhl num pre-emption-time
30 seconds
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 10-2
Configuring Dual-Home Links
Dual-Home Link Active-Active
Dual-Home Link Active-Active
Dual-Home Link (DHL) Active-Active is a high availability feature that provides fast failover between
core and edge switches without using Spanning Tree. To provide this functionality, DHL Active-Active
splits a number of VLANs between two active links. The forwarding status of each VLAN is modified by
DHL to prevent network loops and maintain connectivity to the core when one of the links fails.
The DHL Active-Active feature, however, is configurable on regular switch ports and on logical link
aggregate ports (linkagg ID) instead of just LACP aggregated ports. In addition, the two DHL links are
both active, as opposed to the active and standby mode used with LACP.
DHL Active-Active Operation
A DHL Active-Active configuration consists of the following components:
• A DHL session. Only one session per switch is allowed.
• Two DHL links associated with the session (link A and link B). A physical switch port or a logical link
aggregate (linkagg) ID are configurable as a DHL link.
• A group of VLANs (or pool of common VLANs) in which each VLAN is associated (802.1q tagged)
with both link A and link B.
• A VLAN-to-link mapping that specifies which of the common VLANs each DHL link services. This
mapping prevents network loops by designating only one active link for each VLAN, even though both
links remain active and are associated with each of the common VLANs.
When one of the two active DHL links fails or is brought down, the VLANs mapped to that link are then
forwarded on the remaining active link to maintain connectivity to the core. When the failed link comes
back up, DHL waits a configurable amount of time before the link resumes forwarding of its assigned
VLAN traffic.
The following diagram shows how DHL works when operating in a normal state (both links up) and when
operating in a failed state (one link is down):
Core 1
Core 2
LinkB VLANs
LinkA VLANs
Core 1
Core 2
LinkA and LinkB
VLANs on LinkB
Link Down
Edge
Edge
DHL Normal State
OmniSwitch AOS Release 8 Network Configuration Guide
DHL Failover State
September 2017
page 10-3
Configuring Dual-Home Links
Dual-Home Link Active-Active
Protected VLANs
A protected VLAN is one that is assigned to both links in a DHL session. This means that if the link to
which the VLAN is mapped fails, the VLAN is moved to the other active DHL link to maintain
connectivity with the core switches.
Any VLAN that is only assigned to one of the DHL links is considered an unprotected VLAN. This type
of VLAN is not eligible for DHL support if the link to which the VLAN is assigned fails.
DHL Port Types
DHL is supported on the following port types:
• Physical switch ports.
• Logical link aggregate ports (linkagg ID).
• LPS ports
• NNI ports
• IPM VLAN ports
• DHCP Snooping ports
• IP Source filtering ports.
DHL is not supported on the following port types:
• Any port that is a member of a link aggregate.
• Mobile ports
• 802.1x ports
• GVRP ports.
• UNI ports
• Ports that are enabled for transparent bridging.
Note. No CLI error message is displayed when DHL is configured using a port type that is not supported.
DHL Pre-Emption Timer
The DHL pre-emption timer specifies the amount of time to wait before a failed link that has recovered
can resume servicing VLANs that are mapped to that link. This time value is configured on a per-DHL
session basis.
MAC Address Flushing
Spanning Tree flushes the MAC address table when a topology change occurs that also changes the
forwarding topology. The MAC addresses are then relearned according to the new forwarding topology.
This prevents MAC address entries from becoming stale (entries contain old forwarding information).
When a port is configured as a DHL Active-Active link, Spanning Tree is automatically disabled on the
port. Since Spanning Tree is not used, a changeover from one DHL link to the other does not trigger a
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 10-4
Configuring Dual-Home Links
Dual-Home Link Active-Active
topology change event and the MAC address table is not automatically flushed. This can create stale MAC
address entries that are looking for end devices over the wrong link.
To avoid stale MAC address entries in the forwarding tables of the core switches, some type of
communication needs to occur between the edge uplink switch and the core switches. The DHL ActiveActive feature provides two methods for clearing stale MAC address entries: MVRP Enhanced Operation
or Raw Flooding. Selecting which one of these methods to use is done on a per-DHL session basis.
MVRP Enhanced Operation
The switch uses an enhanced Multiple VLAN Registration Protocol (MVRP) operation to refresh core
MAC address tables as follows:
• For each uplink port, the switch issues joins for each VLAN that is active on that port. This causes the
core switch to only register those VLANs that are active on each link based on the DHL configuration.
• When one of the DHL links fails, the other link issues joins to establish connectivity for the VLANs
that were serviced by the failed link. These new joins contain the “new” flag set, which are forwarded
by the core devices and trigger a flush of the MAC addresses on the core network for the joined
VLANs.
• When a failed DHL link recovers, the link issues new joins to re-establish connectivity for the VLANs
the link was servicing before the link went down. These new joins also trigger a flush of the MAC
addresses on the core network for the joined VLANs.
The switch interacts normally with the core and other devices for MVRP, treating the DHL VLANs on
each uplink port as a fixed registration. This approach requires core devices that support MVRP.
Raw Flooding
When a DHL link fails or recovers and Raw Flooding is enabled for the DHL session, the switch performs
the following tasks to trigger MAC movement:
• Identify a list of MAC addresses within the effected VLANs that were learned on non-DHL ports
(MAC addresses that were reachable through the effected VLANs).
• Create a tagged packet for each of these addresses. The SA for the packet is one of the MAC addresses
from the previously-generated list; the VLAN tag is the resident VLAN for the MAC address; the DA
is set for broadcast (all Fs); the body is just filler.
• Transmit the generated packet once for each VLAN-MAC address combination. These packets are sent
on the link that takes over for the failed link or on a link that has recovered from a failure.
The MAC movement triggered by the Raw Flooding method clears any stale MAC entries. However,
flooded packets are often assigned a low priority and the switch may filter such packets in a highly utilized
network.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 10-5
Configuring Dual-Home Links
Dual-Home Link Active-Active
DHL Configuration Guidelines
Review the following guidelines before attempting to configure a DHL setup:
• Make sure that DHL linkA and linkB are associated with each VLAN protected by the DHL session.
Any VLAN not associated with either link or only associated with one of the links is unprotected.
• DHL linkA and linkB must belong to the same default VLAN. In addition, select a default VLAN that
is one of the VLANs protected by the DHL session. For example, if the session is going to protect
VLANs 10-20, then assign one of those VLANs as the default VLAN for linkA and linkB.
• Only one DHL session per switch is allowed. Each session can have only two links (linkA and linkB).
Specify a physical switch port or a link aggregate (linkagg) ID as a DHL link. The same port or link
aggregate is not configurable as both linkA or linkB.
• The administrative state of a DHL session is not configurable until a linkA port and a linkB port are
associated with the specified DHL session ID number.
• Spanning Tree is automatically disabled on each link when the DHL session is enabled.
• Do not change the link assignments for the DHL session while the session is enabled.
• Configuring a MAC address flush method (MVRP or Raw Flooding) is recommended if the DHL
session ports span across switch modules. This configuration improves convergence time.
• Enabling the registrar mode as “forbidden” is recommended before MVRP is enabled on DHL links.
Configuring DHL Active-Active
Configuring a DHL Active-Active setup requires the following tasks.
1 Configure a set of VLANs that the two DHL session links service.
-> vlan 100-110
2 Identify two ports or link aggregates that serve as the links for the DHL session then assign both links
to the same default VLAN. Make sure the default VLAN is one of the VLANs created in Step 1. For
example, the following commands assign VLAN 100 as the default VLAN for port 1/1/10 and linkagg 5:
-> vlan 100 members port 1/1/10 untagged
-> vlan 100 members linkagg 5 untagged
3 Associate (802.1q tag) the ports identified in Step 2 to each one of the VLANs created in Step 1,
except for the default VLAN already associated with each port. For example, the following commands
associate port 1/1/10 and linkagg 5 with VLANs 101-110:
-> vlan 101-110 members port 1/1/10 tagged
-> vlan 101-110 members linkagg 5 tagged
In the above command example, port 1/1/10 and linkagg 5 are only tagged with VLANs 101-110 because
VLAN 100 is already the default VLAN for both ports.
4 Create a DHL session using the dhl name command. For example:
-> dhl 10
5 Configure the pre-emption (recovery) timer for the DHL session using the dhl num pre-emption-time
command. By default, the timer is set to 30 seconds, so it is only necessary to change this parameter if the
default value is not sufficient. For example, the following command changes the timer value 500 seconds:
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 10-6
Configuring Dual-Home Links
Dual-Home Link Active-Active
-> dhl 10 pre-emption-time 500
6 Configure the MAC address flushing method for the DHL session using the dhl num mac-flushing
command and specify either the raw or mvrp parameter option. By default, the MAC flushing method is
set to none. For example, the following command selects the MVRP method:
-> dhl 10 mac-flushing mvrp
7 Configure two links (linkA and linkB) for the DHL session using the dhl num linka linkb command.
Specify the ports identified in Step 1 as linkA and linkB. For example:
-> dhl 10 linka linkagg 5 linkb port 1/1/10
8 Select VLANs from the set of VLANs created in Step 2 and map those VLANs to linkB using the dhl
num vlan-map linkb command. Any VLAN not mapped to linkB is automatically mapped to linkA. By
default, all VLANs are mapped to linkA. For example, the following command maps VLANs 11-20 to
linkB:
-> dhl 10 vlan-map linkb 11-20
9 Administratively enable the DHL session using the dhl num admin-state command. For example:
-> dhl 10 admin-state enable
See “Dual-Home Link Active-Active Example” on page 10-8 for a DHL application example.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 10-7
Configuring Dual-Home Links
Dual-Home Link Active-Active
Dual-Home Link Active-Active Example
The figure below shows two ports (1/1/10 and 1/1/12) that serve as link A and link B for a DHL session
configured on the Edge switch. Both ports are associated with VLANs 1-10, where VLAN 1 is the default
VLAN for both ports. The odd numbered VLANs (1, 3, 5, 7, 9) are mapped to link A and the even
numbered VLANs (2, 4, 6, 8, 10) are mapped to link B. Spanning Tree is disabled on both ports.
Both DHL links are active and provide connectivity to the Core switches for the VLANs to which each
link is mapped. If one link fails or is brought down, the VLANs mapped to the failed link are switched
over to the remaining active link to maintain connectivity for those VLANs. For example, if link A goes
down, VLANs 1, 3, 5, 7, and 9 are switch over and carried on link B.
Dual-Home Link Active-Active Example
Follow the steps below to configure this example DHL configuration.
Edge Switch:
1 Create VLANs 2-10.
-> vlan 2-10
2 Configure 802.1q tagging on VLANs 2-10 for port 1/1/10. Because VLAN 1 is the default VLAN for
port 1/1/10, there is no need to tag VLAN 1.
-> vlan 2-10 members port 1/1/10 tagged
3 Configure 802.1q tagging on the VLANs 2-10 for port 1/1/12. Because VLAN 1 is the default VLAN
for port 1/1/12, there is no need to tag VLAN 1.
-> vlan 2-10 members port 1/1/12 tagged
4 Configure a session ID and an optional name for the DHL session.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 10-8
Configuring Dual-Home Links
Dual-Home Link Active-Active
-> dhl 1 name dhl_session1
5 Configure port 1/1/10 and port 1/1/12 as the dual-home links (linkA, linkB) for the DHL session.
-> dhl 1 linkA port 1/1/10 linkB port 1/1/12
6 Map VLANs 2, 4, 6, 8, and 10 to DHL linkB.
->
->
->
->
->
dhl
dhl
dhl
dhl
dhl
1
1
1
1
1
vlan-map
vlan-map
vlan-map
vlan-map
vlan-map
linkb
linkb
linkb
linkb
linkb
2
4
6
8
10
7 Specify Raw Flooding as the MAC flushing technique to use for this DHL session.
-> dhl 1 mac-flushing raw
8 Enable the administrative state of the DHL session using the following command:
-> dhl 1 admin-state enable
Core Switches:
1 Create VLANs 2-10.
-> vlan 2-10
2 Configure 802.1q tagging on VLANs 2-10 for port 1/10 on the Core 1 switch. VLAN 1 is the default
VLAN for port 1/10, so there is no need to tag VLAN 1.
-> vlan 2-10 members port 1/1/10 tagged
CLI Command Sequence Example
The following is an example of what the example DHL configuration commands look like entered
sequentially on the command line:
Edge Switch:
->
->
->
->
->
->
->
->
->
->
->
->
vlan 2-10
vlan 2-10 members port 1/1/10 tagged
vlan 2-10 members port 1/1/12 tagged
dhl 1 name dhl_session1
dhl 1 linkA port 1/1/10 linkB port 1/1/12
dhl 1 vlan-map linkb 2
dhl 1 vlan-map linkb 4
dhl 1 vlan-map linkb 6
dhl 1 vlan-map linkb 8
dhl 1 vlan-map linkb 10
dhl 1 mac-flushing raw
dhl 1 admin-state enable
Core 1 Switch:
-> vlan 2-10
Core 2 Switch:
-> vlan 2-10
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 10-9
Configuring Dual-Home Links
Dual-Home Link Active-Active
Recommended DHL Active-Active Topology
The following is an example of a recommended topology for Dual-Home Link Active-Active.
In the above topology, all uplinked switches are connected to the core network through redundant links,
and the links are configured to use DHL Active-Active. Spanning Tree is disabled on all the DHL enabled
ports of the uplinked devices.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 10-10
Configuring Dual-Home Links
Dual-Home Link Active-Active
Unsupported DHL Active-Active Topology (Network Loops)
The following is an example of an unsupported topology for Dual-Homed Link Active-Active.
In the above topology, the link between the uplink device other than core network is not recommended as
it creates a loop in the network. This topology violates the principle that uplink switches can only be
connected to the network cloud through the core network.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 10-11
Configuring Dual-Home Links
Displaying the Dual-Home Link Configuration
Displaying the Dual-Home Link Configuration
You can use Command Line Interface (CLI) show commands to display the current configuration and
statistics of link aggregation. These commands include the following:
show linkagg
Displays information on link aggregation groups.
show linkagg port
Displays information on link aggregation ports.
show dhl
Displays the global status of the DHL configuration.
show dhl num
Displays information about a specific DHL session.
show dhl num link
Displays information about a specific DHL link, for example linkA or
linkB and the VLAN details of the specified link.
Note. See the “Link Aggregation Commands” chapter in the OmniSwitch AOS Release 8 CLI Reference
Guide for complete documentation of show commands for link aggregation.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 10-12
11
Configuring ERP
The ITU-T G.8032/Y.1344 Ethernet Ring Protection (ERP) switching mechanism is a self-configuring
algorithm that maintains a loop-free topology while providing data path redundancy and network
scalability. ERP provides fast recovery times for Ethernet ring topologies by utilizing traditional Ethernet
MAC and bridge functions.
Loop prevention is achieved by allowing traffic to flow on all except one of the links within the protected
Ethernet ring. This link is blocked and is referred to as the Ring Protection Link (RPL). When a ring
failure condition occurs, the RPL is unblocked to allow the flow of traffic to continue through the ring.
The OmniSwitch also supports ERPv2 according to the ITU-T recommendation G.8032 03/2010. ERPv2
implementation helps maintain a loop-free topology in multi-ring and ladder networks that contain
interconnection nodes, interconnected shared links, master rings and sub-rings.
The following chapter details the different functionalities and configuration settings required for ERP and
ERPv2.
In This Chapter
This chapter provides an overview about how Ethernet Ring Protection (ERP) works and how to configure
its parameters through the Command Line Interface (CLI). CLI commands are used in the configuration
examples; for more details about the syntax of commands, see the OmniSwitch AOS Release 8 CLI
Reference Guide.
The following information and configuration procedures are included in this chapter:
• “ERP Overview” on page 11-3.
• “Interaction With Other Features” on page 11-9
• “Quick Steps for Configuring ERP with Standard VLANs” on page 11-10.
• “Quick Steps for Configuring ERP with VLAN Stacking” on page 11-11
• “ERP Configuration Overview and Guidelines” on page 11-12
• “ERPv2 Configuration Overview and Guidelines” on page 11-17.
• “Sample Ethernet Ring Protection Configuration” on page 11-21.
• “Switch B -> erp-ring 2 enable” on page 11-24.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 11-1
Configuring ERP
ERP Defaults
ERP Defaults
ERP default settings:
Parameter Description
Command
Default
ERP ring status
erp-ring
Disabled
RPL status for the node
erp-ring rpl-node
Disabled
The wait-to-restore timer value for
the RPL node
erp-ring wait-to-restore
5 minutes
The guard-timer value for the ring
node
erp-ring guard-timer
50 centi-seconds
The NNI-SVLAN association type
ethernet-service svlan nni
STP
ERPv2 default settings:
The Ethernet Ring Protection (ERP) erp-ring virtual-channel
Ring Virtual Channel.
Enabled
Revertive mode on a specified node. erp-ring revertive
Enabled
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 11-2
Configuring ERP
ERP Overview
ERP Overview
Ethernet Ring Protection (ERP) is a protection switching mechanism for Ethernet ring topologies, such as
multi-ring and ladder networks. This implementation of ERP is based on the Recommendation ITU-T
G.8032/Y.1344 and uses the ring Automatic Protection Switching (APS) protocol to coordinate the
prevention of network loops within a bridged Ethernet ring.
Loop prevention is achieved by allowing the traffic to flow on all but one of the links within the protected
Ethernet ring. This link is blocked and is referred to as the Ring Protection Link (RPL). When a ring
failure condition occurs, the RPL is unblocked to allow the flow of traffic to continue through the ring.
One designated node within the ring serves as the RPL owner and is responsible for blocking the traffic
over the RPL. When a ring failure condition occurs, the RPL owner is responsible for unblocking the RPL
so that the link can forward traffic to maintain ring connectivity.
The ERPv2 capability supports multi-ring and ladder networks with interconnection nodes, interconnected
shared links, master rings and sub-rings. The following features are also supported:
• R-APS Virtual Channel
• Revertive/Non-Revertive modes
A shared link can be a part of one master ring. The sub-rings connected to the interconnection nodes are
open. The sub-rings cannot use shared links.
ERP and ERPv2 Terms
Ring Protection Link (RPL) and RB—A designated link between two ring nodes that is blocked to
prevent a loop on the ring. RB specifies a blocked RPL.
RPL Owner—A node connected to an RPL. This node blocks traffic on the RPL during normal ring
operations and activates the link to forward traffic when a failure condition occurs on another link in the
ring.
RMEPID—Remote Maintenance End Point identifier.
Link Monitoring—Ring links are monitored using standard ETH (Ethernet Layer Network) CC OAM
messages (CFM). Note that for improved convergence times, this implementation also uses Ethernet link
up and link down events.
Signal Fail (SF)—Signal Fail is declared when a failed link or node is detected.
No Request (NR)—No Request is declared when there are no outstanding conditions (for example, SF)
on the node.
Ring APS (Automatic Protection Switching) Messages—Protocol messages defined in Y.1731 and
G.8032 that determine the status of the ring.
ERP Service VLAN—Ring-wide VLAN used exclusively for transmission of messages, including R-APS
messages for Ethernet Ring Protection.
ERP Protected VLAN—A VLAN that is added to the ERP ring. ERP determines the forwarding state of
protected VLANs.
FDB—The Filtering Database that stores filtered data according to the R-APS messages recieved. This
database also maintains an association table that identifies the master rings for a given sub-ring.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 11-3
Configuring ERP
ERP Overview
BPR—The Blocked Port Reference that identifies the ring port (0 for interconnection node or sub-ring, 1
for master ring) that is blocked. The BPR status is used in all R-APS messages.
CCM—When an Ethernet ring contains no ERP capable nodes, CCM (Continuity Check Messages) are
required to monitor the ring-port connectivity across the L2 network.
MEG and MEL—The switches in the Management Entity Group with given priority as MEG level
(MEL).
NR and SF—Not Reachable and Signal Failure specify the status messages that can be sent as part of the
R-APS messages.
ERP Timers
Wait To Restore (WTR) Timer. This timer is used by the RPL to verify stability of the Etherenet ring.
WTR Timer determines the number of minutes the RPL switch waits before returning the RPL ports to a
blocked state after the ring has recovered from a link failure.
Some important points about the WTR Timer are as follows:
• The timer is started when the RPL node receives an R-APS (NR) message that indicates ring protection
is no longer required.
• The timer is stopped when the RPL owner receives an R-APS (SF) message while WTR is running,
which indicates that an error still exists in the ring.
• When the time runs out, the RPL port is blocked and an R-APS (NR, RB) message is transmitted from
both the ring ports to indicate that the RPL is blocked.
• Refer to the “Ethernet Ring Protection Commands” chapter in the OmniSwitch AOS Release 8 CLI
Reference Guide for timer defaults and valid ranges.
Guard Timer. When the failed link recovers, a ring node starts the Guard Timer. The Guard Timer is
used to prevent the ring nodes from receiving outdated R-APS messages that are no longer relevant.
Some important points about the Guard Timer are as follows:
• When the Guard Timer is running, any R-APS messages received are not forwarded.
• The Guard Timer value must be greater than the maximum expected forwarding delay time for which it
takes one R-APS message to circulate around the ring. This calculated value is required to prevent any
looping scenarios within the ring.
• Refer to the “Ethernet Ring Protection Commands” chapter in the OmniSwitch AOS Release 8 CLI
Reference Guide for timer defaults and valid ranges.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 11-4
Configuring ERP
ERP Overview
ERP Basic Operation
ERP operates over standard Ethernet interfaces that are physically connected in a ring topology. It uses an
Automatic Protection Switching (APS) protocol to coordinate protection and recovery switching
mechanisms over the Ethernet ring.
In an Ethernet ring, each node is connected to two adjacent nodes using two independent links called ring
links. A ring link is bound by two adjacent nodes on ports called ring ports. The ring nodes support
standard FDB (Filtering database) MAC learning, forwarding, flush behavior, and port blocking and
unblocking mechanisms.
The Ethernet ring has a designated Ring Protection Link (RPL), which is blocked under normal conditions
in order to avoid forming a loop in the ring. When a link or port failure is detected, a Signal Failure (SF)
message is sent on the ring to inform other ring nodes of the failure condition. At this point the ring is
operating in protection mode. When this mode is invoked, the RPL is unblocked forming a new traffic
pattern on the ring, (for example, traffic is accommodated on the RPL but blocked on the failed link). The
node responsible for blocking and unblocking the RPL is called the RPL Owner.
ERP Ring Modes
A ring operates in one of two modes: idle (normal operation; all links up and RPL is blocked) and
protection (protection switching activated; a ring failure has triggered the RPL into a forwarding state).
The following illustration shows an example of an ERP ring operating in the idle mode; all ring nodes are
up and the RPL is blocked:
Normal Mode
If a link or node failure occurs in the ring shown in the above illustration, the ring transitions as follows
into the protection mode:
• Nodes adjacent to the failure detect and report the failure using the R-APS (SF) message.
• The R-APS (SF) message triggers the RPL owner to unblock the RPL.
• All nodes in the ring flush all the dynamic MAC addresses learned on their ring ports.
The ring is now operating in the protection mode, as shown below:
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 11-5
Configuring ERP
ERP Overview
Protection Mode
When the failed link shown in the above illustration recovers, the ring transitions as follows back to the
idle mode:
• Nodes adjacent to the recovered link initiate an R-APS (NR) message and start the Guard Timer.
• When the RPL owner receives the R-APS (NR) message, it starts the Wait-To-Restore timer (WTR),
which is the set period of time that must elapse before the RPL owner blocks the RPL.
• Once the WTR timer expires, the RPL owner blocks the RPL and transmits an R-APS (NR, RB)
message indicating that RPL is blocked (RB).
• On receiving the R-APS (NR, RB) message, ring nodes flush all the dynamic MAC addresses learned
on their ring ports and unblock any previously blocked ports.
• The ring is now operating in the idle mode. The RPL is blocked and all other ring links are operational.
Overlapping Protected VLANs Between ERP Rings on same Node
In a network where all connected nodes cannot belong to a single ERP ring, the OmniSwitch supports
multiple ERP rings with a single shared node. The network example below shows two ERP rings
connected with a shared node.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 11-6
Configuring ERP
ERP Overview
ERPv2 Basic Operation
The enhanced ERPv2 functionality supports multi-ring and ladder networks that contain interconnection
nodes, interconnected shared links, master rings and sub-rings. Multiple sub-tending rings are supported
over the same physical ring.
A shared link can only be part of the master ring. The sub-rings connected to the interconnection nodes are
not closed and cannot use the shared links.
Consider the following OmniSwitch multi-ring and ladder network with the Master or Major Ring with
five ring nodes. The Sub-ring, ladder networks, RPLs and Shared Links are also depicted as part of the
illustration.
Illustration of ERPv2 on Multi Ring and Ladder Network with RPLs and Shared Links
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 11-7
Configuring ERP
ERP Overview
R-APS Virtual Channel
ERPv2 supports two implementation options for R-APS control channel of the sub-ring.
• Virtual Channel Enabled - R-APS messages are encapsulated and transmitted over an R-APS Virtual
channel configured on the major ring.
• Virtual Channel Disabled - R-APS messages are terminated at the interconnection nodes but not
blocked at RPL of the sub-ring. RPL ports are unblocked when all nodes are active (there is no failed
node).
For details on how to enable and disable R-APS virtual channel, see the section - “Enabling and Disabling
R-APS Virtual Channel” on page 11-19
The R-APS channels are not shared across rings. Each ring must have its own R-APS Channel.
• The R-APS virtual channels of the sub rings are automatically closed using the master ring. R-APS
messages from the sub ring on the interconnection node are forwarded as normal data to and only to
the master ring ports.
• The R-APS messages use a static destination mac-address of 01-19-A7-00-00-00. R-APS messages
must be tagged in order to identify the ring ID.
Note. The Service VLAN must be tagged, no support of "untagged" service VLAN. The sub ring and
master ring cannot use the same service VLAN.
Revertive / Non-Revertive Mode
Revertive mode is configured for compatibility between ERPv1 and ERPv2 nodes in the same ring. When
the ERPv2 node is operating with ERP v1 node in the same ring, it operates in revertive mode regardless
of user configuration.
Non-Revertive mode: Under non-revertive mode, when the failure condition recovers, the port that has
been blocked stays blocked and the unblocked RPL stays unblocked.
An exclusive clear operation can also be performed for non-revertive mode and revertive mode using the
ERPv2 CLI to clear any pending state.
Untagged Service VLAN
R-APS channel can be untagged by removing VLAN type configuration check on the Service VLAN
(SVLAN).
When specifying a SVLAN, the configuration must check that the ring port(s) are members of this VLAN,
tagged or untagged.
The VLAN and VPAs must be created first.
Note. All the nodes and ring ports must be configured with the same default or untagged VLAN.
Example: To configure an untagged R-APS channel for ring 1
On all nodes, a default or untagged VLAN must be configured on the ring ports:
-> vlan 4000
-> vlan 4000 members port 1/1-2 untagged
-> erp-ring 1 port1 1/1 port2 1/2 service-vlan 4000 level 2
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 11-8
Configuring ERP
Interaction With Other Features
Interaction With Other Features
This section contains important information about interaction of ERP with other OmniSwitch features.
Refer to the specific chapter for each feature to get more detailed information about how to configure and
use the feature.
Multicast
• IP multicast switching (IPMS) treats the ERP Service VLAN the same as any other configured VLAN
on the switch. The ERP Service VLAN may carry data traffic, and if enabled and configured to do so,
IPMS will perform regular multicast snooping on that VLAN.
• Disabling IPMS on the ERP Service VLAN is recommended if IP multicast routing or multicast
snooping is enabled for the switch.
Spanning Tree
• Spanning Tree is automatically disabled when ERP is enabled on any port.
• On a switch running AOS Release 6 (for example, an OmniSwitch 6450), the default VLAN for ERP
ports is protected and controlled by Spanning Tree.
• On a switch running AOS Release 7 or 8 (for example, an OmniSwitch 6900), the default VLAN for
ERP ports is protected and controlled by ERP.
VLAN Stacking
ERP has the following interactions with VLAN Stacking:
• ERP is supported on Network Network Interface (NNI) ports; it is not supported on UNI ports.
• Tunneling of STP BPDUs across UNI ports is supported in a VLAN stacking configuration.
See “Configuring ERP with VLAN Stacking NNIs” on page 11-15 for more information.
Source Learning
The ERP protocol determines and performs the MAC address flushing per port.
QoS Interface
The interaction between ERP and QoS is for the purpose so that R-APS PDUs can be handled
appropriately by the switch.
MVRP
ERP NI must provide blocking or forwarding state of ERP ports to MVRP.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 11-9
Configuring ERP
Quick Steps for Configuring ERP with Standard VLANs
Quick Steps for Configuring ERP with Standard
VLANs
The following steps provide a quick tutorial for configuring ERP.
1 Create a VLAN using the vlan command and add the ring ports.
-> vlan 1001
-> vlan 1001 members port 1/1-2 tagged
2 Create ERP ring ID 1, ERP Service VLAN and MEG Level and associate two ports to the ring using
the erp-ring command.
-> erp-ring 1 port1 1/1 port2 1/2 service-vlan 1001 level 1
3 Configure the RPL on one node using the erp-ring rpl-node command.
-> erp-ring 1 rpl-node port 1/1
4 Create additional VLANs and add to the ring ports using the vlan command.
-> vlan 11-20
-> vlan 11-20 members port 1/1-2 tagged
5 Enable the ERP ring configuration using the erp-ring enable command.
-> erp-ring 1 enable
6 Display the ERP configuration using the show erp command.
-> show erp
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 11-10
Configuring ERP
Quick Steps for Configuring ERP with VLAN Stacking
Quick Steps for Configuring ERP with VLAN
Stacking
The following steps provide a quick tutorial for configuring ERP with VLAN Stacking:
1 Create a VLAN Stacking SVLAN 1001 using the command.
-> ethernet-service svlan 1001
2 Create a VLAN Stacking service and associate the service with SVLAN 1001 using the ethernet-
service service-name command.
-> ethernet-service service-name CustomerA svlan 1001
3 Configure ports 1/1 and 1/2 as VLAN Stacking Network Network Interface (NNI) ports, associate the
ports with SVLAN 1001, and configure them for use with ERP using the ethernet-service svlan nni
command.
->
->
->
->
ethernet-service
ethernet-service
ethernet-service
ethernet-service
nni port 1/1
nni port 1/2
svlan 1001 nni port 1/1
svlan 1001 nni port 1/2
4 Create ERP ring ID 1 and associate the two NNI ports to the ring using the erp-ring command.
-> erp-ring 1 port1 1/1 port2 1/2 service-vlan 1001 level 5
5 Configure the RPL on one node using the erp-ring rpl-node command.
-> erp-ring 1 rpl-node port 1/1
6 Create additional SVLANs and add to the ring ports using the command.
->
->
->
->
ethernet-service
ethernet-service
ethernet-service
ethernet-service
svlan
svlan
svlan
svlan
1002
1003
1002 nni port 1/1-2
1002 nni port 1/2-2
7 Enable the ERP ring configuration using the erp-ring enable command.
-> erp-ring 1 enable
8 Display the ERP configuration using the show erp command.
-> show erp
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 11-11
Configuring ERP
ERP Configuration Overview and Guidelines
ERP Configuration Overview and Guidelines
Configuring ERP requires several steps. These steps are outlined here and further described throughout
this section. For a brief tutorial on configuring ERP, see ““Quick Steps for Configuring ERP with
Standard VLANs” on page 11-10.
By default, ERP is disabled on a switch. Configuring ERP consists of these main tasks:
1 Configure the basic components of an ERP ring (ring ports, service VLAN, and MEG level). See
“Configuring an ERP Ring” on page 11-13.
2 Tag VLANs for ring protection. See “Adding VLANs to Ring Ports” on page 11-13.
3 Configure an RPL port. When a ring port is configured as an RPL port, the node to which the port
belongs becomes the RPL owner. The RPL owner is responsible for blocking and unblocking the RPL.
See “Configuring an RPL Port” on page 11-14.
4 Change the Wait-To-Restore timer value. This timer value determines how long the RPL owner waits
before restoring the RPL to a forwarding state. See “Setting the Wait-to-Restore Timer” on page 11-14.
5 Change the Guard timer value. This timer value determines an amount of time during which ring nodes
ignore R-APS messages. See “Setting the Guard Timer” on page 11-14.
6 Configure the ring port to receive the loss of connectivity event for a Remote Ethernet OAM endpoint.
See “Configuring ERP with VLAN Stacking NNIs” on page 11-15.
7 Configure a VLAN Stacking NNI-to-SVLAN association for ERP control. This is done to include an
SVLAN in a ring configuration. See “Configuring ERP with VLAN Stacking NNIs” on page 11-15.
8 Clear ERP statistics. Commands to clear ERP statistics for a single ring or multiple rings are described
in “Clearing ERP Statistics” on page 11-16.
Configuration Guidelines
Use the following guidelines when configuring ERP for the switch:
• Physical switch ports and logical link aggregate ports can be configured as ERP ring ports. This also
includes VLAN Stacking Network Network Interface (NNI) ports.
• ERP is not supported on mobile ports, mirroring ports, link aggregate member ports, multicast VLAN
receiver ports (ERP is supported on Multicast VLAN sender ports only), or VLAN Stacking User
Network Interface (UNI) ports.
• An ERP ring port can belong to only one ERP ring at a time.
• STP is automatically disabled when ERP is enabled on any port.
• If the ERP switch participates in an Ethernet OAM Maintenance Domain (MD), configure the
Management Entity Group (MEG) level of the ERP service VLAN with the number that is used for the
Ethernet OAM MD.
• The Service VLAN can belong to only one ERP ring at a time and must be a static VLAN. Note that
the service VLAN is also a protected VLAN.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 11-12
Configuring ERP
Configuring an ERP Ring
Configuring an ERP Ring
The following configuration steps are required to create an ERP ring:
1 Determine which two ports on the switch are the ring ports. For example, ports 1/1 and 1/2.
2 Determine which VLAN on the switch is the ERP service VLAN for the ring. If the VLAN does not
exist, create the VLAN. For example:
-> vlan 500
3 Create the ERP ring configuration on each switch using the erp-ring command. For example the
following command configures an ERP ring with ring ID 1 on ports 1/2 and 1/2 along with service VLAN
500 and MEG level 1.
-> erp-ring 1 port1 1/1 port2 1/2 service-vlan 500 level 1
-> erp-ring 1 enable
To configure link aggregate logical ports as ring ports, use the erp-ring command with the linkagg
parameter. For example:
-> erp-ring 1 port1 linkagg 1 port2 linkagg 2 service-vlan 500 level 1
-> erp-ring 1 enable
4 Repeat Steps 1 through 6 for each switch that participates in the ERP ring. Make sure to use the same
VLAN ID and MEG level for the service VLAN on each switch.
Use the show erp command to verify the ERP ring configuration. For more information about this
command, see the OmniSwitch AOS Release 8 CLI Reference Guide.
Removing an ERP Ring
To delete an ERP ring from the switch configuration, use the no form of the erp-ring command. For
example:
-> no erp-ring 1
Note. Administratively disable ring ports before deleting the ring to avoid creating any network loops.
Once a ring is deleted, then administratively enable the ports under Spanning Tree protocol.
Adding VLANs to Ring Ports
ERP allows a single VLAN or a number of VLANs to participate in a single ERP ring. The vlan members
tagged command is used to tag the ring ports of the ERP ring with a VLAN ID.
To add a VLAN or range of VLANs to ring ports use the vlan members tagged command.
-> vlan 12-20
-> vlan 12-20 members port 1/1 tagged
-> vlan 12-20 members port 1/2 tagged
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 11-13
Configuring ERP
Configuring an ERP Ring
Configuring an RPL Port
A ring protection link (RPL) port can be a physical or logical port. The port must be a ring port before it is
configured as an RPL port, and out of the two ring ports on the node, only one can be configured as a RPL
port. The RPL remains blocked to prevent loops within the ERP ring.
To configure an RPL port, first disable the ring and then use the erp-ring rpl-node command to specify
which ring port serves as the RPL. For example:
-> erp-ring 1 disable
-> erp-ring 1 rpl-node port 1/1
-> erp-ring 1 enable
Note. RPL node can be configured only when the ring is disabled; RPL configuration applied to the ring
while it is enabled is rejected.
To remove the RPL node configuration for the specified ring, use the no form of the erp-ring rpl-node
command. For example:
-> no erp-ring 1 rpl-node
To verify the RPL node configuration for the switch, use the show erp command. For more information
about this command, see the OmniSwitch AOS Release 8 CLI Reference Guide.
Setting the Wait-to-Restore Timer
The wait-to-restore (WTR) timer determines the number of minutes the RPL owner waits before blocking
the RPL port after the ERP ring has recovered from a link failure.
By default, the WTR time is set to five minutes. To change the value of the WTR timer, use the erp-ring
wait-to-restore command. For example:
-> erp-ring 1 wait-to-restore 6
The above command is only used on a switch that serves as the RPL node for the ERP ring. The specified
ERP ring ID must already exist in the switch configuration.
To restore the timer back to the default setting, use the no form of the erp-ring wait-to-restore command.
For example:
-> no erp-ring 1 wait-to-restore
To verify the WTR configuration, use the show erp command. For more information about this command,
see the OmniSwitch AOS Release 8 CLI Reference Guide.
Setting the Guard Timer
The guard timer is used to prevent the ring nodes from receiving outdated R-APS messages, which are no
longer relevant. Receiving outdated R-APS messages could result in incorrect switching decisions. During
the amount of time determined by this timer, all received R-APS messages are ignored by the ring
protection control process.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 11-14
Configuring ERP
Configuring an ERP Ring
By default, the guard timer value is set to 50 centi-seconds. To change the value of this timer, use the erpring guard-timer command. For example:
-> erp-ring 1 guard-timer 100
To restore the Guard Timer back to the default value, use the no form of the erp-ring guard-timer
command. For example:
-> no erp-ring 1 guard-timer
To verify the configured Guard Timer, use the show erp command. For more information about this
command, see the OmniSwitch AOS Release 8 CLI Reference Guide.
Configuring ERP with VLAN Stacking NNIs
A VLAN Stacking Network Network Interface (NNI) can participate in an ERP ring. However, an NNI is
created through an association of a port with an SVLAN. Both STP and ERP cannot control the same
VLAN-port association (VPA). By default, the NNI to SVLAN association is controlled by STP.
To include an NNI in an ERP ring, specify ERP control at the time the NNI association is configured. This
is done using the erp parameter of the ethernet-service svlan nni command. For example:
-> ethernet-service svlan 1001 nni port 1/1
-> ethernet-service svlan 1001 nni port 1/2
The above commands configure ports 1/1 and 1/2 as NNI ports for SVLAN 1001. Note that the SVLAN
specified must already exist in the switch configuration.
To configure an ERP ring with NNI-SVLAN associations, use the erp-ring command but specify an
SVLAN ID for the service VLAN and the associated NNI ports as the ring ports. For example:
-> erp-ring 1 port1 1/1 port2 1/2 service-vlan 1001 level 2
-> erp-ring 1 enable
Note the following when configuring an ERP ring with VLAN Stacking NNI-SVLAN associations:
• Only two ERP type NNI associations are allowed per SVLAN.
• Configuring an ERP ring on 802.1q tagged port associations with SVLANs is not allowed.
• Configuring an ERP Ring on an STP type NNI association with an SVLAN is not allowed.
• Configuring an IMPVLAN as an ERP service VLAN is not allowed.
• If an SVLAN that is not associated with any NNI ports is configured as the service VLAN for an ERP
ring, the NNI ring ports are automatically associated with that SVLAN at the time the ring is created.
• SVLAN User Network Interface (UNI) associations are not eligible for ERP ring protection.
• If the ERP type NNI ports are connected to the STP path through UNI ports, then STP BPDUs can be
tunneled with the help of VLAN-stacking mechanism.
• Deleting an ERP service VLAN and it is associated NNI ports is only allowed when the ERP ring itself
is deleted using the no for of the erp-ring command. None of the VLAN Stacking CLI commands can
remove a service VLAN consisting of an NNI-SVLAN association.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 11-15
Configuring ERP
Configuring an ERP Ring
Configuring ERP Protected SVLANs
An SVLAN becomes an ERP protected SVLAN when the SVLAN is associated with two NNI ports that
also serve as ring ports. In this case, the SVLAN is automatically protected as part of the association with
NNI ring ports.
The following sequence of configuration commands provides an example of how SVLANs are
automatically added as protected SVLANs to an ERP ring:
->
->
->
->
->
->
->
->
ethernet-service svlan 100
ethernet-service svlan 200
ethernet-service svlan 300
ethernet-service svlan 400
ethernet-service svlan 100
ethernet-service svlan 200
ethernet-service svlan 300
erp-ring 10 port1 1/1 port
nni port 1/1-2
nni port 1/1-2
nni port 1/1-2
2 1/2 service-vlan 400 level 1
In the above example:
• SVLANs 100, 200, and 300 are automatically added as protected VLANs when the ring is created.
This is due to the NNI ports being part of ERP ring 10.
• SVLAN 400 is also automatically added as a protected VLAN when it is configured as the service
VLAN for the ring.
Use the show erp command to verify the configured VLAN Stacking ERP ring configuration. For more
information about these commands, see the OmniSwitch AOS Release 8 CLI Reference Guide.
Clearing ERP Statistics
To clear ERP statistics for all rings in the switch, use the clear erp statistics command. For example:
-> clear erp statistics
To clear ERP statistics for a specific ring in the switch, use the clear erp statistics command with the ring
parameter to specify a ring ID. For example:
-> clear erp statistics ring 5
To clear ERP statistics for a specific ring port, use the clear erp statistics command with the ring and
port parameters. For example:
-> clear erp statistics ring 5 port 1/2
To clear ERP statistics for a specific link aggregate ring port, use clear erp statistics command with the
ring and linkagg parameters. For example:
-> clear erp statistics ring 5 linkagg 2
Use the show erp statistics command to verify ERP statistics. For more information about this command,
see the OmniSwitch AOS Release 8 CLI Reference Guide.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 11-16
Configuring ERP
ERPv2 Configuration Overview and Guidelines
ERPv2 Configuration Overview and Guidelines
The following section details the guidelines and prerequisites for configuring ERPv2 and details on how to
configure the ERPv2 related parameters using the OmniSwitch CLI. Configuring the sample ERPv2 ring
network involves the following tasks:
1 Optional: Configure tagged ports or link aggregate ports before configuring ERP.
2 Configure an ERP ring with same ERP ring ID on all switches in the network.
3 Define same ERP Service VLAN on all switches.
4 Set the same Management Entity Group (MEG) (for example, level 2) for all switches.
5 Assign one switch to be the RPL owner. Configure the port connected to the Ring Protection Link as
an RPL port.
6 Enable the configured ERPv2 ring.
7 Assign separate VLANs as protected VLANs to the ERP ring.
8 Use the default settings for the guard timer and WTR timer values. These values can be adjusted as
necessary.
The following sub-sections provide the details on prerequisites and different configurations for switches to
set up an ERPv2 ring network using OmniSwitch CLI commands.
Major and Sub Ring Management
A shared link must be configured only on the major ring.
The following conditions must be considered for configuring an ERPv2 port for a shared link:
• Sub-rings can not be closed using a shared link.
• An SVLAN must exist before an ERP ring is created and must be unique per ring.
• A given port can only be configured on one ring.
• Each ring must have its own RPL.
• The RPL can be placed anywhere on the major ring including the shared links.
• The RPL can be placed anywhere on the sub-rings, including the sub-ring-port. Since the sub-ring is
not closed using the shared link, the RPL cannot be placed on the shared link.
Configuration Parameters
The following conditions must be considered before configuring an ERPv2 port:
• A given port can only be configured on one ring.
• The shared links are only configurable on the Master Ring.
• The Sub Rings cannot be closed using the shared links.
• Each ring must have its own RPL.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 11-17
Configuring ERP
ERPv2 Configuration Overview and Guidelines
• The RPL can be placed anywhere on the Master Ring, including the shared links.
• The RPL can be placed anywhere on the Sub Rings, including the only ring port of the interconnection
nodes. Since the sub-ring is not closed using the shared link, the RPL cannot be placed on the shared
link.
ERPv2 Ring Sample Configuration
A master ring can be configured using the following command:
Switch 1-> erp-ring 1 port1 1/1 port2 1/2 service-vlan 10 level 2
A sub-ring on the non-interconnection node can be configured using the following command:
Switch 2-> erp-ring 2 port1 1/1 port2 1/3 service-vlan 10 level 2
A sub ring on the interconnection node can be configured using the following command:
Switch 3-> erp-ring 3 sub-ring-port 1/3 service-vlan 10 level 2
Sample Switch Configuration
The following configurations must be performed on each switch in the ERPv2 Ring network:
Step 1 : Create the Service VLAN and add to ring ports.
->
->
->
->
->
vlan
vlan
vlan
vlan
vlan
10
200
10 members port 1/3 tagged
10 members port 1/5 tagged
200 members port 1/6 tagged
Step 2 : Create the rings.
-> erp-ring 1 port1 1/5 port2 1/3 service-vlan 10 level 1
-> erp-ring 2 sub-ring-port 1/6 service-vlan 200 level 1
Step 3 : Create traffic VLANs and add to ring ports as necessary using VM commands
->
->
->
->
vlan
vlan
vlan
vlan
100-400
100-300 members port 1/5 tagged
100-300 members port 1/3 tagged
201-400 members port 1/6 tagged
Step 4 : Enable the rings.
-> erp-ring 1 enable
-> erp-ring 2 enable
Note. The traffic VLANs could be added or deleted as needed at any time during the configuration.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 11-18
Configuring ERP
ERPv2 Configuration Overview and Guidelines
Enabling and Disabling R-APS Virtual Channel
User can enable and disable virtual channel. By default, R-APS virtual channel is enabled.
Enabling R-APS Virtual Channel
Enable R-APS virtual channel using the following command:
-> erp-ring 2 virtual-channel enable
R-APS messages from the sub-ring on the interconnection node are forwarded as normal data to the major
ring ports.A node is identified as interconnection node when atleast one ring is configured with a sub-ringport.
R-APS messages from the sub-ring are tagged with the sub-ring SVLAN, are forwarded to the major ring
member ports of this SVLAN.
Note. All the ring ports in major ring must be member of the sub-ring SVLAN to support R-APS virtual
channel.
Interconnection Node of the Sub-Ring
When R-APS virtual channel is enabled, on the interconnection node of a sub-ring, all the R-APS
messages received from sub-ring port are processed and flooded to major ring ports that are the member of
the VLAN used by R-APS message. For example,
-> erp-ring 3 virtual-channel enable
Other nodes of the Sub-Ring
When enabled, R-APS messages received on blocked port are processed but not forwarded to the other
ring port.
Disabling R-APS Virtual Channel
Disable R-APS virtual channel using the following command:
-> erp-ring 2 virtual-channel disable
Now, R-APS messages from the sub-ring on the interconnection node are not forwarded to any other
ports. R-APS messages are forwarded even on the blocked ports in the sub-ring. A configuration object is
required for the sub-ring to disable the R-APS virtual channel.
Interconnection Node of the Sub-Ring
When virtual channel is disabled, R-APS message received from sub-ring ports are processed but not
flooded to major ring. For example,
-> erp-ring 3 virtual-channel disable
Other nodes of the Sub-Ring
When virtual channel is disabled, R-APS messages received on blocked port are processed and forwarded
to other ring port.
Note. Virtual channel configuration must be consistent among all nodes of the sub-ring.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 11-19
Configuring ERP
ERPv2 Configuration Overview and Guidelines
Enabling or Disabling Revertive Mode
Revertive mode is enabled by default. You can disable revertive mode by setting the following command:
-> erp-ring 2 revertive enable
You can enable revertive mode by setting following command:
-> erp-ring 2 revertive disable
Non-revertive Mode
Under non-revertive mode, when the failure recovers, the blocked port stays blocked and the unblocked
RPL stays unblocked. Revertive mode is enabled by default. Operator can enable non-revertive mode by
setting following command.
When the ERPv2 node is operating with ERPv1 node in the same ring, it operates in different way for
compatibility. In this mode, revertive mode is always assumed, it operates in revertive mode regardless of
user configuration.
-> erp-ring 2 revertive disable
Clear Non-revertive and Revertive Mode
When the ring is in the No Request (NR) state and the blocked port is not the RPL port, the operator must
be allowed to trigger the reversion to the initial state of the ring (make the RPL port blocked).
This situation happens in 2 cases:
• The ring is set in a non-revertive mode.
• The ring is set in a revertive mode but the WTR timer has not expired.
The CLI command is as follows:
-> erp-ring 2 clear
The command can only be issued on the RPL owner node and when the ring is in the NR state and WTR
timer not expired or no WTR (non-revertive mode)
When the command is accepted, the RPL owner node blocks its RPL port, and transmits an R-APS (NR,
RB) message in both directions. Upon receiving the R-APS (NR, RB), each node unblocks its blocking
ports and performs a flush operation when applicable.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 11-20
Configuring ERP
Sample Ethernet Ring Protection Configuration
Sample Ethernet Ring Protection Configuration
This section provides an example network configuration in which ERP is configured on network switches
to maintain a loop-free topology. In addition, a tutorial is also included that provides steps on how to
configure the example network topology using the Command Line Interface (CLI).
Example ERP Overview
The following diagram shows a five-switch ERP ring configuration:
Switch D
Fa
2/1
Fa
]
17
.1.
6
1
.
72
[1
NG
RI
NK
LI
Pr
ot
ec
tio
nL
IN
K
(R
PL
)
[17
2.1
6.1
.13
]
RPL
8]
2/2 6.1.1
a
F 2.1
7
[1
Port
2/1
Switch C
1/2
Fa
]
.21
6.1
2.1
[17
Fa
1/2
[17
2.1
6.1
.10
]
Fa
2/1
Fa
]
.22
6.1
2.1
[17
Fa
2/2
[17
2.1
6.1
.9]
INK
GL
RIN
RING LINK
Fa 2/2
[172.16.1.5]
RPL Owner
RIN
GL
INK
Switch E
1/2
[17
2.1
6.1
.14
]
RI
NG
Fa 1/1
[172.16.1.6]
Switch A
Switch B
Configuring the sample ERP ring network shown in the above diagram involves the following tasks:
1 Configure an ERP ring with ERP ring ID 1 on all switches in the network.
2 Define an ERP Service VLAN as VLAN 10 on all switches.
3 Set the Management Entity Group (MEG) level to 2 for all switches.
4 Switch C is the RPL owner; configure the port connected to the Ring Protection Link as a RPL port.
5 Enable the configured ERP ring.
6 Assign VLANs 11-20 as a protected VLANs to ERP ring 1.
7 Use the default settings for the guard timer and WTR timer values. These values can be adjusted as
necessary.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 11-21
Configuring ERP
Sample Ethernet Ring Protection Configuration
Example ERP Configuration Steps
The following steps provide a quick tutorial for configuring the ERP ring network shown in the diagram
on page 11-21:
1 Configure ERP ring 1 and add protected VLANs 11 through 20 on Switch A, B, C, D, and E using the
following commands:
->
->
->
->
->
vlan 10
vlan 10 members port 2/1-2 tagged
erp-ring 1 port1 2/1 port2 2/2 service-vlan 10 level 2
erp-ring 1 enable
vlan 11-20 members port 2/1-2 tagged
2 Configure Switch C as the RPL owner for the ring using the following commands to designate port 2/1
as the RPL port:
-> erp-ring 1 disable
-> erp-ring 1 rpl-node port 2/1
-> erp-ring 1 enable
3 Verify the ERP ring configuration on any switch using the following command:
-> show erp ring 1
Legend: * - Inactive Configuration
Ring Id
Ring Port1
Ring Port2
Ring Status
Service VLAN
WTR Timer (min)
Guard Timer (centi-sec)
MEG Level
Ring State
Ring Node Type
RPL Port
Last State Change
:
:
:
:
:
:
:
:
:
:
:
:
1,
2/1,
1/2,
enabled,
10,
5,
50,
2,
idle,
rpl,
2/1,
SUN DEC 25 06:50:17 2016 (sysUpTime 00h:01m:31s)
The above output example shows that ERP ring 1 is created on ring ports 2/1 and 1/2 with service VLAN
10, WTR timer of 5 mins, Guard timer of 50 centi-seconds, MEG level 2, and port 2/1 is the RPL port.
4 Verify the status of an ERP ring port on any switch using the following command:
-> show erp port 1/2
Legend: * - Inactive Configuration
Ring-Id : 1
Ring Port Status
Ring Port Type
Ethoam Event
: forwarding,
: non-rpl,
: disabled
The above command shows the forwarding status of the port, the type of ring port (RPL or non-RPL), and
ETHOAM event status.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 11-22
Configuring ERP
Sample ERPv2 Ring Configuration
Sample ERPv2 Ring Configuration
This section provides an example network configuration in which ERPv2 is configured on network
switches to maintain a loop-free topology. In addition, a tutorial is also included that provides steps on
how to configure the example network topology using the Command Line Interface (CLI).
Example ERPv2 Overview
The following diagram shows a seven-switch ERPv2 ring configuration when R-APS virtual channel is
enabled.
The topology of the network is as follows:
• Switches A, B, C, D, and E for the Major Ring.
• Switch A and B form a shared link.
• Switch C is configured to be the main RPL node.
• Switches A, B, F, and G form the Sub Ring.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 11-23
Configuring ERP
Sample ERPv2 Ring Configuration
The following sub-sections provide the details on prerequisites and different configurations for switches to
set up an ERPv2 ring network using OmniSwitch CLI commands.
Configuring Shared Link
The following configurations must be performed on Switch A and Switch B.
Step 1 : Create the Service VLAN and add to ring ports on Switch A and B that are part of a shared link:
Switch
Switch
Switch
Switch
Switch
A
A
A
A
A
->
->
->
->
->
vlan
vlan
vlan
vlan
vlan
10
200
10 members port 2/1 tagged
10 members port 2/2 tagged
200 members port 1/6 tagged
Switch
Switch
Switch
Switch
Switch
B
B
B
B
B
->
->
->
->
->
vlan
vlan
vlan
vlan
vlan
10
200
10 members port 1/1 tagged
10 members port 2/2 tagged
200 members port 1/6 tagged
Step 2 : Create the ERP rings 1 and 2 on Switch A.
Switch A -> erp-ring 1 port1 2/1 port2 2/2 service-vlan 10 level 1
Switch A -> erp-ring 2 sub-ring-port 1/6 service-vlan 200 level 1
Step 3 : Create traffic VLANs and add to ring ports as necessary using VM commands on Switch A.
Switch
Switch
Switch
Switch
A
A
A
A
->
->
->
->
vlan
vlan
vlan
vlan
100-400
100-300 members port 2/1 tagged
100-300 members port 2/2 tagged
201-400 members port 1/6 tagged
Step 4 : Enable the rings on Switch A.
Switch A -> erp-ring 1 enable
Switch A -> erp-ring 2 enable
Configuring Main RPL Node
Main RPL is configured on the Switch B. The following configurations must be performed on Switch B.
Step 1 : Create the ERP rings 1 and 2 on Switch B.
Switch B -> erp-ring 1 port1 1/1 port2 2/2 service-vlan 10 level 1
Switch B -> erp-ring 2 sub-ring-port 1/6 service-vlan 2000 level 1
Step 2 : Configure Switch B as RPL Node using the erp-ring rpl-node command:
Switch B -> erp-ring 1 rpl-node 2/2
Step 3 : Enable the rings on Switch B.
Switch B -> erp-ring 1 enable
Switch B -> erp-ring 2 enable
Step 4 : Create traffic VLANs and add to ring ports as necessary Switch B.
Switch B -> vlan 100-400
Switch B -> vlan 100-300 members port 1/1 tagged
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 11-24
Configuring ERP
Sample ERPv2 Ring Configuration
Switch B -> vlan 100-300 members port 2/2 tagged
Switch B -> vlan 201-400 members port 1/6 tagged
Configuring Switches in Main Ring
The following configurations must be performed on Switch C, D, and E
->
->
->
->
->
->
->
->
vlan 10
vlan 10 members port
vlan 10 members port
erp-ring 1 port1 1/2
vlan 100-300
erp-ring 1 enable
vlan 100-300 members
vlan 100-300 members
1/2 tagged
2/1 tagged
port2 2/1 service-vlan 10 level 1
port 1/2 tagged
port 2/1 tagged
Configuring Secondary RPL Node
The following configurations must be performed on Switch F in the ERPv2 Ring network:
->
->
->
->
->
->
vlan 200-400
vlan 200-400 members port 1/6 tagged
vlan 200-400 members port 2/2 tagged
erp-ring 2 port1 1/6 port2 2/2 service-vlan 200 level 1
erp-ring 2 rpl-node 1/6
erp-ring 2 enable
Configuring Switch in Sub Ring
The following configurations must be performed on Switch G in the ERPv2 Ring network:
->
->
->
->
->
vlan 200-400
vlan 200-400 members port 1/1 tagged
vlan 200-400 members port 1/6 tagged
erp-ring 2 port1 1/1 port2 1/6 service-vlan 200 level 1
erp-ring 2 enable
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 11-25
Configuring ERP
Verifying the ERP Configuration
Verifying the ERP Configuration
A summary of the show commands used for verifying the ERP configuration is given here:
show erp
Displays the ERP configuration information for all rings, a specific ring,
or for a specific ring port.
show erp statistics
Displays the ERP statistics for all rings, a specific ring, or a specific ring
port.
show ethernet-service
Displays configuration information for VLAN Stacking Ethernet
services, which includes SVLANs and NNI port associations.
show ethernet-service nni
Displays the VLAN Stacking NNI configuration.
ethernet-service transparentbridging
Displays a list of SVLANs configured for the switch.
For more information about the displays that result from these commands, see the OmniSwitch AOS
Release 8 CLI Reference Guide.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 11-26
12
Configuring MVRP
Multiple VLAN Registration Protocol (MVRP) is standards-based Layer 2 network protocol for automatic
configuration of VLAN information on switches. It was defined in the 802.1ak amendment to 802.1Q2005.
MVRP provides a method to share VLAN information and configure the needed VLANs within a layer 2
network. For example, in order to add a switch port to a VLAN, only the end port, or the VLANsupporting network device connected to the switch port, has to be reconfigured, and all necessary VLAN
trunks are dynamically created on the other MVRP-enabled switches. MVRP helps to maintain VLAN
configuration dynamically based on current network configurations.
In This Chapter
This chapter describes the MVRP feature and how to configure it through the Command Line Interface
(CLI). CLI commands are used in the configuration examples; for more details about the syntax of
commands, see the OmniSwitch AOS Release 8 CLI Reference Guide. This chapter provides an overview
of MVRP and includes the following information:
• “Enabling MVRP” on page 12-7
• “Configuring the Maximum Number of VLANs” on page 12-7
• “Configuring MVRP Registration” on page 12-8
• “Configuring the MVRP Applicant Mode” on page 12-9
• “Modifying MVRP Timers” on page 12-10
• “Restricting VLAN Registration” on page 12-11
• “Restricting Static VLAN Registration” on page 12-11
• “Restricting VLAN Advertisement” on page 12-12
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 12-1
Configuring MVRP
MVRP Defaults
MVRP Defaults
The following table lists the defaults for MVRP configuration.
Parameter Description
Command
Default Value/Comments
Enables or disables MVRP globally mvrp
on a switch.
disabled
Enables or disables MVRP on
specific ports
mvrp port
disabled
Maximum number of VLANs
mvrp maximum-vlan
256
Registration mode of the port
mvrp registration
normal
Applicant mode of the port
mvrp applicant
active
Timer value for join timer.
mvrp timer join
600 milliseconds
Timer value for leave timer.
mvrp timer leave
1800 milliseconds
Timer value for leaveall timer.
mvrp timer leaveall
30000 milliseconds
Timer value for periodic timer.
mvrp timer periodic-timer
1 second
Restrict dynamic VLAN registration mvrp restrict-vlan-registration
not restricted
Restrict VLAN advertisement
mvrp restrict-vlanadvertisement
not restricted
Restrict static VLAN registration
mvrp static-vlan-restrict
By default, ports are assigned
to the static VLAN based on
MVRP PDU processing.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 12-2
Configuring MVRP
Quick Steps for Configuring MVRP
Quick Steps for Configuring MVRP
The following steps provide a quick tutorial on how to configure MVRP. Each step describes a specific
operation and provides the CLI command syntax for performing that operation.
1 Create a VLAN using the vlan command. For example:
-> vlan 5 name "vlan-5"
2 Assign a port to the VLAN using the vlan members command. For example:
-> vlan 5 members port 1/2
3 Tag the port with one or more VLANs using the vlan members command. For example:
-> vlan 5 members port 1/2 tagged
4 Enable MVRP globally on the switch by using the mvrp command.
-> mvrp enable
5 Enable MVRP on the port by using the mvrp port command. For example, the following command
enables MVRP on port 1/2 of the switch:
-> mvrp port 1/2 enable
6 Optional: Restrict a port from becoming a member of the statically created VLAN by using the mvrp
static-vlan-restrict command. For example, the following command restricts port 1/5 from becoming a
member of static VLAN 10:
-> mvrp port 1/5 static-vlan-restrict vlan 10
Note. To view the global configuration details of the router, enter the show mvrp configuration command.
The globally configured details are displayed as shown:
> show mvrp configuration
MVRP Enabled : yes,
Maximum VLAN Limit : 256
To view the MVRP configuration for a specific port, enter the show mvrp port command. The
configuration data of the particular port is displayed as shown:
> show mvrp port 1/2
MVRP Enabled
Registrar Mode
Applicant Mode
Join Timer (msec)
Leave Timer (msec)
LeaveAll Timer (msec)
Periodic Timer (sec)
Periodic Tx Status
:
:
:
:
:
:
:
:
no,
normal,
participant,
600,
1800,
30000,
1,
disabled
See the OmniSwitch AOS Release 8 CLI Reference Guide for information about the fields in this display.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 12-3
Configuring MVRP
MRP Overview
MRP Overview
Multiple Registration Protocol (MRP) was introduced as a replacement for GARP with the IEEE 802.1ak2007 amendment. The Multiple VLAN Registration Protocol (MVRP) defines a MRP Application that
provides the VLAN registration service.
MVRP provides a mechanism for dynamic maintenance of the contents of dynamic VLAN registration
Entries for each VLAN, and for propagating the information they contain to other bridges. This
information allows MVRP-aware devices to dynamically establish and update their knowledge of the set
of VLANs that currently have active members, and through which ports those members can be reached.
The main purpose of MVRP is to allow switches to automatically discover some of the VLAN information
that would otherwise have to be manually configured.
MVRP Overview
MVRP acts as an MRP application, sending and receiving MVRP information encapsulated in an Ethernet
frame on a specific MAC address. MVRP allows both end stations and bridges in a bridged local area
network to issue and revoke declarations relating to membership of VLANs. Each MVRP device that
receives the declaration in the network creates or updates a dynamic VLAN registration entry in the
filtering database to indicate that the VLAN is registered on the reception port.
In this way, MVRP provides a method to share VLAN information within a layer 2 network dynamically,
and configure the required VLANs. For example, in order to add a switch port to a VLAN, only the end
port, or the VLAN-supporting network device connected to the switch port, must be reconfigured, and all
necessary VLAN trunks are dynamically created on the other MVRP-enabled switches. Without using
MVRP, either a manual configuration of VLAN trunks or use of a manufacturer specific proprietary
method is necessary. MVRP helps to maintain VLAN configuration dynamically based on current network
configurations.
How MVRP Works
An MVRP enabled port sends MRPDUs advertising the VLAN enabling another MVRP aware port
receiving advertisements over a link to join the advertised VLAN dynamically. All ports of a dynamic
VLAN operate as tagged ports for that VLAN.
An MVRP enabled port can forward an advertisement for a VLAN it learned about from other ports on the
same switch. However, the forwarding port does not join that VLAN on its own until an advertisement for
that VLAN is received on that same port.
The following example illustrates the VLAN advertisements.
1
Switch A
Static VLAN: 10, 20, 30
Dynamic VLAN
2
3
Switch B
Static VLAN
Dynamic VLAN
4
5
Switch C
Static VLAN
Dynamic VLAN
End Station
Static VLAN 50
Initial Configuration of MVRP
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 12-4
Configuring MVRP
MVRP Overview
Switch A has 3 VLANs configured as static VLANs (10, 20, and 30). Other switches on the same network
learn these 3 VLANs as dynamic VLANs. Also, the end station connected on port 5 is statically
configured for VLAN 50. Port 1 on Switch A is manually configured for VLANs 10, 20, and 30. All the
ports are in the same Spanning tree instance and are in forwarding state. Hence, as the Initial Configuration
of MVRP diagram shows,
1 Port 1 on Switch A advertises VLAN IDs (VIDs) 10, 20, and 30.
2 Port 2 on Switch B receives the advertisements. VLANs 10, 20, and 30 are created as VLANs on this
Switch B and Port 2 become a member of VLANs 10, 20, and 30.
3 Port 3 on Switch B is triggered to advertise VLANs 10, 20, and 30, but does not become a member of
these VLANs.
4 Port 4 on Switch C receives the advertisements. VLANs 10, 20, and 30 are created as VLANs on
Switch C and Port 4 become a member of VLANs 10, 20, and 30.
5 Port 5 advertises VLANs 10, 20, and 30, but this port is not a member of these VLANs.
Note. Default VLAN (VLAN 1) exists on all switches, but it is not considered here.
The configuration sequence of advertisements and registration of VLANs results in the following
configuration.
1
2
Switch A
Static VLAN: 10, 20, 30
Dynamic VLAN
3
Switch B
Static VLAN
Dynamic VLAN: 10, 20, 30
4
5
Switch C
Static VLAN
Dynamic VLAN: 10, 20, 30
End Station
Static VLAN 50
Dynamic Learning of VLANs 10, 20, and 30
Here, the end station advertises itself as a member of VLAN 50. As the Dynamic Learning of VLANs 10,
20, and 30 diagram shows,
1 Port 5 receives the advertisement and Switch C creates VLAN 50 as a dynamic VLAN. Port 5 of
Switch C becomes a member of VLAN 50.
2 Port 4 advertises VLAN 50, but is not a member of VLAN 50.
3 Port 3 of Switch B receives the advertisement, Switch B creates the dynamic VLAN 50, and Port 3
becomes a member of VLAN 50.
4 Port 2 advertises VLAN 50, but is not a member of this VLAN.
5 Port 1 on Switch A receives the advertisement, creates dynamic VLAN 50. Port 1 becomes a member
of VLAN 50.
The resulting configuration is depicted as follows:
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 12-5
Configuring MVRP
MVRP Overview
1
Switch A
Static VLAN: 10, 20, 30
Dynamic VLAN: 50
2
3
Switch B
Static VLAN
Dynamic VLAN: 10, 20, 30, 50
4
5
Switch C
Static VLAN
Dynamic VLAN: 10, 20, 30, 50
End Station
Static VLAN 50
Dynamic Learning of VLAN 50
Note. Every port on a switch is not a member of all the VLANs. Only those ports that receive the
advertisement become members of the VLAN being advertised.
Interaction With Other Features
This section contains important information about how other OmniSwitch features interact with MVRP.
Refer to the specific chapter for each feature to get more detailed information about how to configure and
use the feature.
STP
MVRP feature is supported only in STP flat mode. If MVRP is configured in the system with STP flat
mode, then STP mode cannot be changed to per-VLAN mode. When a topology change is detected by
STP, MAC addresses for the dynamic VPAs learned by MVRP is also deleted.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 12-6
Configuring MVRP
Configuring MVRP
Configuring MVRP
This section describes how to configure MVRP using the Command Line Interface (CLI) commands.
Enabling MVRP
MVRP is used primarily to prune unnecessary broadcast and unknown unicast traffic, and to create and
manage VLANs. MVRP has to be globally enabled on a switch before it can start forwarding MVRP
frames. When a port is enabled for MVRP, it cannot be converted as an aggregate or a VLAN stacking
User port.
To enable MVRP globally on the switch, enter the mvrp command at the CLI prompt as shown:
-> mvrp enable
To disable MVRP globally on the switch, use disable option of the mvrp command as shown:
-> mvrp disable
Note. Disabling MVRP globally leads to the deletion of all learned VLANs.
MVRP can be enabled on ports regardless of whether it is globally enabled or not. However, for the port
to become an active participant, MVRP must be globally enabled on the switch. By default, MVRP is
disabled on the ports. To enable MVRP on a specified port, use the mvrp port command.
For example, to enable MVRP on port 2 of slot 1, enter:
-> mvrp port 1/2 enable
Similarly, to enable MVRP on aggregate group 10, enter:
-> mvrp linkagg 10 enable
To disable MVRP on a specific port, use disable option of the mvrp port command as shown:
-> mvrp port 1/2 enable
Note. MVRP can be configured only on fixed, 802.1 Q and aggregate ports. It cannot be configured on
aggregate and VLAN Stacking User ports.
Configuring the Maximum Number of VLANs
A switch can create dynamic VLANs using MVRP. If the VLAN limit to be set is less than the current
number of dynamically learned VLANs, then the new configuration takes effect only after the MVRP is
disabled and enabled again on the switch. If this operation is not done, the VLANs learned earlier are
maintained.
To modify the maximum number of dynamic VLANs the switch is allowed to create, use the mvrp
maximum-vlan command as shown:
-> mvrp maximum-vlan 150
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 12-7
Configuring MVRP
Configuring MVRP
Configuring MVRP Registration
MVRP allows a port to register and de-register static VLANs. Every device has a list of all the switches
and end stations that can be reached at any given time. When an attribute for a device is registered or deregistered, the set of reachable switches and end stations, also called participants, is modified. Data frames
are propagated only to registered devices, thereby preventing attempts to send data to devices that are not
reachable.
The following sections describe MVRP registration on switches:
Setting MVRP Normal Registration
The normal registration mode allows dynamic creation, registration, and de-registration of VLANs on a
device. The normal mode is the default registration mode.
To configure a port in normal mode, use the mvrp registration command. For example, to configure port
2 of slot 1 in normal mode, enter the following:
-> mvrp port 1/2 registration normal
To view the registration mode of the port, use the show mvrp port command. For example:
-> show mvrp port 1/2
MVRP Enabled
Registrar Mode
Applicant Mode
Join Timer (msec)
Leave Timer (msec)
:
:
:
:
:
no,
normal,
participant,
600,
1800,
LeaveAll Timer (msec) : 30000,
Periodic Timer (sec) : 1,
Periodic Tx status
: disabled
Setting MVRP Fixed Registration
The fixed registration mode allows only manual registration of the VLANs and prevents dynamic or static
de-registration of VLANs on the port.
To configure a port to fixed mode, use the mvrp registration command. For example, to configure port 2
of slot 1 to fixed mode, enter the following:
-> mvrp port 1/2 registration fixed
To view the registration mode of the port, use the show mvrp port command. For example,
-> show mvrp port 1/2
MVRP Enabled
Registrar Mode
Applicant Mode
Join Timer (msec)
Leave Timer (msec)
LeaveAll Timer (msec)
Periodic Timer (sec)
Periodic Tx status
:
:
:
:
:
:
:
:
no,
fixed,
participant,
600,
1800,
30000,
1,
disabled
Note. The registration mode for the default VLANs of all the ports in the switch is set to normal.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 12-8
Configuring MVRP
Configuring MVRP
Setting MVRP Forbidden Registration
The forbidden registration mode prevents any VLAN registration or de-registration. If dynamic VLANs
previously created are present, they are de-registered.
To configure a port to forbidden mode, use the mvrp registration command. For example, to configure
port 2 of slot 1 to forbidden mode, enter the following:
-> mvrp port 1/2 registration forbidden
To view the registration mode of the port, use the show mvrp port command. For example,
-> show mvrp port 1/2
MVRP Enabled
Registrar Mode
Applicant Mode
Join Timer (msec)
Leave Timer (msec)
LeaveAll Timer (msec)
Periodic Timer (sec)
Periodic Tx status
:
:
:
:
:
:
:
:
no,
forbidden,
participant,
600,
1800,
30000,
1,
disabled
To view the MVRP configurations for all the ports, including timer values, registration and applicant
modes, enter the following:
-> show mvrp port enable
Port Join Leave LeaveAll
Periodic Registration Applicant
Periodic
Timer Timer
Timer
Timer
Mode
Mode
TxStatus
(msec) (msec)
(msec)
(sec)
----+-------+-------+--------+----------+-------------+------------+-------1/1
600
1800
30000
2
fixed
active
enabled
1/2
600
1800
30000
2
fixed
active
enabled
1/7
600
1800
30000
2
fixed
active
enabled
1/8
600
1800
30000
2
fixed
active
enabled
2/24 600
1800
30000
2
fixed
active
enabled
Configuring the MVRP Applicant Mode
The MVRP applicant mode determines whether MVRP PDU exchanges are allowed on a port, depending
on the Spanning Tree state of the port. This mode can be configured to be participant, non-participant,
or active. By default, the port is in the active mode.
To prevent undesirable Spanning Tree Protocol topology reconfiguration on a port, configure the MVRP
applicant mode as active. Ports in the MVRP active applicant state send MVRP VLAN declarations even
when they are in the STP blocking state, thereby preventing the STP bridge protocol data units (BPDUs)
from being pruned from the other ports.
To set the applicant mode of a port to active, use the mvrp applicant command. For example, to set the
applicant mode of port 1/2 to active, enter the following:
-> mvrp port 1/2 applicant active
When a port is set to participant mode, MVRP protocol exchanges are allowed only if the port is set to the
STP forwarding state.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 12-9
Configuring MVRP
Configuring MVRP
To set the applicant mode of port 1/2 to participant mode, enter the following:
-> mvrp port 1/2 applicant participant
When a port is set to non-participant mode, MVRP PDUs are not sent through the STP forwarding and
blocking ports.
To set the applicant mode of port 1/2 to non-participant mode, enter the following:
-> mvrp port 1/2 applicant non-participant
The applicant mode of the port can be set to the default value by using the mvrp applicant command. To
set the MVRP applicant mode of port 1/2 to the default mode (active mode), enter the following
command:
-> mvrp port 1/2 applicant active
Modifying MVRP Timers
MVRP timers control the timing of dynamic VLAN membership updates to connected devices. The
following are the various timers in MVRP:
• Join timer—The maximum time an MVRP instance waits before making declaration for VLANs.
• Leave timer—The wait time taken to remove the port from the VLAN after receiving a Leave message
on that port.
• LeaveAll timer—The time an MVRP instance takes to generate LeaveAll messages. The LeaveAll
message instructs the port to modify the MVRP state of all its VLANs to Leave.
• Periodic timer—The time frequency with which the messages are transmitted again and again.
When you set the timer values, the value for the Leave timer must be greater than or equal to twice the
Join timer value plus 100 milliseconds.(Leave>=Join * 2 +100). The LeaveAll timer value must be
greater than or equal to the Leave timer value (LeaveAll >= Leave). If you attempt to set a timer value
that does not adhere to these rules, an error message is displayed.
For example, if you set the Leave timer to 1200 ms and attempt to configure the Join timer to 600 ms, an
error is returned. Set the Leave timer to at least 1300 ms and then set the Join timer to 600 ms.
To modify the Join timer value, use the mvrp timer join command. For example, to modify the Join timer
value of port 1/2, enter the following:
-> mvrp port 1/2 timer join 600
The Join timer value of port 1/2 is now set to 600 ms.
To set the Leave timer value of port 1/2 to 1800 ms, enter the command as shown:
-> mvrp port 1/2 timer leave 1800
To set the LeaveAll timer of port 1/2 to 30000 ms, enter the command as shown:
-> mvrp port 1/2 timer leaveall 30000
To set the Periodic timer of port 1/2 to 1 second, enter the command as shown:
-> mvrp port 1/2 timer periodic-timer 1
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 12-10
Configuring MVRP
Configuring MVRP
To view the timer value assigned to a particular port, use the show mvrp timer command.
-> show mvrp port 1/2 timer
Join Timer (msec)
: 600,
Leave Timer (msec)
: 1800,
LeaveAll Timer (msec) : 30000,
Periodic-Timer (sec)
: 1
Note. Set the same MVRP timer value on all the connected devices.
Restricting VLAN Registration
Restricted VLAN registration restricts MVRP from dynamically registering specific VLAN or VLANs on
a switch. It decides whether VLANs can be dynamically created on a device or only be mapped to the
ports (if the VLANs are already statically created on the device).
By default, the dynamic VLAN registrations are not restricted and the VLAN can either be created on the
device or mapped to another port.
To restrict a VLAN from being dynamically learned on the device, you can configure the dynamic VLAN
registrations by using the mvrp restrict-vlan-registration command as shown:
-> mvrp port 1/1 restrict-vlan-registration vlan 4
Here, VLAN 4 cannot be learned by the device dynamically. However, if the VLAN exists on the device
as a static VLAN, it can be mapped to the receiving port.
To allow dynamic VLAN registrations on the port, use the no form of the mvrp restrict-vlanregistration command as shown:
-> no mvrp port 1/1 restrict-vlan-registration vlan 4
Restricting Static VLAN Registration
Ports can be exempted from becoming members of statically created VLANs. To restrict a port from
becoming a member of a statically configured VLAN, use the mvrp static-vlan-restrict command as
shown:
-> mvrp port 1/9 static-vlan-restrict vlan 5
Note. This command does not apply to dynamic VLANs.
Here, the port 1/9 is restricted from becoming a MVRP member of VLAN 5.
To restrict a port from becoming a member of a range of statically created VLANs, enter the mvrp staticvlan-restrict command as shown:
-> mvrp port 1/9 static-vlan-restrict vlan 5-9
Here, port 1/9 is restricted from becoming a MVRP member of VLANs 5 to 9.
A port can be allowed to become a member of statically created VLANs using the no form of the mvrp
static-vlan-restrict command. To allow port 1/2 to become a member of a statically created VLAN, enter
the command as shown:
-> no mvrp port 1/2 static-vlan-restrict vlan 5-9
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 12-11
Configuring MVRP
Configuring MVRP
Restricting VLAN Advertisement
VLANs learned by a switch through MVRP can either be propagated to other switches or be blocked. This
helps prune VLANs that have no members on a switch. If the applicant mode is set to participant or active,
you can use the mvrp restrict-vlan-advertisement command to restrict the propagation of VLAN
information on a specified port as shown:
-> mvrp port 1/1 restrict-vlan-advertisement vlan 5
Here, VLAN 5 is not allowed to propagate on port 1 of slot 1.
To enable the propagation of dynamic VLANs on the specified port, use the no form of the command. To
restrict VLAN 5 from being propagated to port 1/1, enter the command as shown:
-> no mvrp port 1/1 restrict-vlan-advertisement vlan 5
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 12-12
Configuring MVRP
Verifying the MVRP Configuration
Verifying the MVRP Configuration
A summary of the commands used for verifying the MVRP configuration is given here:
show mvrp last-pdu-origin
Displays the source MAC address of the last MVRP message
received on specific ports or aggregates.
show mvrp configuration
Displays the global configuration for MVRP.
show mvrp linkagg
Displays the MVRP configuration for a specific port or an aggregate
of ports.
show mvrp port
Displays the MVRP configurations for all the ports, including timer
values, registration and applicant modes.
show mvrp vlan-restrictions
Displays the list of VLANS learned through MVRP and their details.
show mvrp timer
Displays the timer values configured for all the ports or a specific
port.
show mvrp statistics
Displays the MVRP statistics for all the ports, aggregates, or specific
ports.
clear mvrp statistics
Clears MVRP statistics for all the ports, an aggregate of ports, or a
specific port.
For more information about the output details that result from these commands, see the OmniSwitch AOS
Release 8 CLI Reference Guide.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 12-13
13
Configuring 802.1AB
Link Layer Discovery Protocol (LLDP) is an emerging standard that provides a solution for the
configuration issues caused by expanding networks. LLDP supports the network management software
used for complete network management. LLDP is implemented as per the IEEE 802.1AB standard. LLDP
specifically defines a standard method for Ethernet network devices and Media Endpoint Devices (MED)
to exchange information with its neighboring devices and maintain a database of the information. The
exchanged information, passed as LLDPDU, is in TLV (Type, Length, Value) format. The information
available to the network management software must be as new as possible; hence, remote device
information is periodically updated.
In This Chapter
This chapter describes the basic components of 802.1AB and how to configure them through the
Command Line Interface (CLI). The CLI commands are used in the configuration examples; for more
details about the syntax of commands, see Chapter 16, “802.1AB Commands,” in the OmniSwitch AOS
Release 8 CLI Reference Guide.
Configuration procedures described in this chapter include the following:
• “Quick Steps for Configuring 802.1AB” on page 13-3
• “802.1AB Overview” on page 13-4.
• “Configuring LLDPDU Flow” on page 13-8.
• “Enabling and Disabling Notification” on page 13-8.
• “Enabling and Disabling Management TLV” on page 13-9.
• “Enabling and Disabling 802.1 TLV” on page 13-9.
• “Enabling and Disabling 802.3 TLV” on page 13-9.
• “Enabling and Disabling MED TLV” on page 13-10.
• “Enabling and Disabling Proprietary TLV” on page 13-10
• “Enabling and Disabling Application Priority TLV” on page 13-12.
• “Setting the Transmit Interval” on page 13-13.
• “Setting the Transmit Hold Multiplier Value” on page 13-13.
• “Setting the Reinit Delay” on page 13-13.
• “Setting the Notification Interval” on page 13-13.
• “Verifying 802.1AB Configuration” on page 13-15.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 13-1
Configuring 802.1AB
802.1AB Defaults Table
802.1AB Defaults Table
The following table shows the default settings of the configurable 802.1AB parameters.
Parameter Description
Command
Default Value/Comments
Transmit time interval for LLDPDUs lldp transmit interval
30 seconds
Transmit hold multiplier value
lldp transmit hold-multiplier
4
Reinit delay
lldp reinit delay
2 seconds
Notification interval
lldp notification interval
5 seconds
LLDPDUs transmission
lldp lldpdu
Transmission and Reception
Per port notification
lldp notification
Disable
Management TLV
lldp tlv management
Disable
802.1 TLV
lldp tlv dot1
Disable
802.3 TLV
lldp tlv dot3
Disable
LLDP Media Endpoint Device
lldp tlv med
Disable
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 13-2
Configuring 802.1AB
Quick Steps for Configuring 802.1AB
Quick Steps for Configuring 802.1AB
1 To enable the transmission and the reception of LLDPDUs on a port, use the lldp lldpdu command.
For example:
-> lldp port 2/47 lldpdu tx-and-rx
2 To control per port notification status about a change in a remote device associated to a port, use the
lldp notification command. For example:
-> lldp port 2/47 notification enable
3 To control per port management TLV to be incorporated in the LLDPDUs, use the lldp tlv
management command. For example:
-> lldp port 2/47 tlv management port-description enable
4 Set the transmit time interval for LLDPDUs. To set the timer for a 50 second delay, use the lldp
transmit interval command. For example:
-> lldp transmit interval 50
5 Set the LLDPDUs transmit fast start count required for LLDP Fast Restart mechanism to be activated.
Note. Optional. Verify the LLDP per port statistics by entering the show lldp statistics command. For
example:
-> show lldp statistics
LLDPDU
LLDPDU
LLDPDU
LLDPDU
LLDPDU
TLV
TLV
Device
Slot/Port
Tx
TxLenErr
Rx
Errors
Discards Unknown Discards
Ageouts
---------+---------+---------+---------+---------+---------+---------+---------+------1/1
453
0
452
0
0
0
0
0
1/2
452
0
453
0
0
0
0
0
1/5
452
0
473
0
0
476
476
0
1/8
455
0
464
0
0
0
0
0
1/9
456
0
464
0
0
0
0
0
To verify the remote system information, use the show lldp remote-system command. For example:
-> show lldp remote-system
Remote LLDP Agents on Local Slot/Port: 2/47,
Chassis ID Subtype
= 4 (MAC Address),
Chassis ID
= 00:d0:95:e9:c9:2e,
Port ID Subtype
= 7 (Locally assigned),
Port ID
= 2048,
Port Description
= (null),
System Name
= (null),
System Description
= (null),
Capabilites Supported
= none supported,
Capabilites Enabled
= none enabled,
For more information about this display, see the OmniSwitch AOS Release 8 CLI Reference Guide.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 13-3
Configuring 802.1AB
802.1AB Overview
802.1AB Overview
LLDP is a Layer 2 protocol used to detect adjacent devices in a network. Each device in a network sends
and receives LLDPDUs through all ports on which the protocol is enabled. If the protocol is disabled on a
port, then LLDPDUs received on that port are dropped.
The LLDPDUs are transmitted at a certain interval. This transmission interval can be configured. When an
LLDPDU is received from a neighboring device, the LLDPDU software validates the frame and stores the
information in the remote device Management Information Base (MIB). This information ages
periodically. If an LLDPDU is not received from the same device within the time specified in the TTL
TLV of the LLDPDU, the information is updated in the related MIB. By exchanging information with all
the neighbors, each device gets to know its neighbor on each port. The information contained in the
LLDPDU is transmitted in the TLV (Type, Length, Value) format and falls under two categories:
• Mandatory
• Optional
Each LLDPDU contains all the five mandatory TLVs and optional TLVs.
Mandatory TLVs
The mandatory TLV information contains the following information with regard to the LAN device:
• MSAP (MAC service access point) identifier.
• Time period for the validity of the information
The mandatory TLVs contained in an LLDPDU are listed below:
–
–
–
–
–
Chassis ID TLV
Port ID TLV
VLAN ID TLV
Time to live TLV
End of LLDPDU TLV
Optional TLVs
The optional TLVs defined as part of LLDP are grouped into the following sets listed below:
Basic Management TLV Set
• Port Description TLV
• System Name TLV
• System Description TLV
• System capabilities TLV
• Management address TLV
Note. This optional TLV set is required for all LLDP implementation.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 13-4
Configuring 802.1AB
802.1AB Overview
IEEE 802.1 Organizationally Specific TLV Set
• Port VLAN ID TLV
• Port and Protocol VLAN ID TLV
• VLAN name TLV
• Protocol identity TLV
Note. If one TLV from this set is included in the LLDPDU, then all the other TLVs need to be included.
IEEE 802.3 Organizationally Specific TLV Set
• MAC/PHY configuration/status TLV
• Power through MDI TLV (in network connectivity TLV set, Extended Power-through-MDI TLV is
supported)
• Link Aggregation TLV
• Maximum frame size TLV
ANSI-TIA LLDP-MED TLV Sets
• Network connectivity TLV set
• LLDP-MED capabilities TLV
• Inventory Management TLV
• Location Identification TLV
• Extended Power-through-MDI TLV
When an 802.1AB supporting system receives an LLDPDU containing MED capability TLV, then the
remote device is identified as an edge device , for example, IP phone and IP PBX, among others. In such a
case, the switch stops sending LLDPDU and starts sending MED LLDPDU on the port connected to the
edge device.
LLDP-Media Endpoint Devices
LLDP-MED is an extension to 802.1ab (Link Layer Discovery Protocol - LLDP), a link-layer protocol
that defines a method for network access devices using Ethernet connectivity to advertise device
information, device capabilities and media specific configuration information periodically to peer devices
attached to the same network.
The LLDP-MED feature facilitates the information sharing between Media Endpoint Devices and
Network Infrastructure Devices. It is designed to allow the following functionalities:
• Auto-discovery of LAN policies (such as VLAN, Layer 2 Priority and Diffserv settings) leading to
"plug and play" networking. This is achieved by advertising the VLAN information.
• Device location discovery to allow creation of location databases for VoIP, E911 services.
• Extended and automated power management of Power-over-Ethernet endpoints.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 13-5
Configuring 802.1AB
802.1AB Overview
• Inventory management, allowing network administrators to track their network devices, and determine
their characteristics (manufacturer, software and hardware versions, and serial / asset number).
• Support for receiving, storing and advertising of VLAN information from and to remote Network
Connectivity Devices and Media Endpoint Devices (MEDs).
• Support for receiving and storing of Inventory Management TLVs from remote Media Endpoint
Devices.
LLDP Agent Operation
A network device that implements LLDP, supports an LLDP agent. An LLDP agent operates in any one of
the following three modes:
Transmit-only mode: The agent can only transmit the information about the capabilities and the current
status of the local system at regular intervals.
Receive-only mode: The agent can only receive information about the capabilities and the current status
of the remote systems.
Transmit and receive mode: The agent can transmit the capabilities and status information of the local
system and receive the capabilities and the status information of the remote system.
LLDPDU Transmission and Reception
LLDP operates in a one-way direction, so that the information in the LLDPDUs flows from one device to
another. LLDPDUs are not exchanged as an information request by one device and a response sent by
another device. The other devices do not acknowledge LLDP information received from a device.
The transmission of LLDPDU is based on two factors:
• Transmit countdown timing counter. For example, whenever the counter expires, it goes through the
entire database of ports that have links and sends the LLDPDU when the current time has exceeded the
re-transmission time interval.
• If there is change in status of any of the ports. For example, a new port is attached or a new link has
come up.
Reception of LLDPDU is a two-phase process:
• LLDPDU and TLV error handling as per the 802.1AB standard
• LLDP remote system MIB update
Aging Time
The LLDP specific information of the remote system is stored in the LLDP MIB. The TTL TLV carries a
positive value in seconds, and conveys to the other device the duration for which this information is valid.
Once a remote device is learned on a local port, if the receiving device does not receive an LLDPDU from
the same remote device and on the same local port within the TTL mentioned in the previous LLDPDU,
then the local device discards the related entry from its database. This is called the aging time and can be
set by the user.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 13-6
Configuring 802.1AB
802.1AB Overview
LLDP Agent Security Mechanism
The OmniSwitch LLDP Agent Security mechanism provides a solution for secure access to the network
by detecting rogue devices and preventing them from accessing the internal network. LLDP agent security can be achieved by allowing only one trusted LLDP remote agent on a network port.
User is provided an option to configure the Chassis ID subtype that can be used in validating the Chassis
ID type in the incoming LLDP PDU. If the Chassis ID is not configured, by default, the first LLDP remote
agent is learnt with the received Chassis ID. When more than one LLDP agent is learned on a port, the
port is moved to a violation state.
For example, when someone tries to take control over the network by connecting non-registered devices to
an NNI port, the LLDP Security mechanism is activated. One or both of the following actions are
performed according to the security configuration:
• When the rogue device is detected, a violation is reported on the port.
• The NNI port that is connected to the rogue device is blocked. Thus the rogue device is prevented from
accessing the internal network.
LLDP security mechanism can be enabled or disabled globally at chassis level, at slot level, or at
individual port level. When the LLDP agent security is enabled, the configured ports are monitored for
reception of any LLDPDU. When an LLDPDU is received, the remote agent ID is learned and the port is
considered as a trusted port if the port does not have any other LLDP remote agent assigned. If the remote
agent chassis ID and port IDs received are already present in the trusted remote agent database on the
same port, then the port remains in a trusted state.
However, a port is moved to violation state under the following conditions:
• When a link up is received on a LLDP security enabled port, if no LLDPDU is received even after
three times the LLDP timer interval period (30 seconds), the port is moved to a violation state.
• If a trusted remote agent exists, and if no LLDP remote agent is learned even after three times the
LLDP timer interval period (30 seconds), the port is moved to a violation state.
• If a new LLDP remote agent is learned after the link up and down, then the port is moved to a
violation state.
• If the same chassis ID and port ID exist in the trusted remote agent database but on a different port,
then the port remote agent is learned and the port is moved to a violation state.
• If a new LLDP remote agent is learned on a port that has a trusted LLDP remote agent, then the port is
moved to a violation state.
Three actions can be configured when an LLDP security violation occurs. The different violation actions
that can be configured are:
• trap - Generate a trap
• shutdown - Shutdown the port
• trap-and-shutdown - A trap is generated upon shutdown of the port due to violation.
When a shutdown occurs on a port, it can be cleared manually through the CLI interface using the clear
violations command.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 13-7
Configuring 802.1AB
Configuring 802.1AB
Configuring 802.1AB
The following sections list detail procedures to enable 802.1AB and assign ports to 802.1AB.
Configuring LLDPDU Flow
The lldp lldpdu command can be used to enable or disable the LLDPDU flow on a specific port, a slot, or
all ports on a switch. When enabled, the port can be set to receive, transmit, or to transmit and receive
LLDPDUs.
To set the LLDPDU flow on a switch as transmit and receive, enter the lldp lldpdu command:
-> lldp chassis lldpdu tx-and-rx
To set the LLDPDU flow on port 4 of slot 3 as receive, enter the following command at the CLI prompt:
-> lldp 3/4 lldpdu rx
To disable the flow of LLDPDU on a switch, enter the lldp lldpdu command:
-> lldp chassis lldpdu disable
To disable the flow of LLDPDU on port 5 of slot 1, enter the following command at the CLI prompt:
-> lldp 1/5 lldpdu disable
Enabling and Disabling Notification
The lldp notification command is used to control per port notification status about the remote device
change on a specific port, a slot, or all ports on a switch. When enabled, the LLDPDU administrative
status must be in the receive state.
To enable notification of local system MIB changes on a switch, enter the lldp notification command:
-> lldp chassis notification enable
To enable notification on port 2 of slot 1, enter the following command at the CLI prompt:
-> lldp port 1/2 notification enable
To disable notification on a switch, enter the lldp notification command:
-> lldp chassis notification disable
To disable notification on port 4 of slot 1, enter the following command at the CLI prompt:
-> lldp port 1/4 notification disable
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 13-8
Configuring 802.1AB
Configuring 802.1AB
Enabling and Disabling Management TLV
The lldp tlv management command is used to control per port management TLVs transmission in the
LLDPDUs on a specific port, a slot, or all ports on a switch. When enabled, the LLDPDU administrative
status must be in the transmit state.
To enable the management TLV LLDPDU transmission on a switch, enter the lldp tlv management
command:
-> lldp chassis tlv management port-description enable
To enable the management TLV on port 3 of slot 2, enter the following command at the CLI prompt:
-> lldp port 2/3 tlv management system-capabilities enable
To disable the management TLV on a switch, enter the lldp tlv management command:
-> lldp chassis tlv management port-description disable
To disable management TLV on port 3 of slot 2, enter the following command at the CLI prompt:
-> lldp port 2/3 tlv management system-capabilities disable
Enabling and Disabling 802.1 TLV
The lldp tlv dot1 command is used to control per port 802.1 TLVs transmission in the LLDPDUs on a
specific port, a slot, or all ports on a switch. When enabled, the LLDPDU administrative status must be in
the transmit state.
To enable the 802.1 TLV LLDPDU transmission on a switch, enter the lldp tlv dot1 command:
-> lldp chassis tlv dot1 port-vlan enable
To enable the 802.1 TLV on port 1 of slot 5, enter the following command at the CLI prompt:
-> lldp port 5/1 tlv dot1 vlan-name enable
To disable the 802.1 TLV on a switch, enter the lldp tlv dot1 command:
-> lldp chassis tlv dot1 port-vlan disable
To disable 802.1 TLV on port 2 of slot 5, enter the following command at the CLI prompt:
-> lldp port 5/2 tlv dot1 vlan-name disable
Enabling and Disabling 802.3 TLV
The lldp tlv dot3 command is used to control per port 802.3 TLVs transmission in the LLDPDUs on a
specific port, a slot, or all ports on a switch. When enabled, the LLDPDU administrative status must be in
the transmit state.
To enable the 802.3 TLV LLDPDU transmission on a switch, enter the lldp tlv dot3 command, as shown:
-> lldp chassis tlv dot3 mac-phy enable
To enable the 802.3 TLV on port 4 of slot 2, enter the following command at the CLI prompt:
-> lldp port 2/4 tlv dot3 mac-phy enable
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 13-9
Configuring 802.1AB
Configuring 802.1AB
To disable the 802.3 TLV on a switch, enter the lldp tlv dot3 command, as shown:
-> lldp chassis tlv dot3 mac-phy disable
To disable 802.3 TLV on port 5 of slot 3, enter the following command at the CLI prompt:
-> lldp port 3/5 tlv dot3 mac-phy disable
Enabling and Disabling MED TLV
The lldp tlv med command is used to control per port LLDP Media End Device (MED) TLVs
transmission in the LLDPDUs on a specific port, a slot, or all ports on a switch. When enabled, the
LLDPDU administrative status must be in the transmit state.
To enable the LLDP-MED TLV LLDPDU transmission on a switch, enter the lldp tlv med command, as
shown:
-> lldp chassis tlv med power enable
To enable the MED TLV on port 4 of slot 4, enter the following command at the CLI prompt:
-> lldp port 4/4 tlv med capability enable
To disable the MED TLV on a switch, enter the lldp tlv med command, as shown:
-> lldp chassis tlv med power disable
To disable MED TLV on port 3 of slot 4, enter the following command at the CLI prompt:
-> lldp port 4/3 tlv med capability disable
Enabling and Disabling Proprietary TLV
The OmniSwitch advertise the Access Point location information to the OmniAccess Stellar APs
connected to it through the Proprietary TLVs. The proprietary TLVs are transmitted along with the LLDP
BPDU. After LLDP is configured on the network devices, the NMS can obtain the network topology.
The WLAN management VLAN is transmitted to OmniAccess Stellar AP through LLDP using existing
Port VLAN TLV, even if the TLV is disabled by LLDP module.
The Proprietary TLV must be enabled to advertise the OmniAccess Stellar AP location. The lldp tlv
proprietary command is used to enable the Proprietary TLV.
Note. The OmniAccess Stellar AP should always be connected to the UNP Port.
To enable the Proprietary TLV transmission on a switch, enter the lldp tlv proprietary command, as
shown:
-> lldp chassis tlv proprietary enable
To enable the Proprietary TLV on port, for example port 4 of slot 4, enter the following command at the
CLI prompt:
-> lldp port 1/4/4 tlv proprietary enable
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 13-10
Configuring 802.1AB
Configuring 802.1AB
To disable the Proprietary TLV on a switch, enter the ldp tlv proprietary command, as shown:
-> lldp chassis tlv proprietary disable
To disable Proprietary TLV on port, for example port 3 of slot 4, enter the following command at the CLI
prompt:
-> lldp port 1/4/4 tlv proprietary disable
To view the operational status of Proprietary TLV on a switch, use the show lldp config command.
To view the AP location, use the show lldp local-port command.
-> show lldp local-port
Local Slot 1/Port 1 LLDP Info:
Port ID
=
Port Description
=
Vlan
=
AP Location
=
Local Slot 1/Port 2 LLDP Info:
Port ID
=
Port Description
=
Vlan
=
AP Location
=
1001 (Locally assigned),
Alcatel-Lucent 1/1,
1,
sw1,
1002 (Locally assigned),
Alcatel-Lucent 1/2,
1,
-,
The AP location and VLAN information can also be viewed from WebView. To view the information,
from the WebView page:
1 Click on the Physical tab.
2 Click on Adjacencies. Adjacencies home page is displayed.
3 In the Adjacencies home page, select LLDP.
4 Click on Local and select AP Management TLV from the displayed option. This will display the AP
Management TLV information such as Slot, Port, VLAN, and AP Location. A sample screen is displayed
as follows:
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 13-11
Configuring 802.1AB
Configuring 802.1AB
Note. For more information about WebView, see the OmniSwitch AOS Release 8 Switch Management
Guide.
Enabling and Disabling Application Priority TLV
The lldp tlv application command is used to include the LLDP-DCBx Application Priority TLV in the
LLDPDUs transmitted on a specific port, a slot, or all ports on a switch. When enabled, the LLDPDU
administrative status must be in the transmit state.
To enable the Application Priority TLV LLDPDU transmission on a switch, enter the lldp tlv application
command, as shown:
-> lldp chassis tlv application enable
To enable the Application Priority TLV on port 4 of slot 4, enter the following command at the CLI
prompt:
-> lldp port 4/4 tlv application enable
To disable the Application Priority TLV on a switch, enter the lldp tlv application command, as shown:
-> lldp chassis tlv application disable
To disable the Application Priority TLV on port 3 of slot 4, enter the following command at the CLI
prompt:
-> lldp port 4/3 tlv application disable
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 13-12
Configuring 802.1AB
Configuring 802.1AB
Configuring Application Priority TLV Parameters
The lldp tlv application priority command is used to configure the the LLDP-DCBx Application Priority
TLV to advertise an 802.1p priority value for specific protocols on a specific port, a slot, or all ports on a
switch. The LLDPDU administrative status must be enabled and set to transmit and receive before using
this command. In addition, the Application Priority TLV must be enabled for transmission in the
LLDPDU.
To configure Application Priority TLV parameters, enter the lldp tlv application command, as shown:
-> lldp port 1/1/3 tlv application fcoe priority 3
-> lldp port 1/1/3 tlv application tcp-sctp-port 3192 priority 5
To remove Application Priority TLV parameters, use the no form of the lldp tlv application command, as
shown:
-> lldp chassis tlv application no fcoe
-> lldp chassis tlv application no tcp-sctp-port
Setting the Transmit Interval
To set the transmit time interval for LLDPDUs, enter the lldp transmit interval command. For example,
to set the transmit time interval as 40 seconds, enter:
-> lldp transmit interval 40
Setting the Transmit Hold Multiplier Value
To set the transmit hold multiplier value, enter the lldp transmit hold-multiplier command. For example,
to set the transmit hold multiplier value to 2, enter:
-> lldp transmit hold-multiplier 2
Note. The Time To Live is a multiple of the transmit interval and transmit hold-multiplier.
Setting the Reinit Delay
To set the time interval that must elapse before the current status of a port is reinitialized after a status
change, enter the lldp reinit delay command. For example, to set the reinit delay to 7 seconds, enter:
-> lldp reinit delay 7
Setting the Notification Interval
To set the time interval that must elapse before a notification about the local system Management
Information Base (MIB) change is generated, enter the lldp notification interval command. For example,
to set the notification value to 130 seconds, enter:
-> lldp notification interval 130
Note. In a specified interval, generating more than one notification-event is not possible.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 13-13
Configuring 802.1AB
Configuring 802.1AB
Application Example - LLDP MED
The following example describes how to configure LLDP MED on the devices.
Application Example - LLDP MED
In the above example, the NMS obtains Layer 2 information about Core Switch, SwitchA, SwitchB, and
AP. By using the Layer 2 information, a network administrator can know the detailed network topology
information and configuration conflicts. These requirements can be met by configuring LLDP on
SwitchA and SwitchB. In addition, the administrator requires that SwitchA and SwitchB send LLDP traps
to the NMS, when the LLDP management address changes, global LLDP is enabled or disabled.
For more information on the configuration procedure, see “Configuring 802.1AB” on page 13-8
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 13-14
Configuring 802.1AB
Verifying 802.1AB Configuration
Verifying 802.1AB Configuration
To display information about the ports configured to handle 802.1AB, use the following show command:
show lldp system-statistics
Displays system-wide statistics.
show lldp statistics
Displays port statistics.
show lldp local-system
Displays local system information.
show lldp local-port
Displays port information.
show lldp local-management-address
Displays the local management address information.
show lldp config
Displays the general LLDP configuration information for
LLDP ports.
show lldp remote-system
Displays local port information of remote system.
show lldp remote-system med
Displays MED local port information of remote system.
show lldp remote-system application-tlv Displays Application Priority TLV information of the
remote system.
For more information about the resulting display, see Chapter 16, “802.1AB Commands,” in the
OmniSwitch AOS Release 8 CLI Reference Guide.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 13-15
14 Configuring SIP Snooping
Session Initiation Protocol (SIP) address the key challenge of real time delivery and monitoring
requirements for media streams from SIP devices.
SIP Snooping prioritizes voice and video traffic over non-voice traffic.
• Identifies and marks the SIP and its corresponding media streams. Each media stream contains Real
Time Protocol (RTP) and Real Time Control Protocol (RTCP) flows. Marking is done using the DSCP
field in the IP header.
• Provides user configured QOS treatment for SIP/RTP/RTCP traffic flows based on its marking.
• Also snoops voice quality metrics of media streams from their RTCP packets and displays them to the
user with knowledge of media reception quality in real time and helps to diagnose the problems on
their quality. Also in addition, trap will be generated when voice quality parameters like Jitter, Round
trip time, Packet-lost, R-factor and MOS values of media streams crosses user configured threshold.
In This Chapter
This chapter describes the SIP Snooping feature, and how to configure it through the Command Line Interface (CLI). For more details about the syntax of commands, see the OmniSwitch AOS Release 8 CLI Reference Guide.
The following information and procedures are included in this chapter:
• “Quick Steps for Configuring SIP Snooping” on page 14-4.
• “SIP Snooping Overview” on page 14-5
• “SIP Snooping Configuration Guidelines” on page 14-8
• “SIP Snooping Limitations” on page 14-15
• “Verifying the SIP Snooping Configuration” on page 14-16.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 14-1
Configuring SIP Snooping
SIP Snooping Defaults
SIP Snooping Defaults
The following table shows SIP Snooping default values.
Parameter Description
Command
Default Value/Comments
The administrative status of SIP
Snooping
sip-snooping admin-state
disable
Configure the status of SIP snooping sip-snooping port admin-state
disable
SIP Snooping mode
sip-snooping mode
automatic
Configure IP address of the trusted
servers
sip-snooping trusted server
none
Configure SIP PDU DSCP marking
configuration.
sip-snooping sip-control
By default, DSCP is not
marked on the switch.
Configure the SOS call strings
sip-snooping sos-call number
none
Configure the SOS-Call RTP/RTCP sip-snooping sos-call dscp
DSCP Marking
EF/46
Configure the UDP port of the
switch
none
sip-snooping udp port
Configure the TCP port of the switch sip-snooping tcp port
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
port 5260
page 14-2
Configuring SIP Snooping
Parameter Description and Values
Parameter Description and Values
No
PARAMETER Description
Default value
Configurable Min
Max
1
Global SIP snooping
Disable
YES
NA
NA
2
SIP snooping per port
Enable
YES
NA
NA
3
SIP Snooping mode
Automatic
YES
NA
NA
4
Number of SIP UDP Ports
NO
YES
0
8
5
Number of SIP TCP Ports
5260
YES
0
8
6
Number of Trusted Call server
NO
YES
7
Number of SOS-Call
NO
YES
0
4
8
SOS-Call RTP/RTCP Bandwidth
128 kbps
NO
NA
NA
9
SOS-Call RTP/RTCP-DSCP
46 EF
YES
NA
NA
10
SIP control DSCP
NO
YES
NA
NA
11
SIP rate limit
1 mbps
NO
1
4
12
Media Idle timeout
5 min
NO
NA
NA
13
RTCP monitoring
Enable
YES
NA
NA
14
Jitter Threshold (audio/video/other)
50/100/100 ms
YES
0
300
15
Packet-lost Threshold (audio/video/other)
10 /20/20 %
YES
0
99
16
RTT Threshold (audio/video/other)
180 /250/250
ms
YES
0
500
17
R-factor Threshold (audio/video/other)
70/80/80
YES
0
100
18
MOS Threshold (audio/video/other)
3.6/3.0/3.0
YES
0
5
19
TCAM slice reserved
1
NO
1
4
a
8
20
Number of Media streams per NI
(64*TCAM
NO
Slice value) – 4
NA
NA
21
Number of Media streams per system in case MAXNI_SLOT NO
of stack. (VC with MAX_NI_SLOTS = 8)
S*
((64 * TCAM
Slice Value) –
4)
NA
NA
22
Number of Media streams per system in case (64 * TCAM
link aggregation as edge port.
Slice value) - 4
NO
NA
NA
23
Logging Number of calls
YES
50
500
200
a. Subtracted value of 4 is due to the 15 UDF entries required for SIP method based trapping.
Note. When the Jitter, Packet Lost, and RTT crosses the configured threshold traps are raised. And when
the R-factor and MOS goes below the configured threshold traps are raised.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 14-3
Configuring SIP Snooping
Quick Steps for Configuring SIP Snooping
Quick Steps for Configuring SIP Snooping
The following steps provide a quick tutorial on how to configure SIP Snooping. Each step describes a
specific operation and provides the CLI command syntax for performing that operation.
1 Create a global SIP policy to classify incoming flows. Use the policy condition command to create a
QOS condition. For example,
-> policy condition Voice sip audio
-> policy condition Video sip video
2 Create a policy action for the SIP condition using the policy action command. For example,
-> policy action DSCP46 dscp 46
-> policy action DSCP32 dscp 32
3 Configure the policy rule for the SIP policy to classify inbound and outbound media streams. Use the
policy rule command. For example,
-> policy rule Voice_46 condition Voice action DSCP46
-> policy rule Video_32 condition Video action DSCP32
-> qos apply
Note. For more information on policy condition, policy action, and policy rule, see “Configuring QOS”
chapter in the OmniSwitch AOS Release 8 Network Configuration Guide.
4 Enable SIP Snooping using the sip-snooping admin-state command. For example:
-> sip-snooping admin-state enable
This command will enable SIP snooping globally.
Note. When SIP snooping is enabled globally the SIP snooping is enabled on all ports and linkagg. The
user can disable SIP snooping on specific port or linkagg (see Step 5).
5 Configure port/linkagg level SIP Snooping for the switch. Use the sip-snooping admin-state
command with the port or linkagg parameter. For example,
-> sip-snooping port 1/1/5-6 admin-state enable
-> sip-snooping linkagg 1/1/10 admin-state enable
6 Configure the port/linkagg mode to force-edge for the port to which the SIP phone is connected. Use
the sip-snooping mode command. For example,
-> sip-snooping port 1/1/5-6 mode force-edge
-> sip-snooping linkagg 1/1/10 mode force-edge
7 Configure the port/linkagg mode to force-non-edge for uplink port connecting to the call server. Use
the sip-snooping mode command. For example,
-> sip-snooping port 1/5-6 mode force-non-edge
-> sip-snooping linkagg 1/1/10 mode force-non-edge
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 14-4
Configuring SIP Snooping
SIP Snooping Overview
SIP Snooping Overview
The Session Initiation Protocol (SIP) is an IETF-defined signaling protocol widely used for controlling
communication sessions such as voice and video calls over Internet Protocol (IP). The protocol can be
used for creating, modifying and terminating media sessions. Sessions may consist of one or several media
streams.
Other SIP applications include video conferencing, streaming multimedia distribution, instant messaging,
presence information, file transfer and online games.
The SIP protocol is an Application Layer protocol designed to be independent of the underlying Transport
Layer. SIP can run on the Transmission Control Protocol (TCP), User Datagram Protocol (UDP), or
Stream Control Transmission Protocol (SCTP). It is a text-based protocol, incorporating many elements of
the Hypertext Transfer Protocol (HTTP) and the Simple Mail Transfer Protocol (SMTP).
The SIP Snooping feature is provided to address the key challenge of real time delivery and monitoring
requirements for media streams from SIP devices. The feature allows automatic detection of SIP and its
corresponding media streams.
The network is the most critical part of the enterprise infrastructure in delivering diverse applications.
Ever increasing applications and their need for network resources keep demand on networks high.
• Critical applications like real-time voice, video, and mission critical data applications continue to grow.
• Bandwidth needs are growing at a faster pace than the network technologies that need to address them.
• Elastic traffic, such as TCP-based non-real time traffic, tends to use any additional bandwidth
available.
It is essential to differentiate the various types of traffic, based on application, user, and context, and
provide applicable service levels for each.
• Voice and video traffic should be prioritized over non-voice traffic.
• Mission critical data traffic should be provided a bandwidth guarantee for better performance.
The network should be able to monitor the quality of this traffic and inform the user if it is not within the
required expectation. SIP Snooping addresses this issue for media streams managed by SIP.
The SIP snooping feature snoops voice quality metrics of media streams from their corresponding control
packets and displays them to the user with knowledge of media reception quality in real time and helps to
diagnose the problems on their quality. In addition, a trap is generated when the voice quality parameters
crosses a user configured threshold.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 14-5
Configuring SIP Snooping
Using SIP Snooping
Using SIP Snooping
A SIP network consists of the following network elements:
• Edge switches, aggregation switches, and core switches
• SIP user agents (e.g., SIP phones). SIP user agents are directly connected to edge switches
One SIP Server is connected to the Core switch within the campus infrastructure The server is responsible
for all the SIP functions such as registrar, proxy, redirect, gateway.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 14-6
Configuring SIP Snooping
Using SIP Snooping
In the above network, SIP-snooping is enabled on the edge switches.
• For an internal call, QOS treatment is enforced on both edge switches on which the SIP user agent
endpoints are connected. On each edge switch, the QOS treatment is enforced for both ingress and
egress media streams.
• For an external call, QOS treatment is only enforced on the edge switch on which the internal SIP user
agent endpoint is connected. The media streams traversing the aggregation and core switches will not
be subject to the SIP QOS treatment. On the edge switch, the QOS treatment is enforced for both
ingress and egress media streams.
Interoperability
SIP Snooping can interact with the following equipment:
No Equipment
Description
1
OpenTouch Business Edition 1.1 Server
500 Users (OTBE)
SIP based server from Alcatel-Lucent
Enterprise
2
OXE IP Media Gateway MR3
Part of OTBE
3
PCX Enterprise RM3
Part of OTBE
4
Open Touch soft-phone - My Instant Communicator Part of OTBE
5
8082 My IC Phone
OpenTouch SIP Phone
6
LifeSize Passport(Model: LFZ014)
SIP endpoint
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 14-7
Configuring SIP Snooping
SIP Snooping Configuration Guidelines
SIP Snooping Configuration Guidelines
This section describes how to use OmniSwitch Command Line Interface (CLI) commands to configure
SIP Snooping on a switch. Consider the following guidelines when configuring SIP Snooping entities:
Configuring Edge Port
SIP snooping requires that the uplink ports are configured as non-edge port. An edge port is a port on
which the SIP user agent is connected. A non-edge port is the uplink port on which no SIP user agent is
connected but requires SIP snooping. All AOS features available for an edge port are supported with SIP
snooping.
By default, the edge and non-edge port modes are implicitly based on LLDP.
• A port that learns a LLDP remote agent advertising the “switch/router” capability is considered a non-
edge port.
• A port that does not learn a LLDP remote agent advertising the “switch/router” capability is considered
an edge port. A port can be forced to the edge or non-edge mode.
To configure the force-edge/force-non-edge, use the command as follows.
-> sip-snooping port 1/1/5-6 mode force-edge
-> sip-snooping port 1/1/10 mode force-non-edge
On the edge switch, it is recommended to disable auto phone with the qos no phones command. For
example
-> qos no phones
Set all edge ports, including network edge ports to the un-trusted mode. Also ensure uplink port and all the
traversing ports to other SIP endpoint are in trust mode.
Configuring Trusted SIP Server
By default, any SIP server is trusted. The SIP messages are trusted regardless of the origin (e.g., source IP
address) or destination (e.g., destination IP address) of the SIP message.
The SIP snooping feature allows the configuration of trusted SIP servers. This restricts the SIP snooping
functions to only a list of trusted server IP address.
Up to 8 trusted addresses can be configured as trusted SIP server. For configuring the trusted SIP server,
use the command
-> sip-snooping trusted-server 192.168.0.1
All SIP based calls using other than configured trusted call server will not be subject to the configured SIP
QOS treatment
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 14-8
Configuring SIP Snooping
SIP Snooping Configuration Guidelines
Configuring SIP Snooping TCP Ports
The SIP snooping feature allows the configuration of TCP ports. This allows the SIP snooping functions
to a list of TCP ports, SIP packets sent/received on the TCP ports will be snooped. A maximum of 8 TCP
ports can be configured on a switch.
To configure the Server listening TCP ports, use the sip-snooping TCP port as follows
-> sip-snooping tcp-port 5678 5051
The SIP Snooping TCP port configuration is used to snoop the SIP packets, when the SIP endpoints
switches from UDP to TCP to send SIP packets of more than 1300 bytes in size.
Configuring SIP Snooping UDP Ports
The SIP snooping feature allows the configuration of UDP ports. This allows the SIP snooping functions
to a list of UDP ports, SIP packets sent/received on the UDP ports will be snooped. A maximum of 8 UDP
ports can be configured on a switch.
To configure the Server listening UDP port, use the sip-snooping UDP port as follows
-> sip-snooping udp-port 5260 5060
This allows the SIP snooping functionality for the configured UDP ports only.
Configuring the SIP Control DSCP
To configure SIP control DSCP marking, use the sip-snooping sip-control command
-> sip-snooping sip-control dscp 40
This marks the SIP messages with the configured SIP control DSCP.
Configuring SOS Calls
The SIP snooping features allow the detection of emergency calls based on the “to” URI in the INVITE
message. Configuration allows up to 4 SOS call strings to be configured. The string must be the exact URI
to be matched in the ‘to” URI.
When a call is deemed to be a SOS call, a default DSCP of 46 (EF) is assigned for both RTP and RTCP
flows of that call. SOS-Call DSCP can be configured to any value.A non-configurable rate limiter of
128kbps is imposed for SOS-Call.
-> sip-snooping sos-call number “911” “2233”
By default, no SOS number is configured for SIP Snooping
Configuring SOS Call DSCP
To configure the SOS-Call RTP/RTCP DSCP Marking, use the sip-snooping sos-call command.
-> sip-snooping sos-call dscp 56
This marks the SOS-Call RTP/RTCP packets with the configured SOS call dscp.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 14-9
Configuring SIP Snooping
SIP Snooping Configuration Guidelines
Configuring RTCP Thresholds
When RTCP monitoring is enabled, the SIP snooping feature also inspects the RTCP packet that carries
performance metric for the RTP flow.
Depending on the RTCP capabilities of the SIP user agent endpoints, the following metrics can be
determined by software:
• Packet loss
• Round Trip Time
• R Factor Only supported with RTCP-XR
• MOS factor – Only supported with RTCP-XR
The SIP snooping feature offers configurable thresholds for each performance metric and each media
types.
->
->
->
->
->
->
->
->
->
->
sip-snooping
sip-snooping
sip-snooping
sip-snooping
sip-snooping
sip-snooping
sip-snooping
sip-snooping
sip-snooping
sip-snooping
threshold
threshold
threshold
threshold
threshold
threshold
threshold
threshold
threshold
threshold
audio
video
audio
video
audio
video
audio
video
audio
video
jitter 30
jitter 50
packet-lost 40
packet-lost 30
round-trip-delay 180
round-trip-delay 180
R-factor 30
R-factor 30
MOS 1
MOS 2
Configuring the Logging Threshold for the Number of Calls
To configure the threshold for the number of call records to be logged on to the flash file, use the sipsnooping logging-threshold num-of-calls command as follows
-> sip-snooping logging-threshold num-of-calls 300
Configuring Policy Rules for SIP Snooping
Unlike regular policy rule, a SIP policy rule is not programmed in the hardware when it is configured. The
ACL is only programmed when the SIP snooping module detects a new RTP flow and parses the SIP
policy rules to determine the QOS policy actions required for this RTP flow.
Policy Condition
All other policy conditions are still supported for the SIP policy rules. This allows specific QOS
treatments (policy actions) for media streams based on the origin of the call. For instance, a SIP policy
condition can be combined with:
• Source port
• Source IP address/subnet
To configure the policy condition, use the commands as follows.
-> policy condition <condition_name> sip {audio | video | other}
-> policy condition <condition_name> sip {audio | video | other}source port 1/2
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 14-10
Configuring SIP Snooping
SIP Snooping Configuration Guidelines
Other source conditions are also supported but are not foreseen to provide real benefits.
The policy condition is not used as such in the hardware filtering entry, but is used by the SIP snooping
module to determine the policy rule that the new RTP flow is matching. Also, SIP policy rules are
supported in ingress and UNP policy lists.
Policy Action
All other policy actions are still supported for SIP policy rules. For instance:
• DSCP—marks the DSCP value for the RTP/RTCP packets and maps the internal priority to this DSCP
• Priority—forces the internal priority of the RTP/RTCP packets.
• Rate Limiter
To configure the policy action, use the commands as follows.
-> policy action <action_name> dscp 32 rtcp-monitoring {enable | disable}
-> policy action <action_name> dscp 46 rtcp-monitoring enable rtcp-dscp <num>
-> policy action <action_name> rtcp-monitoring disable trust-dscp
Policy Rule
A SIP policy rule is a rule that has the keyword SIP (audio/video/other) in the policy condition and a
corresponding policy action.
The SIP policy rule is configured as follows.
-> policy condition Voice_srcip_SIP1
audio
-> policy condition Video_srcip_SIP1
video
-> policy action DSCP56 dscp 56
-> policy action DSCP32 dscp 32
-> policy rule Voice_srcip_SIP1_rule
-> policy rule Video_srcip_SIP1_rule
-> qos apply
source ip 10.10.0.0 mask 255.255.0.0 sip
source ip 10.10.0.0 mask 255.255.0.0 sip
condition Voice_srcip_SIP1 action DSCP56
condition Video_srcip_SIP1 action DSCP32
Note that a SIP policy rule does not apply for the SIP signaling messages. A SIP policy rule can however
apply for a SOS call since a SOS call is a audio media. However, the DSCP marking and rate limiter for
an SOS call cannot be overwritten by a SIP policy rule.
Unsupported Topologies
The SIP snooping functions and the QOS actions require that the network paths used by the SIP signaling
messages and the RTP/RTCP flows are the same and are “symmetric”. For this reason, the following
topologies are not supported:
• ECMP Routing
• VRRP
In such topologies, it would be possible that one switch/router sees the SIP signaling messages and creates
the dialog with the appropriate QOS actions (i.e. ACLs), but the RTP/RTCP traffic will not be seen by this
switch/router. It would also be possible that the SIP signaling messages and/or RTP/RTCP packets are
load balanced between 2 switch/routers.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 14-11
Configuring SIP Snooping
SIP Snooping Use Case
SIP Snooping Use Case
In this section, advanced SIP configuration use cases are illustrated. Instead of having all voice audio/
video media streams treated the same way, more granular SIP policies can be configured.
Expectations
• Voice media streams from SIP1 to SIP2 will be marked with DSCP 56
• Video media streams from Video SIP1 to Video SIP2 will be marked with DSCP 32
• Voice media streams from SIP2 to SIP1 will be marked with DSCP 46
• Voice media streams from Video SIP2 to Video SIP1 will be marked with DSCP 48
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 14-12
Configuring SIP Snooping
SIP Snooping Use Case
SIP Condition
In this example, specific QOS treatments are configured based on the source IP subnet.
• Voice source IP subnet 10.10.0.0 = DSCP 56
• Video source IP subnet 10.10.0.0=DSCP 32
• Voice source IP subnet 10.20.0.0 = DSCP 46
• Video source IP subnet 10.20.0.0=DSCP 48
The SIP conditions is configured as follows:
-> policy condition Voice_srcip_SIP1
audio
-> policy condition Video_srcip_SIP1
video
-> policy condition Voice_srcip_SIP2
audio
-> policy condition Video_srcip_SIP2
video
-> policy action DSCP56 dscp 56
-> policy action DSCP32 dscp 32
-> policy action DSCP46 dscp 46
-> policy action DSCP48 dscp 48
-> policy rule Voice_srcip_SIP1_rule
-> policy rule Video_srcip_SIP1_rule
-> policy rule Voice_srcip_SIP2_rule
-> policy rule Video_srcip_SIP2_rule
-> qos apply
source ip 10.10.0.0 mask 255.255.0.0 sip
source ip 10.10.0.0 mask 255.255.0.0 sip
source ip 10.20.0.0 mask 255.255.0.0 sip
source ip 10.20.0.0 mask 255.255.0.0 sip
condition
condition
condition
condition
Voice_srcip_SIP1
Video_srcip_SIP1
Voice_srcip_SIP2
Video_srcip_SIP2
action
action
action
action
DSCP56
DSCP32
DSCP46
DSCP48
The active call records can be viewed by using the following command:
-> show sip-snooping call-records active-calls full
Legend: start date time duration media-type end-reason
call-id / from-tag / to-tag
IP address port DSCP (forward/reverse)
policy-rule (F/R)
statistics min / max / avg %samples exceeding threshold (F/R)
-------------------------------------------------------------------------------2013-11-21 18:39:17(PST) 0d 16h 13m 41s Audio
6dddf3236f2d564c / d1fc26f8da / 0061D0A0-7C50-1200-83AF-F1A3FE87AA77-1439499
IP/DSCP
5.5.5.2 6000 NA/NA
7.7.7.2 6000 NA/NA
Policy-Rule
r6
r1
Pkt-Count
2920807 2920807
Pkt-Loss
0
0
0.00
0%
0
0
0.00
0%
Jitter
1
198714
17.34
0%
1
49
0.32
0%
Delay
9
29
16.44
0%
9
29
16.44
0%
R-factor
35
96
35.42
99%
30
96
32.00
99%
MOS
1.00
4.00
1.80
99%
1.00
4.00 1.60
99%
----------------------------------------------------------------------------------Number of Call Records: 1
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 14-13
Configuring SIP Snooping
SIP Snooping Use Case
-> show sip-snooping call-records ended-calls full
Legend: start date time duration media-type end-reason
call-id / from-tag / to-tag
IP address port DSCP (forward/reverse)
policy-rule (F/R)
Pkt count (F/R)
statistics min / max / avg %samples exceeding threshold (F/R)
-------------------------------------------------------------------------------2002-04-06 01:06:10 UTC 0d 0h 4m 15s
Audio
0010CFC0-4A05-10DA-B960-F1A3FE87AA77-23025@ot380.aos.com / 0010CFE8-4A05-10DA-B960F1A3FE87AA77-258649 / 1668946822
IP/DSCP
10.20.0.2 6000 56/56
10.10.0.2 6000 46/46
Policy-Rule
Voice_srcip_SIP1_rule
Voice_srcip_SIP2_rule
Pkt-Count
12272
61385
Pkt-Loss
0
0
0.00
0% 0
0
0.00
0%
Jitter
0
0
0.00
0% 0
0
0.00
0%
Delay
0
0
0.00
0% 0
0
0.00
0%
R-factor
0
0
0.00
0% 96
96
96.00
0%
MOS
0
0
0.00
0% 44
44
44.00
----------------------------------------------------------------------------------Number of Call Records: 1
Similar to the above example, more conditions can be combined in a single SIP rule.
Advanced RTCP Control
For each RTP flow, RTCP monitoring can be enabled or disabled. When enabled, the DSCP marking can
also be controlled. Also Trap will be generated if RTCP parameters exceed the Threshold values
configured in SIP configuration.
In this example, specific QOS treatments are configured based on the Source IP subnet.
• Voice source IP subnet 10.10.0.0 = DSCP 56— RTCP packets for these RTP flows are trapped to CPU
and assigned with DSCP 56.
-> policy action DSCP56 dscp 56
• Video source IP subnet 10.10.0.0= RTCP—packets for these RTP flows are trapped to CPU and have
their DSCP unchanged.
-> policy action DSCP32 rtcp-monitoring enable trust-DSCP
• Voice source IP subnet 10.20.0.0 = DSCP 46 + No RTCP monitoring—RTCP packets for these RTP
flows are not trapped to CPU and assigned with DSCP 46.
-> policy action DSCP46 dscp 46 rtcp-monitoring disable
• Video source IP subnet 10.20.0.0 = DSCP 48 + RTCP monitoring and explicit DSCP 46—RTCP
packets for these RTP flows are trapped to CPU and assigned with DSCP 46.
-> policy action DSCP48 dscp 48 rtcp-monitoring enable rtcp-dscp 46
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 14-14
Configuring SIP Snooping
SIP Snooping Limitations
SIP Snooping Limitations
• Media types other than audio and video as application, image media types etc. are not supported.
• Solution only supports SIP, no support of NOE (New Office Environment).
• SIP Registrar, outbound proxy, proxy, redirect functions should be provided by the same server called
the SIP Server.
• All initial SIP messages between User Agents must go through the SIP Server. Direct SIP session
establishment between end users will be not supported.
• Outbound proxy configured on phone and trusted call server configured on switch must be the same.
• Only SIP over UDP and SIP over UDP/TCP is supported. Solution does not support SIP over SCTP or
MPLS and SIP over TLS.
• Encrypted RTCP or SDP is not supported.
• Only SIP over IPv4 is supported, no support for IPV6.
• Multicast Media Sessions by SIP is not supported
• Only RTP or RTP profile AVP is supported to carry media. SAVP, AVPF, SAVPF are not supported.
• Only IP address is supported. DNS resolution and FQDN name are not supported in SDP
• Only audio and video application in "m" line of SDP is supported.
• No network performance reporting other than RTCP reports.
• RTCP port assignment is taken as one higher than corresponding RTP. Other methods for RTCP port
assignment is not supported
• Media quality metrics displayed to the user only convey the presence of problem in voice and video
transmission quality. Exact location and device responsible for it will not be known and it is expected
that the user will find it by other means and take corrective action.
• QOS SIP policy modifications should be applied for the new calls only and not for existing ones.
• DSCP marking will be done for only [(64 * TCAM Slice Value)-4] SIP audio calls, if a call is through
linkagg on a stack.
• No VRF awareness. Similarly, NAT transversal (ICE, TURN, STUN solution) is not supported.
• Emergency call identification is based on user configured string. Usage of priority or resource-priority
header is not considered.
• SIP IP address and RTP IP address of end point at edge port must be same, otherwise TCAM entries
will not be created.
• Media that flows before TCAM entries are installed does not get configured QOS treatment.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 14-15
Configuring SIP Snooping
Verifying the SIP Snooping Configuration
Verifying the SIP Snooping Configuration
To display information about Sip Snooping on the switch, use the show commands listed below:
show sip-snooping config
Shows the SIP snooping configuration.
show sip-snooping ports
Displays the SIP snooping port level data.
show sip-snooping call-records Displays the SIP-snooping active/ended call records.
show sip-snooping statistics
Displays the SIP snooping statistics.
show qos dscp-table
Displays the QoS DSCP table configured.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 14-16
15
Configuring IP
Internet Protocol (IP) is primarily a network-layer (Layer 3) protocol that contains addressing and control
information that enables packets to be forwarded. Along with Transmission Control Protocol (TCP), IP
represents the heart of the Internet protocols. IP has two primary responsibilities, providing
connectionless, best-effort delivery of datagrams through an internetwork; and providing fragmentation
and reassembly of datagrams to support data links with different Maximum Transmission Unit (MTU)
sizes.
Note. IP routing (Layer 3) can be accomplished using static routes or by using one of the IP routing
protocols, Routing Information Protocol (RIP) and Open Shortest Path First (OSPF). For more information
on these protocols see Chapter 19, “Configuring RIP,” in this manual; or “Configuring OSPF” in the
OmniSwitch AOS Release 8 Advanced Routing Configuration Guide.
Two versions of Internet Protocol are supported - IPv4 and IPv6. For more information about using IPv6,
see Chapter 17, “Configuring IPv6.”
In This Chapter
This chapter describes IP and how to configure it through the Command Line Interface (CLI). It includes
instructions for enabling IP forwarding, configuring IP route maps, as well as basic IP configuration
commands (for example, ip default-ttl). CLI commands are used in the configuration examples; for more
details about the syntax of commands, see the OmniSwitch AOS Release 8 CLI Reference Guide. This
chapter provides an overview of IP and includes information about the following procedures:
• IP Forwarding
–
–
–
–
–
–
–
Configuring an IP Interface (see page 15-7)
Configuring an IP Managed Interface (see page 15-10)
Creating a Static Route or Recursive Static Route (see page 15-11)
Creating a Default Route (see page 15-12)
Configuring an IP Routed Port (see page 15-12)
Configuring Address Resolution Protocol (ARP) (see page 15-13)
Distributed ARP (see page 15-16)
• IP Configuration
–
–
–
–
–
–
Configuring the Router Primary Address (see page 15-19)
Configuring the Router ID (see page 15-19)
Configuring the Time-to-Live (TTL) Value (see page 15-20)
Configuring Route Map Redistribution (see page 15-20)
IP-Directed Broadcasts (see page 15-26)
Protecting the Switch from Denial of Service (DoS) attacks (see page 15-26)
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 15-1
Configuring IP
In This Chapter
• Managing IP
–
–
–
–
–
–
Internet Control Message Protocol (ICMP) (see page 15-32)
Using the Ping Command (see page 15-34)
Tracing an IP Route (see page 15-35)
Transmission Control Protocol (TCP) (see page 15-36)
Displaying User Datagram Protocol (UDP) Information (see page 15-36)
Service Assurance Agent (SAA) (see page 15-36)
• Tunneling
–
–
–
–
Generic Routing Encapsulation (page 15-36)
IP Encapsulation within IP (page 15-36)
Tunneling operation (page 15-37)
Configuring a Tunnel Interface (page 15-38)
• VRF Route Leak
– Quick Steps for Configuring VRF Route Leak (page 15-40)
– Configuring VRF Route Leak (page 15-41)
– Verifying VRF Route Leak Configuration (page 15-42)
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 15-2
Configuring IP
IP Defaults
IP Defaults
The following table lists the defaults for IP configuration through the ip command.
Description
Command
Default
IP-Directed Broadcasts
ip directed-broadcast
disable
Time-to-Live Value
ip default-ttl
64 (hops)
IP interfaces
ip interface
VLAN 1 interface.
ARP filters
arp filter
0
Quick Steps for Configuring IP Forwarding
Using only IP, which is always enabled on the OmniSwitch, devices connected to ports on the same
VLAN are able to communicate at Layer 2. The initial configuration for all OmniSwitch platforms
consists of a default VLAN 1. All switch ports are initially assigned to this VLAN. If additional VLANs
are not configured on the switch, the entire switch is treated as one large broadcast domain, and all ports
receive all traffic from all other ports.
Note. The operational status of a VLAN remains inactive until at least one active switch port is assigned to
the VLAN. If the ports are connected to an active network device, they are considered active. Non-active
port assignments are allowed, but do not change the operational state of the VLAN.
To forward packets to a different VLAN on a switch, create an IP interface on each VLAN. The following
steps provide a quick tutorial of how to enable IP forwarding between VLANs “from scratch”. If active
VLANs have already been created on the switch, you only need to create IP interfaces on each VLAN
(Steps 5 and 6).
1 Create VLAN 10 with a description (for example, VLAN 10) using the vlan command. For example:
-> vlan 10 name “VLAN 10”
2 Create VLAN 20 with a description (for example, VLAN 20) using the vlan command. For example:
-> vlan 20 name “VLAN 20”
3 Assign an active port to VLAN 10 using the vlan members untagged command. For example, the
following command assigns port 1 on slot 1 to VLAN 10:
-> vlan 10 members port 1/1 untagged
4 Assign an active port to VLAN 20 using the vlan members command. For example, the following
command assigns port 2 on slot 1 to VLAN 20:
-> vlan 20 members port 1/2 untagged
5 Create an IP interface on VLAN 10 using the ip interface command. For example:
-> ip interface vlan-10 address 171.10.1.1 vlan 10
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 15-3
Configuring IP
IP Overview
6 Create an IP interface on VLAN 20 using the ip interface command. For example:
-> ip interface vlan-20 address 171.11.1.1 vlan 20
Note. See Chapter 4, “Configuring VLANs,” for more information about how to create VLANs.
IP Overview
IP is a network-layer (Layer 3) protocol that contains addressing and control information that enables
packets to be forwarded on a network. IP is the primary network-layer protocol in the Internet protocol
suite. Along with TCP, IP represents the heart of the Internet protocols.
IP Protocols
IP is associated with Layer 3 and Layer 4 protocols. These protocols are built into the base code loaded on
the switch. A brief overview of the supported IP protocols is described in the following sections.
Transport Protocols
IP is both connectionless (it forwards each datagram separately) and unreliable (it does not guarantee
delivery of datagrams). This means that a datagram can be damaged in transit, thrown away by a busy
switch, or never make it to its destination. The resolution of these transit problems is to use a Layer 4
transport protocol, such as:
• TCP—A major data transport mechanism that provides reliable, connection-oriented, full-duplex data
streams. While the role of TCP is to add reliability to IP, TCP relies upon IP to do the actual delivering
of datagrams.
• UDP—A secondary transport-layer protocol that uses IP for delivery. UDP is not connection-oriented
and does not provide reliable end-to-end delivery of datagrams. Few applications can safely use UDP
to send datagrams that do not require the extra overhead added by TCP. For more information on UDP,
see Chapter 21, “Configuring DHCP Relay.”
Application-Layer Protocols
Application-layer protocols are used for switch configuration and management:
• Bootstrap Protocol (BOOTP)/Dynamic Host Configuration Protocol (DHCP)—can be used by an end
station to obtain an IP address. The switch provides a DHCP Relay that allows BOOTP requests/replies
to cross different networks.
• Simple Network Management Protocol (SNMP)—Allows communication between SNMP managers
and SNMP agents on an IP network. Network administrators use SNMP to monitor network
performance and manage network resources. For more information, see the “Using SNMP” chapter in
the OmniSwitch AOS Release 8 Switch Management Guide.
• Telnet—Used for remote connections to a device. You can telnet to a switch and configure the switch
and the network by using the CLI.
• SSH—Used for remote connections to a device. You can SSH to a switch and configure the switch and
the network by using the CLI.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 15-4
Configuring IP
IP Overview
• File Transfer Protocol (FTP)—Enables the transfer of files between hosts. This protocol is used to load
new images onto the switch.
Additional IP Protocols
Many additional IP-related protocols can be used with IP forwarding. These protocols are included as part
of the base code.
• Address Resolution Protocol (ARP)—Used to match the IP address of a device with its physical
(MAC) address. For more information, see “Configuring Address Resolution Protocol (ARP)” on
page 15-13.
• Virtual Router Redundancy Protocol (VRRP)—Used to back up routers. For more information, see
Chapter 23, “Configuring VRRP.”
• Internet Control Message Protocol (ICMP)—Specifies the generation of error messages, test packets,
and informational messages related to IP. ICMP supports the ping command used to determine if hosts
are online. For more information, see “Internet Control Message Protocol (ICMP)” on page 15-32.
• Multicast Services—Includes IP multicast switching (IPMS). For more information, see Chapter 25,
“Configuring IP Multicast Switching.”
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 15-5
Configuring IP
IP Forwarding
IP Forwarding
Network device traffic is bridged (switched) at the Layer 2 level between ports that are assigned to the
same VLAN. However, if a device needs to communicate with another device that belongs to a different
VLAN, then Layer 3 routing is necessary to transmit traffic between the VLANs. Bridging decides to
forward the packets based on the destination MAC address of the packet. Routing decides on where to
forward packets based on the IP network address of the packet (for example, IP - 21.0.0.10).
The OmniSwitch platforms support routing of IP traffic. A VLAN is available for routing when at least
one- router interface is defined for that VLAN and at least one active port is associated with the VLAN. If
a VLAN does not have a router interface, the ports associated with that VLAN are in essence firewalled
from other VLANs.
IP multi-netting is also supported. A network is said to be multi-netted when multiple IP subnets are
brought together within a single broadcast domain. Each interface is configured with a different subnet. As
a result, traffic from each configured subnet can coexist on the same VLAN.
In the illustration below, an IP router interface has been configured on each VLAN. Therefore,
workstations connected to ports on VLAN 1 on Switch 1 can communicate with VLAN 2; and
workstations connected to ports on VLAN 3 on Switch 2 can communicate with VLAN 2. Also, ports
from both switches have been assigned to VLAN 2, and a physical connection has been made between the
switches. Therefore, workstations connected to VLAN 1 on Switch 1 can communicate with workstations
connected to VLAN 3 on Switch 2.
Switch 1
Switch 2
= IP Router Interface
VLAN 1
110.0.0.1
VLAN 2
120.0.0.0
Physical
Connection
VLAN 2
120.0.0.0
VLAN 3
130.0.0.1
110.0.0.2
130.0.0.2
IP Forwarding
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 15-6
Configuring IP
IP Forwarding
Configuring an IP Interface
IP is enabled by default. Using IP, devices connected to ports on the same VLAN are able to
communicate. However, to forward packets to a different VLAN, create at least one IP interface on each
VLAN.
Use the ip interface command to define IP interfaces for an existing VLAN. The following parameter
values are configured with this command:
• A unique interface name (text string up to 16 characters) is used to identify the IP interface. Specifying
this parameter is required to create or modify an IP interface.
• The VLAN ID of an existing VLAN.
• An IP address to assign to the interface (for example, 193.204.173.21). Router interface IP addresses
must be unique. You cannot have two-router interfaces with the same IP address.
• A subnet mask (defaults to the IP address class). It is possible to specify the mask in dotted decimal
notation (for example, 255.255.0.0) or with a slash (/) after the IP address followed by the number of
bits to specify the mask length (for example, 193.204.173.21/24).
• The forwarding status for the interface (defaults to forwarding). A forwarding router interface sends IP
frames to other subnets. A router interface that is not forwarding can receive frames from other hosts
on the same subnet.
• An Ethernet-II or SNAP encapsulation for the interface (defaults to Ethernet-II). The encapsulation
determines the framing type the interface uses when generating frames that are forwarded out of
VLAN ports. Select an encapsulation that matches the encapsulation of the majority of VLAN traffic.
• The Local Proxy ARP status for the VLAN. If enabled, traffic within the VLAN is routed instead of
bridged. ARP requests return the MAC address of the IP router interface defined for the VLAN. For
more information about Local Proxy ARP, see “Local Proxy ARP” on page 15-15.
• The primary interface status. Designates the specified IP interface as the primary interface for the
VLAN. By default, the first interface bound to a VLAN becomes the primary interface for that VLAN.
The following ip interface command example creates an IP interface named Marketing with an IP
network address of 21.0.0.1 and binds the interface to VLAN 455:
-> ip interface Marketing address 21.0.0.1 vlan 455
The name parameter is the only parameter required with this command. Specifying additional parameters
is only necessary to configure a value other than the default value for that parameter. For example, all of
the following commands create an IP router interface for VLAN 955 with a class A subnet mask, an
enabled forwarding status, Ethernet-II encapsulation, and a disabled Local Proxy ARP and primary
interface status:
->
no
->
->
ip interface Accounting address 71.0.0.1 mask 255.0.0.0 vlan 955 forward e2
local-proxy-arp no primary
ip interface Accounting address 71.0.0.1/8 vlan 955
ip interface Accounting address 71.0.0.1 vlan 955
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 15-7
Configuring IP
IP Forwarding
Modifying an IP Router Interface
The ip interface command is also used to modify existing IP interface parameter values. It is not
necessary to remove the IP interface and then create it again with the new values. The changes specified
overwrite existing parameter values. For example, the following command changes the subnet mask to
255.255.255.0, the forwarding status to no forwarding and the encapsulation to snap by overwriting
existing parameter values defined for the interface. The interface name, Accounting, is specified as part of
the command syntax to identify which interface to change.
-> ip interface Accounting mask 255.255.255.0 no forward snap
When changing the IP address for the interface, the subnet mask reverts to the default mask value if it was
previously set to a non-default value and it is not specified when changing the IP address. For example,
the following command changes the IP address for the Accounting interface:
-> ip interface Accounting address 40.0.0.1
The subnet mask for the Accounting interface was previously set to 255.255.255.0. The above example
resets the mask to the default value of 255.0.0.0 because 40.0.0.1 is a Class A address and no other mask
was specified with the command. This only occurs when the IP address is modified; all other parameter
values remain unchanged unless otherwise specified.
To avoid the problem in the above example, enter the non-default mask value whenever the IP address is
changed for the interface. For example:
-> ip interface Accounting address 40.0.0.1 mask 255.255.255.0
-> ip interface Accounting address 40.0.0.1/8
Use the show ip interface command to verify IP router interface changes. For more information about
these commands, see the OmniSwitch AOS Release 8 CLI Reference Guide.
Removing an IP Router Interface
To remove an IP router interface, use the no form of the ip interface command. It is only necessary to
specify the name of the IP interface, as shown in the following example:
-> no ip interface Marketing
To view a list of IP interfaces configured on the switch, use the show ip interface command. For more
information about this command, see the OmniSwitch AOS Release 8 CLI Reference Guide.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 15-8
Configuring IP
IP Forwarding
Configuring a Loopback0 Interface
Loopback0 is the name assigned to an IP interface to identify a consistent address for network
management purposes. The Loopback0 interface is not bound to any VLAN, so it always remains
operationally active. If there are no active ports in the VLAN, all IP interface associated with that VLAN
are not active. In addition, the Loopback0 interface provides a unique IP address for the switch that is
easily identifiable to network management applications.
This type of interface is created in the same manner as all other IP interfaces, using the ip interface
command. To identify a Loopback0 interface, enter Loopback0 for the interface name. For example, the
following command creates the Loopback0 interface with an IP address of 10.11.4.1:
-> ip interface Loopback0 address 10.11.4.1
Note the following when configuring the Loopback0 interface:
• The interface name, “Loopback0”, is case sensitive.
• The Loopback0 interface is always active and available.
• Only one Loopback0 interface per switch is allowed.
• Loopback0 address cannot be modified once it is configured.
• Creating this interface does not deduct from the total number of IP interfaces allowed per VLAN or
switch.
• To change the address, remove the interface using the no ip interface Loopback0 command and add it
again with the new address.
Loopback0 Address Advertisement
The Loopback0 IP interface address is automatically advertised by the IGP protocols RIP and OSPF when
the interface is created. There is no additional configuration necessary to trigger advertisement with these
protocols.
Note the following regarding Loopback0 advertisement:
• RIP advertises the host route to the Loopback0 IP interface as a redistributed (directhost) route.
• OSPF advertises the host route to the Loopback0 IP interface in its Router-LSAs (as a Stub link) as an
internal route into all its configured areas.
Configuring a BGP Peer Session with Loopback0
It is possible to create BGP peers using the Loopback0 IP interface address of the peering router and
binding the source (that is, outgoing IP interface for the TCP connection) to its own configured
Loopback0 interface. The Loopback0 IP interface address can be used for both Internal and External BGP
peer sessions. For EBGP sessions, if the external peer router is multiple hops away, the ebgp-multihop
parameter can be used.
The following example command configures a BGP peering session using a Loopback0 IP interface
address:
-> ip bgp neighbor 2.2.2.2 update-source Loopback0
See the OmniSwitch AOS Release 8 Advanced Routing Configuration Guide for more information.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 15-9
Configuring IP
IP Forwarding
Configuring an IP Managed Interface
By default, most applications that run on IP use the egress IP interface address as the source IP, while
using a socket to communicate with a peer/server. However, it may be desirable to have some applications
use a specific source IP for the packets that are sent out using the socket.
The ip service source-ip command provides the ability to configure a permanent source IP interface to
send packets. The source IP interface can be the Loopback0 address or user defined IP interface. For
example,
The following commands create a Loopback0 interface and configures that interface as a source IP
interface for the NTP application:
-> ip interface Loopback0 address 10.10.1.1
-> ip service source-ip loopback0 ntp
The following command configures user-defined source IP interface for the FTP application:
-> ip service source-ip ipVlan100 ftp
Notes.
• Use “all” option in the command to configure a common source IP address for the applications. If for a
particular application, specific source IP address is configured and the “all” option is also set, the
configured source IP address for the application is used as the outgoing interface.
• If a source IP interface is not defined for an application, the application uses the outgoing interface
address as the source IP.
A source IP address is configurable for the following applications within the VRF context:
Application
Default Source Interface
VRF Support
ASA Authentication Server
LDAP Server
Outgoing interface
Supported with any VRF
(Configuration available only in the default
VRF)
TACACS+
Outgoing interface
Supported with any VRF
(Configuration available only in the default
VRF)
AAA Authentication Server
RADIUS
Outgoing interface
Supported with any VRF
(Configuration available only in the default
VRF)
Switch Management Applications
SNMP
(includes traps)
Outgoing interface
Supported with any VRF
(Configuration available only in the default
VRF)
SFLOW
Outgoing interface
Supported with only default VRF
NTP
Outgoing interface
Supported with any VRF
(Configuration available only in the default
VRF)
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 15-10
Configuring IP
IP Forwarding
Application
Default Source Interface
VRF Support
SWLOG
Outgoing interface
Supported with any VRF
(Configuration available only in the default
VRF)
DNS
Outgoing interface
Servers can only be set in the default VRF
Switch Access and Utilities
(ping and traceroute command can specify a source address as an optional parameter)
Telenet
Outgoing interface
Supported with any VRF
FTP
Outgoing interface
Supported with any VRF
SSH
Outgoing interface
(includes scp, sftp)
Supported with any VRF
TFTP
Supported with any VRF
Outgoing interface
Creating a Static Route or Recursive Static Route
Static routes are user-defined and carry a higher priority than routes created by dynamic routing protocols.
That is, if two routes have the same metric value, the static route has the higher priority. Static routes
allow you to define, or customize, an explicit path to an IP network segment, which is then added to the IP
Forwarding table. Static routes can be created between VLANs to enable devices on these VLANs to
communicate.
Use the ip static-route command to create a static route. Specify the destination IP address of the route as
well as the IP address of the first hop (gateway/interface) used to reach the destination. For example, to
create a static route to IP address 171.11.0.0 through gateway 171.11.2.1 with a tag of 3, you would enter:
-> ip static-route 171.11.0.0 gateway 171.11.2.1 tag 3
For example, to create a proxy ARP static route to IP address 171.11.0.0 through interface Int1you would
enter:
-> ip static-route 171.11.0.0 interface Int1
If you want to use the natural subnet mask, the subnet mask is not required. By default, the switch imposes
a natural mask on the IP address. In the above example, the Class B mask of 255.255.0.0 is implied. If you
do not want to use the natural mask, enter a subnet mask. For example, to create a static route to IP
address 10.255.11.0, enter the Class C mask of 255.255.255.0:
-> ip static-route 10.255.11.0 mask 255.255.255.0 gateway 171.11.2.1
Specifying the length of the mask in bits is also supported. For example, the above static route is also
configurable using the following command:
-> ip static-route 10.255.11.0/24 gateway 171.11.2.1
When you create a static route, the default metric value of 1 is used. However, you can change the priority
of the route by increasing its metric value. The lower the metric value, the higher the priority. This metric
is added to the metric cost of the route. The metric range is 1 to 15. For example:
-> ip static-route 10.255.11.0/24 gateway 171.11.2.1 metric 5
Static routes do not age out of the IP Forwarding table; delete them from the table. Use the no ip static
route command to delete a static route. Specify the destination IP address of the route as well as the IP
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 15-11
Configuring IP
IP Forwarding
address of the first hop (gateway). For example, to delete a static route to IP address 171.11.0.0 through
gateway 171.11.2.1, you would enter:
-> no ip static-route 171.11.0.0 gateway 171.11.2.1
The IP Forwarding table includes routes learned through one of the routing protocols (RIP, OSPF, BGP)
as well as any static routes that are configured. Use the show ip routes command to display the IP
Forwarding table.
Creating a Recursive Static Route
Recursive static routes are similar to the static routes described above. However, with a recursive static
route the route to reach the gateway is learned through a dynamic routing protocol such as RIP or OSPF. If
a better route to the gateway is learned, the path to a recursive route can be changed dynamically. This
feature can be used to configure a uniformed static route for all routers on a network, but the path to reach
the gateway can differ for each router. To create a recursive static route use the follows parameter:
-> ip static-route 171.11.0.0 follows 192.168.10.1
A route to the 192.168.10.1 address must be learned by a dynamic routing protocol for the recursive static
route to be active.
Creating a Default Route
A default route can be configured for packets destined for networks that are unknown to the switch. Use
the ip static-route command to create a default route. Specify a default route of 0.0.0.0 with a subnet
mask of 0.0.0.0 and the IP address of the next hop (gateway). For example, to create a default route
through gateway 171.11.2.1 you would enter:
-> ip static-route 0.0.0.0 mask 0.0.0.0 gateway 171.11.2.1
Specifying the length of the mask in bits is also supported. For example, the above default route is also
configurable using the following command:
-> ip static-route 0.0.0.0/0 gateway 171.11.2.1
Note. You cannot create a default route by using the EMP port as a gateway.
Configuring an IP Routed Port
An IP interface can be configured on a VLAN and a port or linkagg can be added to this VLAN as tagged
or untagged, in a single CLI command. Use the ip interface rtr-port to create a VLAN, configure an IP
interface on that VLAN and assign a single port as tagged or untagged to that VLAN.
For example.
• To create VLAN interface and assign port 1/1 as tagged port to that VLAN use the below command:
-> ip interface test address 10.0.0.1/8 vlan 30 rtr-port port 1/1 tagged
• To create VLAN interface and assign port 1/2 as untagged port to that VLAN use the below command:
-> ip interface test1 address 20.0.0.1/8 vlan 40 rtr-port port 1/2 untagged
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 15-12
Configuring IP
IP Forwarding
Create a linkagg and then create a VLAN interface and assign the created linkagg as tagged or untagged to
that VLAN.
For example.
• To create VLAN interface and assign linkagg 6 as tagged to that VLAN use the below command:
-> ip interface test address 10.0.0.1/8 vlan 30 rtr-port linkagg 6 tagged
• To create VLAN interface and assign linkagg 7 as untagged to that VLAN use the below command:
-> ip interface test1 address 20.0.0.1/8 vlan 40 rtr-port linkagg 7 untagged
The VLAN associated with the router-port must be a new, unused VLAN. This VLAN is a routing-only
VLAN with a single port or trunk. Configuration to add additional members to this VLAN, or to delete
this VLAN directly using no vlan command is rejected. This vlan can only be deleted by deleting the
associated IP interface using the no form of the ip interface command.
If the IP interface is modified such that it's no longer bound to this VLAN, the corresponding VLAN is
deleted.
Configuring Address Resolution Protocol (ARP)
To send packets on a locally connected network, the switch uses ARP to match the IP address of a device
with its physical (MAC) address. To send a data packet to a device with which it has not previously
communicated, the switch first broadcasts an ARP request packet. The ARP request packet requests the
Ethernet hardware address corresponding to an Internet address. All hosts on the receiving Ethernet
receive the ARP request, but only the host with the specified IP address responds. If present and
functioning, the host with the specified IP address responds with an ARP reply packet containing its
hardware address. The switch receives the ARP reply packet, stores the hardware address in its ARP cache
for future use, and begins exchanging packets with the receiving device.
The switch stores the hardware address in its ARP cache (ARP table). The table contains a listing of IP
addresses and their corresponding translations to MAC addresses. Entries in the table are used to translate
32-bit IP addresses into 48-bit Ethernet or IEEE 802.3 hardware addresses. Dynamic addresses remain in
the table until they time out. You can set this time-out value and you can also manually add or delete
permanent addresses to/from the table.
Adding a Permanent Entry to the ARP Table
As described above, dynamic entries remain in the ARP table for a specified time period before they are
automatically removed. However, you can create a permanent entry in the table.
Use the arp command to add a permanent entry to the ARP table. Enter the IP address of the entry
followed by its physical (MAC) address. For example, to create an entry for IP address 171.11.1.1 with a
corresponding physical address of 00:05:02:c0:7f:11, you would enter:
-> arp 171.11.1.1 00:05:02:c0:7f:11
Configuring a permanent ARP entry with a multicast address is also supported. For example, the
following command creates a permanent multicast ARP entry:
-> arp 2.2.3.40 01:4a:22:03:44:5c
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 15-13
Configuring IP
IP Forwarding
When configuring a static multicast ARP entry, do not use any of the following multicast addresses:
01:00:5E:00:00:00 to 01:00:5E:7F:FF:FF
01:80:C2:XX.XX.XX
33:33:XX:XX:XX:XX
The IP address and hardware address (MAC address) are required when you add an entry to the ARP
table. Optionally, you can also specify:
• Alias. Use the alias keyword to specify that the switch acts as an alias (proxy) for this IP address.
When the alias option is used, the switch responds to all ARP requests for the specified IP address with
its own MAC address. This option is not related to Proxy ARP as defined in RFC 925.
For example:
-> arp 171.11.1.1 00:05:02:c0:7f:11 alias
• ARP Name. Use the arp-name parameter to specify a name for the permanent ARP entry.
For example:
-> arp 171.11.1.1 00:2a:90:d1:8e:10 arp-name server1
• Interface. Use the interface parameter to set the interface for the permanent ARP entry.
For example:
-> arp 171.11.1.1 00:2a:90:d1:8e:10 arp-name server1 interface Int1
Use the show arp command to display the ARP table.
Note. As most hosts support the use of address resolution protocols to determine and cache address
information (called dynamic address resolution), it is not required to specify permanent ARP entries.
Deleting a Permanent Entry from the ARP Table
Permanent entries do not age out of the ARP table. Use the no arp command to delete a permanent entry
from the ARP table. When deleting an ARP entry, you only need to enter the IP address. For example, to
delete an entry for IP address 171.11.1.1, you would enter:
-> no arp 171.11.1.1
Use the show arp command to display the ARP table and verify that the entry was deleted.
Note. You can also use the no arp command to delete a dynamic entry from the table.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 15-14
Configuring IP
IP Forwarding
Clearing a Dynamic Entry from the ARP Table
Dynamic entries can be cleared using the ip distributed-arp admin-state command. This command
clears all dynamic entries. Clear the permanent entries using the no arp command.
Use the show arp command to display the table and verify that the table was cleared.
Note. Dynamic entries remain in the ARP table until they time out. If the switch does not receive data from
a host for this user-specified time, the entry is removed from the table. If another packet is received from
this host, the switch goes through the discovery process again to add the entry to the table. The switch uses
the MAC Address table time-out value as the ARP time-out value. Use the mac-learning aging-time
command to set the time-out value.
Local Proxy ARP
The Local Proxy ARP feature is an extension of the Proxy ARP feature, but is enabled on an IP interface
and applies to the VLAN bound to that interface. When Local Proxy ARP is enabled, all ARP requests
received on VLAN member ports are answered with the MAC address of the IP interface that has Local
Proxy ARP enabled. In essence, all VLAN traffic is now routed within the VLAN instead of bridged.
This feature is intended for use with port mapping applications where VLANs are one-port associations.
This allows hosts on the port mapping device to communicate through the router. ARP packets are still
bridged across multiple ports.
Local Proxy ARP takes precedence over any switch-wide Proxy ARP or ARP function. In addition, it is
not necessary to configure Proxy ARP to use Local Proxy ARP. The two features are independent of each
other.
By default, Local Proxy ARP is disabled when an IP interface is created. To enable this feature, use the ip
interface command. For example:
-> ip interface Accounting local-proxy-arp
When Local Proxy ARP is enabled for any one IP router interface associated with a VLAN, the feature is
applied to the entire VLAN. It is not necessary to enable it for each interface. However, if the IP interface
that has the Local Proxy ARP feature enabled is moved to another VLAN, Local Proxy ARP is enabled
for the new VLAN and must be enabled on another interface for the old VLAN.
ARP Filtering
ARP filtering is used to determine whether the switch responds to ARP requests that contain a specific IP
address. ARP filtering is used in conjunction with the Local Proxy ARP application; however, it is
available for use on its own or with other applications.
By default, no ARP filters exist in the switch configuration. When there are no filters present, all ARP
packets are processed, unless they are blocked or redirected by some other feature.
Use the arp filter command to specify the following parameter values required to create an ARP filter:
• An IP address (for example, 193.204.173.21) used to determine whether an ARP packet is filtered.
• An IP mask (for example, 255.0.0.0) used to identify which part of the ARP packet IP address is
compared to the filter IP address.
• An optional VLAN ID to specify that the filter is only applied to ARP packets from that VLAN.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 15-15
Configuring IP
Distributed ARP
• Which ARP packet IP address to use for filtering (sender or target). If the target IP address in the ARP
packet matches a target IP specified in a filter, then the disposition for that filter applies to the ARP
packet. If the sender IP address in the ARP packet matches a sender IP specified in a filter, then the
disposition for that filter applies to the ARP packet.
• The filter disposition (block or allow). If an ARP packet meets filter criteria, the switch is either
blocked from responding to the packet or allowed to respond to the packet depending on the filter
disposition. Packets that do not meet any filter criteria are responded to by the switch.
The following arp filter command example creates an ARP filter, which blocks the switch from
responding to ARP packets that contain a sender IP address that starts with 198:
-> arp filter 198.0.0.0 mask 255.0.0.0 sender block
Up to 200 ARP filters can be defined on a single switch. To remove an individual filter, use the no form of
the arp filter command. For example:
-> no arp filter 198.0.0.0
To clear all ARP filters from the switch configuration, use the clear arp filter command. For example:
-> clear arp filter
Use the show arp filter command to verify the ARP filter configuration. For more information on ARP
Filtering and other ARP filter commands, see the OmniSwitch AOS Release 8 CLI Reference Guide.
Distributed ARP
The distributed ARP enables effective ARP response. The feature dynamically designates a specific
Network Interface (NI) as the designated-NI for all ARP entries, per IP interface.
Designated-NI and Distributed ARP Management
The designated-NI is dynamically assigned for the interface. By default the NI with the most number of
active ports in the VLAN is set as the designated-NI.
When the number of ARPs learned on the designated-NI exceed a fixed percentage of capacity (e.g. 95%),
a new designated-NI is chosen for the IP interface. The NI with the second highest active ports in the
VLAN is selected depending on the space available to learn the ARPs. For example if the NI with the
second highest active ports has less space to learn the ARPs, then the next available NI with highest active
port is selected if space is available.
The designated-NI performs the ARP lookup, and forwards the traffic. If the designated-NI does not have
a matching ARP entry, the traffic is sent to the CPU of that NI, which will then resolve the ARP.
Note. The ARPs learned on the IP tunnel interfaces are synchronized on all NIs.
Enabling/Disabling Distributed ARP
To enable or disable the distributed ARP feature, use the ip distributed-arp admin-state command.
To enable the feature, use the command as shown in the example:
-> ip distributed-arp admin-state enable
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 15-16
Configuring IP
Distributed ARP
To disable the feature, use the command as shown in the example:
-> ip distributed-arp admin-state disable
Note. To reset or update the designated-NI, the feature must be disabled and then enabled.
Verifying the Distributed ARP
The ARP utilization can be monitored and checked at any time using the show ip arp utilization
command. For example:
-> show ip arp utilization
Distributed ARPs: Enabled
ARP
HW
NI
Max
Count
Usage
%
------+--------+-------+-------+------1/1
16384
8
11
0%
2/1
16384
12
15
0%
To view the ARP utilization for all of the configured interfaces, use the interfaces parameter with the
command. For example:
-> show ip arp utilization interfaces
Distributed ARPs: Enabled
ARP
HW
NI
Max
Count
ARPS
%
VRF
Interface
------+--------+-------+-------+-------+------+-----------------1/1
16384
1
0
0%
0
vlan-1001
1/1
16384
5
4
0%
0
vlan-1002
1/1
16384
5
0
0%
0
vlan-1003
1/1
16384
5
4
0%
0
vlan-1004
1/1
16384
5
0
0%
0
vlan-1005
1/1
16384
5
0
0%
0
vlan-1006
2/1
16384
1
0
0%
0
vlan-1001
2/1
16384
5
0
0%
0
vlan-1002
2/1
16384
5
4
0%
0
vlan-1003
2/1
16384
5
0
0%
0
vlan-1004
2/1
16384
5
4
0%
0
vlan-1005
2/1
16384
5
4
0%
0
vlan-1006
To view the utilization for all the interfaces on a specific chassis and slot, use the interfaces slot
parameter with the command. For example:
-> show ip arp utilization interfaces slot 2/1
Distributed ARPs: Enabled
ARP
HW
NI
Max
Count
ARPS
%
VRF
Interface
------+--------+-------+-------+-------+------+-----------------2/1
16384
1
0
0%
0
vlan-1001
2/1
16384
5
0
0%
0
vlan-1002
2/1
16384
5
4
0%
0
vlan-1003
2/1
16384
5
0
0%
0
vlan-1004
2/1
16384
5
4
0%
0
vlan-1005
2/1
16384
5
4
0%
0
vlan-1006
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 15-17
Configuring IP
Distributed ARP
To view the designated-NI for the interface, use the show ip interface command. For example:
-> show ip interface 15
Interface Name = 15
SNMP Interface Index
IP Address
Subnet Mask
Broadcast Address
Device
Encapsulation
Forwarding
Administrative State
Operational State
Maximum Transfer Unit
Designated ARP NI
ARP Count
Router MAC
Local Proxy ARP
Primary (config/actual)
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
13600001,
15.2.2.1,
255.255.255.0,
15.2.2.255,
vlan 215,
eth2,
enabled,
enabled,
up,
1500,
3/1,
1,
e8:e7:32:8d:9b:b1,
disabled,
no/yes
For more information about the displays that result from these commands, see the OmniSwitch AOS
Release 8 CLI Reference Guide.
Distributed ARP Management Example
Due to the hashing algorithm used for Distributed ARP, the more VLANs, IP interfaces, and physical
ports configured will result in less hashing collisions and a higher total number of ARPs that can be
learned.
Below are some example distributed ARP configurations resulting in the maximum number of ARPs
learned. Please refer to the “Network Configuration Specifications” chapter in the OmniSwitch AOS
Release 8 Specifications Guide for the ARP specifications for each chassis.
VC Configuration
VLANs
Configured
ARPs per
VLAN
Total ARPs
learned
ARPs per chassis
learned
VC of 6 (Mix of Q32
and X72
24
8K
192K
32K
(maximum 192K
ARPs reached)
VC of 2 (Q32/X72)
36
1K through 5K 96K
48K
VC of 2 (X72/X40)
36
1K through 5K 56K
48K - X72
8K - X40
VC of 6 (Q32, Q32,
Q32, X40, X20, X20)
20
19 VLANs- 8K 168K
1 VLAN - 16K
48K - Q32
8K - X20/40
Distributed ARP Example Configurations
• Attempt to keep VLANs with a large amount of routed traffic between them consolidated on the same
designated NI to help reduce traffic flow over the VFL.
• To make a specific NI the designated NI put active ports and VLANs on that NI only.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 15-18
Configuring IP
IP Configuration
• When the threshold of 95% is met on a particular NI, the IP interface/VLAN with the lowest amount of
ARPs will be moved first. The entire set of ARPs from a particular IP interface/VLAN is moved in
case of NI overload.
IP Configuration
IP is enabled on the switch by default and a few options that can, or need to be, configured. This section
provides instructions for basic IP configuration options.
Configuring the Router Primary Address
By default, the router primary address is derived from the first IP interface that becomes operational on the
router. if the router ID is not a valid IP unicast address, the router primary IP address is used by BGP to
derive its unique BGP Identifier.
Use the ip router primary-address command to configure the router primary address. Enter the
command, followed by the IP address. For example, to configure a router primary address of
172.22.2.115, you must enter:
-> ip router primary-address 172.22.2.115
Configuring the Router ID
By default, the router primary address of the router is used as the router ID. However, if a primary address
has not been explicitly configured, the router ID defaults to the address of the first IP interface that
becomes operational.
Use the ip router router-id command to configure the router ID. Enter the command, followed by the IP
address. For example, to configure a router ID of 172.22.2.115, you would enter:
-> ip router router-id 172.22.2.115
Configuring the Route Preference of a Router
By default, the route preference of a router is in this order: local, static, OSPF, RIP, EBGP, and IBGP
(highest to lowest).
Use the ip route-pref command to change the route preference value of a router. For example, to
configure the route preference of an OSPF route, you must enter:
-> ip route-pref ospf 15
To display the current route preference configuration, use the show ip route-pref command:
-> show ip route-pref
Protocol
Route Preference Value
------------+-----------------------Local
1
Static
2
OSPF
110
RIP
120
EBGP
190
IBGP
200
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 15-19
Configuring IP
IP Configuration
Configuring the Time-to-Live (TTL) Value
The TTL value is the default value inserted into the TTL field of the IP header of datagrams originating
from the switch whenever a TTL value is not supplied by the transport layer protocol. The value is
measured in hops.
Use the ip default-ttl command to set the TTL value. Enter the command, followed by the TTL value. For
example, to set a TTL value of 75, you would enter:
-> ip default-ttl 75
The default hop count is 64. The valid range is 1 to 255. Use the show ip config command to display the
default TTL value.
Configuring Route Map Redistribution
You can learn and advertise IPv4 routes between different protocols. Such a process is referred to as route
redistribution and is configured using the ip redist command.
Redistribution uses route maps to control how external routes are learned and distributed. A route map
consists of one or more user-defined statements that can determine which routes are allowed or denied
access to the receiving network. In addition, a route map can also contain statements that modify route
parameters before they are redistributed.
When a route map is created, a name is given to identify the group of statements that it represents. This
name is required by the ip redist command. Therefore, configuring route redistribution involves the
following steps:
1 Create a route map, as described in “Using Route Maps” on page 15-20.
2 Configure redistribution to apply a route map, as described in “Configuring Route Map Redistribution”
on page 15-24.
Using Route Maps
A route map specifies the criteria that are used to control redistribution of routes between protocols. Such
criteria is defined by configuring route map statements. There are three different types of statements:
• Action. An action statement configures the route map name, sequence number, and whether
redistribution is permitted or denied based on route map criteria.
• Match. A match statement specifies criteria that a route must match. When a match occurs, then the
action statement is applied to the route.
• Set. A set statement is used to modify route information before the route is redistributed into the
receiving protocol. This statement is only applied if all the criteria of the route map is met and the
action permits redistribution.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 15-20
Configuring IP
IP Configuration
The ip route-map command is used to configure route map statements and provides the following action,
match, and set parameters:
ip route-map action ...
ip route-map match ...
ip route-map set ...
permit
deny
ip-address
ip-nexthop
ipv6-address
ipv6-nexthop
tag
ipv4-interface
ipv6-interface
metric
route-type
metric
metric-type
tag
community
local-preference
level
ip-nexthop
ipv6-nexthop
Refer to the “IP Commands” chapter in the OmniSwitch AOS Release 8 CLI Reference Guide for more
information about the ip route-map command parameters and usage guidelines.
Once a route map is created, it is then applied using the ip redist command. See “Configuring Route Map
Redistribution” on page 15-24 for more information.
Route Maps are also used for VRF route leaking and RIP route filtering. See “VRF Route Leak” on
page 15-40 section for more information.
Creating a Route Map
When a route map is created, a name (up to 20 characters), a sequence number, and an action (permit or
deny) is specified. Specifying a sequence number is optional. If a value is not configured, then the number
50 is used by default.
To create a route map, use the ip route-map command with the action parameter. For example,
-> ip route-map ospf-to-bgp sequence-number 10 action permit
The above command creates the ospf-to-bgp route map, assigns a sequence number of 10 to the route
map, and specifies a permit action.
To optionally filter routes before redistribution, use the ip route-map command with a match parameter
to configure match criteria for incoming routes. For example,
-> ip route-map ospf-to-bgp sequence-number 10 match tag 8
The above command configures a match statement for the ospf-to-bgp route map to filter routes based on
their tag value. When this route map is applied, only OSPF routes with a tag value of eight are
redistributed into the BGP network. All other routes with a different tag value are dropped.
Note. Configuring match statements is not required. However, if a route map does not contain any match
statements and the route map is applied using the ip redist command, the router redistributes all routes into
the network of the receiving protocol.
Use the ip route-map command with a set parameter to modify route information before redistribution.
For example,
-> ip route-map ospf-to-bgp sequence-number 10 set tag 5
The above command configures a set statement for the ospf-to-bgp route map that changes the route tag
value to five. As this statement is part of the ospf-to-bgp route map, it is only applied to routes that have
an existing tag value equal to eight.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 15-21
Configuring IP
IP Configuration
The following is a summary of the commands used in the above examples:
-> ip route-map ospf-to-bgp sequence-number 10 action permit
-> ip route-map ospf-to-bgp sequence-number 10 match tag 8
-> ip route-map ospf-to-bgp sequence-number 10 set tag 5
To verify a route map configuration, use the show ip route-map command:
-> show ip route-map
Route Maps: configured: 1 max: 200
Route Map: ospf-to-bgp Sequence Number: 10 Action permit
match tag 8
set tag 5
Deleting a Route Map
Use the no form of the ip route-map command to delete an entire route map, a route map sequence, or a
specific statement within a sequence.
To delete an entire route map, enter no ip route-map followed by the route map name. For example, the
following command deletes the entire route map named redistipv4:
-> no ip route-map redistipv4
To delete a specific sequence number within a route map, enter no ip route-map followed by the route
map name, then sequence-number followed by the actual number. For example, the following command
deletes sequence 10 from the redistipv4 route map:
-> no ip route-map redistipv4 sequence-number 10
In the above example, the redistripv4 route map is not deleted. Only those statements associated with
sequence 10 are removed from the route map.
To delete a specific statement within a route map, enter no ip route-map followed by the route map name,
then sequence-number followed by the sequence number for the statement, then either match or set and
the match or set parameter and value. For example, the following command deletes only the match tag 8
statement from route map redistipv4 sequence 10:
-> no ip route-map redistipv4 sequence-number 10 match tag 8
Configuring Route Map Sequences
A route map can consist of one or more sequences of statements. The sequence number determines which
statements belong to which sequence and the order in which sequences for the same route map are
processed.
To add match and set statements to an existing route map sequence, specify the same route map name and
sequence number for each statement. For example, the following series of commands creates route map
rm_1 and configures match and set statements for the rm_1 sequence 10:
-> ip route-map rm_1 sequence-number 10 action permit
-> ip route-map rm_1 sequence-number 10 match tag 8
-> ip route-map rm_1 sequence-number 10 set metric 1
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 15-22
Configuring IP
IP Configuration
To configure a new sequence of statements for an existing route map, specify the same route map name
but use a different sequence number. For example, the following commands create a sequence 20 for the
rm_1 route map:
-> ip route-map rm_1 sequence-number 20 action permit
-> ip route-map rm_1 sequence-number 20 match ipv4-interface to-finance
-> ip route-map rm_1 sequence-number 20 set metric 5
The resulting route map appears as follows:
-> show ip route-map rm_1
Route Map: rm_1 Sequence Number: 10 Action permit
match tag 8
set metric 1
Route Map: rm_1 Sequence Number: 20 Action permit
match ip4 interface to-finance
set metric 5
Sequence 10 and sequence 20 are both linked to route map rm_1 and are processed in ascending order
according to their sequence number value. There is an implied logical OR between sequences. As a result,
if there is no match for the tag value in sequence 10, then the match interface statement in sequence 20 is
processed. However, if a route matches the tag 8 value, then sequence 20 is not used. The set statement for
whichever sequence was matched is applied.
A route map sequence can contain multiple match statements. If these statements are of the same kind (for
example, match tag 5, match tag 8, and so on) then a logical OR is implied between each like statement. If
the match statements specify different types of matches (for example, match tag 5, match ip4 interface tofinance, and so on), then a logical AND is implied between each statement. For example, the following
route map sequence redistributes a route if its tag is either 8 or 5:
-> ip route-map rm_1 sequence-number 10 action permit
-> ip route-map rm_1 sequence-number 10 match tag 5
-> ip route-map rm_1 sequence-number 10 match tag 8
If the route has a tag of 8 or 5 and the route was learned on the IPv4 interface to-finance, the following
route map sequence redistributes a route:
->
->
->
->
ip
ip
ip
ip
route-map
route-map
route-map
route-map
rm_1
rm_1
rm_1
rm_1
sequence-number
sequence-number
sequence-number
sequence-number
10
10
10
10
action permit
match tag 5
match tag 8
match ipv4-interface to-finance
Configuring Access Lists
An IP access list provides a convenient way to add multiple IPv4 or IPv6 addresses to a route map. Using
an access list avoids having to enter a separate route map statement for each individual IP address. Instead,
a single statement is used that specifies the access list name. The route map is then applied to all the
addresses contained within the access list.
Configuring an IP access list involves two steps: creating the access list and adding IP addresses to the list.
To create an IP access list, use the ip access-list command (IPv4) or the ipv6 access-list command (IPv6)
and specify a name to associate with the list. For example,
-> ip access-list ipaddr
-> ipv6 access-list ip6addr
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 15-23
Configuring IP
IP Configuration
To add addresses to an access list, use the ip access-list address (IPv4) or the ipv6 access-list address
(IPv6) command. For example, the following commands add addresses to an existing access list:
-> ip access-list ipaddr address 10.0.0.0/8
-> ipv6 access-list ip6addr address 2001::/64
Use the same access list name each time the above commands are used to add additional addresses to the
same access list. In addition, both commands provide the ability to configure if an address and/or its
matching subnet routes are permitted (the default) or denied redistribution. For example:
-> ip access-list ipaddr address 16.24.2.1/16 action deny redist-control allsubnets
-> ipv6 access-list ip6addr address 2001::1/64 action permit redist-control nosubnets
For more information about configuring access list commands, see the “IP Commands” chapter in the
OmniSwitch AOS Release 8 CLI Reference Guide.
Configuring Route Map Redistribution
The ip redist command is used to configure the redistribution of routes from a source protocol into the
destination protocol. This command is used on the IPv4 router that performs the redistribution.
A source protocol is a protocol from which the routes are learned. A destination protocol is the one into
which the routes are redistributed. Ensure that both protocols are loaded and enabled before configuring
redistribution.
Redistribution applies criteria specified in a route map to routes received from the source protocol.
Therefore, configuring redistribution requires an existing route map. For example, the following command
configures the redistribution of OSPF routes into a BGP network using the ospf-to-bgp route map:
-> ip redist ospf into bgp route-map ospf-to-bgp
OSPF routes received by the router interface are processed based on the contents of the ospf-to-bgp route
map. Routes that match criteria specified in this route map are either allowed or denied redistribution into
the BGP network. The route map can also specify the modification of route information before the route is
redistributed. See “Using Route Maps” on page 15-20 for more information.
To remove a route map redistribution configuration, use the no form of the ip redist command. For
example:
-> no ip redist ospf into bgp route-map ospf-to-bgp
Use the show ip redist command to verify the redistribution configuration:
-> show ip redist
Source
Destination
Protocol
Protocol
Status
Route Map
------------+------------+---------+-------------------LOCAL4
RIP
Enabled
rip_1
LOCAL4
OSPF
Enabled
ospf_2
LOCAL4
BGP
Enabled
bgp_3
RIP
OSPF
Enabled
ospf-to-bgp
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 15-24
Configuring IP
IP Configuration
Configuring the Administrative Status of the Route Map Redistribution
The administrative status of a route map redistribution configuration is enabled by default. To change the
administrative status, use the status parameter with the ip redist command. For example, the following
command disables the redistribution administrative status for the specified route map:
-> ip redist ospf into bgp route-map ospf-to-bgp status disable
The following command example enables the administrative status:
-> ip redist ospf into bgp route-map ospf-to-bgp status enable
Route Map Redistribution Example
The following example configures the redistribution of OSPF routes into a BGP network using a route
map (ospf-to-bgp) to filter specific routes:
-> ip route-map ospf-to-bgp sequence-number 10 action deny
-> ip route-map ospf-to-bgp sequence-number 10 match tag 5
-> ip route-map ospf-to-bgp sequence-number 10 match route-type external type2
-> ip route-map ospf-to-bgp sequence-number 20 action permit
-> ip route-map ospf-to-bgp sequence-number 20 match ipv4-interface intf_ospf
-> ip route-map ospf-to-bgp sequence-number 20 set metric 255
-> ip route-map ospf-to-bgp sequence-number 30 action permit
-> ip route-map ospf-to-bgp sequence-number 30 set tag 8
-> ip redist ospf into bgp route-map ospf-to-bgp
The resulting ospf-to-bgp route map redistribution configuration does the following
• Denies the redistribution of Type 2 external OSPF routes with a tag set to five.
• Redistributes into BGP all routes learned on the intf_ospf interface and sets the metric for such routes
to 255.
• Redistributes into BGP all other routes that are not processed by sequence 10 or 20, and sets the tag for
such routes to eight.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 15-25
Configuring IP
IP Configuration
IP-Directed Broadcasts
An IP directed broadcast is an IP datagram that has all zeros or all 1 in the host portion of the destination
IP address. The packet is sent to the broadcast address of a subnet to which the sender is not directly
attached. Directed broadcasts are used in denial-of-service attacks. In a denial-of-service attack, a
continuous stream of ping requests is sent from a falsified source address to a directed broadcast address,
resulting in a large stream of replies, which can overload the host of the source address. By default, the
switch drops directed broadcasts. Directed broadcasts must not be enabled.
Use the ip directed-broadcast command to enable or disable IP-directed broadcasts. For example:
-> ip directed-broadcast enable
Use the show ip config command to display the IP-directed broadcast state.
Denial of Service (DoS) Filtering
By default, the switch filters denial of service (DoS) attacks, which are security attacks aimed at devices
that are available on a private network or the Internet. Some attacks aim at system bugs or vulnerability,
while other types of attacks involve generating large volumes of traffic so that network service is denied to
legitimate network users. These attacks include the following:
• ICMP Ping of Death—Ping packets that exceed the largest IP datagram size (65535 bytes) are sent to a
host and crash the system.
• Land Attack—Spoofed packets are sent with the SYN flag set to a host on any open port that is
listening. The machine can crash or reboot in an attempt to respond.
• ARP Flood Attack—Floods a switch with a large number of ARP requests, resulting in the switch
using a large amount of the CPU time to respond to these requests. If the number of ARP requests
exceeds the preset value of 500 per second, an attack is detected.
• Invalid IP Attack—Packets with invalid source or destination IP addresses are received by the switch.
When such an Invalid-IP attack is detected, the packets are dropped, and SNMP traps are generated.
Following are few examples of invalid source and destination IP addresses:
Invalid Source IP address
• 0.x.x.x.
• 255.255.255.255.
• subnet broadcast, that is, 172.28.255.255, for an
existing IP interface 172.28.0.0/16.
• in the range 224.x.x.x - 255.255.255.254.
• Source IP address equals one of Switch IP
Interface addresses.
Invalid Destination IP
address
• 127.x.x.x.
• in the range 240.x.x.x - 255.255.255.254.
• 0.0.0.0 (valid exceptions- certain DHCP packets).
• 172.28.0.0 for a router network 172.28.4.11/16.
• 0.x.x.x.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 15-26
Configuring IP
IP Configuration
• Multicast IP and MAC Address Mismatch—This attack is detected when:
– the source MAC address of a packet received by a switch is a Multicast MAC address.
– the destination IP and MAC addresses of a packet received by a switch is same as the Multicast IP
and MAC addresses, but the Multicast IP and the Multicast MAC addresses do not match.
Note. In both the conditions described above in “Multicast IP and MAC Address Mismatch”, packets are
dropped and SNMP traps are generated.
– the destination IP is a unicast IP and the destination MAC address is either a Broadcast or Multicast
address. In such a condition, an event is recorded in the DoS statistics. No SNMP traps are
generated as valid packets can also fall under this category.
• Ping overload—Floods a switch with a large number of ICMP packets, resulting in the switch using a
large amount of CPU time to respond to these packets. If the number of ICMP packets exceed 100 per
second, a DoS attack is detected. By default, the detection of attack is disabled.
• Packets with loopback source IP address—Packets with an invalid source address of 127.0.0.0/8
(loopack network) are received by the switch. When such packets are detected, they are dropped, and
SNMP traps are generated.
The switch can be set to detect various types of port scans by monitoring for TCP or UDP packets sent to
open or closed ports. Monitoring is done in the following manner:
• Packet penalty values set. TCP and UDP packets destined for open or closed ports are assigned a
penalty value. Each time a packet of this type is received, its assigned penalty value is added to a
running total. This total is cumulative and includes all TCP and UDP packets destined for open or
closed ports.
• Port scan penalty value threshold. The switch is given a port scan penalty value threshold. This
number is the maximum value the running penalty total can achieve before triggering an SNMP trap.
• Decay value. A decay value is set. The running penalty total is divided by the decay value every
minute.
• Trap generation. If the total penalty value exceeds the set port scan penalty value threshold, a trap is
generated to alert the administrator that a port scan can be in progress.
For example, imagine that a switch is set so that TCP and UDP packets destined for closed ports are given
a penalty of 10, TCP packets destined for open ports are given a penalty of 5, and UDP packets destined
for open ports are given a penalty of 20. The decay is set to 2, and the switch port scan penalty value
threshold is set to 2000:
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 15-27
Configuring IP
IP Configuration
.
DoS Settings
UDP/TCP closed = 10
UDP open = 20
TCP open = 5
Threshold = 2000
Decay = 2
Penalty Total = 0
In 1 minute, 10 TCP closed port packets and 10 UDP closed port packets are received. This brings the
total penalty value to 200, as shown using the following equation:
(10 TCP X 10 penalty) + (10 UDP X 10 penalty) = 200
This value would be divided by 2 (due to the decay) and decreased to 100. The switch would not record a
port scan:
DoS Settings
UDP/TCP closed = 10
UDP open = 20
TCP open = 5
Threshold = 2000
Decay = 2
10 TCP closed port packets
Do Not
Generate DoS
Attack Warning
Trap
10 UDP closed port packets
Minute 1 Penalty Total = 100
In the next minute, 10 more TCP and UDP closed port packets are received, along with 200 UDP open
port packets. This would bring the total penalty value to 4300, as shown using the following equation:
(100 previous minute value) + (10 TCP X 10 penalty) + (10 UDP X 10 penalty) +
(200 UDP X 20 penalty) = 4300
This value would be divided by 2 (due to decay) and decreased to 2150. The switch would record a port
scan and generate a trap to warn the administrator:
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 15-28
Configuring IP
IP Configuration
DoS Settings
UDP/TCP closed = 10
UDP open =20
TCP open = 5
Threshold = 2000
Decay = 2
10 TCP closed port packets
10 UDP closed port packets
Generate DoS
Attack Warning
Trap
100 UDP open port packets
Minute 2 Penalty Total = 2150
The above functions and how to set their values are covered in the sections that follow.
Setting Penalty Values
You can set a penalty value for the following types of traffic:
• TCP/UDP packets bound for closed ports.
• TCP traffic bound for open ports.
• UDP traffic bound for open ports.
Each type has its own command to assign a penalty value. Penalty values can be any non-negative integer.
Each time a packet is received that matches an assigned penalty, the total penalty value for the switch is
increased by the penalty value of the packet in question.
To assign a penalty value to TCP/UDP packets bound for a closed port, use the ip dos scan close-portpenalty command with a penalty value. For example, to assign a penalty value of 10 to TCP/UDP packets
destined for closed ports, enter the following:
-> ip dos scan close-port-penalty 10
To assign a penalty value to TCP packets bound for an open port, use the ip dos scan tcp open-portpenalty command with a penalty value. For example, to assign a penalty value of 10 to TCP packets
destined for opened ports, enter the following:
-> ip dos scan tcp open-port-penalty 10
To assign a penalty value to UDP packets bound for an open port, use the ip dos scan udp open-portpenalty command with a penalty value. For example, to assign a penalty value of 10 to TCP/UDP packets
destined for closed ports, enter the following:
-> ip dos scan udp open-port-penalty 10
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 15-29
Configuring IP
IP Configuration
Setting the Port Scan Penalty Value Threshold
The port scan penalty value threshold is the highest point the total penalty value for the switch can reach
before a trap is generated informing the administrator that a port scan is in progress.
To set the port scan penalty value threshold, enter the threshold value with the ip dos scan threshold
command. For example, to set the port scan penalty value threshold to 2000, enter the following:
-> ip dos scan threshold 2000
Setting the Decay Value
The decay value is the amount the total penalty value is divided by every minute. As the switch records
incoming UDP and TCP packets, it adds their assigned penalty values together to create the total penalty
value for the switch. To prevent the switch from registering a port scan from normal traffic, the decay
value is set to lower the total penalty value every minute to compensate from normal traffic flow.
To set the decay value, enter the decay value with the ip dos scan decay command. For example, to set
the decay value to 2, enter the following:
-> ip dos scan decay 2
Enabling DoS Traps
Enable the DoS traps for the switch to warn the administrator that a port scan can be in progress when the
total penalty value of the switch crosses the port scan penalty value threshold.
To enable SNMP trap generation, enter the ip dos trap command, as shown:
-> ip dos trap enable
To disable DoS traps, enter the same ip dos trap command, as shown:
-> ip dos trap disable
ARP Poisoning
ARP Poisoning allows an attacker to sniff and tamper the data frames on a network. It also modifies or
halts the traffic. The principle of ARP Poisoning is to send false or spoofed ARP messages to an Ethernet
LAN.
The OmniSwitch introduces the functionality that detects the presence of an ARP poisoning host on a
network. This functionality uses a configured restricted IP addresses, so that the switch does not get ARP
response on sending an ARP request. If an ARP response is received, then an event is logged and the user
is alerted using an SNMP trap.
Use the ip dos arp-poison restricted-address command to add an ARP Poison restricted address. Enter
the command, followed by the IP address. For example, to add an ARP Poison restricted address as
192.168.1.1, you would enter:
-> ip dos arp-poison restricted-address 192.168.1.1
To delete an ARP Poison restricted address, enter no ip dos arp-poison restricted-address followed by
the IP address. For example:
-> no ip dos arp-poison restricted-address 192.168.1.1
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 15-30
Configuring IP
IP Configuration
To verify the number of attacks detected for configured ARP poison restricted addresses, use the show ip
dos arp-poison command. For more information about this command, see the OmniSwitch AOS Release 8
CLI Reference Guide.
Enabling/Disabling IP Services
When a switch initially boots up, all supported TCP/UDP well-known service ports are enabled (open).
Although these ports provide access for essential switch management services, such as telnet, FTP,
SNMP, they also are vulnerable to DoS attacks. It is possible to scan open service ports and launch such
attacks based on well-known port information.
The ip service command allows you to disable (close) TCP/UDP well-known service ports selectively and
enable them when necessary. This command only operates on TCP/UDP ports that are opened by default.
It has no impact on ports that are opened by loading applications, such as RIP and BGP.
In addition, the ip service command allows you to designate which service to enable or disable by
specifying the name of a service as well as changing the well-known port number associated with that
service. For example, the following commands disable the telnet service, change the port and re-enable the
service:
-> ip service telnet admin-state disable
-> ip service telnet port 20999
-> ip service telnet admin-state enable
Use default parameter to revert the port number of a service to the default port number.
-> ip service telnet port default
The following table lists ip service command options for specifying TCP/UDP services and also includes
the well-known port number associated with each service:
service
port
ftp
21
ssh
22
telnet
23
http
80
https
443
network-time
123
snmp
161
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 15-31
Configuring IP
Managing IP
Managing IP
The following sections describe IP commands that can be used to monitor and troubleshoot IP forwarding
on the switch.
Internet Control Message Protocol (ICMP)
Internet Control Message Protocol (ICMP) is a network layer protocol within the IP protocol suite that
provides message packets to report errors and other IP packet processing information back to the source.
ICMP generates various kinds of useful messages, including Destination Unreachable, Echo Request and
Reply, Redirect, Time Exceeded, and Router Advertisement and Solicitation. If an ICMP message cannot
be delivered, a second one is not generated thus preventing an endless flood of ICMP messages.
When an ICMP destination-unreachable message is sent by a switch, it means that the switch is unable to
send the package to its final destination. The switch then discards the original packet. There are two
reasons why a destination is not reachable. Most commonly, the source host has specified a non-existent
address. Less frequently, the switch does not have a route to the destination. The destination-unreachable
messages include four basic types:
• Network-Unreachable Message—Usually means that a failure has occurred in the route lookup of the
destination IP in the packet.
• Host-Unreachable Message—Usually indicates delivery failure, such as an unresolved client's
hardware address or an incorrect subnet mask.
• Protocol-Unreachable Message—Usually means that the destination does not support the upper-layer
protocol specified in the packet.
• Port-Unreachable Message—Implies that the TCP/UDP socket or port is not available.
Additional ICMP messages include:
• Echo-Request Message—Generated by the ping command, the message is sent by any host to test node
reachability across an internetwork. The ICMP echo-reply message indicates that the node can be
successfully reached.
• Redirect Message—Sent by the switch to the source host to stimulate more efficient routing. The
switch still forwards the original packet to the destination. ICMP redirect messages allow host routing
tables to remain small because it is necessary to know the address of only one switch, even if that
switch does not provide the best path. Even after receiving an ICMP redirect message, few devices
continue using the less-efficient route.
• Time-Exceeded Message—Sent by the switch if an IP packet’s TTL field reaches zero. If the
internetwork contains a routing loop, the TTL field prevents packets from continuously circulating the
internetwork. Once a packet TTL field reaches 0, the switch discards the packet.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 15-32
Configuring IP
Managing IP
Activating ICMP Control Messages
ICMP messages are identified by a type and a code. This number pair specifies an ICMP message. For
example, ICMP type 4, code 0, specifies the source quench ICMP message.
To enable or disable an ICMP message, use the icmp type command with the type and code. For example,
to enable the source quench the ICMP message (type 4, code 0) enter the following:
-> icmp type 4 code 0 enable
To list the ICMP message information use the show icmp control command.
In addition to the icmp type command, many commonly used ICMP messages have separate CLI
commands for convenience. The following table lists the ICMP message name, type, and code:
ICMP Message
Command
Network unreachable (type 0, code 3)
icmp unreachable
Host unreachable (type 3, code 1)
icmp unreachable
Protocol unreachable (type 3, code 2)
icmp unreachable
Port unreachable (type 3, code 3)
icmp unreachable
Echo reply (type 0, code 0)
icmp echo
Echo request (type 8, code 0)
icmp echo
Timestamp request (type 13, code 0)
icmp timestamp
Timestamp reply (type 14, code 0)
icmp timestamp
Address Mask request (type 17, code 0)
icmp addr-mask
Address Mask reply (type 18, code 0)
icmp addr-mask
These commands are entered as the icmp type command, only without specifying a type or code. The
echo, timestamp, and address mask commands have options for distinguishing between a request or a
reply, and the unreachable command has options distinguishing between a network, host, protocol, or port.
For example, to enable an echo request message, enter the following:
-> icmp echo request enable
To enable a network unreachable message, enter the following:
-> icmp unreachable net-unreachable enable
Note. Enabling host-unreachable and net-unreachable messages are not recommended as it can cause the
switch instability due to high-CPU conditions depending upon the volume of traffic required by these
messages.
See Chapter 19, “IP Commands,” for specifics on the ICMP message commands.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 15-33
Configuring IP
Managing IP
Enabling All ICMP Types
To enable all ICMP message types, use the icmp messages command with the enable keyword. For
example:
-> icmp messages enable
To disable all ICMP messages, enter the same command with the disable keyword. For example:
-> icmp messages enable
Setting the Minimum Packet Gap
The minimum packet gap is the time required between sending messages of a like type. For instance, if the
minimum packet gap for Address Mask request messages is 40 microseconds, and an Address Mask
message is sent, at least 40 microseconds must pass before another one could be sent.
To set the minimum packet gap, use the min-pkt-gap keyword with any of the ICMP control commands.
For example, to set the Source Quench minimum packet gap to 100 microseconds, enter the following:
-> icmp type 4 code 0 min-pkt-gap 100
Likewise, to set the Timestamp Reply minimum packet gap to 100 microseconds, enter the following:
-> icmp timestamp reply min-pkt-gap 100
ICMP Control Table
The ICMP Control Table displays the ICMP control messages, whether they are enabled or disabled, and
the minimum packet gap times. Use the show icmp control command to display the table.
ICMP Statistics Table
The ICMP Statistics Table displays the ICMP statistics and errors. This data can be used to monitor and
troubleshoot IP on the switch. Use the show icmp statistics command to display the table.
Using the Ping Command
The ping command is used to test whether an IP destination can be reached from the local switch. This
command sends an ICMP echo request to a destination and then waits for a reply. To ping a destination,
enter the ping command and enter either the IP address of the destination or the host name. The switch
pings the destination by using the default frame count, packet size, interval, and time-out parameters (6
frames, 64 bytes, 1 second, and 5 seconds, respectively). For example:
-> ping 172.22.2.115
When you ping a device, the device IP address or host name is required. Optionally, you can also specify:
• Count. Use the count keyword to set the number of frames to be transmitted.
• Size. Use the size keyword to set the size, in bytes, of the data portion of the packet sent for this ping.
You can specify a size or a range of sizes up to 60000.
• Interval. Use the interval keyword to set the frequency, in seconds, that the switch polls the host.
• Time-out. Use the time-out keyword to set the number of seconds the program waits for a response
before timing out.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 15-34
Configuring IP
Managing IP
• source-interface. Use the source-interface keyword to set the IP address to be used as source IP for
the ping packets.
• data-pattern. Use the data-pattern keyword to set the data pattern to be used in the data field of the
ping packets.
• dont-fragment. Use the dont-fragment keyword to set the don't-fragment bit in the IP packet.
• tos. Use the tos keyword to set the type of service field in the IP header.
For example, to send a ping with a count of 2, a size of 32 bytes, an interval of 2 seconds, time-out of 10
seconds, a source-interface using mgmt, tos of 1, data-pattern of AB and dont-fragment you would enter:
-> ping 172.22.2.115 count 2 size 32 interval 2 timeout 10 source-interface mgmt
tos 1 data-pattern AB dont-fragment
Note. If you change the default values, they only apply to the current ping. The next time you use the ping
command, the default values are used unless you enter different values again.
Tracing an IP Route
The traceroute command is used to find the path taken by an IP packet from the local switch to a
specified destination. This command displays the individual hops to the destination as well as timing
information. When using this command, enter the name of the destination as part of the command line
(either the IP address or host name). Use the optional max-hop parameter to set a maximum hop count to
the destination. If the trace reaches this maximum hop count without reaching the destination, the trace
stops.
For example, to perform a traceroute to a device with an IP address of 172.22.2.115 with a maximum hop
count of 10 you would enter:
-> traceroute 172.22.2.115 max-hop 10
Optionally, you can also specify:
• min-hop. Use the min-hop keyword to set the minimum number of hops for the first packet.
• source-interface. Use the source-interface keyword to set the source IP interface to be used in the
traceroute packets.
• probes. Use the probes keyword to set the number of packets (retry) to be sent for each hop-count.
• timeout. Use the timeout keyword to set the time to wait for the response of each probe packet.
• port. Use the port keyword to set the destination port number to be used in the probing packets.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 15-35
Configuring IP
Tunneling
Transmission Control Protocol (TCP)
TCP Half-open Timeout Configuration
Use the ip tcp half-open-timeout command to configure the timeout periods for dropping half-open TCP
connections.
Current supported values are 3, 7, 15, 31 and 63 (in seconds). The default value is 63 seconds.
-> ip tcp half-open-timeout 7
The show ip tcp half-open-timeout displays the timeout value configured for half-open TCP sessions.
Displaying TCP Information
Use the show tcp statistics command to display TCP statistics. Use the show tcp ports command to
display TCP port information.
Displaying UDP Information
UDP is a secondary transport-layer protocol that uses IP for delivery. UDP is not connection-oriented and
does not provide reliable end-to-end delivery of datagrams. Few applications can safely use UDP to send
datagrams that do not require the extra overhead added by TCP. Use the show udp statistics command to
display UDP statistics. Use the show udp ports command to display UDP port information.
Tunneling
Tunneling is a mechanism that can encapsulate a wide variety of protocol packet types and route them
through the configured tunnels. Tunneling is used to create a virtual point-to-point link between routers at
remote points in a network. This feature supports the creation, administration, and deletion of IP interfaces
whose underlying virtual device is a tunnel. The OmniSwitch implementation provides support for two
tunneling protocols: Generic Routing Encapsulation (GRE) and IP encapsulation within IP(IPIP).
Generic Routing Encapsulation
GRE encapsulates a packet to be carried over the GRE tunnel with a GRE header. The resulting packet is
then encapsulated with an outer header by the delivery protocol and forwarded to the other end of the GRE
tunnel. The destination IP address field in the outer header of the GRE packet contains the IP address of
the router at the remote end of the tunnel. The router at the receiving end of the GRE tunnel extracts the
original payload and routes it to the destination address specified in the IP header of the payload.
Note. A switch can support up to 127 GRE tunnel interfaces.
IP Encapsulation within IP
IPIP tunneling is a method by which an IP packet is encapsulated within another IP packet. The Source
Address and Destination Address of the outer IP header identifies the endpoints of tunnel. Whereas Source
Address and Destination Address of the inner IP header identifies the original sender and recipient of the
packet, respectively.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 15-36
Configuring IP
Tunneling
Consider the following when configuring the IPIP tunnel interfaces:
• A switch can support up to 127 IPIP tunnel interfaces.
• IPIP tunnel interfaces are included in the maximum number of IP interfaces that are supported on the
switch.
Tunneling Operation
The following diagram illustrates how packets are forwarded over the tunnel.
Private IP Network
40.0.0.0
Private IP Network
50.0.0.0
IP Host
50.0.0.1
IP Host
Switch A
Switch B
24.24.24.1
24.24.24.2
Tunnel Endpoint
155.2.2.2
Tunnel Endpoint
23.23.23.1
IP Host
IP Host
40.0.0.1
Outer IP Header : 23.23.23.1, 155.2.2.2
Inner IP Header : 50.0.0.1, 40.0.0.1
In the given diagram, IP packets flowing from the private IP network 50.0.0.0 to the private IP network
40.0.0.0 are encapsulated by the tunneling protocol at switch A and forwarded to switch B. Intermediate
switches route the packets using addresses in the delivery protocol header. Switch B extracts the original
payload and routes it to the appropriate destination in the 40.0.0.0 network.
The tunnel interface is identified as being up when all of the following are satisfied:
• Both source and destination addresses are assigned.
• The source address of the tunnel is one of the switch's IP interface addresses that is either a VLAN or
Loopback0 interface.
• A route is available to reach the destination IP address. A route whose egress interface is a VLAN-
based interface is available for its destination IP address. The switch supports assigning an IP address
as well as routes to a tunnel interface.
This section describes how to configure a tunnel interface using GRE and IPIP, using Command Line
Interface (CLI) commands.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 15-37
Configuring IP
Tunneling
Configuring a Tunnel Interface
To configure a GRE tunnel, use the ip interface tunnel command as shown:
-> ip interface "gre" tunnel source 23.23.23.1 destination 155.2.2.2 protocol gre
In this example, the GRE tunnel named “gre” is created and assigned a source IP address of 23.23.23.1
and a destination IP address of 155.2.2.2.
You can configure an IP address for the GRE tunnel interface using the ip interface command as shown:
-> ip interface "gre" address 24.24.24.1 mask 255.255.255.0
To configure an IPIP tunnel, use the ip interface tunnel command as shown:
-> ip interface "ipip" tunnel source 23.23.23.1 destination 155.2.2.2 protocol
ipip
In this example, the IPIP tunnel named “ipip” is created and assigned a source IP address of 23.23.23.1
and a destination IP address of 155.2.2.2.
You can configure an IP address for the IPIP tunnel interface using the ip interface command as shown:
-> ip interface "ipip" address 24.24.24.1 mask 255.255.255.0
Notes.
• An interface can be configured only as a VLAN or a Tunnel interface.
• To display information about the configured tunnels on the switch, use the show ip interface
command.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 15-38
Configuring IP
Verifying the IP Configuration
Verifying the IP Configuration
A summary of the show commands used for verifying the IP configuration is given here:
show ip interface
Displays the usability status of interfaces configured for IP.
show ip routes
Displays the IP Forwarding table.
show ip route-pref
Displays the configured route preference of a router.
show ip router database
Displays a list of all routes (static and dynamic) that exist in the IP
router database.
show ip config
Displays IP configuration parameters.
show ip protocols
Displays switch routing protocol information and status.
show ip router-id
Displays the status of TCP/UDP service ports. Includes service name
and well-known port number.
show arp
Displays the ARP table.
show ip arp utilization
Displays the ARP filter configuration for the switch.
show icmp control
This command allows the viewing of the ICMP control settings.
show ip dos config
Displays the configuration parameters of the DoS scan for the switch.
show ip dos statistics
Displays the statistics on detected port scans for the switch.
show ip dos arp-poison
Displays the number of attacks detected for a restricted address.
For more information about the displays that result from these commands, see the OmniSwitch AOS
Release 8 CLI Reference Guide.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 15-39
Configuring IP
VRF Route Leak
VRF Route Leak
VRF provides isolation of routing instances from each other. The basic principle of VRF is to exclude two
or more routing domains mutually by containing the exchange of routing information and forwarding
packets within the same routing instance. VRF provides independent routing instances logically separating
Layer3 topology of unrelated entities sharing a single physical infrastructure.
However, network devices in one VRF might need to access selected network devices in another VRF,
such as in the following scenarios:
• In an enterprise, various departments can be isolated within individual VRFs but users in all the VRFs
need access to the Mail Server/common enterprise portal.
• Users in other VRFs need Internet access that is available in only one VRF.
• Buildings where multiple companies sharing the same router reside within individual VRFs have to
access common services like logistics, common network equipment that is a part of an independent
VRF.
VRF Route Leak feature can be used to forward routes from one VRF routing table to another VRF
routing table, allowing routing from one VRF to a gateway in another VRF.
Quick Steps for Configuring VRF Route Leak
The following steps provide a quick tutorial on how to configure VRF Route Leak. Each step describes a
specific operation and provides the CLI command syntax for performing that operation.
1 Create a route map to use as a filter for exporting or importing routes.
-> ip route-map R1 action permit
2 Define protocol preference for export policy route map using the ip route-map match protocol
command. This route map controls the export of routes from the VRF FDB (Forwarding Routing
Database) to the GRT (Global Routing Table). A route map with no specific match clause matches all
FDB routes. For example,
-> ip route-map R1 match protocol static
3 Export routes from the source VRF to the GRT using the ip export command. For example,
-> ip export route-map R1
4 Define protocol preference for import policy route map using the ip route-map match protocol
command. This route map controls the import of routes from the GRT. For example,
-> ip route-map R2 action permit
5 Import the leaked routes from the GRT using the ip import command. For example,
-> ip import vrf V1 import route-map R2
6 Configure route preference for imported routes using the ip route-pref command with the import
parameter. For example,
-> ip route-pref import 100
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 15-40
Configuring IP
VRF Route Leak
7 Redistribute imported routes to other routing protocols that are imported and added to the RDB from
other VRFs using the ip redist command. For example,
-> ip redist import into ospf route-map R3 status enable
Configuring VRF Route Leak
This section describes how to configure VRF Route Leak using the CLI commands.
Export Routes to the GRT
Export routes from the source VRF to the Global Routing Table (GRT). Use route map to filter routes.
Only those FDB (Forwarding Routing Database) routes that match the conditions of the route map are
exported to GRT.
If VRF is not configured, the routes are exported from the default VRF to GRT. Only one-route map can
be configured as export policy in a VRF. Route leaking between VRFs only supports IPv4 routes.
To export routes from the default VRF, enter the ip export command at the CLI prompt as shown:
-> ip export route-map R1
To export routes from a specific VRF, specify the VRF globally or enter into the specific VRF instance
and enter ip export command:
-> vrf vrf2 ip export route-map R1
-> vrf vrf1
vrf1::-> ip export route-map R1
Note. As a pre-requisite to export routes, create a route map and define protocol preference for the route
map by using the ip route-map commands. A route map configured for an export policy can contain any of
the following filter and set options:
• Filter options: ip-address, ip-next-hop, tag, protocol, ipv4-interface, metric, route-type
• Set option: tag, metric
If the tag or metric set option is not used in the export route map, the existing tag or metric value associated
with the route is passed through unchanged. For example, a route tag is passed to the GRT unchanged
unless the value is reset by a tag set clause in the export route map.
For route map configuration and match extensions, see “Using Route Maps” on page 15-20.
To disable exporting of routes from the VRF to the GRT, use the no form of this command as shown:
-> no ip export R1
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 15-41
Configuring IP
VRF Route Leak
Import Routes from the GRT
Import routes from GRT to the destination VRF. Use route map to filter imported routes. Only one route
map can be configured for an import policy for each export VRF.
Note. As a pre-requisite to import routes, create a route map and define protocol preference for the route
map by using ip route-map commands. A route map configured for the import policy can contain any of
the following filter and set options:
• Filter options: ip-address, ip-next-hop, tag, metric
• Set option: tag, metric
For route map configuration and match extensions, “Using Route Maps” on page 15-20.
To import routes from the GRT to the destination VRF, enter the ip import command at the CLI prompt
as shown:
-> ip import vrf V1 route-map R2
To disable importing of routes from the GRT, use the no form of this command as shown:
-> no ip import VRF V1
Configure Route Preference for Imported Routes
To configure the route preference for the routes that are imported and added to the RDB from other VRFs,
use the ip route-pref command with the import parameter. For example,
-> ip route-pref import 100
Leaked routes are only for forwarding. If a local route is leaked, that interface is not accessible in the
importing VRF. Another switch will not be able to ping the interface in the import VRF.
Redistribute Imported Routes
To enable redistribution of imported routes that are imported and added to the RDB from other VRFs into
routing protocols in the routing instance, use the ip redist command. For example,
-> ip redist import into ospf route-map R3 status enable
Verifying VRF Route Leak Configuration
A summary of the commands used for verifying the VRF Route Leak configuration is given here:
show ip export
Displays the export route configuration details.
show ip import
Displays the import route configuration details.
show ip global-route-table
Displays the GRT for all the routes that are exported from the VRFs.
The imported routes are also displayed under the protocol field as IMPORT in the show ip routes, show
ip route-pref, show ip redist, and show ip router database commands.
For more information about the output details that result from the show commands, see the OmniSwitch
AOS Release 8 CLI Reference Guide.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 15-42
16
Configuring Multiple VRF
Multiple Virtual Routing and Forwarding (VRF) provides a mechanism for segmenting Layer 3 traffic into
virtual routing domains (instances) on the same switch. Each routing instance independently maintains its
own routing and forwarding table, peer, and interface information.
In This Chapter
This chapter describes the Multiple VRF feature and how to configure it through the Command Line
Interface (CLI). CLI commands are used in the configuration examples; for more details about the syntax
of commands, see the OmniSwitch AOS Release 8 CLI Reference Guide. This chapter provides an
overview of Multiple VRF and includes the following information:
• “VRF Defaults” on page 16-2.
• “Quick Steps for Configuring Multiple VRF” on page 16-3.
• “Multiple VRF Overview” on page 16-6.
• “VRF Interaction With Other Features” on page 16-11.
• “Configuring VRF Instances” on page 16-15.
• “Verifying the VRF Configuration” on page 16-18.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 16-1
Configuring Multiple VRF
VRF Defaults
VRF Defaults
Parameter Description
Command
Default Value/Comments
Active VRF instance
vrf
Default VRF instance with
max profile capabilities
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 16-2
Configuring Multiple VRF
Quick Steps for Configuring Multiple VRF
Quick Steps for Configuring Multiple VRF
The initial configuration for an OmniSwitch consists of a default VRF instance. This instance is always
available and is not removable. The following procedure provides a quick tutorial for creating two
additional VRF instances and configuring IPv4 protocols to run in each instance:
Note. Configuring a VRF instance name is case sensitive. In addition, if the name specified does not exist,
a VRF instance is automatically created. As a result, it is possible to accidentally create or delete instances.
Use the show vrf command to verify the VRF instance configuration before selecting, adding, or removing
instances.
1 Create VRF instance, IpOne, using the vrf command. For example:
-> vrf IpOne
IpOne::->
In this example, the change in the command prompt from “->” to “IpOne: ->” indicates that the
instance was created and is now the active VRF CLI context. Any commands entered at this point
apply to this instance, unless the commands entered are not supported in multiple VRF instances.
2 Create a second VRF instance, IpTwo, using the vrf command. For example:
IpOne::-> vrf IpTwo
IpTwo::->
In this example, IpOne was the active instance until IpTwo was created and replaced IpOne as the
active VRF CLI context.
3 Select IpOne for the active VRF instance and create an IP router interface on VLAN 100 and VLAN
101 using the ip interface command. For example:
IpTwo::-> vrf IpOne
IpOne::-> ip interface intf100 address 100.1.1.1/24 vlan 100
IpOne::-> ip interface intf101 address 101.1.1.1/24 vlan 101
IpOne::->
4 Configure 1.1.1.1 as the primary router ID address for the IpOne VRF instance using the ip router
router-id command. For example:
IpOne::-> ip router router-id 1.1.1.1
IpOne::->
5 Create an IP static route for the IpOne VRF instance using the ip static-route command. For example:
IpOne::-> ip static-route 192.100.1.1/24 gateway 100.1.1.10
IpOne::->
6 Load and enable the RIP protocol for the IpOne VRF instance using the ip load rip and ip rip adminstate commands. For example:
IpOne::-> ip load rip
IpOne::-> ip rip admin-state enable
IpOne::->
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 16-3
Configuring Multiple VRF
Quick Steps for Configuring Multiple VRF
7 Enable RIP on IP interface “intf100” in the IpOne VRF instance using the ip rip interface adminstate command. For example:
IpOne::-> ip rip interface intf100 admin-state enable
IpOne::->
8 Select IpTwo for the active VRF instance and create an IP router interface on VLAN 102 using the ip
interface command. For example:
IpOne::-> vrf IpTwo
IpTwo::-> ip interface intf102 address 102.1.1.1/24 vlan 102
IpTwo::->
9 Configure 2.2.2.2 as the primary router ID address for the IpTwo VRF instance using the ip router
router-id command. For example:
IpTwo::-> ip router router-id 2.2.2.2
IpTwo::->
10 Load and enable the BGP protocol for the IpTwo VRF instance using the ip load bgp command. For
example:
IpTwo::-> ip load bgp
IpTwo::->
11 Configure a BGP neighbor for the IpTwo VRF instance using the ip bgp neighbor, ip bgp neighbor
remote-as, and ip bgp neighbor admin-state commands. For example:
IpTwo::-> ip bgp neighbor 102.1.1.10
IpTwo::-> ip bgp neighbor 102.1.1.10 remote-as 1000
IpTwo::-> ip bgp neighbor 102.1.1.10 status enable
12 Optional. To configure a VRF instance as a low profile VRF (restricted routing protocols and
capabilities) use the vrf command with the profile low parameter option. For example:
IpTwo::-> vrf IpThree profile low
IpThree::->
By default, a VRF instance is created using max profile capabilities. Low profile VRFs use less switch
resources, which allows more VRF instances to operate on the switch.
Note. Verify the Multiple VRF configuration using the show vrf command:
IpOne::-> show vrf
Virtual Routers
Profile Protocols
--------------------+-------+------------------default
default BGP PIM VRRP
IpOne
max
RIP
IpTwo
max
BGP
IpThree
low
Total Number of Virtual Routers: 4
To verify the configuration of a protocol within a VRF instance, use the show commands related to that
protocol. For example, the show ip interface command displays the IP interfaces associated with the
current CLI VRF context:
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 16-4
Configuring Multiple VRF
Quick Steps for Configuring Multiple VRF
-> vrf IpOne
IpOne: -> show ip interface
Total 1 interfaces
Name
IP Address
Subnet Mask
Status Forward Device
--------------------+---------------+---------------+------+-------+-------intfone
200.1.1.1
255.255.255.0 DOWN
NO
vlan 200
See the OmniSwitch AOS Release 8 CLI Reference Guide for information about the fields in the above
displays.
An example of what the Quick Steps configuration commands look like when entered sequentially on the
switch:
-> vlan 100
-> vlan 101
-> vlan 102
-> vrf IpOne
IpOne::-> vrf IpTwo
IpTwo::-> vrf IpOne
IpOne::-> ip interface intf100 address 100.1.1.1/24 vlan 100
IpOne::-> ip interface intf101 address 101.1.1.1/24 vlan 101
IpOne::-> ip router router-id 1.1.1.1
IpOne::-> ip static-route 192.100.1.1/24 gateway 100.1.1.10
IpOne::-> ip load rip
IpOne::-> ip rip admin-state enable
IpOne::-> ip rip interface intf100 admin-state enable
IpOne::-> vrf IpTwo
IpTwo::-> ip interface intf102 address 102.1.1.1/24 vlan 102
IpTwo::-> ip router router-id 2.2.2.2
IpTwo::-> ip load bgp
IpTwo::-> ip bgp neighbor 102.1.1.10
IpTwo::-> ip bgp neighbor 102.1.1.10 remote-as 1000
IpTwo::-> ip bgp neighbor 102.1.1.10 admin-state enable
IpTwo::-> vrf IpThree profile low
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 16-5
Configuring Multiple VRF
Multiple VRF Overview
Multiple VRF Overview
The Multiple Virtual Routing and Forwarding (VRF) feature provides the ability to configure separate
routing instances on the same switch. Similar to using VLANs to segment Layer 2 traffic, VRF instances
are used to segment Layer 3 traffic.
Some of the benefits of using the Multiple VRF feature include the following:
• Multiple routing instances within the same physical switch. Each VRF instance is associated with a set
of IP interfaces and creates and maintains independent routing tables. Traffic between IP interfaces is
only routed and forwarded to those interfaces that belong to the same VRF instance.
• Multiple instances of IP routing protocols, such as static, RIP, IPv4, BGPv4, and OSPFv2 on the same
physical switch. An instance of each type of protocol operates within its own VRF instance.
• The ability to use duplicate IP addresses across VRF instances. Each VRF instance maintains its own
IP address space to avoid any conflict with the service provider network or other customer networks.
• Separate IP routing domains for customer networks. VRF instances configured on the Provider Edge
(PE) are used to isolate and carry customer traffic through the shared provider network.
This implementation of VRF functionality does not require a BGP/MPLS configuration in the provider
network. Instead, VRF instances can route and forward IP traffic between customer sites using point-topoint Layer 3 protocols, such as IP-IP or GRE tunneling.
The illustration on page 16-7 shows an example of how the Multiple VRF feature is used to provide
independent routing domains that isolate and carry customer traffic through the provider network. In this
example:
• Each PE switch maintains more than one routing and forwarding table, in addition to the default VRF
instance table.
• One VRF instance is configured on the PE switch for each customer network to which the PE is
connected.
• Each interface on the PE that is connected to a customer edge (CE) switch is associated with the VRF
instance configured for that customer.
• When an IP packet for Customer A is received on a PE 1 or PE 2 interface associated with VRF A, the
VRF A instance determines how to route the packet through the provider backbone so that it reaches
the intended Customer A destination.
• When an IP packet for Customer B is received on a PE 1, PE 2, or PE 3 interface associated with VRF
B, the VRF B instance determines how to route the packet through the provider backbone so that it
reaches the intended Customer B destination.
• When an IP packet for Customer C is received on a PE 1 or PE 3 interface associated with VRF C, the
VRF C instance determines how to route the packet through the provider backbone so that it reaches
the intended Customer C destination.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 16-6
Configuring Multiple VRF
Multiple VRF Overview
Customer A
Site 2
PE 2
VRF A
Customer A
Site 1
VRF A
VRF A
VRF B
Customer B
Site 2
VRF B
Customer B
Site 1
VRF B
VRF A
VRF B
Service Provider
IP Network
VRF C
Customer C
Site 1
VRF C
PE 1
Customer B
Site 3
VRF B
VRF B
VRF C
Customer C
Site 2
VRF C
PE 3
Example Multiple VRF Configuration
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 16-7
Configuring Multiple VRF
Multiple VRF Overview
VRF Profiles
The VRF feature supports two types of VRF instances: a low profile instance and a max profile instance.
The type of profile assigned to a VRF instance determines the routing protocols and capabilities supported
within that instance.
• Low profile VRFs only support IPv4 and VRRP, with routing capabilities restricted to static and
imported routes. In addition, limiting low profiles to 9 routes and 3 IP interfaces is highly
recommended.
• Max profile VRFs support full VRF routing capabilities and limits.
The type of profile applied is determined at the time the VRF instance is created. The default VRF
instance uses the max profile capabilities; configuring the default VRF profile is not allowed.
Using low profile VRFs gives an administrator the ability to create VRFs with minor routing capabilities
and complexity. Low profiles take up less switch resources than max profiles, which allows for creating
more VRFs on the switch.
The ability to create many low profile VRFs is particularly useful in cases where all traffic only flows
through a handful of individual routes to reach specific destinations; the administrator can separate many
network access points into VRFs. For example: in a building there may be many tenants that need to reach
several end stations and one or two WAN access points through a shared core network. Each private
network needs its own address space, but does not need a routing protocol to share many routes (may only
need a default route).
A combination of low and max profiles is allowed on the switch. However, the total number of VRFs
allowed on the switch may differ depending on the availability of switch resources and the number of low
and max profile VRFs configured.
Using the VRF Command Line Interface
The Multiple VRF feature uses a context-based command line interface (CLI). When the switch boots up,
the default VRF instance is automatically created and active. Any commands subsequently entered apply
to this default instance. If a different VRF instance is selected, then all subsequent commands apply to that
instance.
Note. Only those commands for features that are VRF aware are accepted within the context of a VRF
instance. Default VRF applications are supported only in the default VRF instance. For more information
about VRF supported applications, see “VRF Interaction With Other Features” on page 16-11.
The CLI command prompt indicates which instance is the active VRF context; the instance name is added
as a prefix to the command prompt. For example, if VRF instance IpOne is the current context, then IpOne
appears in the CLI command prompt. For example:
IpOne: ->
When the default VRF instance is the active context, no VRF name appears in the command prompt. For
example, the following prompt indicates that the default VRF instance is the current context:
->
It is also possible to enter configuration commands for other non-default instances from within the default
VRF CLI context. For more information about how to do this and additional examples of using the VRF
context-based CLI, see “Configuring VRF Instances” on page 16-15 and “Verifying the VRF
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 16-8
Configuring Multiple VRF
Multiple VRF Overview
Configuration” on page 16-18.
Note. All VRF instances are active in terms of routing and forwarding tasks whether or not the instance is
the current CLI context. Selecting a VRF instance as the CLI context simply indicates the instance to which
any configuration or show commands apply.
ASCII-File-Only Syntax
When configuration commands for VRF-aware applications are configured and saved in an ASCII file
(typically through the snapshot command) or the switch boot.cfg file, a prefix is added to these
commands to indicate the name of the VRF instance to which the commands apply. For example:
! VRF
vrf vrfOne
! IP
vrf vrfOne
vrf vrfOne
vrf vrfOne
vrf vrfOne
! RIP
vrf vrfOne
vrf vrfOne
vrf vrfOne
ip
ip
ip
ip
interface intf100 address 100.1.1.1/24 vlan 100
interface intf101 address 101.1.1.1/24 vlan 101
router router-id 1.1.1.1
static route 192.100.1.0/24 gateway 100.1.1.10
ip load rip
ip rip status enable
ip rip interface intf100 status enable
In this example, vrfOne is added to the beginning of the IP and RIP configuration command lines. This
indicates that these commands apply to the vrfOne instance. If a command line does not contain an
instance name, then that command is for an application that applies only to the default VRF instance or the
application is not VRF-aware.
Default VRF commands appear first in an ASCII or boot.cfg file, followed by commands for VRF-aware
applications configured in non-default instances.
Management VRF
The Management VRF feature gives the user the ability to control which VRF is used for the various
switch management protocols (Telnet, RADIUS, and so on.)
The following level of support is provided:
• Level 0 - The management service may only appear in the Default VRF.
• Level 1 - User may specify a single VRF that all management services can be configured in. For
example, both RADIUS and LDAP can use vrf-1.
• Level 2 - Each management service or multiple management services can be configured for a different
VRF. For example, RADIUS in vrf-1, LDAP in vrf-2, SNMP in vrf-3.
• Level 3 - A management service may appear in multiple VRFs. For example, SSH and Telnet in vrf-1
and vrf-2.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 16-9
Configuring Multiple VRF
Multiple VRF Overview
Level
Description
Telnet/SSH/SFTP/
SCP
Radius/SNMP/HTTP/HTTPS/
NTP/LDAP/TACACS+/Syslog
0
Default VRF Only
Yes
Yes
1
Single VRF for all services
Yes
Yes
2
Single VRF per service,
each service can be on a
different VRF
Yes
Yes
3
Multiple VRFs per service,
any service on any VRF
Yes
No
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 16-10
Configuring Multiple VRF
VRF Interaction With Other Features
VRF Interaction With Other Features
This section contains important information about how other OmniSwitch features interact with VRF
instances. Refer to the specific chapter for each feature to get more detailed information about how to
configure and use the feature.
All OmniSwitch AOS applications fall into one of the following three categories in relation to the Multiple
VRF feature:
• VRF Aware. Switch applications that are configurable independently and separately within one or
more VRF instances. All VRF aware applications can be enabled or disabled on each VRF instance.
• Default VRF. Switch applications that are VRF aware but only use the default VRF instance when IP
connectivity is needed; these applications are not supported across multiple VRF instances.
• Non-VRF Aware. Switch applications that have no association with any VRF instance, even the
default instance. Note that configuration of this type of application is only allowed when the default
instance is the active CLI context.
Refer to the following table to determine the VRF association for a specific switch application.
Applications that do not appear in this table are non-VRF aware.
VRF-Aware Applications
AAA RADIUS Server
BFD
BGPv4
DVMRP
FTP Server
GRE Tunnels
HTTP Server
IPv4/ARP
IP-IP Tunnels
IS-ISv4
LDAP Server
NTP
OSPFv2
PIM-DM (IPv4)
PIM-SM (IPv4)
Ping
QoS VRF Policies
RIPv2
Route Map Redistribution
SSH Server (SSH, SFTP,
SCP)
SNMP (Agent)
Static routes
TACACS+ Server
Telnet Server
Traceroute
UDP/DHCP Relay
DHCP Client
VRRPv2
Webview
Default VRF Applications
AAA
BGPv6
DNS Client
EMP access
FTP Client
IPv6 (NDP/Tunnel)
IS-ISv6
OSPFv3
Policy Based Routing
Router Discovery Protocol
RIPng
SFTP
SSH Client
Telnet Client
Trap Manager
VXLAN
VRRPv3
The following subsections provide additional information related to Multiple VRF interaction with
specific applications.
AAA RADIUS/TACACS+/LDAP Servers
• AAA RADIUS or TACACS+ or LDAP server can be configured on any VRF instance including the
default VRF instance. However, all of the servers (for example, all the RADIUS servers) must reside
on the same VRF instance.
• The VRF instance that the server is configured on becomes the “management” VRF instance and can
perform authentication for any of the following services:
Console
Telnet
FTP
SSH (ssh, sftp, and scp)
HTTP
SNMP
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 16-11
Configuring Multiple VRF
VRF Interaction With Other Features
• If the VRF instance that the servers (RADIUS / TACACS+ / LDAP) reside on is deleted or disabled,
access to the servers is disabled as well.
• More than one management service can use the same VRF instance. For example, both RADIUS and
and LDAP can use the same VRF instance “VrfA”.
BGPv4
• Each BGPv4 routing instance requires configuration of an Autonomous System number, router ID
number, and primary IP address that is explicit to the associated VRF instance.
• BGP neighbors defined for a specific VRF instance and address family (IPv4 and IPv6) peer with
neighbors accessible through interfaces associated with the same VRF instance.
IP-IP and GRE Tunnels
Tunnel endpoint addresses always exist in the default VRF instance regardless of the instance in which the
tunnel interface is configured.
Management Applications (Telnet and SSH)
• Telnet and SSH (SSH, SFTP, and SCP) sessions “to” the switch are VRF aware. Client support for
these utilities is supported only in the default VRF instance.
• A maximum of four combined Telnet sessions are allowed simultaneously across all VRFs on the
switch.
• A maximum of eight combined SSH sessions are allowed simultaneously across all VRFs on the
switch
• More than one VRF including the default VRF can be used for Telnet / SSH sessions.
FTP
• FTP session “to” the switch is VRF aware.
• A maximum of four combined FTP sessions are allowed simultaneously across all VRFs on the switch.
NTP
Supports VRF configuration for all NTP operations (both client and server).
WebView
Supports VRF configuration for "WebView Server" and "WebView Access".
Syslog Server
Supports VRF configuration for forwarding swlog output to the syslog daemon of the switch (or host).
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 16-12
Configuring Multiple VRF
VRF Interaction With Other Features
Quality of Service (QoS)
• The Auto-NMS feature (non-VRF aware) recognizes all of the IP interfaces configured in the default
VRF instance. The first eight of these interfaces are prioritized by Auto-NMS to ensure switch
manageability in the event of a DoS attack.
• Policy Based Routing, as indicated in the table above, is a default VRF application. The functionality
of this feature remains the same as in releases prior to the implementation of Multiple VRF instances.
VRF Policies
• A VRF policy condition parameter is available to specify a VRF name to which the policy condition
applies. This parameter can also specify the default VRF, and a no form of the command exists to
remove a VRF condition parameter. For example:
-> qos policy condition c1 vrf engr_vrf
-> qos policy condition c2 vrf default
-> qos policy condition c1 no vrf
• VRF policies are configured in the default VRF, similar to how all other QoS policies are configured.
If the VRF name specified does not exist, the policy is not allocated any system resources.
• Policies that do not specify a VRF name are considered global policies and are applied across all VRF
instances and VLANs.
• Policies that specify the default VRF apply only to traffic in the default VRF instance.
• Policies that specify a VRF name apply only to traffic in the VRF instance associated with that name.
• The switch network group is supported only in VRF policies that specify the default VRF instance. If
this group is specified in a global policy (no VRF specified) then the policy is applied across all VRF
instances.
SNMP
• SNMPv3 is required to manage VRF instances; SNMPv1 and v2 are not supported.
• Configuring the management station to use SNMPv3 is required to receive traps from VRF-aware
applications.
VLANs
Configuring an interface for a VLAN also associates that VLAN with the active VRF context. A VLAN,
however, can only belong to one VRF instance at a time. As a result, all interfaces configured for a VLAN
must belong to the same VRF instance. See “Assigning IP Interfaces to a VRF Instance” on page 16-17
for more information.
UDP/DHCP Relay
VRF support for UDP/DHCP Relay allows for the configuration and management of relay agents and
servers within the context of a VRF instance.
The following guidelines apply when configuring UDP/DHCP Relay within the context of VRF instances:
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 16-13
Configuring Multiple VRF
VRF Interaction With Other Features
• A separate DHCP server is required for each VRF instance to which DHCP packets are relayed to and
from the server. The server should reside in the same VRF as the originating requests. For example, the
following command configures the DHCP server address for the vrfOne instance:
-> vrf vrfOne
vrfOne:> ip helper address 10.0.0.1
The above configuration relays all DHCP packets within the vrfOne instance to the specified server
which also resides in the vrfOne instance.
• A separate UDP relay setting for port/service to VLAN is required per VRF instance. For example, the
following command configures the forwarding of specific UDP packets to VLAN 100 within the
context of the vrfTwo instance:
-> ip udp dns vlan 100
• When a VRF instance is deleted, all UDP/DHCP Relay configuration associated with that instance is
also deleted. However, if the VRF instance is created again with the same name, the relay
configuration previously associated with that name is not restored.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 16-14
Configuring Multiple VRF
Configuring VRF Instances
Configuring VRF Instances
Configuring the Multiple VRF feature consists of the following:
• Creating a VRF instance with a low profile or the default max profile.
• Assigning one or more IP interfaces to the instance.
• Configuring routing protocols to operate within a specific instance.
The initial configuration of an OmniSwitch consists of a default VRF instance, which is always active
when the switch starts up and is not removable from the switch configuration. Any subsequent
configuration of switch applications applies only to the default instance. To provide multiple, independent
IP routing domains on the same switch, configuring additional VRF instances is required.
The VRF CLI is context-based in that commands used to configure VRF-aware applications are applied to
the active VRF instance. A VRF instance becomes active when the instance is either created or selected
using the vrf command.
A VRF instance is identified by a name, which is specified at the time the instance is configured. For
example, the following command creates the IpOne instance:
-> vrf IpOne
IpOne: ->
In this example, instance IpOne is created and made the active VRF context at the same time. Note that
the CLI command prompt indicates the active context by displaying the name of the VRF instance as part
of the actual prompt. Any subsequent commands entered on this command line are applied to the IpOne
instance.
Within the context of the default VRF instance, it is also possible to enter configuration commands for
another instance. For example, to configure an IP interface for instance IpOne from within the CLI context
of the default instance, prefix the ip interface command with vrf command followed by the name of the
instance. For example:
-> vrf IpOne ip interface intf100 address 100.1.1.1/24 vlan 100
->
The above command creates the IP interface for VRF IpOne but does not change the CLI context in which
the command was entered. The default VRF instance remains the active context.
Note. The default VRF instance is the only VRF CLI context within which configuration of another
instance is allowed.
Configuring the VRF Profile
By default, the max profile capabilities are applied when a VRF instance is created. A max profile VRF
supports dynamic routing protocols and other supported VRF limits. To create a VRF instance with low
profile capabilities, use the vrf command with the profile low parameter. For example:
-> vrf IpTwo profile low
IpTwo-low::->
Changing the profile for an existing VRF instance is not allowed. To change the profile, first delete the
VRF then create it again with a different profile. For example, to change profile IpTwo to a max profile
VRF, use the following commands:
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 16-15
Configuring Multiple VRF
Configuring VRF Instances
-> no vrf IpTwo
-> vrf IpTwo profile max
IpTwo-low::->
In this example, the profile max parameter option is not needed, since the max profile is applied by
default. However, this parameter was used here to demonstrate the command syntax.
The total number of VRFs allowed depends on the available switch memory. At 80% memory usage, a
low memory warning is displayed when a new VRF is created. When 90% usage is reached, creating a
new VRF is stopped. For example:
-> vrf LowProfVrf400 profile low
+++ WARNING: Memory usage over 80%, creating VRF
->vrf LowProfVrf412 profile low
ERROR: resource allocation failure
+++ ERROR: Memory usage over 90%, VRF creation failed
Selecting a VRF Instance
Moving between VRF instances is done by selecting an existing instance to become the active VRF CLI
context. The vrf command is also used to select an existing instance. For example, the following
command selects the IpTwo instance:
IpOne: -> vrf IpTwo
IpTwo: ->
In the above example, selecting the IpTwo instance changed the VRF CLI context from IpOne to IpTwo.
Any subsequent commands entered apply to the IpTwo instance.
Note. If the instance name specified with the vrf command does not exist, a VRF instance is automatically
created. In addition, configuring a VRF instance name is case sensitive. As a result, it is possible to
accidentally create or delete instances. Use the show vrf command to verify the VRF instance
configuration before selecting, adding, or removing instances.
To return to the default VRF instance from within the context of another instance, enter the vrf command
with or without the optional default parameter. For example, both of the following commands return the
CLI context to the default VRF instance:
IpOne: -> vrf
IpOne: -> vrf default
Note that the command prompt for the default VRF instance does not display the instance name.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 16-16
Configuring Multiple VRF
Configuring VRF Instances
Assigning IP Interfaces to a VRF Instance
When a VRF instance is created or an existing instance is selected, any IP interface subsequently
configured is associated with that instance. For example, the following commands select the IpOne VRF
instance and configure an IP interface for that instance:
-> vrf IpOne
IpOne: -> ip interface intf100 address 100.1.1.1/24 vlan 100
IpOne: ->
Once an IP interface is associated with a VRF instance, Layer 3 traffic on that interface is routed within
the domain of the VRF instance. In other words, such traffic is only routed between other IP interfaces that
are associated with the same VRF instance. Any additional routing protocol traffic configured for that
same interface is also routed within the associated VRF domain.
Use the following guidelines when configuring IP interfaces for a VRF instance:
• A single IP interface as well as the VLAN associated with the interface, can only belong to one VRF
instance at a time.
• Once a VLAN is associated with a specific VRF instance, configuring an interface for that VLAN
within the context of any other instance, is not allowed. For example, if the first IP interface configured
for VLAN 100 was associated with the VRF IpOne instance, then any subsequent IP interface
configuration for VLAN 100 is only allowed within the context of the IpOne instance.
• A VRF instance can have multiple VLAN associations, even though a VLAN can only have one VRF
association.
Configuring Routing Protocols for a Specific VRF Instance
There are no additional CLI commands or parameters required to associate a routing protocol
configuration (for example, RIP, BGP, OSPF) with a specific VRF instance. Instead, the VRF CLI context
is used to determine the association between a specific routing configuration and a VRF instance. For
example, if a BGP routing instance is configured when VRF instance IpOne is the active CLI context, then
the BGP routing instance is associated with IpOne. All traffic for the BGP instance is routed and
forwarded on the interfaces associated with VRF IpOne.
For more information about the interaction of switch applications with VRF instances, see “VRF
Interaction With Other Features” on page 16-11. To see examples of configuring routing protocol
instances within the context of a VRF instance, refer to “Quick Steps for Configuring Multiple VRF” on
page 16-3.
Removing a VRF Instance
To remove a VRF instance from the switch configuration, use the no form of the vrf command. For
example:
-> no vrf IpTwo
To view a list of VRF instances configured on the switch, use the show vrf command. For more
information about this command, see the OmniSwitch AOS Release 8 CLI Reference Guide.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 16-17
Configuring Multiple VRF
Verifying the VRF Configuration
Verifying the VRF Configuration
To display a list of VRF instances configured for the switch, use the show vrf command. For example:
-> show vrf
Virtual Routers
Profile Protocols
--------------------+-------+------------------default
default BGP PIM VRRP
IpOne
max
RIP
IpTwo
max
BGP
IpThree
low
The VRF CLI context determines which information is displayed using application-specific show
commands. For example, if IpOne is the active VRF context, then only IP interfaces associated with
IpOne are displayed.
-> vrf IpOne
IpOne: -> show ip interface
Total 1 interfaces
Name
IP Address
Subnet Mask
Status Forward Device
--------------------+---------------+---------------+------+-------+-------Loopback
127.0.0.1
255.0.0.0
UP
NO Loopback
intfone
200.1.1.1
255.255.255.0
DOWN
NO vlan 200
IpOne: -> vrf default
-> show ip interface
Total 6 interfaces
Name
IP Address
Subnet Mask
Status Forward Device
--------------------+---------------+---------------+------+-------+-------EMP
192.168.10.1
255.255.255.0
DOWN
NO EMP
Loopback
127.0.0.1
255.0.0.0
UP
NO Loopback
vlan 130
192.168.130.161 255.255.255.0
DOWN
NO vlan 130
vlan 2
10.255.11.161
255.255.255.0
UP
YES vlan 2
vlan-2000
172.20.0.1
255.255.0.0
UP
YES vlan 2000
vlan-2100
172.21.0.1
255.255.0.0
UP
YES vlan 2100
Note that when the default VRF CLI context is active, the show commands can display specific
information for another instance. This is done by first entering the vrf command followed by the instance
name and then the show command. For example, the following command displays the IP interfaces
configured for IpOne from within the context of the default VRF CLI:
-> vrf IpOne show ip interface
For more information about the displays that result from these commands, see the OmniSwitch AOS
Release 8 CLI Reference Guide.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 16-18
17
Configuring IPv6
Internet Protocol version 6 (IPv6) is the next generation of Internet Protocol version 4 (IPv4). Both
versions are supported along with the ability to tunnel IPv6 traffic over IPv4. Implementing IPv6 solves
the limited address problem currently facing IPv4, which provides a 32-bit address space. IPv6 increases
the address space available to 128 bits.
In This Chapter
This chapter describes IPv6 and how to configure it through Command Line Interface (CLI). The CLI
commands are used in the configuration examples; for more details about the syntax of commands, see the
OmniSwitch AOS Release 8 CLI Reference Guide.
This chapter provides an overview of IPv6 and includes information about the following procedures:
• Configuring an IPv6 interface (see page 17-12)
• Configuring a Unique Local Ipv6 Interface (see page 17-12)
• Assigning IPv6 Addresses (see page 17-14)
• Configuring IPv6 Tunnel Interfaces (see page 17-16)
• Creating a Static Route (see page 17-17)
• Configuring the Route Preference of a Router (see page 17-19)
• Configuring Route Map Redistribution (see page 17-20)
• Reply or Ignore Echo Requests (see page 17-26)
• ICMPv6 Error Message Rate Limiting (see page 17-26)
• Configure IPv6 EMP Interface (see page 17-27)
• Verifying the IPv6 Configuration (see page 17-29)
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 17-1
Configuring IPv6
IPv6 Defaults
IPv6 Defaults
The following table lists the defaults for IPv6 configuration through the ip command.
Description
Command
Default
Global status of IPv6 on the
switch
N/A
Enabled
Interfaces
ipv6 interface
loopback
6to4 tunnels
ipv6 interface
tunnel_6to4
Prefixes
ipv6 prefix
None
Hop Limit
ipv6 hop-limit
64
Path MTU entry minimum
lifetime
ipv6 pmtu-lifetime
10 minutes
Neighbor stale lifetime
ipv6 neighbor stale-lifetime
10 minutes
Local Unicast Global ID
ipv6 address global-id
None
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 17-2
Configuring IPv6
Quick Steps for Configuring IPv6 Routing
Quick Steps for Configuring IPv6 Routing
The following tutorial assumes that VLAN 200 and VLAN 300 already exist in the switch configuration.
For information about how to configure VLANs, see Chapter 4, “Configuring VLANs.”
1 Configure an IPv6 interface for VLAN 200 by using the ipv6 interface command. For example:
-> ipv6 interface v6if-v200 vlan 200
Note that when the IPv6 interface is configured, the switch automatically generates a link-local address
for the interface. This allows for communication with other interfaces and/or devices on the same link,
but does not provide routing between interfaces.
2 Assign a unicast address to the v6if-v200 interface by using the ipv6 address command. For example:
-> ipv6 address 2001:db8:4100:1::/64 eui-64 v6if-v200
3 Configure an IPv6 interface for VLAN 300 by using the ipv6 interface command. For example:
-> ipv6 interface v6if-v300 vlan 300
4 Assign a unicast address to the v6if-v300 interface by using the ipv6 address command. For example:
-> ipv6 address 2001:db8:4100:2::/64 eui-64 v6if-v300
Note. Optional. To verify the IPv6 interface configuration, enter show ipv6 interface For example:
-> show ipv6 interface
Name
IPv6 Address/Prefix Length
Status Device
-----------------+------------------------------------------+-------+----------v6if-v200
fe80::2d0:95ff:fe12:fab5/64
Down
VLAN 200
2001:db8:4100:1::2d0:95ff:fe12:fab5/64
2001:db8:4100:1::/64
v6if-v300
fe80::2d0:95ff:fe12:fab6/64
Down
VLAN 300
2001:db8:4100:2::2d0:95ff:fe12:fab6/64
2001:db8:4100:2::/64
loopback
::1/128
Active Loopback
fe80::1/64
Note that the link-local addresses for the two new interfaces and the loopback interface were automatically
created and included in the show ipv6 interface display output. In addition, the subnet router anycast
address that corresponds to the unicast address automatically generated for the interface.
5 Enable RIPng for the switch by using the ipv6 load rip command. For example:
-> ipv6 load rip
6 Create a RIPng interface for each of the IPv6 VLAN interfaces by using the ipv6 rip interface
command. For example:
-> ipv6 rip interface v6if-v200
-> ipv6 rip interface v6if-v300
IPv6 routing is now configured for VLAN 200 and VLAN 300 interfaces, but it is not active until at least
one port in each VLAN goes active.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 17-3
Configuring IPv6
IPv6 Overview
IPv6 Overview
IPv6 provides the basic functionality that is offered with IPv4 but includes the following enhancements
and features not available with IPv4:
• Increased IP address size—IPv6 uses a 128-bit address, a substantial increase over the 32-bit IPv4
address size. Providing a larger address size also significantly increases the address space available,
thus eliminating the concern over running out of IP addresses. See “IPv6 Addressing” on page 17-5 for
more information.
• Autoconfiguration of addresses—When an IPv6 interface is created or a device is connected to the
switch, an IPv6 link-local address is automatically assigned for the interface and/or device. See
“Autoconfiguration of IPv6 Addresses” on page 17-7 for more information.
• Anycast addresses—A new type of address. Packets sent to an anycast address are delivered to one
member of the anycast group.
• Simplified header format—A simpler IPv6 header format is used to keep the processing and
bandwidth cost of IPv6 packets as low as possible. As a result, the IPv6 header is only twice the size of
the IPv4 header despite the significant increase in address size.
• Improved support for header options—Improved header option encoding allows more efficient
forwarding, fewer restrictions on the length of options, and greater flexibility to introduce new options.
• Security improvements—Extension definitions provide support for authentication, data integrity, and
confidentiality.
• Neighbor Discovery protocol—A protocol defined for IPv6 that detects neighboring devices on the
same link and the availability of those devices. Additional information that is useful for facilitating the
interaction between devices on the same link is also detected (e.g., neighboring address prefixes,
address resolution, duplicate address detection, link MTU, and hop limit values, etc.).
This implementation of IPv6 also provides the following mechanisms to maintain compatibility between
IPv4 and IPv6:
• Dual-stack support for both IPv4 and IPv6 on the same switch.
• Configuration of IPv6 and IPv4 interfaces on the same VLAN.
• Tunneling of IPv6 traffic over an IPv4 network infrastructure.
• Embedded IPv4 addresses in the four lower-order bytes of the IPv6 address.
The remainder of this section provides a brief overview of the new IPv6 address notation,
autoconfiguration of addresses, and tunneling of IPv6 over IPv4.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 17-4
Configuring IPv6
IPv6 Overview
IPv6 Addressing
One of the main differences between IPv6 and IPv4 is that the address size has increased from 32 bits to
128 bits. Going to a 128-bit address also increases the size of the address space to the point where running
out of IPv6 addresses is not a concern.
The following types of IPv6 addresses are supported:
Link-local—A link-local address is a private unicast address that identifies an interface or device on the
local network. This type of address allows communication with devices and/or neighboring nodes that are
attached to the same physical link. Note that when the communication is between two nodes that are not
attached to the same link, both nodes must have a configured global unicast address. Routing between
link-local addresses is not available because link-local addresses are not known or advertised to the
general network. Link-local addresses are unique only for a link and the same link-local address may be
used on multiple interfaces.
Unicast—Standard unicast addresses, similar to IPv4.
Unique Local IPv6 Unicast—IPv6 unicast address format that is globally unique and intended for local
communications, usually inside of a site. These addresses are not expected to be routable on the global
Internet.
Multicast—Addresses that represent a group of devices. Traffic sent to a multicast address is delivered to
all members of the multicast group.
Anycast—Traffic that is sent to this type of address is delivered to one member of the anycast group. The
device that receives the traffic is usually the one that is easiest to reach as determined by the active routing
protocol.
Note.
• IPv6 does not support the use of broadcast addresses. This functionality is replaced using improved
multicast addressing capabilities.
• When JITC mode is enabled, Site-Local addresses of range FEC0::/10 cannot be configured. This
consists of all the addresses that begin with FEC, FED, FEE and FEF. Refer to the “AAA Commands”
chapter in the OmniSwitch AOS Release 8 CLI Reference Guide for more information on enabling JITC
mode.
IPv6 address types are identified by the high-order bits of the address, as shown in the following table:
Address Type
Binary Prefix
IPv6 Notation
Unspecified
00...0 (128 bits)
::/128
Loopback
00...1 (128 bits)
::1/128
Multicast
11111111
FF00::/8
Link-local unicast
1111111010
FE80::/10
Unique Local IPv6 unicast
11111100
FC00::/7
Global unicast
everything else
Note that anycast addresses are unicast addresses that are not identifiable by a known prefix.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 17-5
Configuring IPv6
IPv6 Overview
IPv6 Address Notation
IPv4 addresses are expressed using dotted decimal notation and consist of four eight-bit octets. If this
same method was used for IPv6 addresses, the address would contain 16 such octets, thus making it
difficult to manage. IPv6 addresses are expressed using colon hexadecimal notation and consist of eight
16-bit words, as shown in the following example:
1234:000F:531F:4567:0000:0000:BCD2:F34A
Note that any field may contain all zeros or all ones. In addition, it is possible to shorten IPv6 addresses by
suppressing leading zeros. For example:
1234:F:531F:4567:0:0:BCD2:F34A
Another method for shortening IPv6 addresses is known as zero compression. When an address contains
contiguous words that consist of all zeros, a double colon (::) is used to identify these words. For example,
using zero compression the address 0:0:0:0:1234:531F:BCD2:F34A is expressed as follows:
::1234:531F:BCD2:F34A
Because the last four words of the above address are uncompressed values, the double colon indicates that
the first four words of the address all contain zeros. Note that using the double colon is only allowed once
within a single address. So if the address was1234:531F:0:0:BCD2:F34A:0:0, a double colon could not
replace both sets of zeros. For example, the first two versions of this address shown below are valid, but
the last version is not valid:
1 1234:531F::BCD2:F34A:0:0
2 1234:531F:0:0:BCD2:F34A::
3 1234:531F::BCD2:F34A:: (not valid)
With IPv6 addresses that have long strings of zeros, the benefit of zero compression is more dramatic. For
example, address FF00:0:0:0:0:0:4501:32 becomes FF00::4501:32.
Note that hexadecimal notation used for IPv6 addresses resembles the notation which is used for MAC
addresses. However, it is important to remember that IPv6 addresses still identify a device at the Layer 3
level and MAC addresses identify a device at the Layer 2 level.
Another supported IPv6 address notation includes embedding an IPv4 address as the four lower-order
bytes of the IPv6 address. This is especially useful when dealing with a mixed IPv4/IPv6 network. For
example:
0:0:0:0:0:0:212.100.13.6
IPv6 Address Prefix Notation
The Classless Inter-Domain Routing (CIDR) notation is used to express IPv6 address prefixes. This
notation consists of the 128-bit IPv6 address followed by a slash (/) and a number representing the prefix
length (IPv6-address/prefix-length). For example, the following IPv6 address has a prefix length of 64
bits:
FE80::2D0:95FF:FE12:FAB2/64
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 17-6
Configuring IPv6
IPv6 Overview
Autoconfiguration of IPv6 Addresses
This implementation of IPv6 supports the stateless autoconfiguration of link-local addresses for IPv6
VLAN and tunnel interfaces and for devices when they are connected to the switch. Stateless refers to the
fact that little or no configuration is required to generate such addresses and there is no dependency on an
address configuration server, such as a DHCP server, to provide the addresses.
A link-local address is a private unicast address that identifies an interface or device on the local network.
This type of address allows communication with devices and/or neighboring nodes that are attached to the
same physical link. Note that when the communication is between two nodes that are not attached to the
same link, both nodes must have a configured global unicast address. Routing between link-local
addresses is not available because link-local addresses are not known or advertised to the general network.
When an IPv6 VLAN or a tunnel interface is created or a device is connected to the switch, a link-local
address is automatically generated for the interface or device. This type of address consists of the wellknown IPv6 prefix FE80::/64 combined with an interface ID. The interface ID is derived from the router
MAC address associated with the IPv6 interface or the source MAC address if the address is for a device.
The resulting link-local address resembles the following example:
FE80::2d0:95ff:fe6b:5ccd/64
Note that when this example address was created, the MAC address was modified by complementing the
second bit of the leftmost byte and by inserting the hex values 0xFF and 0xFE between the third and
fourth octets of the address. These modifications were made because IPv6 requires an interface ID that is
derived using Modified EUI-64 format.
Stateless autoconfiguration is not available for assigning a global unicast address to an IPv6 interface. In
other words, manual configuration is required to assign a non-link-local address to an interface. See
“Assigning IPv6 Addresses” on page 17-14 for more information.
Both stateless and stateful autoconfiguration is supported for devices, such as a workstation, when they are
connected to the switch. When the stateless method is used in this instance, the device listens for router
advertisements in order to obtain a subnet prefix. The unicast address for the device is then formed by
combining the subnet prefix with the interface ID for that device.
Stateful autoconfiguration refers to the use of an independent server, such as a DHCP server, to obtain an
IPv6 unicast address and other related information. Of course, manual configuration of an IPv6 address is
always available for devices as well.
Regardless of how an IPv6 address is obtained, duplicate address detection (DAD) is performed before the
address is assigned to an interface or device. If a duplicate is found, the address is not assigned. Note that
DAD is not performed for anycast addresses, 6to4 tunnels, or VRRP virtual router addresses.
Please refer to RFCs 2462, 2464, and 3513 for more technical information about autoconfiguration and
IPv6 address notation.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 17-7
Configuring IPv6
IPv6 Overview
Globally Unique Local IPv6 Unicast Addresses
These addresses are intended to be routable within a limited area such as a site but not on the global
Internet. Unique Local IPv6 Unicast Addresses are used in conjunction with BGP (IBGP) speakers as well
as exterior BGP (EBGP) neighbors based on configured policies. See the BGP chapter of the Advanced
Routing Guide for details.
Local IPv6 unicast addresses have the following characteristics:
• Globally unique ID (with high probability of uniqueness).
• Use the well-known prefix FC00::/7 to to allow for easy filtering at site boundaries.
• Allow sites to be combined or privately interconnected without creating any address conflicts or
requiring renumbering of interfaces that use these prefixes.
• Internet Service Provider independent and can be used for communications inside of a site without
having any permanent or intermittent Internet connectivity.
• If accidentally leaked outside of a site via routing or DNS, there is no conflict with any other addresses.
• In practice, applications may treat these addresses like global scoped addresses.
A 40-bit global identifier is used to make the local IPv6 address prefixes globally unique. This global ID
can either be explicitly configured, or created using the pseudo-algorithm recommended in RFC 4193.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 17-8
Configuring IPv6
IPv6 Overview
Tunneling IPv6 over IPv4
It is likely that IPv6 and IPv4 network infrastructures will coexist for some time, if not indefinitely.
Tunneling provides a mechanism for transitioning an IPv4 network to IPv6 and/or maintaining
interoperability between IPv4 and IPv6 networks. This implementation of IPv6 supports tunneling of IPv6
traffic over IPv4. There are two types of tunnels supported, 6to4 and configured.
Note. Dynamic routing protocols are not supported over 6to4 tunnels. However, it is possible to configure
dynamic routing for a configured tunnel. See “Configuring IPv6 Tunnel Interfaces” on page 17-16 for more
information.
6to4 Tunnels
6to4 tunneling provides a mechanism for transporting IPv6 host traffic over an IPv4 network infrastructure
to other IPv6 hosts and/or domains without having to configure explicit tunnel endpoints. Instead, an IPv6
6to4 tunnel interface is created at points in the network where IPv6 packets are encapsulated (IPv4 header
added) prior to transmission over the IPv4 network or decapsulated (IPv4 header stripped) for
transmission to an IPv6 destination.
An IPv6 6to4 tunnel interface is identified by its assigned address, which is derived by combining a 6to4
well-known prefix (2002) with a globally unique IPv4 address and embedded as the first 48 bits of an IPv6
address. For example, 2002:d467:8a89::137/64, where d467:8a89 is the hex equivalent of the IPv4 address
212.103.138.137.
6to4 tunnel interfaces are configured on routers and identify a 6to4 site. Because 6to4 tunnels are point-tomulti-point in nature, any one 6to4 router can communicate with one or more other 6to4 routers across the
IPv4 cloud. Additionally, IPv6 multicast traffic cannot be forwarded over a 6to4 tunnel. Two common
scenarios for using 6to4 tunnels are described below.
6to4 Site to 6to4 Site over IPv4 Domain
In this scenario, isolated IPv6 sites have connectivity over an IPv4 network through 6to4 border routers.
An IPv6 6to4 tunnel interface is configured on each border router and assigned an IPv6 address with the
6to4 well-known prefix, as described above. IPv6 hosts serviced by the 6to4 border router have at least
one IPv6 router interface configured with a 6to4 address. Note that additional IPv6 interfaces or external
IPv6 routing protocols are not required on the 6to4 border router.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 17-9
Configuring IPv6
IPv6 Overview
The following diagram illustrates the basic traffic flow between IPv6 hosts communicating over an IPv4
domain:
IPv6 6to4
Border Router
IPv6 6to4
Border Router
IPv4 Domain
6to4 Site
6to4 Site
6to4 Host
6to4 Host
In the above diagram:
1 The 6to4 hosts receive 6to4 prefix from Router Advertisement.
2 The 6to4 host sends IPv6 packets to 6to4 border router.
3 The 6to4 border router encapsulates IPv6 packets with IPv4 headers and sends to the destination 6to4
border router over the IPv4 domain.
4 The destination 6to4 border router strips IPv4 header and forwards to 6to4 destination host.
6to4 Site to IPv6 Site over IPv4/IPv6 Domains
In this scenario, 6to4 sites have connectivity to native IPv6 domains through a relay router, which is
connected to both the IPv4 and IPv6 domains. The 6to4 border routers are still used by 6to4 sites for
encapsulating/decapsulating host traffic and providing connectivity across the IPv4 domain. In addition,
each border router has a default IPv6 route pointing to the relay router.
In essence, a relay router is a 6to4 border router on which a 6to4 tunnel interface is configured. However,
a native IPv6 router interface is also required on the relay router to transmit 6to4 traffic to/from IPv6 hosts
connected to an IPv6 domain. Therefore, the relay router participates in both the IPv4 and IPv6 routing
domains.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 17-10
Configuring IPv6
IPv6 Overview
The following diagram illustrates the basic traffic flow between native IPv6 hosts and 6to4 sites:
IPv6 6to4
Border Router
IPv6/IPv4 6to4
Relay Router
IPv4 Domain
6to4 Site
IPv6 Domain
IPv6
Router
6to4 Host
IPv6 Site
IPv6 Host
In the above diagram:
1 The 6to4 relay router advertises a route to 2002::/16 on its IPv6 router interface.
2 The IPv6 host traffic received by the relay router that has a next hop address that matches 2002::/16 is
routed to the 6to4 tunnel interface configured on the relay router.
3 The traffic routed to the 6to4 tunnel interface is then encapsulated into IPv4 headers and sent to the
destination 6to4 router over the IPv4 domain.
4 The destination 6to4 router strips the IPv4 header and forwards it to the IPv6 destination host.
For more information about configuring an IPv6 6to4 tunnel interface, see “Configuring an IPv6
Interface” on page 17-12 and “Configuring IPv6 Tunnel Interfaces” on page 17-16. For more detailed
information and scenarios by using 6to4 tunnels, refer to RFC 3056.
Configured Tunnels
A configured tunnel is where the endpoint addresses are manually configured to create a point-to-point
tunnel. This type of tunnel is similar to the 6to4 tunnel on which IPv6 packets are encapsulated in IPv4
headers to facilitate communication over an IPv4 network. The difference between the two types of
tunnels is that configured tunnel endpoints require manual configuration, whereas 6to4 tunneling relies on
an embedded IPv4 destination address to identify tunnel endpoints. Additionally, IPv6 multicast traffic
can be sent over configured tunnels allows RIPng and OSPFv3 to run over a configured tunnel.
For more information about IPv6 configured tunnels, see “Configuring IPv6 Tunnel Interfaces” on
page 17-16. For more detailed information about configured tunnels, refer to RFC 4213.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 17-11
Configuring IPv6
Configuring an IPv6 Interface
Configuring an IPv6 Interface
The ipv6 interface command is used to create an IPv6 interface for a VLAN or a tunnel. Note the
following when configuring an IPv6 interface:
• A unique interface name is required for both a VLAN and tunnel interface.
• If creating a VLAN interface, the VLAN must already exist. See Chapter 4, “Configuring VLANs,” for
more information.
• If creating a tunnel interface, a tunnel ID or 6to4 is specified. Only one 6to4 tunnel is allowed per
switch, so it is not necessary to specify an ID when creating this type of tunnel.
• If a tunnel ID is specified, then a configured tunnel interface is created. This type of tunnel requires
additional configuration by using the ipv6 address global-id command. See “Configuring IPv6 Tunnel
Interfaces” on page 17-16 for more information.
• Each VLAN can have one IPv6 interface. Configuring both an IPv4 and IPv6 interface on the same
VLAN is allowed. Note that the VLAN interfaces of both types are not active until at least one port
associated with the VLAN goes active.
• A link-local address is automatically configured for an IPv6 interface, except for 6to4 tunnels, when
the interface is configured. For more information regarding how this address is formed, see
“Autoconfiguration of IPv6 Addresses” on page 17-7.
• Assigning more than one IPv6 address to a single IPv6 interface is allowed.
• Assigning the same link-local address to multiple interfaces is allowed. Each global unicast prefix,
subset of, or superset of a prefix can only exist on one interface. For example, if an interface for VLAN
100 is configured with an address 2001:db8:4100:1000::1/64, an interface for VLAN 200 cannot have
an address 2001:db8:4100:1000::2/64.
• A subnet router anycast address is automatically created when a global unicast address is assigned to
an interface.
To create an IPv6 interface for a VLAN or configured tunnel, enter ipv6 interface followed by an
interface name, then vlan (or tunnel) followed by a VLAN ID (or tunnel ID). For example, the following
two commands create an IPv6 interface for VLAN 200 and an interface for tunnel 35:
-> ipv6 interface v6if-v200 vlan 200
-> ipv6 interface v6if-tunnel-35 tunnel 35
To create an IPv6 interface for a 6to4 tunnel, use the following command:
-> ipv6 interface v6if-6to4 tunnel 6to4
Note. A 6to4 tunnel is automatically created at startup.
Use the show ipv6 interface command to verify the interface configuration for the switch. For more
information about this command, see the OmniSwitch AOS Release 8 CLI Reference Guide.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 17-12
Configuring IPv6
Configuring an IPv6 Interface
Configuring a Unique Local IPv6 Unicast Address
The ipv6 address global-id command is used to create a new value for the global ID. A 5-byte global ID
value can be manually specified or automatically generated:
-> ipv6 address global-id generate
-> ipv6 address global-id 32:57a3:8fed
Note. If the global-id has not previously been specified with the commands above it will automatically be
generated when the first IPv6 local-unicast address command is issued.
Once the global ID is generated the ipv6 address local-unicast command can be used to generate a
unique local address using the configured global-id.
Modifying an IPv6 Interface
The ipv6 interface command is also used to modify existing IPv6 interface parameter values. It is not
necessary to first remove the interface and then create it again with the new values. The changes specified
will overwrite existing parameter values. For example, the following command changes the router
advertisement (RA) reachable time and the RA retransmit timer values for interface v6if-v200:
-> ipv6 interface v6if-v200 ra-reachable-time 60000 ra-retrans-time 2000
When an existing interface name is specified with the ipv6 interface command, the command modifies
specified parameters for that interface. If an unknown interface name is entered along with an existing
VLAN or tunnel parameter, a new interface is created with the name specified.
Removing an IPv6 Interface
To remove an IPv6 interface from the switch configuration, use the no form of the ipv6 interface
command. Note that it is only necessary to specify the name of the interface, as shown in the following
example:
-> no ipv6 interface v6if-v200
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 17-13
Configuring IPv6
Assigning IPv6 Addresses
Assigning IPv6 Addresses
When an IPv6 interface is created for a VLAN or a configured tunnel, an IPv6 link-local address is
automatically created for that interface. This is also true when a device, such as a workstation, is
connected to the switch.
Link-local addresses, although private and non-routable, enable interfaces and workstations to
communicate with other interfaces and workstations that are connected to the same link. This simplifies
getting devices up and running on the local network. If this level of communication is sufficient, assigning
additional addresses is not required.
If it is necessary to identify an interface or device to the entire network, or as a member of a particular
group, or enable an interface to perform routing functions, then configuring additional addresses (for
example, global unicast) is required.
Use the ipv6 address command to manually assign addresses to an existing interface (VLAN or tunnel) or
device. For example, the following command assigns a global unicast address to the VLAN interface v6ifv200:
-> ipv6 address 2001:db8:4100:1000::20/64 v6if-v200
In the above example, 2001:db8:4100:1000:: is specified as the subnet prefix and 20 is the interface
identifier. Note that the IPv6 address is expressed using CIDR notation to specify the prefix length. In the
above example, /64 indicates a subnet prefix length of 64 bits.
To use the MAC address of an interface or device as the interface ID, specify the eui-64 option with this
command. For example:
-> ipv6 address 2001:db8:4100:1000::/64 eui-64 v6if-v200
The above command example creates address 2001:db8:4100:1000::2d0:95ff:fe12:fab2/64 for interface
v6if-v200.
Note the following when configuring IPv6 addresses:
• It is possible to assign more than one address to a single interface.
• Any field of an address may contain all zeros or all ones. The exception to this is the interface
identifier portion of the address, which cannot be all zeros. If the eui-64 option is specified with the
ipv6 address command, this is not an issue.
• The EUI-64 interface identifier takes up the last 64 bits of the 128-bit IPv6 address. If the subnet prefix
combined with the EUI-64 interface ID is longer than 128 bits, an error occurs and the address is not
created.
A subnet router anycast address is automatically created when a global unicast address is assigned to an
interface. The anycast address is derived from the global address by adding an interface ID of all zeros to
the prefix of the global address. For example, the global address 2001:db8:4100:1000::20/64 generates the
anycast address 2001:db8:4100:1000::/64.
• Devices, such as a PC, are eligible for stateless autoconfiguration of unicast addresses in addition to the
link-local address. If this type of configuration is in use on the network, manual configuration of
addresses on the PC is not required.
• IPv6 VLAN or tunnel interfaces are only eligible for stateless autoconfiguration of their link-local
addresses. Manual configuration of addresses is required for all additional addresses.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 17-14
Configuring IPv6
Assigning IPv6 Addresses
See “IPv6 Addressing” on page 17-5 for an overview of IPv6 address notation. Refer to RFC 4291 for
more technical address information.
Removing an IPv6 Address
To remove an IPv6 address from an interface, use the no form of the ipv6 address command as shown:
-> no ipv6 address 2001:db8:4100:1000::20 v6if-v200
Note that the subnet router anycast address is automatically deleted when the last unicast address of the
same subnet is removed from the interface.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 17-15
Configuring IPv6
Configuring IPv6 Tunnel Interfaces
Configuring IPv6 Tunnel Interfaces
There are two types of tunnels supported, 6to4 and configured. Both types facilitate the interaction of IPv6
networks with IPv4 networks by providing a mechanism for carrying IPv6 traffic over an IPv4 network
infrastructure. This is an important function since it is more than likely that both protocols will need to
coexist within the same network for some time.
A 6to4 tunnel is configured by creating an IPv6 6to4 tunnel interface on a router. This interface is then
assigned an IPv6 address with an embedded well-known 6to4 prefix (e.g., 2002) combined with an IPv4
local address. This is all done using the ipv6 interface and ipv6 address commands. Since a 6to4
interface named “tunnel_6to4” is automatically created, enter the following commands to create a 6to4
tunnel interface:
-> ipv6 address 2002:c633:6489::254/16 tunnel_6to4
-> ipv6 interface tunnel_6to4 admin-state enable
In the above example, 2002 is the well-known prefix that identifies a 6to4 tunnel. The C633:6489 part of
the address that follows 2002 is the hex equivalent of the IPv4 address 198.51.100.137. Note that an IPv4
interface configured with the embedded IPv4 address is required on the switch. In addition, do not
configure a private (e.g., 192.168.10.1), broadcast, or unspecified address as the embedded IPv4 address.
One of the main benefits of 6to4 tunneling is that no other configuration is required to identify tunnel
endpoints. The router that the 6to4 tunnel interface is configured on will encapsulate IPv6 packets in IPv4
headers and send them to the IPv4 destination address where they will be processed. This is particularly
useful in situations where the IPv6 host is isolated.
The second type of tunnel supported is referred to as a configured tunnel. With this type of tunnel it is
necessary to specify an IPv4 address for the source and destination tunnel endpoints. Note that if
bidirectional communication is desired, then it is also necessary to create the tunnel interface at each end
of the tunnel.
Creating an IPv6 configured tunnel involves the following general steps:
• Create an IPv6 tunnel interface using the ipv6 interface command.
• Associate an IPv4 source and destination address with the tunnel interface by using the ipv6 interface
command. These addresses identify the tunnel endpoints.
• Associate an IPv6 address with the tunnel interface by using the ipv6 address command.
• Configure a tunnel interface and associated addresses at the other end of tunnel.
The following example commands create the v6if-tunnel-137 configured tunnel:
-> ipv6 interface v6if-tunnel-137 tunnel 1
-> ipv6 interface v6if-tunnel-137 tunnel source 198.51.100.137 destination
192.0.2.195
-> ipv6 address 2100:db8:4132:4000::/64 eui-64 v6if-tunnel-137
-> ipv6 interface v6if-tunnel-137 admin-state enable
Note that dynamic routing protocols are not supported over 6to4 tunnels, but are allowed over configured
tunnels. To use this protocol on a configured tunnel, a dynamic routing protocol interface is created for the
tunnel interface. For example, the following command creates a RIPng interface for tunnel v6if-tunnel137:
-> ipv6 rip interface v6if-tunnel-137
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 17-16
Configuring IPv6
Creating an IPv6 Static Route
Creating an IPv6 Static Route
Static routes are user-defined and carry a higher priority than routes created by dynamic routing protocols.
That is, if two routes have the same metric value, the static route has the higher priority. Static routes
allow you to define, or customize, an explicit path to an IPv6 network segment, which is then added to the
IPv6 Forwarding table. Static routes can be created between VLANs to enable devices on these VLANs to
communicate.
Use the ipv6 static-route command to create a static route. You must specify the destination IPv6 address
of the route as well as the IPv6 address of the first hop (gateway) used to reach the destination. For
example, to create a static route to IPv6 address 212:95:5::/64 through gateway
fe80::2d0:95ff:fe6a:f458 on interface v6if-137, you would enter:
-> ipv6 static-route 2001:db8:212:95::/64 gateway fe80::2d0:95ff:fe6a:f458 v6if-137
Note that in the example above the IPv6 interface name for the gateway was included. This parameter is
required only when a link local address is specified as the gateway.
When you create a static route, the default metric value of 1 is used. However, you can change the priority
of the route by increasing its metric value. The lower the metric value, the higher the priority. This metric
is added to the metric cost of the route. The metric range is 1 to 15. For example:
-> ipv6 static-route 2001:db8:212:95::/64 gateway fe80::2d0:95ff:fe6a:f458 v6if-137
metric 3
Static routes do not age out of the IPv6 Forwarding table; you must delete them from the table. Use the no
ipv6 static-route command to delete a static route. You must specify the destination IPv6 address of the
route as well as the IPv6 address of the first hop (gateway). For example, to delete the static you would
enter:
-> no ip static-route 2001:db8:212:95::/64 gateway fe80::2d0:95ff:fe6a:f458 v6if-137
The IPv6 Forwarding table includes routes learned through one of the routing protocols (RIP, OSPF,
BGP) as well as any static routes that are configured. Use the show ipv6 routes command to display the
IPv6 Forwarding table.
Note. A static route is not active unless the gateway it is using is active.
To create an IPv6 static route with gateway pointing to an EMP interface, specify the keyword emp for
the interface name field instead of specifying the exact interface name of the EMP interface (for example,
EMP-CMMA-CHAS1).
-> ipv6 static-route 212:95:5::/64 gateway 2001::205 emp
or
-> ipv6 static-route 212:95:5::/64 gateway 2001::205 EMP-CMMA-CHAS1
Note.
• If an IPv6 address is configured on the EMP port on a VC or chassis setup, ensure to configure the
IPv6 address on all the VC elements or CMM.
• Static route with default gateway towards EMP interface is not allowed.
-> ipv6 static-route ::/0 gateway 2001::205 EMP-CMMA-CHAS1
ERROR: Default routes with gateway on EMP port not allowed
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 17-17
Configuring IPv6
Creating an IPv6 Static Route
See “Configure IPv6 EMP Interface” on page 17-27 for more information on configuring IPv6 EMP
interface.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 17-18
Configuring IPv6
Configuring the Route Preference of a Router
Configuring the Route Preference of a Router
By default, the route preference of a router is in this order: local, static, OSPFv3, RIPng, EBGP, and IBGP
(highest to lowest).
Use the ipv6 route-pref command to change the route preference value of a router. For example, to
configure the route preference of an OSPF route, you would enter:
-> ipv6 route-pref ospf 15
To display the current route preference configuration, use the show ipv6 route-pref command:
-> show ipv6 route-pref
Protocol
Route Preference Value
------------+-----------------------Local
1
Static
2
OSPF
110
RIP
120
EBGP
190
IBGP
200
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 17-19
Configuring IPv6
Configuring Route Map Redistribution
Configuring Route Map Redistribution
It is possible to learn and advertise IPv6 routes between different protocols. Such a process is referred to
as route redistribution and is configured using the ipv6 redist command.
Redistribution uses route maps to control how external routes are learned and distributed. A route map
consists of one or more user-defined statements that can determine which routes are allowed or denied
access to the receiving network. In addition a route map may also contain statements that modify route
parameters before they are redistributed.
When a route map is created, it is given a name to identify the group of statements that it represents. This
name is required by the ipv6 redist command. Therefore, configuring route redistribution involves the
following steps:
1 Create a route map, as described in “Using Route Maps” on page 17-20.
2 Configure redistribution to apply a route map, as described in “Configuring Route Map Redistribution”
on page 17-24.
Using Route Maps
A route map specifies the criteria that are used to control redistribution of routes between protocols. Such
criteria is defined by configuring route map statements. There are three different types of statements:
• Action. An action statement configures the route map name, sequence number, and whether or not
redistribution is permitted or denied based on route map criteria.
• Match. A match statement specifies criteria that a route must match. When a match occurs, then the
action statement is applied to the route.
• Set. A set statement is used to modify route information before the route is redistributed into the
receiving protocol. This statement is only applied if all the criteria of the route map is met and the
action permits redistribution.
The ip route-map command is used to configure route map statements and provides the following action,
match, and set parameters:
ip route-map action ...
ip route-map match ...
ip route-map set ...
permit
deny
ip-address
ip-nexthop
ipv6-address
ipv6-nexthop
tag
ipv4-interface
ipv6-interface
metric
route-type
metric
metric-type
tag
community
local-preference
level
ip-nexthop
ipv6-nexthop
Refer to the “IP Commands” chapter in the OmniSwitch AOS Release 8 CLI Reference Guide for more
information about the ip route-map command parameters and usage guidelines.
Once a route map is created, it is then applied using the ipv6 redist command. See “Configuring Route
Map Redistribution” on page 17-24 for more information.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 17-20
Configuring IPv6
Configuring Route Map Redistribution
Creating a Route Map
When a route map is created, it is given a name (up to 20 characters), a sequence number, and an action
(permit or deny). Specifying a sequence number is optional. If a value is not configured, then the number
50 is used by default.
To create a route map, use the ip route-map command with the action parameter. For example,
-> ip route-map ospf-to-rip sequence-number 10 action permit
The above command creates the ospf-to-rip route map, assigns a sequence number of 10 to the route
map, and specifies a permit action.
To optionally filter routes before redistribution, use the ip route-map command with a match parameter
to configure match criteria for incoming routes. For example,
-> ip route-map ospf-to-rip sequence-number 10 match tag 8
The above command configures a match statement for the ospf-to-rip route map to filter routes based on
their tag value. When this route map is applied, only OSPF routes with a tag value of eight are
redistributed into the RIP network. All other routes with a different tag value are dropped.
Note. Configuring match statements is not required. However, if a route map does not contain any match
statements and the route map is applied using the ipv6 redist command, the router redistributes all routes
into the network of the receiving protocol.
To modify route information before it is redistributed, use the ip route-map command with a set
parameter. For example,
-> ip route-map ospf-to-rip sequence-number 10 set tag 5
The above command configures a set statement for the ospf-to-rip route map that changes the route tag
value to five. Because this statement is part of the ospf-to-rip route map, it is only applied to routes that
have an existing tag value equal to eight.
The following is a summary of the commands used in the above examples:
-> ip route-map ospf-to-rip sequence-number 10 action permit
-> ip route-map ospf-to-rip sequence-number 10 match tag 8
-> ip route-map ospf-to-rip sequence-number 10 set tag 5
To verify a route map configuration, use the show ip route-map command:
-> show ip route-map
Route Maps: configured: 1 max: 200
Route Map: ospf-to-rip Sequence Number: 10 Action permit
match tag 8
set tag 5
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 17-21
Configuring IPv6
Configuring Route Map Redistribution
Deleting a Route Map
Use the no form of the ip route-map command to delete an entire route map, a route map sequence, or a
specific statement within a sequence.
To delete an entire route map, enter no ip route-map followed by the route map name. For example, the
following command deletes the entire route map named redistipv4:
-> no ip route-map redistipv4
To delete a specific sequence number within a route map, enter no ip route-map followed by the route
map name, then sequence-number followed by the actual number. For example, the following command
deletes sequence 10 from the redistipv4 route map:
-> no ip route-map redistipv4 sequence-number 10
Note that in the above example, the redistripv4 route map is not deleted. Only those statements associated
with sequence 10 are removed from the route map.
To delete a specific statement within a route map, enter no ip route-map followed by the route map name,
then sequence-number followed by the sequence number for the statement, then either match or set and
the match or set parameter and value. For example, the following command deletes only the match tag 8
statement from route map redistipv4 sequence 10:
-> no ip route-map redistipv4 sequence-number 10 match tag 8
Configuring Route Map Sequences
A route map may consist of one or more sequences of statements. The sequence number determines which
statements belong to which sequence and the order in which sequences for the same route map are
processed.
To add match and set statements to an existing route map sequence, specify the same route map name and
sequence number for each statement. For example, the following series of commands creates route map
rm_1 and configures match and set statements for the rm_1 sequence 10:
-> ip route-map rm_1 sequence-number 10 action permit
-> ip route-map rm_1 sequence-number 10 match tag 8
-> ip route-map rm_1 sequence-number 10 set metric 1
To configure a new sequence of statements for an existing route map, specify the same route map name
but use a different sequence number. For example, the following command creates a new sequence 20 for
the rm_1 route map:
-> ip route-map rm_1 sequence-number 20 action permit
-> ip route-map rm_1 sequence-number 20 match ipv4-interface to-finance
-> ip route-map rm_1 sequence-number 20 set metric 5
The resulting route map appears as follows:
-> show ip route-map rm_1
Route Map: rm_1 Sequence Number: 10 Action permit
match tag 8
set metric 1
Route Map: rm_1 Sequence Number: 20 Action permit
match ip4 interface to-finance
set metric 5
Sequence 10 and sequence 20 are both linked to route map rm_1 and are processed in ascending order
according to their sequence number value. Note that there is an implied logical OR between sequences. As
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 17-22
Configuring IPv6
Configuring Route Map Redistribution
a result, if there is no match for the tag value in sequence 10, then the match interface statement in
sequence 20 is processed. However, if a route matches the tag 8 value, then sequence 20 is not used. The
set statement for whichever sequence was matched is applied.
A route map sequence may contain multiple match statements. If these statements are of the same kind
(e.g., match tag 5, match tag 8, etc.) then a logical OR is implied between each like statement. If the match
statements specify different types of matches (e.g. match tag 5, match ip4 interface to-finance, etc.), then a
logical AND is implied between each statement. For example, the following route map sequence will
redistribute a route if its tag is either 8 or 5:
-> ip route-map rm_1 sequence-number 10 action permit
-> ip route-map rm_1 sequence-number 10 match tag 5
-> ip route-map rm_1 sequence-number 10 match tag 8
The following route map sequence will redistribute a route if the route has a tag of 8 or 5 and the route
was learned on the IPv6 interface to-finance:
->
->
->
->
ip
ip
ip
ip
route-map
route-map
route-map
route-map
rm_1
rm_1
rm_1
rm_1
sequence-number
sequence-number
sequence-number
sequence-number
10
10
10
10
action permit
match tag 5
match tag 8
match ipv6-interface to-finance
Configuring Access Lists
An IP access list provides a convenient way to add multiple IPv4 or IPv6 addresses to a route map. Using
an access list avoids having to enter a separate route map statement for each individual IP address. Instead,
a single statement is used that specifies the access list name. The route map is then applied to all the
addresses contained within the access list.
Configuring an IP access list involves two steps: creating the access list and adding IP addresses to the list.
To create an IP access list, use the ip access-list command (IPv4) or the ipv6 access-list command (IPv6)
and specify a name to associate with the list. For example,
-> ip access-list ipaddr
-> ipv6 access-list ip6addr
To add addresses to an access list, use the ip access-list address (IPv4) or the ipv6 access-list address
(IPv6) command. For example, the following commands add addresses to an existing access list:
-> ip access-list ipaddr address 10.0.0.0/8
-> ipv6 access-list ip6addr address 2001::/64
Use the same access list name each time the above commands are used to add additional addresses to the
same access list. In addition, both commands provide the ability to configure if an address and/or its
matching subnet routes are permitted (the default) or denied redistribution. For example:
-> ip access-list ipaddr address 16.24.2.1/16 action deny redist-control allsubnets
-> ipv6 access-list ip6addr address 2001::1/64 action permit redist-control nosubnets
For more information about configuring access list commands, see the “IP Commands” chapter in the
OmniSwitch AOS Release 8 CLI Reference Guide.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 17-23
Configuring IPv6
Configuring Route Map Redistribution
Configuring Route Map Redistribution
The ipv6 redist command is used to configure the redistribution of routes from a source protocol into the
destination protocol. This command is used on the IPv6 router that will perform the redistribution.
Note. A router automatically becomes an Autonomous System Border Router (ASBR) when redistribution
is configured on the router.
A source protocol is a protocol from which the routes are learned. A destination protocol is the one into
which the routes are redistributed. Make sure that both protocols are loaded and enabled before
configuring redistribution.
Redistribution applies criteria specified in a route map to routes received from the source protocol.
Therefore, configuring redistribution requires an existing route map. For example, the following command
configures the redistribution of OSPFv3 routes into the RIPng network using the ospf-to-rip route map:
-> ipv6 redist ospf into rip route-map ospf-to-rip
OSPFv3 routes received by the router interface are processed based on the contents of the ospf-to-rip route
map. Routes that match criteria specified in this route map are either allowed or denied redistribution into
the RIPng network. The route map may also specify the modification of route information before the route
is redistributed. See “Using Route Maps” on page 17-20 for more information.
To remove a route map redistribution configuration, use the no form of the ipv6 redist command. For
example:
-> no ipv6 redist ospf into rip route-map ospf-to-rip
Use the show ipv6 redist command to verify the redistribution configuration:
-> show ipv6 redist
Source
Destination
Protocol
Protocol
Status
Route Map
------------+------------+---------+-------------------localIPv6
RIPng
Enabled
ipv6rm
OSPFv3
RIPng
Enabled
ospf-to-rip
Configuring the Administrative Status of the Route Map Redistribution
The administrative status of a route map redistribution configuration is enabled by default. To change the
administrative status, use the admin-state parameter with the ipv6 redist command. For example, the
following command disables the redistribution administrative status for the specified route map:
-> ipv6 redist ospf into rip route-map ospf-to-rip admin-state disable
The following command example enables the administrative status:
-> ipv6 redist ospf into rip route-map ospf-to-rip admin-state enable
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 17-24
Configuring IPv6
Configuring Route Map Redistribution
Route Map Redistribution Example
The following example configures the redistribution of OSPFv3 routes into a RIPng network using a route
map (ospf-to-rip) to filter specific routes:
->
->
->
->
->
->
ip
ip
ip
ip
ip
ip
route-map
route-map
route-map
route-map
route-map
route-map
ospf-to-rip
ospf-to-rip
ospf-to-rip
ospf-to-rip
ospf-to-rip
ospf-to-rip
sequence-number
sequence-number
sequence-number
sequence-number
sequence-number
sequence-number
10
10
10
20
20
20
action deny
match tag 5
match route-type external type2
action permit
match ipv6-interface intf_ospf
set metric 255
-> ip route-map ospf-to-rip sequence-number 30 action permit
-> ip route-map ospf-to-rip sequence-number 30 set tag 8
-> ip redist ospf into rip route-map ospf-to-rip
The resulting ospf-to-rip route map redistribution configuration does the following:
• Denies the redistribution of Type 2 external OSPFv3 routes with a tag set to five.
• Redistributes into RIPng all routes learned on the intf_ospf interface and sets the metric for such routes
to 255.
• Redistributes into RIPng all other routes (those not processed by sequence 10 or 20) and sets the tag for
such routes to eight.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 17-25
Configuring IPv6
Reply or Ignore Echo Requests
Reply or Ignore Echo Requests
By default, the switch will reply to all echo requests, including those sent to anycast or multicast
addresses. The ipv6 echo command can be used to configure the switch to ignore echo requests sent to
anycast or multicast addresses.
Use the ipv6 echo command to reply to multicast or any echo requests:
-> ipv6 echo multicast
-> ipv6 echo anycast
Use no option in ipv6 echo command to ignore reply to anycast or multicast echo requests.
-> no ipv6 echo anycast
ICMPv6 Error Message Rate Limiting
The ipv6 icmp rate-limit command configures the rate limit interval and maximum burst size. This
command configures the maximum number of ICMPv6 error messages that may be sent in one burst,
regardless of the interval, per-VRF basis.
AOS uses the token bucket method for rate limiting ICMPv6 error messages on a per-interface basis.
Tokens are added to an interface’s bucket at the specified rate limit interval up to the maximum burst
value. When an ICMPv6 error message needs to be sent, a token is removed from the bucket. If a token
was available the message is sent, otherwise it is discarded.
-> ipv6 icmp rate-limit interval 100
-> ipv6 icmp rate-limit burst 20
Use no option to disable the ICMPv6 error message rate limiting.
-> no ipv6 icmp rate-limit
The show ipv6 information command displays the ICMPv6 rate limit values.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 17-26
Configuring IPv6
IPv6 EMP Interface
IPv6 EMP Interface
IPv6 EMP interface is an IPv6 interface associated with the physical EMP port.
Only one global unicast address can be assigned to an IPv6 EMP interface. Link-local addresses will be
assigned when the interface is first enabled and updated with IPv4 EMP address. If the switch has an EMP
port even without the global unique IPv6 address configuration, IPv6 EMP interface shall be created and
assigned with the link local address created using the MAC address of the EMP port. Since Duplicate
Address Detection (DAD) is disabled on the EMP interface, it is required to configure an unique IPv6
Address that does not conflict with any other IPv6 interface configured in the system.
Only one EMP IPv6 interface may be created per switch in the default VRF. IPv6 EMP address can be
added or modified using modify boot parameters command. EMP interface is externally reachable
through the EMP port after reload.
If an IPv6 address is configured on the EMP port on a VC or chassis setup, ensure to configure the IPv6
address on all the VC elements or CMM.
Configure IPv6 EMP Interface
You must be on the system console to modify the system boot parameters. Use modify boot parameters
command to configure an IPv6 EMP interface. This enters the boot mode. IPv6 EMP interface parameters
like the unique IP address and mask, baudrate, priority, and so on can be configured after entering this
mode.
It is required to reload the switch for the modified interface configuration to come into effect.
-> modify boot parameters
Please wait...
Type '?' for help, 'exit' to exit the boot param parser.
Boot > ?
boot empipaddr
<ip address>
boot empmasklength
<number of bits in mask>
boot serialbaudrate
<1200, 2400, 4800, 9600, 19200, 38400, 57600, 76800,
115200>
boot serialparity
<none, even, odd>
boot serialwordsize
<7, 8>
boot serialstopbits
<1, 2>
boot serialmode
<modemControlOn, modemControlOff>
boot empipv6addr
<ipv6 address>
boot empipv6masklength <number of bits in mask>
'show'
- Display the edit buffer
'commit boot'
- Commit the changes to non volatile memory for future boots
'commit system' - Commit the changes to running system ONLY
Note: EMP changes will only take effect on a future boot
'exit'
- Exit (quit)
show command displays the existing configuration of EMP interface.
Boot > show
EMP IP Address
Serial (console)
Serial (console)
Serial (console)
Serial (console)
Serial (console)
EMP IPV6 Address
baud
parity
wordsize
stopbits
mode
:
:
:
:
:
:
:
10.200.105.21/24
9600
none
8
1
modemControlOff
/
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 17-27
Configuring IPv6
IPv6 EMP Interface
To Configure IPv6 EMP interface, configure the IP address and mask:
Boot > boot empipv6masklength 64
Boot > show
EMP IP Address
: 10.200.105.21/24
Serial (console) baud
: 9600
Serial (console) parity
: none
Serial (console) wordsize : 8
Serial (console) stopbits : 1
Serial (console) mode
: modemControlOff
EMP IPV6 Address
: /64
Boot > boot empipv6addr 2001::205
Boot > show
EMP IP Address
: 10.200.105.21/24
Serial (console) baud
: 9600
Serial (console) parity
: none
Serial (console) wordsize : 8
Serial (console) stopbits : 1
Serial (console) mode
: modemControlOff
EMP IPV6 Address
: 2001::205/64
Boot >
show ipv6 interface, show ipv6 emp-interface commands can be used to view the EMP interface
configuration. show ipv6 emp-routes displays the IPv6 routes targeted to EMP port/IPv6 EMP interface
configuration.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 17-28
Configuring IPv6
Verifying the IPv6 Configuration
Verifying the IPv6 Configuration
A summary of the show commands used for verifying the IPv6 configuration is given here:
show ipv6 redist
Displays the route map redistribution configuration.
show ipv6 interface
Displays the status and configuration of IPv6 interfaces.
show ipv6 tunnel configured
Displays IPv6 configured tunnel information.
show ipv6 tunnel 6to4
Displays IPv6 6to4 tunnel information.
show ipv6 routes
Displays the IPv6 Forwarding Table.
show ipv6 route-pref
Displays the configured route preference of a router.
show ipv6 router database
Displays a list of all routes (static and dynamic) that exist in the IPv6
router database.
show ipv6 prefixes
Displays IPv6 subnet prefixes used in router advertisements.
show ipv6 neighbors
Displays the IPv6 Neighbor Table.
show ipv6 tcp listeners
Displays statistics for IPv6 listener traffic.
show ipv6 tcp connections
Displays statistics for IPv6 connection traffic.
show ipv6 icmp statistics
Displays ICMP6 statistics.
show ipv6 pmtu table
Displays the IPv6 Path MTU Table.
show ipv6 tcp connections
Displays TCP Over IPv6 Connection Table. Contains information
about existing TCP connections between IPv6 endpoints.
show ipv6 tunnel 6to4
Displays the UDP Over IPv6 Listener Table. Contains information
about UDP/IPv6 endpoints.
show ipv6 information
Displays IPv6 information.
show ipv6 emp-interface
Displays the IPv6 EMP interface configuration.
show ipv6 emp-routes
Displays the IPv6 routes targeted to EMP port/IPv6 EMP interface
configuration.
For more information about the displays that result from these commands, see the OmniSwitch AOS
Release 8 CLI Reference Guide.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 17-29
18
Configuring IPsec
Internet Protocol security (IPsec) is a suite of protocols for securing IPv6 communications by
authenticating and/or encrypting each IPv6 packet in a data stream. IPsec is a framework of open standards
designed to provide interoperable, high quality, cryptographically-based security for IPv6 networks
through the use of appropriate security protocols, cryptographic algorithms, and cryptographic keys. The
set of security services offered includes access control, connectionless integrity, data origin authentication,
detection and rejection of replays (a form of partial sequence integrity), and confidentiality (via
encryption).
These security services are provided through use of two security protocols, the Authentication Header
(AH) and the Encapsulating Security Payload (ESP), and through the use of cryptographic key
management procedures and protocols.
Note. The OmniSwitch currently supports IPsec for IPv6 only.
In This Chapter
This chapter describes the basic components of IPsec and how to configure them through the Command
Line Interface (CLI). CLI commands are used in the configuration examples; for more details about the
syntax of commands, see the OmniSwitch AOS Release 8 CLI Reference Guide.
Configuration procedures described in this chapter include:
• Master Key Configuration (see “Configuring an IPsec Master Key” on page 18-10).
• Security Policy Configuration (see “Configuring an IPsec Policy” on page 18-11).
• Security Policy Rule Configuration (see “Configuring an IPsec Rule” on page 18-14).
• Assigning an action to a policy” on page 18-13 (see “Assigning an Action to a Policy” on page 18-13)
• SA Configuration (see “Configuring an IPsec SA” on page 18-15).
• Security Association Key Configuration (see “Configuring IPsec SA Keys” on page 18-16).
• Default Discard Policy (see “Enabling and Disabling Default Discard Policy” on page 18-19).
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 18-1
Configuring IPsec
IPsec Defaults
IPsec Defaults
The following table shows the default settings of the configurable IPsec parameters.
Parameter Description
Command
Default Value/Comments
IPsec global status (A license file
must be present on the switch)
Disabled
Master security key for the switch
ipsec security-key
No master security key set
IPsec policy priority
ipsec policy
100
IPsec security policy status
ipsec policy
Disabled
IPsec discard policy status
ipsec policy
Enabled
IPsec SA status
ipsec sa
Disabled
Key length AES-CBC
ipsec sa
128 bits
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 18-2
Configuring IPsec
Quick Steps for Configuring an IPsec AH Policy
Quick Steps for Configuring an IPsec AH Policy
IP Authentication Header (AH) provides data origin authentication, data integrity, and replay protection.
Data integrity verifies that the contents of the datagram were not changed in transit, either deliberately or
due to random errors, however, AH does not provide data encryption.
1 Configure the master security key. The master security key must be set if keys are to be encrypted
when saved in the boot.cfg and snapshot files.
-> ipsec security-key master-key-12345
2 Define the policy. A policy defines the traffic that requires IPsec protection. The commands below
define a bi-directional policy for any protocol and the associated IPv6 address ranges. For example:
-> ipsec policy ALLoutMD5 source 664:1:1:1::199/64 destination 664:1:1:1::1/64
protocol any out ipsec admin-state disable
-> ipsec policy ALLinMD5 source 664:1:1:1::1/64 destination 664:1:1:1::199/64
protocol any in ipsec admin-state disable
3 Define the rule. A rule defines the security services for the traffic defined by its associated policy. For
example the commands below add an AH rule to the polices defined above:
-> ipsec policy ALLoutMD5 rule 1 ah
-> ipsec policy ALLinMD5 rule 1 ah
4 Enable the policies. A policy cannot be enabled until the rules are defined. Now that rules have been
defined, enable the policy using the commands below:
-> ipsec policy ALLoutMD5 admin-state enable
-> ipsec policy ALLinMD5 admin-state enable
5 Define the Security Keys. Each SA has its own unique set of security keys. The key name is the SA
name that is going to use the key and the length must match the authentication algorithm key size. Keys
must be defined before the SA can be enabled.
-> ipsec key ALLoutMD5_SA sa-authentication 0x11112222333344445555666677778888
-> ipsec key ALLinMD5_SA sa-authentication 0x11112222333344445555666677778888
6 Define the SA. An SA specifies the actual actions to be performed. The security parameters index
(SPI) helps identify the source/destination pair. The security parameters index (SPI) in combination with
the source and destination addresses uniquely identifies an SA. An identical SA (same SPI, source, and
destination) must be configured on both systems exchanging IPsec protected traffic.
-> ipsec sa ALLoutMD5_SA ah source 664:1:1:1::199 destination 664:1:1:1::1 spi
2000 authentication HMAC-MD5 admin-state enable
-> ipsec sa ALLinMD5_SA ah source 664:1:1:1::1 destination 664:1:1:1::199 spi
2001 authentication HMAC-MD5 admin-state enable
7 Use the following show commands to verify the IPsec configuration:
-> show ipsec policy
-> show ipsec sa
-> show ipsec key sa-authentication
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 18-3
Configuring IPsec
Quick Steps for Configuring an IPsec Discard Policy
Quick Steps for Configuring an IPsec Discard
Policy
IPsec can be used for discarding IPv6 traffic as well as configuring encryption and authentication. For
discard policies, no rules, SAs or keys need to be defined.
1 Define the policy. The commands below use similar policy information as in the previous example but
the action has been changed to discard:
-> ipsec policy Discard_ALLoutMD5 source 664:1:1:1::199/64 destination
664:1:1:1::1/64 protocol any out discard admin-state enable
-> ipsec policy Discard_ALLinMD5 source 664:1:1:1::1/64 destination
664:1:1:1::199/64 protocol any in discard admin-state enable
2 Use the following show commands to verify the IPsec configuration:
-> show ipsec policy
-> show ipsec ipv6 statistics
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 18-4
Configuring IPsec
IPsec Overview
IPsec Overview
IPsec provides protection to IPv6 traffic. To achieve this, IPsec provides security services for IPv6 packets
at the network layer. These services include access control, data integrity, authentication, protection
against replay, and data confidentiality. IPsec enables a system to select the security protocols, encryption
and authentication algorithms, and use any cryptographic keys as required. IPsec uses the following two
protocols to provide security for an IPv6 datagram:
• Encapsulating Security Payload (ESP) to provide confidentiality, data origin authentication and
connectionless integrity.
• Authentication Header (AH) to provide connectionless integrity and data origin authentication for IPv6
datagrams and to provide optional protection against replay attacks. Unlike ESP, AH does not provide
confidentiality.
IPsec on an OmniSwitch operates in Transport mode. In transport mode only the payload of the IPv6
packet is encapsulated, and an IPsec header (AH or ESP) is inserted between the original IPv6 header and
the upper-layer protocol header. The figure below shows an IPv6 packet protected by IPsec in transport
mode.
IP Packet in IPsec Transport Mode
Note. The OmniSwitch currently supports the Transport Mode of operation.
Encapsulating Security Payload (ESP)
The ESP protocol provides a means to ensure privacy (encryption), source authentication, and content
integrity (authentication). It helps provide enhanced security of the data packet and protects it against
eavesdropping during transit.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 18-5
Configuring IPsec
IPsec Overview
Unlike AH which only authenticates the data, ESP encrypts data and also optionally authenticates it. It
provides these services by encrypting the original payload and encapsulating the packet between a header
and a trailer, as shown in the figure below.
16
24
32-bit
Security association identifier (SPI)
Sequence Number
Payload data (variable length)
Padding (0-255 bytes)
Pad Length
Next Header
Authentication Data (variable)
IP Packet protected by ESP
ESP is identified by a value of 50 in the IPv6 header. The ESP header is inserted after the IPv6 header and
before the upper layer protocol header. The Security Parameter Index (SPI) in the ESP header is a 32-bit
value that, combined with the destination address and protocol in the preceding IPv6 header, identifies the
security association (SA) to be used to process the packet. SPI helps distinguish multiple SA’s configured
for the same source and destination combination. The payload data field carries the data that is being
encrypted by ESP. The Authentication digest in the ESP header is used to verify data integrity.
Authentication is always applied after encryption, so a check for validity of the data is done upon receipt
of the packet and before decryption.
Encryption Algorithms
There are several different encryption algorithms that can be used in IPsec. However, the most commonly
used algorithms are “AES” and “3DES”. These algorithms are used for encrypting IPv6 packets.
• Advanced Encryption Standard - Cipher Block Chaining - (AES-CBC)
The AES-CBC mode comprises three different key lengths; AES-128, AES-192 and AES-256. Each block
of plaintext is XOR'd with the previous encrypted block before being encrypted again.
• Triple DES (3DES)
A mode of the DES encryption algorithm that encrypts data three times. Three 64-bit keys are used,
instead of one, for an overall key length of 192 bits (the first encryption is encrypted with second key, and
the resulting cipher text is again encrypted with a third key). 3DES is a more powerful version of DES.
Authentication Header (AH)
An Authentication Header (AH) provides connectionless integrity and data origin authentication. This
protocol permits communicating parties to verify that data was not modified in transit and that it was
genuinely transmitted from the apparent source. AH helps verify the authenticity/integrity of the content
and origin of a packet. It can optionally protect against replay attacks by using the sliding window
technique and discarding old packets. It authenticates the packet by calculating the checksum via hashbased message authentication code (HMAC) using a secret key and either HMAC-MD-5 or HMAC-SHA1
hash functions.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 18-6
Configuring IPsec
IPsec Overview
Authentication Algorithms
• HMAC-MD5 - An algorithm that produces a 128-bit hash (also called a digital signature or message
digest) from a message of arbitrary length and a 16-byte key. The resulting hash is used, like a
fingerprint of the input, to verify content and source authenticity and integrity.
• HMAC-SHA1 - An algorithm that produces a 160-bit hash from a message of arbitrary length and a
20-byte key. It is generally regarded as more secure than MD5 because of the larger hashes it produces.
• AES-XCBC-MAC-96 - An algorithm that uses AES [AES] in CBC mode [MODES] with a set of
extensions [XCBC-MAC-1] to overcome the limitations of the classic CBC-MAC algorithm. It uses
the AES block cipher with an increased block size and key length (128 bits) which enables it to
withstand continuing advances in crypto-analytic techniques and computational capability. Its goal is
to ensure that the datagram is authentic and cannot be modified in transit.
Unlike ESP, AH does not encrypt the data. Therefore, it has a much simpler header than ESP. The figure
below shows an AH-protected IPv6 packet.
Next Header(8 bits)
Payload Length(8 bits)
Reserved (16 bits)
Security association identifier (SPI) (32 bits)
Sequence Number (32 bits)
Authentication Data (Variable)
(Integrity Check Value)
IP Packet protected by AH
AH is identified by a value of 51 in the IPv6 header. The Next header field indicates the value of the upper
layer protocol being protected (for example, UDP or TCP) in the transport mode. The payload length field
in the AH header indicates the length of the header. The SPI, in combination with the source and
destination addresses, helps distinguish multiple SAs configured for the same source and destination
combination. The AH header provides a means to verify data integrity. It is similar to the integrity check
provided by the ESP header with one key difference. The ESP integrity check only verifies the contents of
the ESP payload. AH's integrity check also includes portions of the packet header as well.
IPsec on the OmniSwtich
IPsec allows the following 3 types of actions to be performed on an IPv6 datagram that matches the filters
defined in the security policy:
• The IPv6 datagram can be subjected to IPsec processing, i.e. encrypted, and/or authenticated via ESP
and AH protocols.
• The IPv6 datagram can be discarded.
• The IPv6 datagram can be permitted to pass without being subjected to any IPsec processing.
The system decides which packets are processed and how they are processed by using the combination of
the policy and the SA. The policy is used to specificy which IPsec protocols are used such as AH or ESP
while the SA specifies the algorithms such as AES and HMAC-MD5.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 18-7
Configuring IPsec
IPsec Overview
Securing Traffic Using IPsec
Securing traffic using IPsec requires the following main procedures below:
• Master Security Key—Used to encrypt SA keys when stored on the switch.
• Policies—Determines which traffic should be processed using IPsec.
• Policy Rules—Determines whether AH, ESP, or a combination of both should be used.
• Security Associations (SAs)—Determines which algorithms should be used to secure the traffic.
• SA Keys—Determines the keys to be used with the SA to secure the traffic.
Master Security Key
The master security key is used to encrypt and decrypt the configured SA keys that are saved to permanent
storage (e.g., boot.cfg file). If no master security key is configured, SA keys are stored unencrypted.
Therefore, configuring a master key is VITALLY IMPORTANT and STRONGLY RECOMMENDED. A
warning message will be logged if the config is saved witout a Master Security Key being set.
IPsec Policy
IPsec Policies define which traffic requires IPsec processing. The policy requires the source and
destination of the traffic to be specified as IPv6 addresses. The policy may cover all traffic from source to
destination or may further restrict it by specifying an upper-layer protocol, source, and/or destination
ports. Each policy is unidirectional, applying either to inbound or outbound traffic. Therefore, to cover all
traffic between a source and destination, two policies would need to be defined.
IPsec Policy Rules
Rules are created and applied to policies. Rules determine what type of encryption or authentication
should be used for the associated policy. For example, for a security policy where an IPv6 payload should
be protected by an ESP header, which should then be protected by an AH header, two rules would be
applied to the policy, one for ESP and one for AH.
Security Association (SA)
A Security Association, more commonly referred to as an SA, is a basic building block of IPsec. It
specifies the actual IPsec algorithms to be employed. SA is a unidirectional agreement between the
participants regarding the methods and parameters to use in securing a communication channel. A
Security Association is a management tool used to enforce a security policy in the IPsec environment. SA
actually specifies encryption and authentication between communicating peers.
Manually configured SAs are unidirectional; bi-directional communication requires at least two SAs, one
for each direction. Manually-configured SAs are specified by a combination of their SPI, source and
destination addresses. However, multiple SAs can be configured for the same source and destination
combination. Such SAs are distinguished by a unique Security Parameter Index (SPI).
SA Keys
Keys are used for encrypting and authenticating the traffic. Key lengths must match what is required by
the encryption or authentication algorithm specified in the SA. Key values may be specified either in
hexadecimal format or as a string.
Note. The OmniSwitch currently supports manually configured SAs only.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 18-8
Configuring IPsec
IPsec Overview
Discarding Traffic using IPsec
In order to discard IPv6 datagrams, a policy is configured in the same manner as an IPsec security policy,
the difference being that the action is set to ‘discard’ instead of ‘ipsec’. A discard policy can prevent IPv6
traffic from traversing the network.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 18-9
Configuring IPsec
Configuring IPsec on the OmniSwitch
Configuring IPsec on the OmniSwitch
Before configuring IPsec the following security best practices should be followed:
• Set the Master Security Key—This is used to encrypt SA keys when stored.
• Use SSH, HTTPS, or SNMPv3 to prevent sensitive information such as SA keys from being sent in the
clear.
• Restrict IPsec commands to authorized users only. This is described in Chapter 6, “Managing Switch
User Accounts.” in the OmniSwitch AOS Release 8 Switch Management Guide.
Configuring IPsec for securing IPv6 traffic on a switch requires several steps which are explained below
• Configure the master security key for the switch which is used to encrypt and decrypt the configured
SA keys. This is described in “Configuring an IPsec Master Key” on page 18-10.
• Configure an IPsec Security Policy on the switch. This is described in “Configuring an IPsec Policy”
on page 18-11.
• Set an IPsec rule for the configured IPsec Security Policy on the switch. This is described in
“Configuring an IPsec Rule” on page 18-14.
• Enable the Security Policy. This is described in “Enabling and Disabling a Policy” on page 18-12.
• Configure the authentication and encryption keys required for manually configured IPsec Security
associations (SA). This is described in “Configuring IPsec SA Keys” on page 18-16
• Configure an IPsec Security Association on the switch by setting parameters such as Security
Association type, encryption and authentication for SA. This is described in “Configuring an IPsec
SA” on page 18-15.
Configuring IPsec for discarding IPv6 traffic on a switch requires a single step:
• Configure the IPsec Discard policy on the switch which is used to discard or filter the IPv6 packets.
This is described in “Discarding Traffic using IPsec” on page 18-9.
Configuring an IPsec Master Key
The master security key is used to encrypt and decrypt the configured SA keys that are saved to permanent
storage (e.g., boot.cfg file). To set a master security key the first time, simply enter the ipsec security-key
command along with a new key value. For example:
-> ipsec security-key new_master_key_1
or
-> ipsec security-key 0x12345678123456781234567812345678
Note. The key value can be specified either in hexadecimal format (16 bytes in length) or as a string (16
characters in length). A warning message is logged if SA keys are set without the Master Key being set.
To change the master security key specify the old and new key values.
-> ipsec security-key new_master_key_1 new_master_key_2
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 18-10
Configuring IPsec
Configuring IPsec on the OmniSwitch
The above command replaces the old security key with the new key value. The old key value must be
entered to modify an existing key. If an incorrect old key value is entered, then setting the new key will
fail.
When the master security key is set or changed, its value is immediately propagated to the secondary
CMM. When the master security key is changed, save and synchronize the current configuration to ensure
the proper operation of IPsec in the event of a switch reboot or takeover.
Note.
• By default, no master security key is set for the switch. When no master security key is configured for
the switch, the SA key values are written unencrypted to permanent storage (boot.cfg or other
configuration file).
• When running in a virtual chassis setup, the master security key must be manually configured, to the
same value, on each switch.
Configuring an IPsec Policy
A policy determines how traffic is going to be processed. For example, policies are used to decide if a
particular IPv6 packet needs to be processed by IPsec or not. If security is required, the security policy
provides general guidelines as to how it should be provided, and if necessary, links to more specific detail.
Each IPsec security policy is unidirectional and can be applied to IPv6 inbound or outbound traffic
depending upon the security level required for the network. Therefore, in order to cover all traffic between
source and destination, a minimum of two policies need to be defined; one policy for inbound traffic and
another policy for outbound traffic.
To configure an IPsec policy, use the ipsec policy command along with the policy name, source IPv6
address, destination IPv6 address and optional parameters such as IPv6 port number, and protocol to
which the security policy gets applied. For example:
Local System
-> ipsec policy tcp_in source 3ffe:1:1:1::99 destination 3ffe:1:1:1::1 protocol
tcp in ipsec description “IPsec on all inbound TCP” admin-state enable
-> ipsec policy tcp_out source 3ffe:1:1:1::1 destination 3ffe:1:1:1:99 protocol
tcp out ipsec description “IPsec on all outbound TCP” admin-state enable
Remote System
-> ipsec policy tcp_out source 3ffe:1:1:1::99 destination 3ffe:1:1:1::1 protocol
tcp out ipsec description “IPsec on all outbound TCP” admin-state enable
-> ipsec policy tcp_in source 3ffe:1:1:1::1 destination 3ffe:1:1:1:99 protocol
tcp in ipsec description “IPsec on all inbound TCP” admin-state enable
The above commands configure a bi-directional IPsec policy for IPv6 traffic destined to or from the
specified IPv6 addresses and indicates the traffic should be processed using IPsec.
Prefixes can also be used when configuring a policy to match a range of addresses as shown below:
-> ipsec policy tcp_in source 3ffe::/16 destination 4ffe::/16 protocol tcp in ipsec
description “Any 3ffe to any 4ffe” admin-state enable
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 18-11
Configuring IPsec
Configuring IPsec on the OmniSwitch
Use the no form of the command to remove the configured IPsec policy. For example:
-> no ipsec policy tcp_in
Enabling and Disabling a Policy
You can administratively enable or disable the configured security policy by using the keywords adminstate enable/disable after the command as shown below:
-> ipsec policy tcp_in admin-state disable
The above command disables the configured IPsec security policy.
Note. Policies cannot be enabled until at least one rule is configured. See “Configuring an IPsec Rule” on
page 18-14.
Assigning a Priority to a Policy
You can use the optional priority parameter to assign a priority to the configured IPsec policy so that if
IPv6 traffic matches more than one configured policy, the policy with the highest priority is applied to the
traffic. The policy with the lower value has the higher priority. For example:
-> ipsec policy tcp_in priority 500
Note. If two security policies have the same priority then the one configured first will be processed first.
Policy Priority Example
-> ipsec policy telnet_deny priority 1000 source ::/0 destination ::/0 port 23
protocol tcp in discard
-> ipsec policy telnet_ipsec priority 200 source 3ffe:1200::/32 destination ::/0
port 23 protocol tcp in ipsec admin-state disable
-> ipsec policy telnet_ipsec rule 1 esp
-> ipsec policy telnet_ipsec admin-state enable
-> ipsec policy telnet_clear priority 100 source 3ffe:1200::1 destination ::/0
port 23 protocol tcp in none
-> ipsec policy telnet_malicious priority 1 source 3ffe:1200::35 destination ::/
0 port 23 protocol tcp in discard
1 Policy telnet_deny is the lowest priority policy. It will discard any incoming telnet connection
attempts.
2 Policy telnet_ipsec covers a subset of the source addresses of telnet_deny. With its greater priority, it
overrides telnet_deny and allows incoming telnet connections from addresses starting with the prefix
3ffe:1200::/32 as long as they are protected by ESP.
3 The policy telnet_clear overrides telnet_ipsec, allowing telnet connection attempts from the host to be
accepted without any IPsec protection.
4 Policy telnet_malicious can be configured to handle a known malicious system that otherwise would
fall under the telnet_ipsec policy. Its priority of 1 ensures that it always takes precedence and discards any
incoming telnet connection attempts from the known malicious system.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 18-12
Configuring IPsec
Configuring IPsec on the OmniSwitch
Assigning an Action to a Policy
To define what action will be performed on the traffic specified in the security policy, you can use the
following parameters:
• discard - Discards the IPv6 packets.
• ipsec - Allows IPsec processing of the traffic to which this policy is applied.
If the action is ipsec, then a rule must be defined before the policy can be enabled. Additionally, SAs and
SA keys must also be configured to support the rule.
• none - No action is performed.
The above commands could be modified to discard the traffic instead of processing using IPsec.
-> ipsec policy tcp_in discard
-> ipsec policy tcp_out discard
Configuring the Protocol for a Policy
You can define the type of protocol to which the security policy can be applied by using the protocol
parameter. For example:
-> ipsec policy udp_in source ::/0 destination 3ffe:200:200:4001::99 protocol
udp in ipsec description "IPsec on all inbound UDP" admin-state enable
The following table lists the various protocols that can be specified, refer to the ipsec policy command for
additional details.
protocol
any
icmp6[type type]
tcp
udp
ospf
vrrp
number protocol
Verifying a Policy
To verify the configured IPsec policy, use the show ipsec policy command. For example:
-> show ipsec policy
Name
Priority Source-> Destination
Protocol Direction Action State
-----------+--------+-----------------------------+--------+-------+-------+-----tcp_in
500
3ffe:1:1:1::99->3ffe:1:1:1::1
TCP
in
ipsec esp active
tcp_out
500
3ffe:1:1:1::1->3ffe:1:1:1::99
TCP
out
ipsec esp active
ftp-in-drop 100
::/0->::/0
TCP
in
discard disabled
telnet-in-1 100
2000::/48->::/0
TCP
in
ipsec
disabled
The above command provides examples of various configured policies.
Note. The presence of a ‘+’ sign in the ‘Source->Destination’ or ‘Action’ indicates the values has been
truncated to fit. View a specific security policy to view additional details.
You can also verify the configuration of a specific security policy by using the show ipsec policy
command followed by the name of the security policy. For example:
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 18-13
Configuring IPsec
Configuring IPsec on the OmniSwitch
-> show ipsec policy tcp_in
Name
= tcp_in
Priority
= 500
Source
= 3ffe:1:1:1::99
Destination = 3ffe:1:1:1::1
Protocol
= TCP
Direction
= in
Action
= ipsec
State
= active
Rules:
1 : esp
Description:
IPsec on all inbound TCP
Configuring an IPsec Rule
To configure an IPsec rule for a configured IPsec security policy, use the ipsec policy rule command
along with the policy name, index value for the IPsec policy rule, and IPsec protocol type (AH or ESP).
For example:
-> ipsec policy tcp_in rule 1 esp
The above command applies the configured IPsec security policy with rule 1 to ESP. The index value
specified determines the order in which a rule should get applied to the payload. The policy name
configured for the IPsec policy rule should be the same as the policy name configured for the IPsec
security policy. It’s possible to first encrypt the original content of an IPv6 packet using ESP and then
authenticate the packet using AH by configuring an ESP rule with an index of one and then configuring
the AH rule with an index of two. For example:
-> ipsec policy tcp_in rule 1 esp
-> ipsec policy tcp_in rule 2 ah
Use the no form of this command to remove the configured IPsec rule for an IPsec security policy. For
example:
-> no ipsec policy tcp_in rule 2
Verifying IPsec rule for IPsec Policy
To verify the IPsec policy, use the show ipsec policy command. For example:
-> show ipsec policy tcp_in
Name
= tcp_in
Priority
= 500
Source
= 3ffe:1:1:1::99
Destination = 3ffe:1:1:1::1
Protocol
= TCP
Direction
= in
Action
= ipsec
State
= active
Rules:
1 : esp,
2 : ah
Description:
IPsec on all inbound TCP
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 18-14
Configuring IPsec
Configuring IPsec on the OmniSwitch
Configuring an IPsec SA
IPsec Security Association (SA) is a set of security information that describes a particular kind of secure
connection between two devices. An SA specifies the actual IPsec algorithms applied to the IPv6 traffic
(e.g. encryption using 3DES, HMAC-SHA1 for authentication).
To configure an IPsec Security Association, use the ipsec sa command along with the type of security
association, IPv6 source address, IPv6 destination address, encryption and authentication algorithms used
for SA. For example:
Local System
-> ipsec sa tcp_in_ah ah source 3ffe:1:1:1::99 destination 3ffe:1:1:1::1 spi
9901 authentication hmac-sha1 description "HMAC SHA1 on traffic from 99 to 1"
-> ipsec sa tcp_out_ah ah source 3ffe:1:1:1::1 destination 3ffe:1:1:1::99 spi
9902 authentication hmac-sha1 description "HMAC SHA1 on traffic from 1 to 99"
Remote System
-> ipsec sa tcp_out_ah ah source 3ffe:1:1:1::99 destination 3ffe:1:1:1::1 spi
9901 authentication hmac-sha1 description "HMAC SHA1 on traffic from 99 to 1"
-> ipsec sa tcp_in_ah ah source 3ffe:1:1:1::1 destination 3ffe:1:1:1::99 spi
9902 authentication hmac-sha1 description "HMAC SHA1 on traffic from 1 to 99"
The above commands configure bi-directional IPsec SAs of AH type for data traffic to and from source
IPv6 addresses 3ffe:1:1:1::99 and 3ffe:1:1:1::1 with security parameter indexes (SPI) of 9901 and 9902.
The combination of SPI, source, and destination addresses uniquely identify an SA. The above commands
also configure hmac-shal as the type of authentication algorithm which is to be used for the IPv6 traffic
covered by the configured SA.
Note. The IPsec endpoints must have identical SAs (SPI, source address, destination addresses) configured.
Use the admin-state enable/disable parameters to enable or disable the SA.
-> ipsec sa tcp_in_ah admin-state enable
Use the no form of the command to disable the SA.
-> no ipsec sa tcp_in_ah
Configuring ESP or AH
The IPsec SA can be configured as ESP or AH. In the above example, the IPsec SA is configured as AH.
You can also configure the SA as ESP, as shown below:
-> ipsec sa tcp_in_ah esp source 3ffe:1:1:1::99 destination 3ffe:1:1:1::1 spi
9901 encryption 3DES-CBC description "3DES on traffic from 99 to 1"
You can use the encryption parameter to specify the encryption algorithm to be used for the traffic
covered by the SA. This parameter can only be used when the SA type is ESP.
Configuring the ESP Key Size
Some types of encryption algorithms allow the key size to specified; specifying the key lengths overrides
their default values. To do so, use the key-size option after the specified encryption algorithm. For
example:
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 18-15
Configuring IPsec
Configuring IPsec on the OmniSwitch
-> ipsec sa tcp_in_ah esp source 3ffe:1:1:1::99 destination 3ffe:1:1:1::1 spi
9901 encryption aes-cbc key-size 192
The above command configures an IPsec SA of ESP using aes-cbs and a key length of 192 bits. You can
allow an IPsec SA to operate as an ESP confidentiality-only SA by using the none option with the
authentication parameter or by simply omitting the authentication parameter from the command.
Refer to “Configuring IPsec SA Keys” on page 18-16 or the ipsec sa command for supported encryption
types and key lengths.
Verifying IPsec SA
To display the configured IPsec SA, use the show ipsec sa command. For example:
-> show ipsec sa
Name
Type Source-> Destination[SPI]
Encryption Authentication State
---------+---+----------------------------------------+----------+-------------+--tcp_in_ah ah
tcp_out_ah ah
3ffe:1:1:1::99 -> 3ffe:1:1:1::1 [9901]
3ffe:1:1:1::1 -> 3ffe:1:1:1::99 [9902]
none
none
hmac-sha1
hmac-sha1
active
active
To display the configuration of a specific IPsec SA, use the show ipsec sa command followed by the
name of the configured IPsec SA. For example:
-> show ipsec sa tcp_in_ah
Name
Type
Source
Destination
SPI
Encryption
Authentication
State
Description:
"HMAC SHA1 on
=
=
=
=
=
=
=
=
tcp_in_ah
AH
3ffe:1:1:1::99,
3ffe:1:1:1::1,
9901
none
hmac-sha1
active
traffic from 99 to 1
Configuring IPsec SA Keys
To configure the authentication and encryption keys for a manually configured SA, use the ipsec key
command along with the SA name and key value which will be used for AH or ESP. For example:
-> ipsec key tcp_in_ah sa-authentication 0x11223344556677889900112233445566
The above command configures an IPsec SA key named tcp_in_ah. This IPsec SA key will be used for the
AH authentication protocol and has a value of 0x11223344556677889900112233445566.
The length of the key value must match the value that is required by the encryption or authentication
algorithm that will use the key. The table shown below displays the key lengths for the supported algorithms:
Algorithm
Key Length
3DES-CBC
192 Bits
AES-CBC
128,192, or 256
Bits
HMAC-MD5
128 Bits
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 18-16
Configuring IPsec
Configuring IPsec on the OmniSwitch
Algorithm
Key Length
HMAC-SHA1
160 Bits
AES-XCBC-MAC
128 Bits
Use the following information to determine how to create the proper key size:
• Number of Characters = Key Size (in bits) / 8; Ex. A 160-bit key would require 20 characters for the
key.
• Number of Hexidecimal = Key Size (in bits) / 4; Ex. A 160-bit key would require 40 hexidecimal
digits.
Note. The name parameter must be the same as the name of the manually configured IPsec SA. Also, the
combination of the key name and type must be unique.
Use the no form of this command to delete the configured IPsec SA key. For example:
-> no ipsec key tcp_in_ah
Verifying IPsec SA Key
To display the encryption key values which are configured for manually configured IPsec SAs, use the
show ipsec key command For example:
-> show ipsec key sa-encryption
Encryption Keys
Name
Length (bits)
--------------------+--------------sa_1
192
sa_2
160
sa_3
64
The above command shows the number of manually configured SAs along with their encryption key
lengths in bits respectively. To display the IPsec SA keys used for authentication, use the show ipsec key
command, as shown below:
-> show ipsec key sa-authentication
Authentication Keys
Name
Length (bits)
--------------------+---------------tcp_in_ah
160
sa_1
128
sa_5
160
The above command shows the number of manually configured SAs along with their authentication key
lengths in bits respectively.
Note. Due to security reasons, key values will not be displayed; only key names and key lengths will be
displayed.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 18-17
Configuring IPsec
Configuring IPsec on the OmniSwitch
Once IPsec is configured for IPv6 on the switch, you can monitor the incoming and outgoing packets for
the configured parameters by using the show ipsec ipv6 statistics command.
-> show ipsec ipv6 statistics
Inbound:
Successful
Policy violation
No SA found
Unknown SPI
AH replay check failed
ESP replay check failed
AH authentication success
AH authentication failure
ESP authentication success
ESP authentication failure
Packet not valid
No memory available
Outbound:
Successful
Policy violation
No SA found
Packet not valid
No memory available
=
=
=
=
=
=
=
=
=
=
=
=
2787
0
0
0
0
0
93
0
25
0
0
0
=
=
=
=
=
5135
0
19
0
0
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 18-18
Configuring IPsec
Configuring IPsec on the OmniSwitch
Enabling and Disabling Default Discard Policy
A default discard IPsec policy drops all the inbound traffic that does not match an IPsec policy. This
policy on its own drops all the incoming traffic destined for the switch, hence, it is required to add
appropriate higher priority policies to allow the desired traffic to be received. The default discard policy is
not applied to the forwarded traffic.
To enable an default discard IPsec policy, use the enable keyword:
-> ipsec policy default-discard admin-state enable
To disable an default discard IPsec policy, use the disable keyword:
-> ipsec policy default-discard admin-state disable
The default discard policy on its own drops all the incoming traffic destined for the switch. It is required to
add appropriate higher priority policies to allow the desired traffic to be received. At a minimum, policies
must be added to allow neighbor discovery traffic to be accepted.
For example:
-> ipsec policy ns-in priority 100 source ::/0 destination ::/0 protocol ICMP6
type 135 in none
-> ipsec policy na-in priority 100 source ::/0 destination ::/0 protocol ICMP6
type 136 in none
show ipsec policy indicates whether the default discard policy is enabled or disabled.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 18-19
Configuring IPsec
Additional Examples
Additional Examples
Configuring ESP
The example below shows the commands for configuring ESP between two OmniSwitches for all TCP
traffic.
Switch A
Switch B
ESP
IPv6 address: 3ffe::100
IPv6 address: 3ffe::200
ESP Between Two OmniSwitches
Switch A
-> ipsec security-key master-key-12345
-> ipsec policy tcp_out source 3ffe::100 destination 3ffe::200 protocol tcp out
ipsec description “IPsec on TCP to 200”
-> ipsec policy tcp_in source 3ffe::200 destination 3ffe::100 protocol tcp in
ipsec description “IPsec on TCP from 200”
-> ipsec policy tcp_out rule 1 esp
-> ipsec policy tcp_in rule 1 esp
-> ipsec policy tcp_out admin-state enable
-> ipsec policy tcp_in admin-state enable
-> ipsec sa tcp_out_esp esp source 3ffe::100 destination 3ffe::200 spi 1000
encryption des-cbc authentication hmac-sha1 description “ESP to 200” admin-state
enable
-> ipsec sa tcp_in_esp esp source 3ffe::200 destination 3ffe::100 spi 1001
encryption des-cbc authentication hmac-sha1 description “ESP from 200” adminstate enable
-> ipsec key tcp_out_esp sa-encryption 12345678
-> ipsec key tcp_out_esp sa-authentication 12345678901234567890
-> ipsec key tcp_in_esp sa-encryption 12345678
-> ipsec key tcp_in_esp sa-authentication 12345678901234567890
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 18-20
Configuring IPsec
Additional Examples
Switch B
-> ipsec security-key master-key-12345
-> ipsec policy tcp_out source 3ffe::200 destination 3ffe::100 protocol tcp out
ipsec description “IPsec on TCP to 100”
-> ipsec policy tcp_in source 3ffe::100 destination 3ffe::200 protocol tcp in
ipsec description “IPsec on TCP from 100”
-> ipsec policy tcp_out rule 1 esp
-> ipsec policy tcp_in rule 1 esp
-> ipsec policy tcp_out admin-state enable
-> ipsec policy tcp_in admin-state enable
-> ipsec sa tcp_out_esp esp source 3ffe::200 destination 3ffe::100 spi 1001
encryption des-cbc authentication hmac-sha1 description “ESP to 100” admin-state
enable
-> ipsec sa tcp_in_esp esp source 3ffe::100 destination 3ffe::200 spi 1000
encryption des-cbc authentication hmac-sha1 description “ESP from 100” adminstate enable
-> ipsec key tcp_out_esp sa-encryption 12345678
-> ipsec key tcp_out_esp sa-authentication 12345678901234567890
-> ipsec key tcp_in_esp sa-encryption 12345678
-> ipsec key tcp_in_esp sa-authentication 12345678901234567890
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 18-21
Configuring IPsec
Additional Examples
Discarding RIPng Packets
RIPng uses the well known address of ff02::9 to advertise routes. The following example shows how
IPsec can be configured to drop all RIPng packets.
Switch A
Switch B
Link Local: fe80::100
Link Local: fe80::200
Discarding RIPng Packets
Switch A
-> ipsec policy DISCARD_UDPout source fe80::100 destination ff02::9 protocol udp
out discard
-> ipsec policy DISCARD_UDPin source fe80::200 destination ff02::9 protocol udp
in discard
Switch B
-> ipsec policy DISCARD_UDPout source fe80::200 destination ff02::9 protocol udp
out discard
-> ipsec policy DISCARD_UDPin source fe80::100 destination ff02::9 protocol udp
in discard
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 18-22
Configuring IPsec
Verifying IPsec Configuration
Verifying IPsec Configuration
To display information such as details about manually configured IPsec Security Associations and other
IPsec parameters configured on the switch, use the show commands listed in the following table::
show ipsec sa
Displays information about manually configured IPsec SAs.
show ipsec key
Displays encryption and authentication key values for the manually
configured IPsec SA.
show ipsec policy
Displays information about IPsec Security Policies configured for the
switch.
show ipsec ipv6 statistics
Displays IPsec statistics for IPv6 traffic.
For more information about the resulting displays form these commands, see the “IPsec Commands”
chapter in the OmniSwitch AOS Release 8 CLI Reference Guide.
Examples of the above commands and their outputs are given in the section “Configuring IPsec on the
OmniSwitch” on page 18-10.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 18-23
19
Configuring RIP
Routing Information Protocol (RIP) is a widely used Interior Gateway Protocol (IGP) that uses hop count
as its routing metric. RIP-enabled routers update neighboring routers by transmitting a copy of their own
routing table. The RIP routing table uses the most efficient route to a destination, that is, the route with the
fewest hops and longest matching prefix.
The switch supports RIP version 1 (RIPv1), RIP version 2 (RIPv2), and RIPv2 that is compatible with
RIPv1. It also supports text key and MD5 authentication, on an interface basis, for RIPv2.
In This Chapter
This chapter describes RIP and how to configure it through the Command Line Interface (CLI). It includes
instructions for configuring basic RIP routing and fine-tuning RIP by using optional RIP configuration
parameters (e.g., RIP send/receive option and RIP interface metric). It also details RIP redistribution,
which allows a RIP network to exchange routing information with networks running different protocols
(e.g., OSPF and BGP). CLI commands are used in the configuration examples; for more details about the
syntax of commands, see the OmniSwitch AOS Release 8 CLI Reference Guide.
This chapter provides an overview of RIP and includes information about the following procedures:
• RIP Routing
–
–
–
–
Loading RIP (see page 19-6)
Enabling RIP (see page 19-7)
Creating a RIP Interface (see page 19-7)
Enabling a RIP Interface (see page 19-7)
• RIP Options
–
–
–
–
–
–
Configuring the RIP Forced Hold-Down Interval (see page 19-9)
Configuring the RIP Update Interval (see page 19-9)
Configuring the RIP Invalid Timer (see page 19-10)
Configuring the RIP Garbage Timer (see page 19-10)
Configuring the RIP Hold-Down Timer (see page 19-10)
Enabling a RIP Host Route (see page 19-11)
• RIP Redistribution
– Configuring Route Redistribution (see page page 19-12)
• RIP Security
– Configuring Authentication Type (see page 19-18)
– Configuring Passwords (see page 19-18)
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 19-1
Configuring RIP
RIP Defaults
RIP Defaults
The following table lists the defaults for RIP configuration through the ip rip command.
Description
Command
Default
RIP Status
ip rip admin-state
disable
RIP Forced Hold-Down Interval ip rip force-holddowntimer
0
RIP Update Interval
ip rip update-interval
30 seconds
RIP Invalid Timer
ip rip invalid-timer
180 seconds
RIP Garbage Timer
ip rip garbage-timer
120 seconds
RIP Hold-Down Timer
ip rip holddown-timer
0
RIP Interface Metric
ip rip interface metric
1
RIP Interface Send Version
ip rip interface send-version
v2
RIP Interface Receive Version
ip rip interface recv-version
both
RIP Host Route
ip rip host-route
enable
RIP Route Tag
ip rip host-route
0
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 19-2
Configuring RIP
Quick Steps for Configuring RIP Routing
Quick Steps for Configuring RIP Routing
To forward packets to a device on a different VLAN, you must create a router interface on each VLAN.
To route packets by using RIP, you must enable RIP and create a RIP interface on the router interface. The
following steps show you how to enable RIP routing between VLANs “from scratch”. If active VLANs
and router ports have already been created on the switch, go to Step 7.
1 Create VLAN 1 with a description (e.g., VLAN 1) by using the vlan command. For example:
-> vlan 1 name “VLAN 1”
2 Create VLAN 2 with a description (e.g., VLAN 2) by using the vlan command. For example:
-> vlan 2 name “VLAN 2”
3 Assign an active port to VLAN 1 by using the vlan members untagged command. For example, the
following command assigns port 1 on slot 1 to VLAN 1:
-> vlan 1 members port 1/1 untagged
4 Assign an active port to VLAN 2 by using the vlan members command. For example, the following
command assigns port 2 on slot 1 to VLAN 2:
-> vlan 2 members port 1/2 untagged
5 Configure an IP interface to enable IP routing on a VLAN by using the ip interface command. For
example:
-> ip interface vlan-1 address 171.10.1.1 vlan 1
6 Configure an IP interface to enable IP routing on a VLAN by using the ip interface command. For
example:
-> ip interface vlan-2 address 171.11.1.1 vlan 2
7 Load RIP into the switch memory by using the ip load rip command. For example:
-> ip load rip
8 Enable RIP on the switch by using the ip rip admin-state command. For example:
-> ip rip admin-state enable
9 Create a RIP interface on VLAN 1 by using the ip rip interface command. For example:
-> ip rip interface vlan-1
10 Enable the RIP interface by using the ip rip interface admin-state command. For example:
-> ip rip interface vlan-1 admin-state enable
11 Create an RIP interface on VLAN 2 by using the ip rip interface command. For example:
-> ip rip interface vlan-2
Note. For more information on VLANs and router ports, see Chapter 4, “Configuring VLANs.”
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 19-3
Configuring RIP
RIP Overview
RIP Overview
In switching, traffic can be transmitted from one media type to another within the same VLAN. Switching
happens at Layer 2, the link layer; routing happens at Layer 3, the network layer. In IP routing, traffic can
be transmitted across VLANs. When IP routing is enabled, the switch uses routing protocols to build
routing tables that keep track of stations in the network and decide the best path for forwarding data.
When the switch receives a packet to be routed, it strips off the MAC header and examines the IP header.
It looks up the source/destination address in the routing table, and then adds the appropriate MAC address
to the packet. Calculating routing tables and stripping/adding MAC headers to packets is performed by
switch software.
IP is associated with several Layer 3 routing protocols. RIP is built into the base code loaded onto the
switch. Others are part of the optional OmniSwitch Advanced Routing Software implementation. IP
supports the following IP routing protocols:
• RIP—An IGP that defines how routers exchange information. RIP makes routing decisions by using a
“least-cost path” method. RIPv1 and RIPv2 services allow the switch to learn routing information from
neighboring RIP routers. For more information and instructions for configuring RIP, see “RIP
Routing” on page 19-6.
• Open Shortest Path First (OSPF)—An IGP that provides a routing function similar to RIP but uses
different techniques to determine the best route for a datagram. OSPF is part of the optional Advanced
Routing Software. For more information see the “Configuring OSPF” chapter in the OmniSwitch AOS
Release 8 Advanced Routing Configuration Guide.
When RIP is initially enabled on a switch, it issues a request for routing information, and listens for
responses to the request. If a switch configured to supply RIP hears the request, it responds with a
response packet based on information in its routing database. The response packet contains destination
network addresses and the routing metric for each destination. When a RIP response packet is received,
RIP takes the information and rebuilds the switch’s routing database, adding new routes and “better”
(lower metric) routes to destinations already listed in the database.
RIP uses a hop count metric to measure the distance to a destination. In the RIP metric, a switch advertises
directly connected networks at a metric of 1. Networks that are reachable through one other gateway are 2
hops, networks that are reachable through two gateways are 3 hops, etc. Thus, the number of hops (or hop
count) along a path from a given source to a given destination refers to the number of networks that are
traversed by a datagram along that path. When a switch receives a routing update that contains a new or
changed destination network entry, the switch adds one to the metric value indicated in the update and
enters the network in the routing table. After updating its routing table, the switch immediately begins
transmitting routing updates to inform other network switches of the change. These updates are sent
independently of the regularly scheduled updates. By default, RIP packets are broadcast every 30 seconds,
even if no change has occurred anywhere in a route or service.
RIP deletes routes from the database if the next switch to that destination says the route contains more
than 15 hops. In addition, all routes through a gateway are deleted by RIP if no updates are received from
that gateway for a specified time period. If a gateway is not heard from for 120 seconds, all routes from
that gateway are placed in a hold-down state. If the hold-down timer value is exceeded, the routes are
deleted from the routing database. These intervals also apply to deletion of specific routes.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 19-4
Configuring RIP
RIP Overview
RIP Version 2
RIP version 2 (RIPv2) adds additional capabilities to RIP. Not all RIPv2 enhancements are compatible
with RIPv1. To avoid supplying information to RIPv1 routes that could be misinterpreted, RIPv2 can only
use non-compatible features when its packets are multicast. Multicast is not supported by RIPv1. On
interfaces that are not compatible with IP multicast, the RIPv1-compatible packets used do not contain
potentially confusing information. RIPv2 enhancements are listed below.
• Next Hop—RIPv2 can advertise a next hop other than the switch supplying the routing update. This
capability is useful when advertising a static route to a silent switch not using RIP, since packets
passing through the silent switch do not have to cross the network twice.
• Network Mask—RIPv1 assumes that all subnetworks of a given network have the same network mask.
It uses this assumption to calculate the network masks for all routes received. This assumption prevents
subnets with different netmasks from being included in RIP packets. RIPv2 adds the ability to specify
the network mask with each network in a packet. Because RIPv1 switches ignore the network mask in
RIPv2 packets, their calculation of the network mask could possibly be wrong. For this reason, RIPv1compatible RIPv2 packets cannot contain networks that would be misinterpreted by RIPv1. These
networks must only be provided in native RIPv2 packets that are multicast.
• Authentication—RIPv2 packets can contain an authentication key that can be used to verify the
validity of the supplied routing data. Authentication can be used in RIPv1-compatible RIPv2 packets,
but RIPv1 switches ignore authentication information. Authentication is a simple password in which an
authentication key of up to 16 characters is included in the packet. If this key does not match the
configured authentication key, the packet is discarded. For more information on RIP authentication, see
“RIP Security” on page 19-18.
• IP Multicast—IP Multicast Switching (IPMS) is a one-to-many communication technique employed by
emerging applications such as video distribution, news feeds, netcasting, and resource discovery.
Unlike unicast, which sends one packet per destination, multicast sends one packet to all devices in any
subnetwork that has at least one device requesting the multicast traffic. For more information on IPMS,
see Chapter 25, “Configuring IP Multicast Switching.”
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 19-5
Configuring RIP
RIP Routing
RIP Routing
IP routing requires IP router interfaces to be configured on VLANs and a routing protocol to be enabled
and configured on the switch. RIP also requires a RIP interface to be created and enabled on the routing
interface. In the illustration below, a router interface and RIP interface have been configured on each
VLAN. Therefore, workstations connected to ports on VLAN 1 on Switch 1 can communicate with
VLAN 2; workstations connected to ports on VLAN 3 on Switch 2 can communicate with VLAN 2. Also,
ports from both switches have been assigned to VLAN 2, and a physical connection has been made
between the switches. Therefore, workstations connected to VLAN 1 on Switch 1 can communicate with
workstations connected to VLAN 3 on Switch 2.
Switch 1
Switch 2
Router interface/
= RIP Interface
RIP Routing Table
VLAN 1
110.0.0.0
110.0.0.1
VLAN 2
120.0.0.0
RIP Routing Table
Physical
Connection
VLAN 2
120.0.0.0
110.0.0.2
VLAN 3
130.0.0.0
130.0.0.1
130.0.0.2
RIP Routing
Loading RIP
When the switch is initially configured, RIP must be loaded into the switch memory. Use the ip load rip
command to load RIP.
To remove RIP from the switch memory, you must manually edit the boot.cfg file. The boot.cfg file is an
ASCII text-based file that controls many of the switch parameters. Open the file and delete all references
to RIP. You must reboot the switch when this is complete.
Note. In simple networks where only IP forwarding is required, you need not use RIP. If you are not using
RIP, it is best not to load it to save switch resources.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 19-6
Configuring RIP
RIP Routing
Enabling RIP
RIP is disabled by default. Use the ip rip admin-state command to enable RIP routing on the switch. For
example:
-> ip rip admin-state enable
Use the ip rip admin-state disable command to disable RIP routing on the switch. Use the show ip rip
command to display the current RIP status.
Creating a RIP Interface
You must create a RIP interface on a VLAN’s IP router interface to enable RIP routing. Enter the ip rip
interface command followed by the name of the VLAN router port. For example, to create a RIP interface
on a router port with a name of rip-1 you would enter:
-> ip rip interface rip-1
Use the no ip rip interface command to delete a RIP interface. Use the show ip rip interface command
to display configuration and error information for a RIP interface.
Note. You can create a RIP interface even if an IP router interface has not been configured. However, RIP
does not function unless a RIP interface is created and enabled on an IP router interface. See Chapter 4,
“Configuring VLANs,” and Chapter 15, “Configuring IP,” for more information.
Enabling a RIP Interface
Once you have created a RIP interface, you must enable it to enable RIP routing. Use the ip rip interface
admin-state command followed by the interface IP address to enable a RIP interface. For example, to
enable RIP routing on a RIP interface rip-1 you would enter:
-> ip rip interface rip-1 admin-state enable
To disable an RIP interface, use the disable keyword with the ip rip interface admin-state command. For
example to disable RIP routing on a RIP interface rip-1 you would enter:
-> ip rip interface rip-1 admin-state disable
Configuring the RIP Interface Send Option
The RIP Send option defines the type(s) of RIP packets that the interface sends. Using this command
overrides RIP default behavior. Other devices must be able to interpret the information provided by this
command or routing information is not properly exchanged between the switch and other devices on the
network.
Use the ip rip interface send-version command to configure an individual RIP interface Send option.
Enter the IP address of the RIP interface, and then enter a Send option. For example, to configure a RIP
interface rip-1 to send only RIPv1 packets you would enter:
-> ip rip interface rip-1 send-version v1
The Send options are:
• v1. Only RIPv1 packets is sent by the switch.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 19-7
Configuring RIP
RIP Routing
• v2. Only RIPv2 packets is sent by the switch.
• v1compatible. Only RIPv2 broadcast packets (not multicast) is sent by the switch.
• none. Interface does not forward RIP packets.
To set the default RIP send option use the ip rip interface send-version command.
Use the show ip rip interface command to display the current interface send option.
Configuring the RIP Interface Receive Option
The RIP Receive option defines the type(s) of RIP packets that the interface accepts. Using this command
overrides RIP default behavior. Other devices must be able to interpret the information provided by this
command or routing information is not properly exchanged between the switch and other devices on the
network.
Use the ip rip interface recv-version command to configure an individual RIP interface Receive option.
Enter the IP address of the RIP interface, and then enter a Receive option. For example, to configure RIP
interface rip-1 to receive only RIPv1 packets you would enter:
-> ip rip interface rip-1 recv-version v1
The Receive options are:
• v1. Only RIPv1 packets is received by the switch.
• v2. Only RIPv2 packets is received by the switch.
• both. Both RIPv1 and RIPv2 packets is received by the switch.
• none. Interface ignores any RIP packets received.
To set the default RIP receive option use the ip rip interface recv-version command.
Configuring the RIP Interface Metric
You can set priorities for routes generated by a switch by assigning a metric value to routes generated by
that switch’s RIP interface. For example, routes generated by a neighboring switch can have a hop count
of 1. However, you can lower the priority of routes generated by that switch by increasing the metric value
for routes generated by the RIP interface.
Note. When you configure a metric for a RIP interface, this metric cost is added to the metric of the
incoming route.
Use the ip rip interface metric command to configure the RIP metric or cost for routes generated by a
RIP interface. Enter the IP address of the RIP interface as well as a metric value. For example, to set a
metric value of 2 for the RIP interface rip-1 you would enter:
-> ip rip interface rip-1 metric 2
The valid metric range is 1 to 15. To change the default value use the ip rip interface metric command.
Use the show ip rip interface command to display the current interface metric.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 19-8
Configuring RIP
RIP Options
Configuring the RIP Interface Route Tag
Use the ip rip route-tag command to configure a route tag value for routes generated by the RIP
interface. This value is used to set priorities for RIP routing. Enter the command and the route tag value.
For example, to set a route tag value of 1 you would enter:
-> ip rip route-tag 1
The valid route tag value range is 1 to 2147483647.
Use the show ip rip command to display the current route tag value.
RIP Options
The following sections detail procedures for configuring RIP options. RIP must be loaded and enabled on
the switch before you can configure any of the RIP configuration options.
Configuring the RIP Forced Hold-Down Interval
The RIP forced hold-down timer value defines an amount of time, in seconds, during which routing
information regarding better paths is suppressed. A route enters into a forced hold-down state when an
update packet is received that indicates the route is unreachable and when this timer is set to a non-zero
value. After this timer has expired and if the value is less that 120 seconds, the route enters a hold-down
state for the rest of the period until the remainder of the 120 seconds has also expired. During this time the
switch accepts any advertisements for better paths that are received.
Note that the RIP forced hold-down timer is not the same as the RIP hold-down timer. The forced holddown timer defines a separate interval that overlaps the hold-down state. During the forced hold-down
timer interval, the switch does not accept better routes from other gateways. For more information on RIP
hold-down timer, see “Configuring the RIP Hold-Down Timer” on page 19-10.
Use the ip rip force-holddowntimer command to configure the interval during which a RIP route
remains in a forced hold-down state. Enter the command and the forced hold-down interval value, in
seconds. For example, to set a forced hold-down interval value of 10 seconds you would enter:
-> ip rip force-holddowntimer 10
The valid forced hold-down timer range is 0 to 120.
Use the show ip rip command to display the current forced hold-down timer value.
Configuring the RIP Update Interval
The RIP update interval defines the time interval, in seconds, when routing updates are sent out. This
interval value must be less than or equal to one-third the value of the invalid timer.
Use the ip rip update-interval command to configure the interval during which a RIP route remains in an
update state. Enter the command and the update interval value, in seconds. For example, to set an update
interval value of 45 seconds, you would enter:
-> ip rip update-interval 45
The valid update interval range is 1 to 120.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 19-9
Configuring RIP
RIP Options
Configuring the RIP Invalid Timer
The RIP invalid timer value defines the time interval, in seconds, during which a route remains active in
the Routing Information Base (RIB) before it is moved to the invalid state. This timer value must be at
least three times the update interval value.
Use the ip rip invalid-timer command to configure the time interval that must elapse before an active
route becomes invalid. Enter the command and the invalid timer value, in seconds. For example, to set an
invalid interval value of 270 seconds you would enter:
-> ip rip invalid-timer 270
The invalid timer range is 3 to 360.
Configuring the RIP Garbage Timer
The RIP garbage timer defines the time interval, in seconds, that must elapse before an expired route is
removed from the RIB.
Note that during the garbage interval, the router advertises the route with a metric of INFINITY.
Use the ip rip garbage-timer command to configure the time interval after which an expired route is
removed from the RIB. Enter the command and the garbage timer value, in seconds. For example, to set a
garbage timer value of 180 seconds you would enter:
-> ip rip garbage-timer 180
The garbage timer range is 0 to 180.
Configuring the RIP Hold-Down Timer
The RIP hold-down timer defines the time interval, in seconds, during which a route remains in the
holddown state.
Whenever RIP detects a route with a higher metric than the route in the RIB, the route with the higher
metric goes into the hold-down state. The route updates with a metric of INFINITY are excluded.
Use the ip rip holddown-timer command to configure the interval during which a RIP route remains in
the hold-down state. Enter the command and the hold-down timer value, in seconds. For example, to set a
hold-down timer value of 10 seconds you would enter:
-> ip rip holddown-timer 10
The hold-down timer range is 0 to 120.
Reducing the Frequency of RIP Routing Updates
To optimize system performance, you can reduce the frequency of the RIP routing updates by increasing
the length of the update, invalid, and garbage timers by about 50% above their default values. For
example:
-> ip rip update-interval 45
-> ip rip invalid-timer 270
-> ip rip garbage-timer 180
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 19-10
Configuring RIP
RIP Options
Enabling a RIP Host Route
A host route differs from a network route, which is a route to a specific network. This command allows a
direct connection to the host without using the RIP table. If a switch is directly attached to a host on a
network, use the ip rip host-route command to enable a default route to the host. For example:
-> ip rip host-route
The default is to enable a default host route.
Use the no ip rip host-route command to disable the host route. Use the show ip rip command to display
the current host route status.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 19-11
Configuring RIP
Configuring Redistribution
Configuring Redistribution
It is possible to configure the RIP protocol to advertise routes learned from other routing protocols into the
RIP network. Such a process is referred to as route redistribution and is configured using the ip redist
command.
Redistribution uses route maps to control how external routes are learned and distributed. A route map
consists of one or more user-defined statements that can determine which routes are allowed or denied
access to the RIP network. In addition a route map can also contain statements that modify route
parameters before they are redistributed.
When a route map is created, it is given a name to identify the group of statements that it represents. This
name is required by the ip redist command. Therefore, configuring route redistribution involves the
following steps:
1 Create a route map, as described in “Using Route Maps” on page 19-12.
2 Configure redistribution to apply a route map, as described in “Configuring Route Map Redistribution”
on page 19-15.
Using Route Maps
A route map specifies the criteria that are used to control redistribution of routes between protocols. Such
criteria is defined by configuring route map statements. There are three different types of statements:
• Action. An action statement configures the route map name, sequence number, and whether or not
redistribution is permitted or denied based on route map criteria.
• Match. A match statement specifies criteria that a route must match. When a match occurs, then the
action statement is applied to the route.
• Set. A set statement is used to modify route information before the route is redistributed into the
receiving protocol. This statement is only applied if all the criteria of the route map is met and the
action permits redistribution.
The ip route-map command is used to configure route map statements and provides the following action,
match, and set parameters:
ip route-map action ...
ip route-map match ...
ip route-map set ...
permit
deny
ip-address
ip-nexthop
ipv6-address
ipv6-nexthop
tag
ipv4-interface
ipv6-interface
metric
route-type
metric
metric-type
tag
community
local-preference
level
ip-nexthop
ipv6-nexthop
Refer to the “IP Commands” chapter in the OmniSwitch AOS Release 8 CLI Reference Guide for more
information about the ip route-map command parameters and usage guidelines.
Once a route map is created, it is then applied using the ip redist command. See “Configuring Route Map
Redistribution” on page 19-15 for more information.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 19-12
Configuring RIP
Configuring Redistribution
Creating a Route Map
When a route map is created, it is given a name (up to 20 characters), a sequence number, and an action
(permit or deny). Specifying a sequence number is optional. If a value is not configured, then the number
50 is used by default.
To create a route map, use the ip route-map command with the action parameter. For example,
-> ip route-map ospf-to-rip sequence-number 10 action permit
The above command creates the ospf-to-rip route map, assigns a sequence number of 10 to the route
map, and specifies a permit action.
To optionally filter routes before redistribution, use the ip route-map command with a match parameter
to configure match criteria for incoming routes. For example,
-> ip route-map ospf-to-rip sequence-number 10 match tag 8
The above command configures a match statement for the ospf-to-rip route map to filter routes based on
their tag value. When this route map is applied, only OSPF routes with a tag value of eight are
redistributed into the RIP network. All other routes with a different tag value are dropped.
Note. Configuring match statements is not required. However, if a route map does not contain any match
statements and the route map is applied using the ip redist command, the router redistributes all routes into
the network of the receiving protocol.
To modify route information before it is redistributed, use the ip route-map command with a set
parameter. For example,
-> ip route-map ospf-to-rip sequence-number 10 set tag 5
The above command configures a set statement for the ospf-to-rip route map that changes the route tag
value to five. Because this statement is part of the ospf-to-rip route map, it is only applied to routes that
have an existing tag value equal to eight.
The following is a summary of the commands used in the above examples:
-> ip route-map ospf-to-rip sequence-number 10 action permit
-> ip route-map ospf-to-rip sequence-number 10 match tag 8
-> ip route-map ospf-to-rip sequence-number 10 set tag 5
To verify a route map configuration, use the show ip route-map command:
-> show ip route-map
Route Maps: configured: 1 max: 200
Route Map: ospf-to-rip Sequence Number: 10 Action permit
match tag 8
set tag 5
Deleting a Route Map
Use the no form of the ip route-map command to delete an entire route map, a route map sequence, or a
specific statement within a sequence.
To delete an entire route map, enter no ip route-map followed by the route map name. For example, the
following command deletes the entire route map named redistipv4:
-> no ip route-map redistipv4
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 19-13
Configuring RIP
Configuring Redistribution
To delete a specific sequence number within a route map, enter no ip route-map followed by the route
map name, then sequence-number followed by the actual number. For example, the following command
deletes sequence 10 from the redistipv4 route map:
-> no ip route-map redistipv4 sequence-number 10
Note that in the above example, the redistripv4 route map is not deleted. Only those statements associated
with sequence 10 are removed from the route map.
To delete a specific statement within a route map, enter no ip route-map followed by the route map name,
then sequence-number followed by the sequence number for the statement, then either match or set and
the match or set parameter and value. For example, the following command deletes only the match tag 8
statement from route map redistipv4 sequence 10:
-> no ip route-map redistipv4 sequence-number 10 match tag 8
Configuring Route Map Sequences
A route map consists of one or more sequences of statements. The sequence number determines which
statements belong to which sequence and the order in which sequences for the same route map are
processed.
To add match and set statements to an existing route map sequence, specify the same route map name and
sequence number for each statement. For example, the following series of commands creates route map
rm_1 and configures match and set statements for the rm_1 sequence 10:
-> ip route-map rm_1 sequence-number 10 action permit
-> ip route-map rm_1 sequence-number 10 match tag 8
-> ip route-map rm_1 sequence-number 10 set metric 1
To configure a new sequence of statements for an existing route map, specify the same route map name
but use a different sequence number. For example, the following command creates a new sequence 20 for
the rm_1 route map:
-> ip route-map rm_1 sequence-number 20 action permit
-> ip route-map rm_1 sequence-number 20 match ipv4-interface to-finance
-> ip route-map rm_1 sequence-number 20 set metric 5
The resulting route map appears as follows:
-> show ip route-map rm_1
Route Map: rm_1 Sequence Number: 10 Action permit
match tag 8
set metric 1
Route Map: rm_1 Sequence Number: 20 Action permit
match ipv4 interface to-finance
set metric 5
Sequence 10 and sequence 20 are both linked to route map rm_1 and are processed in ascending order
according to their sequence number value. Note that there is an implied logical OR between sequences. As
a result, if there is no match for the tag value in sequence 10, then the match interface statement in
sequence 20 is processed. However, if a route matches the tag 8 value, then sequence 20 is not used. The
set statement for whichever sequence was matched is applied.
A route map sequence contains multiple match statements. If these statements are of the same kind (e.g.,
match tag 5, match tag 8, etc.) then a logical OR is implied between each like statement. If the match
statements specify different types of matches (e.g. match tag 5, match ip4 interface to-finance, etc.), then a
logical AND is implied between each statement. For example, the following route map sequence
redistributes a route if its tag is either 8 or 5:
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 19-14
Configuring RIP
Configuring Redistribution
-> ip route-map rm_1 sequence-number 10 action permit
-> ip route-map rm_1 sequence-number 10 match tag 5
-> ip route-map rm_1 sequence-number 10 match tag 8
The following route map sequence redistributes a route if the route has a tag of 8 or 5 and the route was
learned on the IPv4 interface to-finance:
->
->
->
->
ip
ip
ip
ip
route-map
route-map
route-map
route-map
rm_1
rm_1
rm_1
rm_1
sequence-number
sequence-number
sequence-number
sequence-number
10
10
10
10
action permit
match tag 5
match tag 8
match ipv4-interface to-finance
Configuring Access Lists
An IP access list provides a convenient way to add multiple IPv4 or IPv6 addresses to a route map. Using
an access list avoids having to enter a separate route map statement for each individual IP address. Instead,
a single statement is used that specifies the access list name. The route map is then applied to all the
addresses contained within the access list.
Configuring an IP access list involves two steps: creating the access list and adding IP addresses to the list.
To create an IP access list, use the ip access-list command (IPv4) or the ipv6 access-list command (IPv6)
and specify a name to associate with the list. For example,
-> ip access-list ipaddr
-> ipv6 access-list ip6addr
To add addresses to an access list, use the ip access-list address (IPv4) or the ipv6 access-list address
(IPv6) command. For example, the following commands add addresses to an existing access list:
-> ip access-list ipaddr address 16.24.2.1/16
-> ipv6 access-list ip6addr address 2001::1/64
Use the same access list name each time the above commands are used to add additional addresses to the
same access list. In addition, both commands provide the ability to configure if an address and/or its
matching subnet routes are permitted (the default) or denied redistribution. For example:
-> ip access-list ipaddr address 16.24.2.1/16 action deny redist-control allsubnets
-> ipv6 access-list ip6addr address 2001::1/64 action permit redist-control nosubnets
For more information about configuring access list commands, see the “IP Commands” chapter in the
OmniSwitch AOS Release 8 CLI Reference Guide.
Configuring Route Map Redistribution
The ip redist command is used to configure the redistribution of routes from a source protocol into the
RIP destination protocol. This command is used on the RIP router that performs the redistribution.
A source protocol is a protocol from which the routes are learned. A destination protocol is the one into
which the routes are redistributed. Make sure that both protocols are loaded and enabled before
configuring redistribution.
Redistribution applies criteria specified in a route map to routes received from the source protocol.
Therefore, configuring redistribution requires an existing route map. For example, the following command
configures the redistribution of OSPF routes into the RIP network using the ospf-to-rip route map:
-> ip redist ospf into rip route-map ospf-to-rip
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 19-15
Configuring RIP
Configuring Redistribution
RIP routes received by the router interface are processed based on the contents of the ospf-to-rip route
map. Routes that match criteria specified in this route map are either allowed or denied redistribution into
the RIP network. The route map can also specify the modification of route information before the route is
redistributed. See “Using Route Maps” on page 19-12 for more information.
To remove a route map redistribution configuration, use the no form of the ip redist command. For
example:
-> no ipv6 redist ospf into rip route-map ospf-to-rip
Use the show ip redist command to verify the redistribution configuration:
-> show ip redist
Source
Destination
Protocol
Protocol
Status
Route Map
------------+------------+---------+-------------------LOCAL4
RIP
Enabled
rip_1
LOCAL4
OSPF
Enabled
ospf_2
LOCAL4
BGP
Enabled
bgp_3
RIP
OSPF
Enabled
ospf-to-rip
Configuring the Administrative Status of the Route Map Redistribution
The administrative status of a route map redistribution configuration is enabled by default. To change the
administrative status, use the status parameter with the ip redist command. For example, the following
command disables the redistribution administrative status for the specified route map:
-> ip redist ospf into rip route-map ospf-to-rip admin-state disable
The following command example enables the administrative status:
-> ip redist ospf into rip route-map ospf-to-rip admin-state enable
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 19-16
Configuring RIP
Configuring Redistribution
Route Map Redistribution Example
The following example configures the redistribution of OSPF routes into a RIP network using a route map
(ospf-to-rip) to filter specific routes:
-> ip route-map ospf-to-rip sequence-number 10 action deny
-> ip route-map ospf-to-rip sequence-number 10 match tag 5
-> ip route-map ospf-to-rip sequence-number 10 match route-type external type2
-> ip route-map ospf-to-rip sequence-number 20 action permit
-> ip route-map ospf-to-rip sequence-number 20 match ipv4-interface intf_ospf
-> ip route-map ospf-to-rip sequence-number 20 set metric 255
-> ip route-map ospf-to-rip sequence-number 30 action permit
-> ip route-map ospf-to-rip sequence-number 30 set tag 8
-> ipv6 redist ospf into rip route-map ospf-to-rip
The resulting ospf-to-rip route map redistribution configuration does the following:
• Denies the redistribution of Type 2 external OSPF routes with a tag set to five.
• Redistributes into RIP all routes learned on the intf_ospf interface and sets the metric for such routes to
255.
• Redistributes into RIP all other routes (those not processed by sequence 10 or 20) and sets the tag for
such routes to eight.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 19-17
Configuring RIP
RIP Security
RIP Security
By default, there is no authentication used for a RIP. However, you can configure a password for a RIP
interface. To configure a password, you must first select the authentication type (simple or MD5), and
then configure a password.
Configuring Authentication Type
If simple or MD5 password authentication is used, both switches on either end of a link must share the
same password. Use the ip rip interface auth-type command to configure the authentication type. Enter
the name of the RIP interface, and then enter an authentication type:
• none. No authentication is used.
• simple. Simple password authentication is used.
• md5. MD5 authentication is used.
For example, to configure the RIP interface rip-1 for simple authentication you would enter:
-> ip rip interface rip-1 auth-type simple
To configure the RIP interface rip-1 for MD5 authentication you would enter:
-> ip rip interface rip-1 md5 auth-type md5
Configuring Passwords
If you configure simple or MD5 authentication you must configure a text string that is used as the
password for the RIP interface. If a password is used, all switches that are intended to communicate with
each other must share the same password.
After configuring the interface for simple authentication as described above, configure the password for
the interface by using the ip rip interface auth-key command. Enter the IP address of the RIP interface,
and then enter a 16-byte text string. For example to configure a password “nms” you would enter:
-> ip rip interface rip-1 auth-key nms
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 19-18
Configuring RIP
Verifying the RIP Configuration
Verifying the RIP Configuration
A summary of the show commands used for verifying the RIP configuration is given here:
show ip rip
Displays the RIP status and general configuration parameters (e.g.,
forced hold-down timer).
show ip rip routes
Displays the RIP routing database. The routing database contains all
the routes learned through RIP.
show ip rip interface
Displays the RIP interface status and configuration.
show ip rip peer
Displays active RIP neighbors (peers).
show ip redist
Displays the currently configured RIP redistribution filters.
For more information about the displays that result from these commands, see the OmniSwitch AOS
Release 8 CLI Reference Guide.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 19-19
20
Configuring BFD
An increasingly important requirement of networking equipment is to rapidly detect communication
failures between network systems to quickly establish alternative paths and reduce network convergence
time. Data link hardware such as SONET alarms make failure detection fairly easy and quick. However,
some media, such as Ethernet, do not support such kind of signaling, and some media can not detect
certain kinds of failures in the path, such as failing interfaces or forwarding engine components.
In the absence of such signaling hardware, networks resort to using simple “Hello” mechanisms to detect
failures in the communication pathways between adjacent systems. One such mechanism is the
Bidirectional Forwarding Detection (BFD) protocol.
BFD protocol is a fairly simple and quick Hello protocol; it can be configured on the interfaces with
routing protocols to rapidly detect faults in the bidirectional paths between adjacent forwarding engines,
including data link(s) and forwarding engines. BFD is not intended to directly control liveliness
information; instead, the application provides parameters and BFD supplies the state of the session. It acts
in an advisory role to the control protocols. It provides a low overhead alternative to detect faults for all
media types and routing protocols in a variety of network environments and topologies. BFD protocol
sessions can be initiated for any remote IP address reachable through outgoing IP interface ports.
In This Chapter
This chapter describes the basic components of BFD and how to configure them through the Command
Line Interface (CLI). CLI commands are used in the configuration examples; for more details about the
syntax of commands, see the OmniSwitch AOS Release 8 CLI Reference Guide.
Configuration procedures described in this chapter include:
• Global Configuration (see page 20-12).
• Interface Level Configuration (see page 20-12).
• OSPF level configuration (see page 20-16).
• BGP Level Configuration (see page 20-19).
• VRRP Level Configuration (see page 20-20).
• Static Routing Level Configuration (see page 20-22).
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 20-1
Configuring BFD
BFD Defaults
BFD Defaults
The following table shows the default settings of the configurable BFD parameters.
Parameter Description
Command
Default Value/Comments
BFD global status for the switch
ip bfd admin-state
Disabled
Global transmit time interval for BFD ip bfd transmit
control packets
300 milliseconds
Global receive time interval for BFD ip bfd receive
control packets.
300 milliseconds
Global BFD detection time multiplier ip bfd multiplier
3
Global BFD echo packet time interval ip bfd echo-interval
300 milliseconds
Administrative status of a BFD
interface
ip bfd interface admin-state
Disabled
Transmit time interval for a BFD
interface.
ip bfd interface transmit
300 milliseconds
Receive time interval for the BFD
interface.
ip bfd interface receive
300 milliseconds
BFD interface detection time
multiplier.
ip bfd interface multiplier
3
Echo time interval for the BFD
interface
ip bfd interface echo-interval
300 milliseconds
BFD status for the OSPF protocol
ip ospf bfd-state
Disabled
BFD status for an OSPF interface
ip ospf interface bfd-state
Disabled
BFD session status with all BGP
neighbors
ip bgp bfd-state all-neighbors
Disabled
BFD session status with all neighbors ip ospf interface bfd-state allof the corresponding interface which neighbors
are greater than or equal to “2-way”
state
Enabled
BFD status for the BGP protocol
ip bgp bfd-state
Disabled
BFD status for BGP neighbors
ip bgp neighbor bfd-state
Disabled
BFD status for VRRP protocol
vrrp bfd-state
Disabled
BFD status for a VRRP tracking
policy.
vrrp track
Enabled
BFD status for a static route.
ip static-route bfd-state
Enabled
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 20-2
Configuring BFD
Quick Steps for Configuring BFD
Quick Steps for Configuring BFD
Configuring BFD involves:
• Optional: Configuring BFD explicitly on the IP interfaces.
• Configuring Layer 3 protocols to use BFD (see “Quick Steps for Configuring BFD Support for Layer 3
Protocols” on page 20-5).
Note. Configuring a BFD session explicitly with an IP interface name is optional, and must be used if userdefined BFD session parameters need to be applied. All the steps for explicit configuration are mentioned
as optional.
If BFD is not explicitly configured, the default BFD global session parameters (transmit, receive and echo
intervals) are applied to the BFD sessions.
The following steps provide a brief tutorial for configuring a BFD session and related parameters:
1 Configure a BFD session on IP interface using the ip bfd interface command. For example:
-> ip bfd interface
Optional: Configure the BFD session explicitly with an IP interface name if non-default BFD session
parameters are required for BFD sessions that must be run separate from the IP interface.
-> ip bfd interface bfd_int_1
2 Optional: Configure a global transmit time interval for all BFD sessions using the ip bfd transmit
command. This command defines a default transmit value that is automatically applied when a BFD
session is created. For example:
-> ip bfd transmit 500
3 Optional: Configure the transmit time interval for a specific BFD session using the ip bfd interface
transmit command. The value set with this command overrides the global transmit value configured for
the routing instance. For example:
-> ip bfd interface bfd-vlan-101 transmit 500
4 Optional: Configure a global receive time interval for all BFD sessions using the ip bfd receive
command. This command defines a default receive time value that is automatically applied when a BFD
session is created. For example:
-> ip bfd receive 500
5 Optional: Configure the receive time interval for a specific BFD session using the ip bfd interface
receive command. The value set with this command overrides the global receive time value configured for
the routing instance:
-> ip bfd interface bfd-vlan-101 receive 500
6 Optional: Configure a global detection time multiplier value for all BFD sessions using the ip bfd
multiplier command. For example:
-> ip bfd multiplier 5
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 20-3
Configuring BFD
Quick Steps for Configuring BFD
7 Optional: Configure the BFD session detection time multiplier value using the ip bfd interface
multiplier command. For example:
-> ip bfd interface bfd-vlan-101 multiplier 5
8 Optional: Configure the global BFD echo packet time interval using the ip bfd echo-interval
command. This command defines a default echo packet time value that is automatically applied when a
BFD session is created. For example:
-> ip bfd echo-interval 500
9 Optional: Configure the echo time interval for a specific BFD session using the ip bfd interface
echo-interval command. The echo time interval value set with this command overrides the global echo
time interval configured for the routing instance. For example:
-> ip bfd interface bfd-vlan-101 echo-interval 500
Note. VRRP and Static Routes only use the Asynchronous Echo function, so BFD sends only Echo packets.
Other protocols (OSPF, IS-IS, BGP) use the Asynchronous control packet mode, so BFD initiates and
maintains sessions by sending control packets. Make sure an Asynchronous Echo function does not share
the same remote IP address as an Asynchronous control packet session.
10 Optional: Enable the administrative status of a BFD interface using the ip bfd interface admin-state
command. For example:
-> ip bfd interface bfd-vlan-101 admin-state enable
Note. BFD parameters are not configurable once the BFD administrative status is enabled on the interface.
11 Enable the BFD protocol for the routing instance globally using the ip bfd admin-state command. For
example:
-> ip bfd admin-state enable
Note. Optional. Verify the BFD interface session status and configuration using the show ip bfd interfaces
command. For example:
-> show ip bfd interfaces one
Interface Name
Interface IP Address
Admin Status
Desired Transmit Interval
Minimum Receive Interval
Detection Time Multiplier
Minimum Echo Receive Interval
Authentication Present
Oper Status
=
=
=
=
=
=
=
=
=
one,
100.1.1.1,
Enabled,
300,
300,
3,
300,
No,
UP
To verify the global BFD configuration for the switch, use the show ip bfd command. For example:
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 20-4
Configuring BFD
-> show ip bfd
BFD Version Number
Admin Status
Desired Tranmit Interval
Minimum Receive Interval
Detection Time Multiplier
Minimum Echo Receive Interval
Applications Registered
Quick Steps for Configuring BFD
=
=
=
=
=
=
=
1,
Enabled,
300,
300,
3,
300,
STATIC-ROUTING OSPF
See the “BFD Commands” chapter in the OmniSwitch AOS Release 8 CLI Reference Guide for information
about the fields in this display.
Quick Steps for Configuring BFD Support for Layer 3 Protocols
BFD runs on top of Layer 3 protocol traffic that is forwarded between two systems. This implementation
of BFD supports the following protocols:
• BGP
• OSPF
• VRRP Tracking
• Static routes
Once the BFD configuration is in place (see “Quick Steps for Configuring BFD” on page 20-3), the steps
described in the following sections are used to configure BFD interaction with the supported Layer 3
protocols.
Configuring BFD Support for OSPF
1 Register OSPF with the BFD protocol using the ip ospf bfd-state command. For example:
-> ip ospf bfd-state enable
2 Enable BFD session on specific OSPF interface using the ip ospf interface bfd-state command or on
all OSPF interfaces using the ip ospf bfd-state all-interfaces command. For example:
-> ip ospf interface int1 bfd-state enable
-> ip ospf bfd-state all-interfaces
3 Establish BFD sessions with all OSPF DR neighbors in full states only or with all neighbors greater
than or equal to the “2-way” state using the ip ospf interface bfd-state drs-only command or the ip ospf
interface bfd-state all-neighbors command. For example:
-> ip ospf interface int1 bfd-state drs-only
-> ip ospf interface int1 bfd-state all-neighbors enable
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 20-5
Configuring BFD
Quick Steps for Configuring BFD
Configuring BFD Support for BGP
1 Register BGP with the BFD protocol using the ip bgp bfd-state command. For example:
-> ip bgp bfd-state enable
2 Enable BFD for specific BGP neighbors using the ip bgp neighbor bfd-state command or for all BGP
neighbors using the ip bgp bfd-state all-neighbors command. For example:
-> ip bgp neighbor 135.10.10.2 bfd-state enable
-> ip bgp bfd-state all-neighbors enable
Configuring BFD Support for VRRP Track Policies
1 Register VRRP with the BFD protocol using the vrrp bfd-state command. For example:
-> vrrp bfd-state enable
2 Enable BFD for a specific track policy using the vrrp track command. For example:
-> vrrp track 2 address 10.1.1.1 bfd-state enable
Make sure that the track policy is associated with at least one of the virtual routers. In addition, note that
the value of the address parameter should be a remote interface address. BFD cannot be configured for a
local interface address.
Note. To display the VRRP tracking policies on which BFD is enabled, use the show vrrp track command.
-> show vrrp track
Track
Admin
Oper
BFD
ID
Policy
State
State
Pri
Status
-----+-----------------------+-------------+--------+-------+--------------+
1
25.25.25.1
Enabled
Down
50 Enabled
2
192.10.150.42
Enabled
Down
25 Enabled
See the “VRRP Commands” chapter in the OmniSwitch AOS Release 8 CLI Reference Guide for
information about the fields in this display.
Configuring BFD Support for Static Routes
Enable BFD support for a specific static route using the ip static-route bfd-state command or for all
static routes using the ip static-route all bfd-state command. For example:
-> ip static-route 192.100.1.0/24 gateway 100.1.1.10 bfd-state enable
-> ip static-route all bfd-state enable
To create a BFD session for a static route, make sure that:
• the gateway address does not match any of the local interface addresses on the switch
• BFD is enabled on the interface on which the gateway address exists.
• If multiple routes are configured with the same gateway address, only one BFD session is run.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 20-6
Configuring BFD
Quick Steps for Configuring BFD
Note. To display the static routes on which BFD is enabled use the show ip router database command
along with the protocol static option as shown below:
-> ip static-route 100.0.0.0/8 gateway 100.1.1.10 bfd-state enable
-> show ip router database protocol static
Legend: + indicates routes in-use
b indicates BFD-enabled static route
r indicates recursive static route, with following address in brackets
Total IPRM IPv4 routes: 7
Destination
Gateway
Interface
Protocol Metric Tag
Misc-Info
-------------------+---------------+------------+--------+-------+-----+----------+b 100.0.0.0/8
100.1.1.10
v1001
STATIC
1
0
+ 128.251.40.0/24
172.28.4.254
EMP
STATIC
1
0
Inactive Static Routes
Destination
Gateway
Metric
--------------------+-----------------+---------
See the “IP Commands” chapter in the OmniSwitch AOS Release 8 CLI Reference Guide for information
about the fields in this display.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 20-7
Configuring BFD
BFD Overview
BFD Overview
Detecting communication failures as soon as possible is the first step in any network recovery process;
until a failure is detected, network convergence can’t begin. By rapidly detecting failures, BFD enables
faster convergence of routing protocols particularly on shared media such as Ethernet.
The BFD protocol is very similar to the widely-used Hello mechanisms prevalent in a majority of routing
protocols, with the exception that BFD tests bidirectional communication links, has smaller packets, and is
focused exclusively on path-failure detection. BFD can also be less CPU-intensive in routers with
distributed architecture because unlike routing protocol Hello packets, BFD packets can be processed on
the interface modules rather than the control plane.
BFD protocol is a fairly simple Hello protocol designed to provide fast forwarding path failure detection
that can be enabled at the interface and routing protocol levels. It helps in the verification of forwarding
plane-to-forwarding plane connectivity (including links, interfaces, tunnels). It allows semantic separation
of forwarding plane connectivity and control plane connectivity. BFD is a single mechanism that works
independently of underlying media, data, and network protocols. It can be associated with any routing
protocol running between two systems. Moreover, it requires no changes to the existing protocols.
This implementation of BFD can be associated with tracking of next hops with the BGP, OSPF, VRRP
and other static route protocols.
Benefits of Using BFD For Failure Detection
It is more advantageous to implement BFD rather than reduce timer mechanisms for routing protocols due
to the following reasons:
• BFD can detect failures in milliseconds without having to fine-tune routing protocol Hello timers.
• BFD is not tied to any particular routing protocol. As a result, BFD provides a generic and consistent
failure detection mechanism for OSPF, BGP, VRRP Remote Tracking, and static routes.
• BFD is less CPU-intensive than reduced timer mechanisms for routing protocols.
How the BFD Protocol Works
A BFD session must be explicitly configured between two adjacent systems. Once BFD has been enabled
on the interfaces and at the appropriate Layer 3 routing protocol level, a BFD session is created for the
adjacent systems and BFD timers are negotiated between these systems.
The BFD protocol does not have a neighbor discovery mechanism to detect neighboring systems;
protocols that BFD services notify BFD of devices to which it needs to establish sessions. For example, an
OSPF implementation can request BFD to establish a session with a neighbor discovered using the OSPF
Hello protocol.
Once a session is established, BFD peers—neighboring systems sharing a BFD interface—begin sending
BFD control packets to each other over the bidirectional forwarding path. The packets are transmitted
periodically at the negotiated rate. The BFD control packets function in a similar manner to that of an IGP
Hello protocol, except at a more accelerated rate.
Each time a BFD control packet is successfully received through a BFD interface, the detect-timer for that
session is reset to zero. As long as the BFD peer systems receive the control packets from each other
within the negotiated time interval [(Detect Time Multiplier) * (Required Minimum Rx Interval)], the
BFD session remains up. Any routing protocol that associates the BFD maintains its adjacencies and
continues its periodic transmission of BFD control packets at the negotiated rate.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 20-8
Configuring BFD
BFD Overview
In case a system stops receiving the packets within the predetermined time frame, some component in the
bidirectional path to that particular system is assumed to have failed, and the BFD system simply informs
its client protocol that a failure has occurred. It does this by sending rapid failure detection notices to
respective registered routing protocols in the local router to initiate the router table recalculation process in
order to accelerate routing convergence and network uptime.
In order to agree with its peers about how rapidly failure detection takes place, each system estimates the
rate at which it can send and receive BFD control packets. This design also enables fast systems on shared
medium with a slow system to detect failures more rapidly between fast systems while allowing the slow
system to participate to the best of its ability.
Operational Mode and Echo Function
The BFD protocol offers two different modes of operation:
• Asynchronous mode
• Demand mode (not supported)
This implementation of BFD supports an Asynchronous control packet mode or an Asynchronous Echo
function.
• When the Asynchronous control packet mode is activated, BFD neighbors periodically send BFD
control packets to each other. A time interval for transmitting and receiving such packets is negotiated
between the two BFD systems. If a neighboring system fails to receive a number of control packets
continuously over a specific period of time, the session is considered down and BFD informs the
appropriate routing protocol.
• The Asynchronous Echo function is used to verify the forwarding path between neighboring BFD
systems. When active, a BFD system transmits Echo packets only (no control packets are sent) to a
BFD neighbor, which then sends the packets back to the originating system along the forwarding path.
If no Echo packets are received back from the BFD neighbor within a configured Echo time interval,
the session is considered down.
VRRP and Static Routes only use the Asynchronous Echo function, so BFD sends only Echo packets.
Other protocols (OSPF, IS-IS, BGP) use the Asynchronous control packet mode, so BFD initiates and
maintains sessions by sending control packets.
Consider the following regarding how BFD operates between peers:
• Transmitting Echo packets is only allowed over a single hop; transmitting BFD control packets is
allowed over multiple hops.
• The Echo function does not require a BFD session to run; instead, the function is activated when BFD
is enabled for the switch that is going to send the Echo packets. The peer switches that are going to
receive the Echo packets do not require a BFD configuration since this function is not a BFD session.
• VRRP address tracking and Static Routes only use the Asynchronous Echo function, so they do not
share BFD sessions with other protocols (such as OSPF). As a result, only an Asynchronous control
packet session or an Asynchronous Echo function is allowed to the same remote IP address.
• If an Asynchronous control packet session and an Asynchronous Echo function are both directed to the
same remote IP address, then the Asynchronous control packet session may become unstable (may take
several minutes to stabilize).
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 20-9
Configuring BFD
BFD Overview
BFD Packet Formats
The detection packets BFD sends are UDP packets which are of two types: BFD control packets and Echo
packets.
BFD Control Packets
There is no specific encapsulation type for BFD control packets; instead, the BFD IETF RFC-5880
recommends an encapsulation type that is “appropriate to the medium and network” used. This
implementation of BFD for IPv4 routing protocols (BGP, OSPF, VRRP Remote Tracking, and static
routes), associates BFD control packets in UDP packets using destination port 3784 and a source port in
the range of 49152 to 65535.
Note. The BFD control packet has a mandatory section and an optional authentication section.
Authentication is not supported in this implementation of the BFD protocol.
BFD Echo Packets
There is no specific definition for Echo packet format. The only requirement is that the transmitting
system is able to use the packet contents to distinguish between the various BFD sessions so that packets
are correctly processed for the appropriate session.
This implementation of BFD associates Echo packets in UDP packets using port 3785 and the IP address
of the transmitting interface. The contents of the Echo packet is defined as follows:
Field
Description
Version
The version number of the BFD
protocol.
My Discriminator
An identifier for the BFD session
connecting to the local side.
Sequence Number
The sequence number for this
packet. This value is incremented
for each successive packet
transmitted for a session.
BFD Session Establishment
There are three states through which a BFD session normally proceeds: two for establishing a session (Up
and Init state) and one for tearing down a session (Down state). In addition, an AdminDown state exists to
administratively take down a session.
BFD uses a three-way handshake to establish sessions and guarantee that each BFD peer is aware of all
the state changes. The transmitting system fills the state field in the transmitted BFD control packet with
its current session state. To establish a session, the receiving peer system changes its session state based
on the state field value in the received BFD control packet and its own session status.
A Down state means that a session is down or has been recently created. A session remains down until the
remote system sends a packet with any state other than an up state. If a BFD packet with the state field set
to down is received by the local system that is also in a down state, the session advances to Init state; if
that packet signals Init state, the session advances to Up state.
Init signals that there is communication between the systems and that the local system wishes to start a
session but the remote system has not yet acknowledged it. The session stays at Init until the local system
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 20-10
Configuring BFD
BFD Overview
receives a control packet with Init or Up in its state field (in which case the session state moves to Up) or
until the detection time limit is reached.(in which case the remote system is then considered unreachable
and the state moves to Down)
An Up state indicates that a BFD session has been created and both BFD peers are communicating with
each other. The BFD session continues to remain in this state until connectivity fails and the state moves
to Down or until the BFD session is taken down administratively.
Demultiplexing
Each BFD session must be able to uniquely identify itself and received BFD packets among the myriad of
BFD sessions that are running. Each BFD peer must choose an identifying and unique discriminator value.
This value is sent in the “My Discriminator” field of the BFD control packet, and is reflected back in the
“Your Discriminator” field of the control packet sent from the remote peer. Once the system has echoed
the respective “Your Discriminator” value back to its peer, the packets are demultiplexed (converted back
into their original separate signals).
BFD Timer Negotiation
The BFD control packet contains information about how quickly a system would like to send packets to its
peer, as well as how rapidly it is willing to receive packets from the peer. The BFD detection time is not
carried explicitly in the protocol, but rather, it is determined by the receiving system independently based
on the transmission interval (TX) and Detection Time Multiplier that have been negotiated.
The Detection Time Multiplier field value is approximately the number of packets that must be missed in
order to declare a session down. In Asynchronous mode, detection times can be different in each direction.
The local system detection time in this mode equals the value of Detection Time Multiplier received from
the remote system multiplied by the negotiated transmission interval (TX). Because the time values for
BFD control packet transmissions and session detection are being constantly negotiated by the
participating BFD peers, they can be changed at any time. They are also independent in each direction for
each session.
To change the rate at which BFD control packets are received, you can change the Required Min RX
Interval at any time to any value. This new value is sent in the next outgoing packet so that the remote
system can accommodate the changes made. Similarly, to change the rate at which BFD control packets
are transmitted, you can change the Desired Min TX Interval at any time to any value.
With some exceptions, a system cannot transmit control packets with an interval shorter than the larger
value of the TX interval and RX interval fields. This means that the system with the slower rate
determines the BFD control packet transmission speed.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 20-11
Configuring BFD
Configuring BFD
Configuring BFD
Configuring BFD for your network requires the following approach:
1 Optional: Configure a BFD session and related session parameter values. Once configured, enable all
participating BFD sessions before configuring BFD interoperability with the supported Layer 3 protocols.
See “Configuring BFD Session Parameters” on page 20-12 for more information.
2 Configure BFD support for the Layer 3 protocols for which BFD establishes sessions. This
implementation of BFD supports the IPv4 versions of BGP, OSPF, VRRP remote tracking, and static
routes. See “Configuring BFD Support for Layer 3 Protocols” on page 20-15 for more information.
At the end of the chapter is a simple BFD network diagram with instructions on how it can be created on a
router-by-router basis. See “BFD Application Example” on page 20-24 for more information.
Configuring BFD Session Parameters
When a BFD session is created, default values are automatically set for these parameters. However, it is
possible to change these parameter values globally or for a specific BFD session. The following BFD
session parameter values are used to create, monitor, and negotiate BFD sessions between peers.
• BFD session status (see “Configuring a BFD Session” on page 20-12).
• Transmit time interval (see “Configuring the BFD Transmit Time interval” on page 20-13).
• Receive time interval (see “Configuring the BFD Receive Time Interval” on page 20-13).
• Multiplier (see “Configuring the BFD Multiplier” on page 20-14).
• Echo interval (see “Configuring the BFD Echo interval” on page 20-13).
Note. Once the default state of the BFD session is changed and the session is enabled, parameter values are
no longer configurable. To subsequently change parameter values, disable the BFD session. See “Enabling
or Disabling BFD Status” on page 20-14 for more information.
Configuring a BFD Session
To configure a BFD session, use the ip bfd interface command and specify an existing IP interface name.
For example:
-> ip bfd interface bfd-vlan-101
The above command configures BFD with the name bfd-vlan-101. See “Enabling or Disabling BFD
Status” on page 20-14 for more information.
To delete the BFD session, use the no form of the above command. For example:
-> no ip bfd interface bfd-vlan-101
The above command deletes the BFD session on bfd-vlan-101.
Note. The BFD interface session must be associated to an existing IP interface that is configured with an IP
address.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 20-12
Configuring BFD
Configuring BFD
Configuring the BFD Transmit Time interval
Transit Time Interval is the minimum amount of time that BFD waits between each successive
transmission of control packets. BFD allows you to change the default value and set the transmit time
interval from the valid range.
To change the global transmit time interval for BFD control packets, use the ip bfd transmit command.
For example:
-> ip bfd transmit 500
The above command changes the global transmit time interval to 500 msecs.
To change the transmit time interval for a specific BFD interface session, use the ip bfd interface
transmit command along with the name and transmit time interval in milliseconds. For example:
-> ip bfd interface bfd-vlan-101 transmit 500
The above command changes the transmit time interval value to 500 msecs on bfd-vlan-101.
The global transmit time interval serves as the default interval value for transmitting BFD control packets.
This default value is overridden when a specific transmit value is configured.
Configuring the BFD Receive Time Interval
Receive Time Interval is the minimum amount of time that BFD waits to receive control packets before
determining if there is a problem. BFD allows you to change the default value and set the receive time
interval from the valid range.
To change the global receive time interval for BFD control packets, use the ip bfd receive command. For
example:
-> ip bfd receive 500
The above command configures the global receive time interval of 500 msecs.
To change the receive time interval for BFD control packets, use the ip bfd interface receive command.
For example:
-> ip bfd interface bfd-vlan-101 receive 500
The above command changes the receive time interval value to 500 msecs on bfd-vlan-101.
The global receive time interval serves as the default interval value for receiving BFD control packets.
The default interval value is overridden when a specific receive value is configured.
Configuring the BFD Echo interval
The time interval between received BFD echo packets is configurable and applies when the echo function
is enabled. When this function is active, a stream of Echo packets is sent to a peer, which then loops these
back to the sender without processing them through its forwarding path. If the sender does not receive
several continuous echo packets from its peer, the BFD session is declared down.
To change the default value of the global BFD echo packet time interval, use the ip bfd echo-interval
command. For example:
-> ip bfd echo-interval 500
The above command sets the echo interval to 500 milliseconds globally on all BFD sessions.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 20-13
Configuring BFD
Configuring BFD
To change the BFD echo time interval for a particular BFD session, use the ip bfd interface echointerval command. For example:
-> ip bfd interface bfd-vlan-101 echo-interval 500
The above command configures the echo time interval value to 500 milliseconds on bfd-vlan-101.
The global echo packet time interval serves as the default interval value. The default interval value is
overridden when a specific value is configured.
Configuring the BFD Multiplier
The BFD multiplier value is used to calculate the BFD detection time in asynchronous mode. The
detection time between neighbors is calculated by multiplying the negotiated transmit time interval by the
dead interval multiplier. When an interface stops receiving packets from a neighbor, the interface uses the
detection time value to determine how long to wait before declaring that the BFD session is down.
The BFD multiplier parameter can be configured globally for all BFD configured interfaces as well as for
a specific interface.
To set or change the default global detection time multiplier value for all BFD sessions, use the ip bfd
multiplier command. For example:
-> ip bfd multiplier 5
The above command assigns a multiplier value of 5 to all BFD sessions.
To change the BFD multiplier for a specific session, use the ip bfd interface multiplier command. For
example:
-> ip bfd interface bfd-vlan-101 multiplier 5
The above command assigns a multiplier value of 5 to bfd-vlan-101.
Enabling or Disabling BFD Status
As BFD is globally disabled for the routing instance, to enable the global BFD status, use the ip bfd
admin-state command. For example:
-> ip bfd admin-state enable
To disable the global BFD status for the routing instance, use the ip bfd admin-state command with the
disable keyword. For example:
-> ip bfd admin-state disable
The above command disables BFD globally on the routing instance. Note that disabling BFD does not
remove the existing BFD configuration from the routing instance. Also, when BFD is globally disabled,
all BFD functionality is disabled for the routing instance, but configuring BFD is still allowed.
To enable a BFD session, use the ip bfd interface admin-state command. For example:
-> ip bfd interface bfd-vlan-101 admin-state enable
The above command enables the administrative status of bfd-vlan-101.
Note that a BFD session must be disabled before any of its parameters can be changed. To disable a BFD
session, use the ip bfd interface status command with the disable keyword. For example:
-> ip bfd interface bfd-vlan-101 admin-state disable
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 20-14
Configuring BFD
Configuring BFD
To verify the BFD status and configuration for the switch, use the show ip bfd command,. For example:
-> show ip bfd
BFD Version Number
Admin Status
Desired Tranmit Interval
Minimum Receive Interval
Detection Time Multiplier
Minimum Echo Receive Interval
Applications Registered
=
=
=
=
=
=
=
1,
Enabled,
300,
300,
3,
300,
STATIC-ROUTING OSPF
The above command shows that BFD is registered with the OSPF protocol and has a transmit interval of
300 msecs, receive interval of 300 msecs, multiplier 3, and echo interval of 300 msecs.
To verify the BFD status and configuration, use the show ip bfd interfaces command. For example:
-> show ip bfd interfaces
Interface
Admin
Tx
Min Rx
Min EchoRx Detect Oper
Name
Status
Interval Interval
Interval
Mult Status
---------------------+----------+----------+----------+----------+------+-----one
enabled
300
300
300
3
UP
two
enabled
300
300
300
3
UP
The output above displays the interfaces participating in the BFD sessions, along with their IP interface
names and respective BFD session parameters. To see additional detail for a specific interface, use the
show ip bfd interfaces command and specify an interface name. For example:
-> show ip bfd interfaces one
Interface Name
Interface IP Address
Admin Status
Desired Transmit Interval
Minimum Receive Interval
Detection Time Multiplier
Minimum Echo Receive Interval
Authentication Present
Oper Status
=
=
=
=
=
=
=
=
=
one,
100.1.1.1,
Enabled,
300,
300,
3,
300,
No,
UP
Configuring BFD Support for Layer 3 Protocols
After a BFD session is configured on all interfaces or on a specific set of individual interfaces, the next
step is to configure BFD interoperability with the supported Layer 3 protocols (BGP, OSPF, VRRP
Tracking, Static Routes). BFD interoperability with Layer 3 protocols is configurable at the router level to
enable BFD session globally, or at the interface level for specific interfaces only.
The following sections provide information about how to configure BFD support for BGP, OSPF, VRRP
Tracking, and Static Routes:
“Configuring BFD Support for OSPF” on page 20-16.
“Configuring BFD Support for BGP” on page 20-19.
“Configuring BFD Support for VRRP Tracking” on page 20-20.
“Configuring BFD Support for Static Routes” on page 20-22.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 20-15
Configuring BFD
Configuring BFD
Configuring BFD Support for OSPF
The steps below show how to configure and verify BFD support for OSPF, so that OSPF is a registered
protocol with BFD and receives forwarding path detection failure messages from BFD.
Note. OSPF must be running on all participating routers, and BFD must be configured and enabled on the
participating OSPF interfaces. See “Configuring BFD Session Parameters” on page 20-12 for more
information.
1 To associate BFD with the OSPF protocol and to change the default BFD status for the OSPF protocol,
register OSPF with BFD at the protocol level using the ip ospf bfd-state command. For example:
-> ip ospf bfd-state enable
The BFD status for the OSPF protocol is now enabled, which means that communication between OSPF
and BFD is enabled. To de-register OSPF with BFD, enter the following command:
-> ip ospf bfd-state disable
2 To verify the BFD status for OSPF protocol, use the show ip ospf command. For example:
->show ip ospf
Router Id
OSPF Version Number
Admin Status
Area Border Router ?
AS Border Router Status
Route Tag
SPF Hold Time (in seconds)
SPF Delay Time (in seconds)
MTU Checking
# of Routes
# of AS-External LSAs
# of self-originated LSAs
# of LSAs received
External LSDB Limit
Exit Overflow Interval
# of SPF calculations done
# of Incr SPF calculations done
# of Init State Nbrs
# of 2-Way State Nbrs
# of Exchange State Nbrs
# of Full State Nbrs
# of attached areas
# of Active areas
# of Transit areas
# of attached NSSAs
Default Route Origination
Default Route Metric-Type/Metric
BFD Status
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
10.172.18.16,
2,
Enabled,
No,
Disabled,
0,
10,
5,
Disabled,
9,
0,
1,
0,
-1,
0,
4,
0,
0,
0,
0,
0,
1,
1,
0,
0,
none,
type2 / 1
Disabled
3 Once OSPF is registered with BFD at the protocol level, enable the OSPF interface(s) that participate
in BFD using the ip ospf interface bfd-state command. For example:
-> ip ospf interface vlan-10 bfd-state enable
The above command enables BFD on the interface named vlan-10. To enable BFD on all configured
OSPF interfaces, use the ip ospf bfd-state all-interfaces command. For example:
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 20-16
Configuring BFD
Configuring BFD
-> ip ospf bfd-state all-interfaces enable
To disable BFD for all configured OSPF interfaces, use the ip ospf bfd-state all-interfaces command
with the disable keyword. For example:
-> ip ospf bfd-state all-interfaces disable
4 To display the BFD status on an OSPF interface, use the show ip ospf interface command. For
example:
-> show ip ospf interface
Interface
DR Backup
DR
Admin
Oper
BFD
Name
Address
Address
Status Status State Status
----------+-------------+--------------+--------+------+------+-----------vlan-10
213.10.10.1
213.10.10.254 enabled
up
DR
enabled
vlan-20
215.10.10.254 215.10.10.1
enabled
up
BDR
disabled
5 Once OSPF is registered with BFD at the protocol level and BFD is enabled on the desired OSPF
interface(s), use the show ip bfd interfaces command to display BFD-enabled interfaces. For example:
-> show ip bfd interfaces
Interface Admin
Tx
Min Rx
Min EchoRx Detect
OperStatus
Name
Status
Interval Interval Interval
Multiplier
---------+--------+---------+---------+----------+----------+---------one
enabled
300
300
300
3
UP
two
enabled
300
300
300
3
UP
6 To establish BFD sessions with neighbors that are in full state only, enter the ip ospf interface bfdstate drs-only command as shown below:
-> ip ospf interface int1 bfd-state drs-only
The above command establishes a BFD session on interface named int1 with OSPF DR neighbors in full
state only.
To establish a BFD session on an interface with all neighbors which are greater than or equal to “2-way”
state, use the ip ospf interface bfd-state all-neighbors command as shown below:
-> ip ospf interface int2 bfd-state all-neighbors enable
The above command establishes a BFD session on interface named int2 with all OSPF neighbors that are
greater than or equal to “2-way” state.
When any neighbors are added to this interface, OSPF informs BFD about the newly added neighbor(s);
BFD then establishes a session with them. Use the show ip bfd sessions command to view BFD sessions
with all BFD neighbors, as shown below:
-> show ip bfd sessions
Legends: Neg.
Discr
Intvl
= Negotiated
= Discriminator
= Interval (in milliseconds)
Local
Interface Neighbor
State
Remote
Neg. Rx Neg. Tx EchoRx
Discr
Name
Address
Discr
Intvl
Intvl
Intvl
------+-----------+--------------+----------+------+----------+--------+------1
v1001
101.1.1.11
UP
1
300
300
300
2
v2000
200.1.1.1
UP
0
0
0
300
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 20-17
Configuring BFD
Configuring BFD
To view a BFD session with a particular neighbor, use the show ip bfd sessions command followed by the
session number. For example:
-> show ip bfd sessions 1
Local discriminator
Neighbor IP Address
Requested Session Type
Interface IfIndex
Source UDP Port
State
Session Operating Mode
Remote discriminator
Negotiated Tx interval
Negotiated Rx interval
Echo Rx interval
Multiplier
Applications Registered:
=
=
=
=
=
=
=
=
=
=
=
=
=
1,
101.1.1.11,
ASYNC ,
2,
49153,
UP,
None,
1,
300,
300,
300,
3,
OSPF
Whenever there is any change to the interface/neighbor list or interface/neighbor state, OSPF immediately
informs BFD about the changes. Additionally, whenever BFD detects any changes to the other end, BFD
updates its database accordingly and informs OSPF for its fastest convergence.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 20-18
Configuring BFD
Configuring BFD
Configuring BFD Support for BGP
The steps below show how to configure and verify BFD support for the BGP protocol, so that BGP is a
registered protocol with BFD and receives forwarding path detection failure messages from BFD.
Note. BFD must be configured and enabled on the participating BGP interfaces. See “Configuring BFD
Session Parameters” on page 20-12 for more information.
1 To associate BGP protocol with BFD liveliness detection, register BGP with BFD at the protocol level
using the ip bgp bfd-state command as shown below:
-> ip bgp bfd-state enable
The BFD status for the BGP protocol is now enabled, which means that communication between BGP and
BFD is enabled. To de-register BGP with BFD, enter the following command:
-> ip bgp bfd-state disable
To verify the BFD status for BGP protocol, you can use the show ip bgp command as shown below:
-> show ip bgp
Admin Status
Operational Status
Autonomous System Number
BGP Router Id
Confederation Identifier
IGP Synchronization Status
Minimum AS Origin Interval (seconds)
Default Local Preference
Route Reflection
Cluster Id
Missing MED Status
Aspath Comparison
Always Compare MED
Fast External FailOver
Log Neighbor Changes
Multiple Paths
Graceful Restart
Graceful Restart Status
Configured Graceful Restart Interval
IPv4 Unicast
IPv6 Unicast
BFD Status
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
disabled,
down,
1,
0.0.0.0,
0,
disabled,
15,
100,
disabled,
0.0.0.0,
Best,
enabled,
disabled,
disabled,
disabled,
disabled,
enabled,
Not Restarting,
90s,
enabled,
disabled,
disabled
2 Once BGP is registered with BFD at the protocol level, you need to enable BFD for particular BGP
neighbors using the ip bgp neighbor bfd-state command as shown below:
-> ip bgp neighbor 135.10.10.2 bfd-state enable
The above command enables BFD for neighbor with IP address 135.10.10.2. To enable BFD for all
BGP neighbors, use the ip bgp bfd-state all-neighbors command as shown below:
-> ip bgp bfd-state all-neighbors enable
To disable BFD for all configured BGP neighbors, use the ip bgp bfd-state all-neighbors with the
disable keyword, as shown below:
-> ip bgp bfd-state all-neighbors disable
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 20-19
Configuring BFD
Configuring BFD
To display the BFD status of BGP neighbors, use the show ip bgp neighbors command. For example:
-> show ip bgp neighbors
Legends: Nbr = Neighbor
As = Autonomous System
Nbr address
As
Admin state Oper state
BGP Id
Up/Down
BFD Status
---------------+-----+-----------+------------+-----------+------------+--------100.1.1.10
2
enabled
established 3.3.3.3
00h:02m:19s enabled
Use the show ip bfd sessions command to view BFD sessions with all BFD neighbors. For example:
-> show ip bfd sessions
Legends: Neg.
Discr
Intvl
= Negotiated
= Discriminator
= Interval (in milliseconds)
Local
Interface Neighbor
State
Remote
Neg. Rx Neg. Tx EchoRx
Discr
Name
Address
Discr
Intvl
Intvl
Intvl
------+-----------+--------------+----------+------+----------+--------+------1
v1001
101.1.1.11
UP
1
300
300
300
2
v2000
200.1.1.1
UP
0
0
0
300
-> show ip bfd sessions 1
Local discriminator
Neighbor IP Address
Requested Session Type
Interface IfIndex
Source UDP Port
State
Session Operating Mode
Remote discriminator
Negotiated Tx interval
Negotiated Rx interval
Echo Rx interval
Multiplier
Applications Registered:
=
=
=
=
=
=
=
=
=
=
=
=
=
1,
100.1.1.10,
ASYNC ,
2,
49152,
UP,
None,
1,
300,
300,
300,
3,
BGP
Configuring BFD Support for VRRP Tracking
The steps below show you how to configure and verify BFD support for VRRP protocol, so that VRRP is
a registered protocol with BFD and receives forwarding path detection failure messages from BFD.
1 To associate VRRP protocol with BFD liveliness detection, register VRRP with BFD at the protocol
level using the vrrp bfd-state command as shown below:
-> vrrp bfd-state enable
Note. VRRP protocol supports BFD in the echo-only operational mode.
BFD status for VRRP protocol is now enabled which means that socket communication between VRRP
and BFD is enabled.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 20-20
Configuring BFD
Configuring BFD
To de-register VRRP with BFD, enter the following command at the system prompt:
-> vrrp bfd-state disable
To verify the BFD status for VRRP protocol, you can use the show vrrp command as shown below:
-> show vrrp
VRRP
VRRP
VRRP
VRRP
VRRP
default advertisement interval: 1 second
default priority: 100
default preempt: Yes
trap generation: Enabled
startup delay: 45 (expired)
VRRP BFD-STATUS : Enabled
IP
Admin
Adv.
VRID VLAN
Address(es)
Status
Priority Preempt
Interval
----+ ----+ -------------+----------+----------+----------+--------1
1
192.168.170.1
Enabled
255
Yes
1
192.168.170.2
2
15
10.2.25.254
Disabled
100
No
1
2 Once VRRP is registered with BFD at the protocol level, enable BFD for a particular VRRP track
policy using the vrrp track command. Ensure that the track policy is associated with at least one of the
virtual routers. For example:
-> vrrp track 2 address 10.1.1.1 bfd-state enable
The above command enables BFD for a track policy with VRRP track number 2 and a remote interface
address of 10.1.1.1.
Note. The value of the address parameter should be a remote interface address. BFD cannot be configured
for a local interface address.
Use the show vrrp track command to verify whether BFD is enabled for a particular track policy. For
example:
-> show vrrp track
Track
Admin
Oper
BFD
ID
Policy
State
State Pri
Status
-----+---------------------------------------+----------+------+------+--------1
190.1.1.10
Enabled
Down
100 Disabled
2
10.1.1.1
Enabled
Up
25
Enabled
Use the show ip bfd interfaces command to verify the BFD interface/session configuration and operation
status.
Once the track policy is configured, the BFD session is established with the remote IP address. BFD
session is also established with the BFD neighbors.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 20-21
Configuring BFD
Configuring BFD
Use the show ip bfd sessions command to view BFD sessions with all BFD neighbors. For example:
-> show ip bfd sessions
Legends: Neg.
Discr
Intvl
= Negotiated
= Discriminator
= Interval (in milliseconds)
Local
Interface Neighbor
State
Remote
Neg. Rx Neg. Tx EchoRx
Discr
Name
Address
Discr
Intvl
Intvl
Intvl
------+-----------+--------------+----------+------+----------+--------+------1
v1001
101.1.1.11
UP
1
300
300
300
2
v2000
200.1.1.1
UP
0
0
0
300
-> show ip bfd sessions 2
Local discriminator
Neighbor IP Address
Requested Session Type
Interface IfIndex
Source UDP Port
State
Session Operating Mode
Remote discriminator
Negotiated Tx interval
Negotiated Rx interval
Echo Rx interval
Multiplier
Applications Registered:
=
=
=
=
=
=
=
=
=
=
=
=
=
2,
10.1.1.1,
ECHO,
4,
49153,
UP,
None,
0,
0,
0,
300,
3,
VRRP
Configuring BFD Support for Static Routes
This section provides information about how to configure and verify BFD support for static routing.
To change the default BFD status for a particular static route and to enable BFD support, use the ip staticroute bfd-state command. For example:
-> ip static-route 10.1.1.1 mask 255.0.0.0 gateway 10.1.1.25 bfd-state enable
Note. Static Routes support BFD in the echo-only operational mode.
The above command enables BFD support for a static route with destination ip address as 10.1.1.1,
destination network mask as 255.0.0.0, and gateway address as 10.1.1.25.
In order to create a BFD session for a static route, the gateway address should not match with any local
interface address of the switch. If multiple routes are configured with the same gateway address, only one
BFD session is run. You can verify the BFD session list which shows the gateway address using the show
ip bfd sessions command.
To enable BFD support for all static routes, use the ip static-route all bfd-state command:
-> ip static-route all bfd-state enable
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 20-22
Configuring BFD
Configuring BFD
To verify the static routes on which BFD is enabled, use the show ip router database command with the
protocol static option. For example:
-> show ip router database protocol static
Legend: + indicates routes in-use
b indicates BFD-enabled static route
r indicates recursive static route, with following address in brackets
Total IPRM IPv4 routes: 7
Destination
Gateway
Interface
Protocol Metric Tag
Misc-Info
-------------------+---------------+------------+--------+-------+-----+----------+b 100.0.0.0/8
100.1.1.10
v1001
STATIC
1
0
+ 128.251.40.0/24
172.28.4.254
EMP
STATIC
1
0
Inactive Static Routes
Destination
Gateway
Metric
--------------------+-----------------+---------
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 20-23
Configuring BFD
BFD Application Example
BFD Application Example
This section provides an example network configuration in which BFD is associated with the OSPF
protocol running on the network. In addition, a tutorial is also included that provides steps on how to
configure the example network topology using the Command Line Interface (CLI).
Example Network Overview
The diagram below represents a simple OSPF network consisting of three routers. On all three routers,
OSPF is associated with BFD for faster failure detection of any router on the network.
Router 1
Router ID 1.1.1.1
VLAN 12
Interface 12.x.x.x
VLAN 31
Interface 31.x.x.x
OSPF Area 0.0.0.1 with BFD
Router 2
Router ID 2.2.2.2
VLAN 23
Interface 23.x.x.x
Router 3
Router ID 3.3.3.3
Example OSPF Network using the BFD Protocol
The following steps are used to configure the example BFD-enabled OSPF network as shown in the
diagram above.
Note. Configuring a BFD session explicitly with an IP interface name on individual routers is optional, and
must be used if user defined BFD session parameters need to be applied. All the steps for explicit
configuration are mentioned as optional.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 20-24
Configuring BFD
BFD Application Example
Step 1: Prepare the Routers
The first step is to create the VLANs on each router, add an IP interface to the VLAN, assign a port to the
VLAN, and assign a router identification number to the routers. For the backbone connection, the network
design in this case uses slot 2, port 1 as the egress port and slot 2, port 2 as ingress port on each router.
Router 1 connects to Router 2, Router 2 connects to Router 3, and Router 3 connects to Router 1.
Note. The ports are statically assigned to the router VLANs, as a VLAN must have a physical port assigned
to it in order for the IP router interface to function.
The commands to set up the VLAN configuration are shown below:
Router 1 (using ports 2/1 and 2/2 for the backbone and ports 2/3-5 for end devices):
-> vlan 31
-> ip interface vlan-31 vlan 31 address 31.0.0.1 mask 255.0.0.0
-> vlan 31 members port 2/1
-> vlan 12
-> ip interface vlan-12 vlan 12 address 12.0.0.1 mask 255.0.0.0
-> vlan 12 members port 2/2
-> vlan 10
-> ip interface vlan-10 vlan 10 address 10.0.0.1 mask 255.0.0.0
-> vlan 10 members port 2/3-5
-> ip router router-id 1.1.1.1
These commands created VLANs 31, 12, and 10.
• VLAN 31 handles the backbone connection from Router 1 to Router 3, using the IP router port
31.0.0.1 and physical port 2/1.
• VLAN 12 handles the backbone connection from Router 1 to Router 2, using the IP router port
12.0.0.1 and physical port 2/2.
• VLAN 10 handles the device connections to Router 1, using the IP router port 10.0.0.1 and physical
ports 2/3-5. More ports could be added at a later time if necessary.
The router was assigned the Router ID of 1.1.1.1.
Router 2 (using ports 2/1 and 2/2 for the backbone and ports 2/3-5 for end devices):
-> vlan 12
-> ip interface vlan-12 vlan 12 address 12.0.0.2 mask 255.0.0.0
-> vlan 12 members port 2/1
-> vlan 23
-> ip interface vlan-23 vlan 23 address 23.0.0.2 mask 255.0.0.0
-> vlan 23 members port 2/2
-> vlan 20
-> ip interface vlan-20 vlan 20 address 20.0.0.2 mask 255.0.0.0
-> vlan 20 members port 2/3-5
-> ip router router-id 2.2.2.2
These commands created VLANs 12, 23, and 20.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 20-25
Configuring BFD
BFD Application Example
• VLAN 12 handles the backbone connection from Router 1 to Router 2, using the IP router port
12.0.0.2 and physical port 2/1.
• VLAN 23 handles the backbone connection from Router 2 to Router 3, using the IP router port
23.0.0.2 and physical port 2/2.
• VLAN 20 handles the device connections to Router 2, using the IP router port 20.0.0.2 and physical
ports 2/3-5. More ports could be added at a later time if necessary.
The router was assigned the Router ID of 2.2.2.2.
Router 3 (using ports 2/1 and 2/2 for the backbone, and ports 2/3-5 for end devices):
-> vlan 23
-> ip interface vlan-23 vlan 23 address 23.0.0.3 mask 255.0.0.0
-> vlan 23 members port 2/1
-> vlan 31
-> ip interface vlan-31 vlan 31 address 31.0.0.3 mask 255.0.0.0
-> vlan 31 members port 2/2
-> vlan 30
-> ip interface vlan-30 vlan 30 address 30.0.0.3 mask 255.0.0.0
-> vlan 30 members port 2/3-5
-> ip router router-id 3.3.3.3
These commands created VLANs 23, 31, and 30.
• VLAN 23 handles the backbone connection from Router 2 to Router 3, using the IP router port
23.0.0.3 and physical port 2/1.
• VLAN 31 handles the backbone connection from Router 3 to Router 1, using the IP router port
31.0.0.3 and physical port 2/2.
• VLAN 30 handles the device connections to Router 3, using the IP router port 30.0.0.3 and physical
ports 2/3-5. More ports could be added at a later time if necessary.
The router was assigned the Router ID of 3.3.3.3.
Step 2: Enable OSPF
The next step is to load and enable OSPF on each router. The commands for this step are below (the
commands are the same on each router):
-> ip load ospf
-> ip ospf admin-state enable
Step 3: Create the OSPF Area
Now the area should be created. In this case, we create area 0.0.0.1. The command for this step is below
(the command is the same on each router):
-> ip ospf area 0.0.0.1
Area 0.0.0.1 is created and enabled.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 20-26
Configuring BFD
BFD Application Example
Step 4: Configure OSPF Interfaces
Next, OSPF interfaces must be created, enabled, and assigned to area 0.0.0.1. The OSPF interfaces should
have the same interface name as the IP router interfaces created above in “Step 1: Prepare the Routers” on
page 20-25.
Router 1
-> ip ospf interface vlan-31
-> ip ospf interface vlan-31 area 0.0.0.0
-> ip ospf interface vlan-31 admin-state enable
-> ip ospf interface vlan-12
-> ip ospf interface vlan-12 area 0.0.0.0
-> ip ospf interface vlan-12 admin-state enable
-> ip ospf interface vlan-10
-> ip ospf interface vlan-10 area 0.0.0.1
-> ip ospf interface vlan-10 admin-state enable
Router 2
-> ip ospf interface vlan-12
-> ip ospf interface vlan-12 area 0.0.0.0
-> ip ospf interface vlan-12 admin-state enable
-> ip ospf interface vlan-23
-> ip ospf interface vlan-23 area 0.0.0.0
-> ip ospf interface vlan-23 admin-state enable
-> ip ospf interface vlan-20
-> ip ospf interface vlan-20 area 0.0.0.2
-> ip ospf interface vlan-20 admin-state enable
Router 3
-> ip ospf interface vlan-23
-> ip ospf interface vlan-23 area 0.0.0.0
-> ip ospf interface vlan-23 admin-state enable
-> ip ospf interface vlan-31
-> ip ospf interface vlan-31 area 0.0.0.0
-> ip ospf interface vlan-31 admin-state enable
-> ip ospf interface vlan-30
-> ip ospf interface vlan-30 area 0.0.0.3
-> ip ospf interface vlan-30 admin-state enable
Step 5: (Optional) Configure BFD Interfaces
Next, BFD interfaces must be created and enabled. The BFD interfaces should have the same interface
name as the IP router interfaces created above in “Step 1: Prepare the Routers” on page 20-25.
Router 1
-> ip bfd interface vlan-31
-> ip bfd interface vlan-31 admin-state enable
-> ip bfd interface vlan-12
-> ip bfd interface vlan-12 admin-state enable
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 20-27
Configuring BFD
BFD Application Example
-> ip bfd interface vlan-10
-> ip bfd interface vlan-10 admin-state enable
Router 2
-> ip bfd interface vlan-12
-> ip bfd interface vlan-12 admin-state enable
-> ip bfd interface vlan-23
-> ip bfd interface vlan-23 admin-state enable
-> ip bfd interface vlan-20
-> ip bfd interface vlan-20 admin-state enable
Router 3
-> ip bfd interface vlan-23
-> ip bfd interface vlan-23 admin-state enable
-> ip bfd interface vlan-31
-> ip bfd interface vlan-31 admin-state enable
-> ip bfd interface vlan-30
-> ip bfd interface vlan-30 admin-state enable
Step 6: (Optional) Configure Global BFD Parameters
Global BFD parameter settings for timer values and operational mode are applied to all BFD interfaces
configured on the routing instance. When a BFD interface is created, the global settings are also applied as
the default parameter values for the interface.
The following steps change the default global BFD parameter values for the example network; the
commands used are the same on each router.
• Set the minimum amount of time BFD waits between each transmission of control packets to 200.
-> ip bfd transmit 200 milliseconds
• Set the minimum amount of time BFD waits to receive control packets to 200 milliseconds.
-> ip bfd receive 200
• Set the global BFD Echo packet time interval to 200 milliseconds.
-> ip bfd echo-interval 200
Step 7: Enable BFD and register OSPF with BFD
Once all the global BFD parameters are configured, enable BFD on all interfaces, register BFD with
OSPF, and then enable BFD on all OSPF interfaces. The following steps are the same on each router:
'In this example, global BFD parameters will be used for the BFD sessions. Enable BFD admin status and
register OSPF with BFD and then enable BFD on all OSPF interfaces. Repeat the following steps on each
router:
-> ip bfd admin-state enable
-> ip ospf bfd-state enable
-> ip ospf bfd-state all-interfaces enable
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 20-28
Configuring BFD
Verifying the BFD Configuration
Step 8: Examine the Network
After the network has been created, use the following show commands to check various aspects of the
example network:
• To verify the configured BFD status on routers, use the show ip bfd command. This command shows
the protocols registered for BFD (OSPF in example network) and the parameter values for the transmit,
receive, and echo intervals, the multiplier number, and the operational mode.
• To display information about BFD sessions, use the show ip bfd sessions command.
• To check the BFD status at the OSPF protocol level, use the show ip ospf command. This command is
also used to check the general OSPF configuration. For OSPF interfaces, use the show ip ospf
interface command.
Verifying the BFD Configuration
To display information such as the BFD status for different session parameters and Layer 3 protocols, use
the show commands listed in the following table:
show ip bfd
Displays the global BFD configuration for the routing instance.
show ip bfd interfaces
Displays the BFD interface configuration for the switch.
show ip bfd sessions
Displays the BFD neighbors and session states.
show ip ospf
Displays the BFD status for the OSPF protocol.
show ip ospf interface
Displays the BFD status for OSPF interfaces.
show ip bgp
Displays the BFD status for the BGP protocol.
show ip bgp neighbors
Displays the BFD status for BGP neighbors.
show vrrp
Displays the BFD status for the VRRP protocol.
show vrrp track
Displays the BFD status for a track policy.
show ip router database
protocol static
Displays the BFD status for static routes.
For more information about the resulting displays form these commands, see the OmniSwitch AOS
Release 8 CLI Reference Guide. Examples of the above commands and their outputs are given in the
section “Configuring BFD” on page 20-12.
OmniSwitch AOS Release 8 Network Configuration Guide
September 2017
page 20-29
21
Configuring DHCP Relay
The User Datagram Protocol (UDP) is a connectionless transport protocol that runs on top of IP networks.
The DHCP Relay allows you to use nonroutable protocols (such as UDP) in a routing environment. UDP
is used for applications that do not require the establishment of a session and end-to-end error checking.
Email and file transfer are two applications that could use UDP. UDP offers a direct way to send and
receive datagrams over an IP network and is primarily used for broadcasting messages. This chapter
describes the DHCP Relay feature. This feature allows UDP broadcast packets to be forwarded across
VLANs that have IP routing enabled.
In This Chapter
This chapter describes the basic components of DHCP Relay and how to configure them. CLI commands
are used in the configuration examples. For more details about the syntax of commands, see the
OmniSwitch AOS Release 8 CLI