Escolar Documentos
Profissional Documentos
Cultura Documentos
Contents
About This Guide
Intended Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Related Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Typographical Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cautions, Warnings, and Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IPv6 Address Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Customer Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 11 12 12 13 14 16
Chapter 1: Introduction
Hardware Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network Processor Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Control Processor Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Application Processor Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Module Link Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Virtual Application Processor (VAP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Traffic Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Application Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Greenlight Element Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Automated Workflow System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Management Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Greenlight Element Manager (GEM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Command Line Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Element Management System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 18 18 18 19 19 19 20 20 21 21 22 23 23 23 24
33 33 34 34 34 35 35 35 35 36 36 37 37 38
3
61 62 62 62 62 63 63 65 65 65 66 66 66 68
4
Packet Mirroring on the NPM Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Access Control Lists (ACL Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . configure acl-interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Access Control Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Chassis Resource Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Resource Protection Workflow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Disabling Flow Table Limit Action per Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Redundant Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring a Multi-Link Group Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73 73 73 75 78 81 82 83 85
Contents
Chapter 15: Using UNIX Commands on VAP Groups and Upgrading Applications
Executing UNIX Commands on a Designated VAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Executing UNIX Commands on All VAPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Copying a File from the CPM to all the VAPs in a VAP Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Starting and Stopping the Swatch Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Single Key Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Swatch Tool Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a Swatch Tool Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the swacquire Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the swread Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the swcalc Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the swaggr Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the swscreen Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the swdisplay Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Logging Screen Data to a File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Predefined TCL Variables in a Swatch Tool Configuration File. . . . . . . . . . . . . . . . . . . . . . . Using Swatch Tool Variables in All Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Existing Swatch Tool Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Performance Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Swatch Tool Child Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Single Shared-Memory Region and Semaphore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Troubleshooting the Swatch Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data Not Being Displayed or Updated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data is Not Displayed in the Correct Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Swatch Tool is Affecting CPM Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Swatch Tool is Affecting Performance of Remote APMs or NPMs . . . . . . . . . . . . . . . . . . . . . . . . .
259 259 260 260 260 261 261 262 262 262 263 263 263 264 264 264 265 265 265 265 265 265
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Contents
10
Intended Audience
This guide is intended for qualified service personnel responsible for installing, configuring, and managing software on Crossbeam X-Series Platforms.
Related Documentation
The following documents are provided on the Crossbeam Systems USB Installer (USBI) or are available on the Crossbeam Systems Customer Support Portal located at http://www.crossbeam.com/support/online-support/.
z z z z z z z z z z z
APM, CPM, and NPM Installation Notice X80-S Platform Hardware Installation Guide X60 Platform Hardware Installation Guide X20 and X30 Platform Hardware Installation Guide XOS Command Reference Guide Multi-Application Serialization Configuration Guide Multi-System High Availability Configuration Guide Install Server User Guide USB Installer User Guide RSW Installation Guide (available with the RSW kit, purchased separately) XOS V9.5.1 Release Notes
Configuration Guide
11
Conventions
Typographical Conventions
For paragraph text conventions, see Table 1 on page 12. For command-line text conventions, see Table 2 on page 13.
Table 1.
Courier
Keys on the keyboard. File names, folder names, and command names. Any information that you must type exactly as shown. Program output text.
Press Esc to return to the main menu. Save the user.txt file in the user_install directory. Use the start command to start the application. In the Username field, type Administrator. The XOS CLI show calendar command displays the system calendar: Fri Feb 25 13:32:03 2011
Courier Italic
File names, folder names, command names, or other information that you must supply. A sequence of commands from the task bar or menu bar.
>
From the taskbar, choose Start > Run. From the main menu, choose File > Save As... Right-click on the desktop and choose Arrange Icons By > Name from the pop-up menu.
12
Table 2.
Courier Bold Information that you must type in exactly as shown. <Courier Italic> Angle brackets surrounding Courier italic text indicate file names, folder names, command names, or other information that you must supply. Square brackets contain optional information that may be supplied with a command. Separates two or more mutually exclusive options. Braces contain two or more mutually exclusive options from which you must choose one.
[root@xxxxx]# md <your_folder_name>
[]
{}
Configuration Guide
13
NOTE: XOS V9.5.x does not support mixed notation IPv6 addresses.
Standard notation
The standard notation for IPv6 addresses is eight 16-bit hexadecimal words separated by colons. For example: 2001:BA95:AC10:0000:CF6A:000D:2145:3713 Specifying leading zeros is not required, provided that there is at least one numeric value in each field of the address. The above address can also be represented as: 2001:BA95:AC10:0:CF6A:D:2145:3713
Compressed notation
Many IPv6 addresses contain multiple fields of zeros. Use the double colon (::) notation to represent a single contiguous group of zero fields within an IPv6 address. For example: 1458:0:0:0:0:A03:5:AC17 AF06:0:0:0:BC:0:0:4 0:0:0:0:0:0:0:1 0:0:0:0:0:0:0:0 These can be represented as: 1458::A03:5:AC17 AF06::BC:0:0:4 ::1 :: NOTE: The AF06:0:0:0:BC:0:0:4 example is represented as AF06::BC:0:0:4 because only one ::'' is allowed in an address. In this guide, the example IPv6 addresses are taken from:
z z
The Unique Local Unicast address range (FC00::/7) because these addresses are not propagated over the Internet The 2002: address range as part of the prefix for IPv6 6to4 tunnels
14
NOTE: In accordance with the IANA IPv6 address space allocations, an XOS VAP of type xslinux_v3 ("V3"), xslinux_v5 ("V5"), or xslinux_v5_64 ("V5_64") will treat some address ranges as reserved. At this writing, the IANA range assignments are as follows (excerpted from http://www.iana.org/assignments/ipv6-address-space/): IPv6 Prefix 0000::/8 0100::/8 0200::/7 0400::/6 0800::/5 1000::/4 2000::/3 4000::/3 6000::/3 8000::/3 A000::/3 C000::/3 E000::/4 F000::/5 F800::/6 FC00::/7 FE00::/9 FE80::/10 FEC0::/10 FF00::/8 Allocation Reserved by IETF Reserved by IETF Reserved by IETF Reserved by IETF Reserved by IETF Reserved by IETF Global Unicast Reserved by IETF Reserved by IETF Reserved by IETF Reserved by IETF Reserved by IETF Reserved by IETF Reserved by IETF Reserved by IETF Unique Local Unicast Reserved by IETF Link Local Unicast Reserved by IETF Multicast Reference [RFC4291] [RFC4291] [RFC4048] [RFC4291] [RFC4291] [RFC4291] [RFC4291] [RFC4291] [RFC4291] [RFC4291] [RFC4291] [RFC4291] [RFC4291] [RFC4291] [RFC4291] [RFC4193] [RFC4291] [RFC4291] [RFC3879] [RFC4291]
With regard to reserved address blocks, some kernel versions make address-type determinations that are different from those made by other kernel versions. It should be noted that, in particular, V3 VAPs treat the following ranges as strictly reserved (that is, these addresses are reserved and are not treated as Global Unicast addresses), whereas V5 and V5_64 VAPs treat these ranges as reserved Global Unicast addresses:
z z z z
For purposes of XOS circuit/interface configuration, it is recommended that the above "Reserved by IETF" ranges NOT be used unless warranted by special circumstances. In the general case, user-assigned XOS IPv6 unicast circuit/interface addresses should be allocated from the 2000::/3 (Global Unicast) and/or the FC00::/7 (Unique Local Unicast) address block(s).
Configuration Guide
15
Customer Support
Crossbeam Systems offers a variety of service plans designed to meet your specific technical support requirements. For information on purchasing a service plan for your organization, please contact your account representative or refer to http://www.crossbeam.com/support/technical-support/. If you have purchased a Crossbeam Systems product service plan and need technical assistance, you can report issues by telephone: United States: +1 800-331-1338 OR +1 978-318-7595 EMEA: + 33 4 8986 0400 Asia Pacific: +1 978-318-7595 Latin America: +1 978-318-7595 You can also report issues via e-mail to support@crossbeam.com. In addition, all of our service plans include access to the Crossbeam Customer Support Portal located at http://www.crossbeam.com/support/online-support/. The Crossbeam Customer Support Portal provides you with access to a variety of resources, including Customer Support Knowledgebase articles, technical bulletins, product documentation, and release notes. You can also access our real-time problem reporting application, which lets you submit new technical support requests and view all your open requests. Crossbeam Systems also offers extensive customer training on all of its products. For current course offerings and schedules, please refer to the Crossbeam Education Services Web pages located at http://www.crossbeam.com/support/training-services/.
16
1
Introduction
The X-Series Platform running the XOS software is an open networked application server designed to deliver enhanced application services while providing high-performance and availability. The modular design of the X-Series Platform allows it to run multiple applications, while providing multi-gigabit throughput performance. The XOS software, using secure standard interfaces with multiple levels of controlled access, enables cost effective integration of the X-Series Platform into the overall operation of your network. This chapter provides an overview of the various features and functions of the X-Series Platform.
z z z z z z z z z
Hardware Overview on page 17 Virtual Application Processor (VAP) on page 19 Traffic Flow on page 19 Networking on page 20 High Availability on page 20 Application Overview on page 21 Greenlight Element Manager on page 21 Automated Workflow System on page 22 Management Options on page 23
Hardware Overview
There are various XOS hardware platforms for different business needs. Each hardware platform contains three types of modules:
z z z
Network Processor Module (NPM) for packet reception, classification and load balancing. Control Processor Module (CPM) maintaining overall system configuration, management and integrity. Application Processor Module (APM) for hosting applications and network services that process packets belonging to individual flows.
These modules contain standard network interfaces including 10/100/1000 Ethernet, and RS-232 ports. When populated with two CPMs, two to four NPMs, and two to ten APMs, the X-Series Platform operates without a single point of failure. The X-Series Platform also supports multiple, redundant power supplies (1200W or 2700W). For more information about power supply compatibility, refer to the X-Series AC Power Supply Installation and Replacement Guide.
17
Switched Ethernet control network for all slots in the chassis. 10/100/1000 external Ethernet management port, logging port, console port, and chassis interconnect port (for dual-box high availability). Management of the system boot process. Management of insertion or removal of new modules into the X-Series Platform. Software upgrade. Service provisioning. CP redundancy. RAID data protection or hard drive maximization. Management of alarms.
The X-Series Platform supports up to two CPMs, with both CPM slots providing identical control plane connectivity. The CPM designated as the Primary CPM can manage and support all NPMs and APMs in chassis. When two CPMs are present, one module remains in a standby (secondary) state until needed, which provides CP redundancy. The CPM communicates to the other modules through a dual-redundant, private, switched control plane. The switching elements for the control plane are housed on the CPM, with all the point-to-point connections from each of the other slots in the chassis arriving at the CPM through the backplane connector.
Introduction
18
Hellos: Broadcast tracking states of links interconnecting modules. Election: Unicast between two CPMs to negotiate which CPM is to become the primary.
Traffic Flow
The X-Series Platform dynamically creates internal flow paths for each serviced flow. On the arrival of the first packet of a new flow, a new path is created based on the flow rule associating user traffic with provisioned application services. All subsequent packets of the flow follow the same path through the system and are processed by the same set of applications. The X-Series Platform can parallelize or serialize traffic. As shown in Figure 1, parallelization is copying a traffic flow to one or more passive applications. For example, traffic can be passed to a Firewall and IDS simultaneously. This eliminates the need for external taps or SPAN ports. You configure parallelization by mapping a circuit to two VAP groups. Also shown in Figure 1, serialization is defined as moving traffic through two or more active applications. For example, passing a flow first to an intrusion protection application then to a Firewall. Serialization is configured with the use of an internal circuit. Flow rules determine how a new traffic flow is processed when it arrives on a logical interface. A traffic flow is identified by a set of parameters in the flow rule, configured by the user.
19
Figure 1.
Physical Port
Traffic Logical
Pa
Circuit
ra
lle
ra lT
c ffi
VAP Group 2
VAP VAP VAP
Parallel Traffic
NPM
Serial Traffic
VAP VAP VAP
VAP Group 3
Networking
The X-Series Platform supports these networking features:
z z z z z
Bridge mode for firewall and IDS/IPS Virtual Local Area Network (VLAN) IP static routes Equal Cost-MultiPath (ECMP) support for static routes Dynamic routing protocols, BGP, OSPF, OSPFv3, RIP, RIPNG, PIM-SM, and IGMP; however, these protocols require the optional Routing Software (RSW) kit (purchased separately)
High Availability
The X-Series Platform provides a number of features to ensure that the system remains operational. The features include:
z z z z
CP Redundancy. Each chassis contains two CPMs, where one is Active and the other is Standby. Interface Redundancy. A physical interface can be configured as a backup to another physical interface. Failover occurs quickly and is transparent to the application. LACP (Link Aggregation Control Protocol). Multiple physical interfaces can be combined into one interface. A failure of one physical link does not prevent traffic flow. VAP Load Balancing. Each VAP corresponds to an APM. In a VAP group, each VAP runs an instance of the application, and traffic is load balanced among the VAPs. Should an APM fail, the system automatically redistributes the traffic flow among the remaining VAPs. VAP Load Balancing with Synchronization. State synchronization may be necessary when switching a flow from one VAP to another while stateful packet processing is being performed. Using Check Point FireWall-1 synchronization, when a flow is reassigned to another VAP within the group, that VAP will have the proper FireWall-1 connection state to process the arriving packets. There may be a delay in synchronizing the new connection state to other VAPs so some packets may be dropped by the Firewall on the new VAP until the connection state is created.
Introduction
20
z z z
Standby VAP. An unused VAP is configured as Standby. Should a VAP in any VAP group fail, the standby VAP automatically joins that group. APM Preemption Mode. VAP groups are assigned a priority. Should a higher priority VAP group have a VAP failure, a VAP from a lower priority application is taken and reloaded into the high priority group. Multi-System High Availability. Using VRRP (Virtual Router Redundancy Protocol), two or more X-Series Platforms can be configured to provide High Availability (HA).
Application Overview
The X-Series Platform supports these basic application configurations:
z z
Multiple instances of the same application on different VAP groups. For example, you can have many distributed firewalls and have distinct policies in each instance. One VAP group can span multiple Application Processor Modules (APMs). The flow classification and distribution allow for even load balancing across all VAPs, thereby increasing the performance of a single application. Multiple applications can be configured to run concurrently. The multi-application configurations can use the Check Point OPSEC APIs to allow configurations of Check Point and one or more OPSEC-compliant applications. For example, Check Point FW-1/VPN-1 can be configured to use the Squid and Websense URL filtering applications using the Check Point OPSEC APIs. These applications would run in separate VAP groups. Other non-OPSEC compliant multi-application scenarios are supported as well. Multiple applications can be configured to run in series. Multiple, different applications can be linked through an interface-internal, allowing traffic to be inspected by each application. Traffic is passed from one application to the next, allowing for multi-layered, in-depth inspection by best-of-breed security applications within a single X-Series Platform.
2 Ghz, dual-core processor, with 2GB RAM Minimum screen resolution of 1024x768 Microsoft Windows 7, Vista, or XP
z z
Apple Mac 10.5 with Firefox 3.0 or 3.5 Linux with Firefox 3.0 or 3.5
21
To access the Greenlight Element Manager, configure the Web server during the XOS software installation, or from the command line after install. Use a secure connection (https://) to enter the system IP address or name in a Web browser. https://<ip_address>
Select a submenu to view available automated workflows. Enter x to exit or ? for help. Please Enter Selection: Use the question mark to access the help on any of the menu or submenu commands.
Introduction
22
Management Options
XOS provides the following system management options:
z z z
Greenlight Element Manager Command Line Interface (CLI) Element Management System (EMS)
A user account has CLI, GEM, AWS, and EMS access. However, the level of access for CLI and EMS is configured differently. XOS supports Access Control Lists (ACLs) for the Ethernet management port.
Figure 2.
unix su
Unix Prompt [root@xxxx admin]# rsh fw_1 rsh fw_2 rsh fw_3
23
Configure and monitor the NPM, APM, and CPM Configure and monitor circuits View information about modules Maintain user accounts and access levels View performance statistics
EMS requires Java Runtime Environment (JRE) 1.6.x or higher on the client system. If you are using Internet Explorer as your browser, you will be automatically taken to Sun's web site to download JRE the first time you start EMS. Otherwise, you can download it manually from http://java.sun.com. NOTE: EMS cannot be used to install applications. This can only be done using the CLI. Also, EMS cannot configure offline modules; this must also be done using the CLI. EMS access levels differ from the CLI access levels. Each user account is assigned a specific role, restricting the user to view and configure only certain windows within EMS. EMS is displayed in a browser window that directly connects to a web server running on the X-Series Platform. Multiple X-Series Platforms can be managed from a workstation by using separate browser windows. Communication between the workstation and each individual X-Series Platform uses an HTTPS-based private interface and exchange XML-formatted data. To access EMS, configure the Web server during the XOS software installation, or from the command line after install. NOTE: The log on process to EMS has changed. Enter the IP address of the X-Series Platform followed by /ems (i.e. https://<ip_address>/ems) into your browsers address field. The user name and password are case sensitive. The connection between the X-Series Platform and a dedicated workstation is made secure by the Secure Socket Layer (SSL). SSL provides authentication, integrity, and security between a browser and the XOS web server. The EMS window contains three sections:
z z z
The menus in the top frame provide access to administrative functions, configuration, and other tasks. The navigation tree in the left frame displays folders to open windows for configuring, provisioning, and monitoring the system. The work space in the right pane displays information windows about a folder or component you select in the tree view. For example, when you click on the System Configuration folder, a window is displayed showing configuration properties for the system.
Introduction
24
2
Initial Configuration
When you log in to the X-Series Platform for the first time, the system runs the Interview program. This program prompts you to configure various parameters. The Interview does not run on subsequent startups, unless you reset the system to factory defaults. By default, DHCP and SSH are enabled for quick access and initial setup. This chapter contains the following topics:
z z z z
Configuration Overview on page 25 Using the Interview Process on page 28 Changing Default Usernames and Passwords on page 30 Changing Default SSH Keys on page 31
Configuration Overview
The basic steps to configure the X-Series Platform are as follows: 1. 2. Gather information about your network and security applications. Use the Interview program to configure the basic parameters, such as:
CPM management IP Address and subnet mask Activate the Web Server to provide access to Greenlight Element Manager and EMS Create and configure user accounts Create and configure Access Control Lists (ACLs) Internal IP network address and subnet mask NOTE: The internal network IP address must be unique to your network. CPM default gateway and host name Time server IP address System Identifier, which is a unique value from 1 to 255 given to each X-Series Platform Operating mode
3. 4. 5. 6.
Create Virtual Application Processors (VAPs). Define circuits, which are interfaces to the VAP. Define the physical interfaces and map them to the circuits. Define the IP and non-IP flow rules.
Load and configure the various applications. Configure facility alarms. Configure the routing features, such as IP static routes and their cost, and the optional routing protocols (OSPF, OSPFv3, RIP, RIPNG, BGP, and PIM-SM). Configure High Availability. This can include single or multi-box redundancy, CPM redundancy, and redundant interfaces.
25
Network Topology
Gather or create the following network topology information: 1. 2. Create a diagram containing as much information as possible about your network topology. List all known IP, VLAN, and media information.
Table 3.
NPM
3.
Specify the VAP group default gateway route for all XOS VAP groups.
Table 4.
Initial Configuration
26
4.
Table 5.
Destination Network
5.
Specify information about other devices that are directly connected to your X-Series Platform. Add them to your diagram and supply their IP and/or VLAN information if applicable.
6.
Specify all information about remote access to your Security Service Switch. For example:
Application Information
Gather the following application specific information: 1. Specify the platform you are using, for example:
27
2.
Specify the intended VAP group names used with the applications.
Table 6.
Application
3.
CPM management IP Address Subnet mask System Identifier Interfaces Internal IP network address and subnet mask CPM default gateway and host name Time server IP address
Initial Configuration
28
These features can also be configured using the Command Line Interface (CLI) or the graphical Element Management System (EMS) utility. Each feature is described in detail in the appropriate chapter of this configuration guide. Refer to specific chapters as necessary. Some reasons you would exit the Interview program:
z z
To configure VAP groups and circuits. To import an existing configuration file using FTP.
If you choose to exit the Interview program, you can refer to the Configuration Overview on page 25 as a guideline to complete the system configuration.
Display the running and startup configuration files as follows: show running-config show startup-config
NOTE: If you are using EMS, use the System Config menu to display the running or startup configuration file.
z z z
Display the running configuration validation Copy the running configuration to the startup configuration or to a file Copy the startup configuration to a named file
29
To access the Command Line Interface (CLI), the username is admin, and the password is admin. From the admin account, use the following command to change the password. You are prompted for a new password. CBS# configure password
NOTE: The admin user can be deleted using the configure no username admin command. Before deleting the admin user, make sure that another user name with the same privileges exists. If the admin user is deleted, this command appears in the running configuration file after an XOS upgrade to prevent the admin user from being recreated by default.
z z
To access the X-Series Platform from the EMS web server, the username is admin and the password is admin. Use the configure password command to change the password. The GRUB password is MD5-encrypted. The password to access GRUB is x40rocks. Perform the following to change the password: a. b. Log into the system as root which will place you at the Linux prompt. Run /sbin/grub-md5-crypt to create the MD5-crypted password, for example: [root@xxxxx root]# /sbin/grub-md5-crypt Password: $1$LiTbt0$30FLNL0TWxFWWyBBhoYw6. c. d. Edit the /boot/grub/grub.conf file and replace the old MD5-crypted password with the new MD5-crypted password string. Save the /boot/grub/grub.conf file.
Initial Configuration
30
31
Initial Configuration
32
3
Configuring System Settings
The main topics in this chapter include:
z z z z z
Configuring Basic System Settings on page 33 Configure Facility Alarms on page 36 Configuring and Displaying the System Operational Mode on page 37 Configuring an NTP Server on page 37 Configuring a DNS Server on page 38
Change and display device and domain name Change the network and subnet mask addresses Change system information Change time zones Change external access ability
NOTE: To access the device settings using EMS, expand Configuration in the Navigation Tree and open Wizard. In the Configuration Wizard window, click Open next to Device Configuration. The following sections describe how to access the device settings using the CLI.
33
The following is an example of this command: CBS# configure system-internal-network 2.2.0.0 255.255.0.0 NOTE: The configuration of system-internal-network is restricted from Class D or E internal networks. An internal network configured as Class D or E will cause boot problems with the modules in the X-Series Platform. If the configured network is not unique in the system, an error message will display.
34
This command displays both configured and operational system-internal-network (IP and mask). Configured System Internal Network Configured System Internal Netmask Operational System Internal Network Operational System Internal Netmask (1 row) : : : : 2.2.0.0 255.255.0.0 2.2.0.0 255.255.0.0
The following example sets the system calendar to 1:32 p.m. on December 23, 2010: calendar 13:32:00 23 dec 2010 NOTE: This command will not run when the system is configured with an NTP server.
To access the Greenlight Element Manager, use a secure connection (https://) to enter the system IP address or name in a Web browser. https://<ip_address>
Table 7.
Facility Alarms:
Upper/Lower Threshold Default Values Minor Major Critical
Parameter
CPU cycles, percent of capacity CPU core usage, percent of capacity /root partition disk usage, percent of capacity /boot partition disk usage, percent of capacity /mgmt partition disk usage, percentage of capacity /cbconfig partition disk usage, percent of capacity /tftboot partition disk usage, percent of capacity /var partition disk usage, percent of capacity APM free memory page count multiplier
90% / 0% 99% / 0% 90% / 0% 99% / 0% 80% / 0% 97% / 0% 80% / 0% 97% / 0% 80% / 0% 97% / 0% 80% / 0% 97% / 0% 80% / 0% 97% / 0% 80% / 0% 97% / 0% N/A / 2 N/A
There are additional facility alarms that are not user configurable, but provide output in the message logs. For information about these alarms and how to view the complete list, refer to the show alarms command in the XOS Command Reference Guide.
To display the current operational mode, use the following command: CBS# show operating-mode Chassis Type Configured Operating Mode Operational Mode Configured NPM Mode Operational NPM Mode : : : : : X80 dual-np dual-np series-6 series-6
37
To configure a DNS server address on the X-Series Platform, use the following command: configure dns server <server-address> Where server-address is the IP address of the DNS server. For example: CBS# configure dns server 172.16.31.101 To configure a DNS server address for a VAP group, use the following command: configure dns server <server-address> vap-group <vap-group-name> Where server-address is the IP address of the DNS server, and vap-group-name is the name of the VAP group associated with the server address. The following is an example of this command: CBS# configure dns server 192.168.30.81 vap-group fw To configure a DNS server search name for a VAP group, use the following command: configure dns search-name <name> vap-group <vap-group-name> Where name is the search-name for the specified VAP group, and vap-group-name is the name of the VAP group associated with the server address. The following is an example of this command: CBS# configure dns search-name mycompany.com vap-group fw To display the current DNS server configured on the X-Series Platform, use the following command: show dns-server DNS Server Address 192.168.30.81 192.168.30.81 VAP Group fw
To display the a DNS server search-name assigned to a VAP group, use the following command: show dns-search-name DNS Search Name mycompany.com VAP Group
38
4
Configuring Administration Settings
This chapter contains the following major administration setup topics:
z z z z
Managing User Accounts on page 39 Changing the CPM Root Password and Expiration Interval on page 41 Changing the Web Server SSL Certificate on page 43 Enabling SSH Access to VAPs on page 44
The following sections describe how to perform these tasks using the CLI. To manage user accounts using the Element Management System (EMS), select Administration from the menu bar in the main window then select User Admin. From the Administration menu, you can also change your password, view system users, and view users logged in from the web.
39
5.
Define the user EMS access level, using the following command: CBS# configure username <name> gui-level <level> Where level is the access level assigned to the user. The predefined levels restrict the user to view and configure specific windows within EMS in the table below.
The administrator level can view and configure all windows. Administration tasks include managing user accounts, upgrading software, and configuring system parameters. Configuration tasks include configuring the system, module, VAP groups, interfaces and protocols. Flow Provisioning tasks include managing rate limiters and IP flow rules. The following is an example of how to create an account named rudolph: CBS# configure username rudolph privilege 15 gui-level administrator Password : Retype Password: To delete a user account from the CLI: CBS# configure no username <name> To change a users password, use the following command, and enter the new password. CBS# configure reset-password <username> NOTE: You can use the enable level command to change your user access level for this session. This command may require a password for higher levels. The no parameter restores the default privilege level. To create, modify, or delete a user account from EMS, go to the Administration menu and select User Admin. Also use EMS to specify how long web users can remain logged in. If an individual web user does not request a new page within the specified number of minutes, the user session is cancelled and the user must log in again. This setting applies to all users who login to the X-Series Platform via HTTP. To specify the timeout value for all user web sessions, go to the Administration menu and select Web Session Timeout. The default value is 20 minutes.
40
41
NOTE: To use the backspace function in GRUB, enter CTRL-h. a. b. c. d. At the GRUB menu, type p on the keyboard then enter the password, x40rocks. At the GRUB prompt, type e to edit. Change the line number by pressing the down arrow until you reach the grub line starting with kernel. Edit the line to add single for single user mode. For example: grub edit> kernel /vmlinuz-x.x.xx-x ro root=/dev/hda7 console=ttyS0,9600n8 single e. f. 4. Type b to boot the CPM in single user mode. At the root prompt, you can use the passwd <password> command to change the password, or refer to Changing Default Usernames and Passwords on page 30 to change the GRUB password.
Shutdown and reboot the X-Series Platform, using the following command: [root@xxxx admin]# shutdown -r now
When the X-Series Platform reboots, use the vap-group-password command if you desire to propagate the new CPM root password to one or more of the VAPs.
42
Overview
The XOS web server resides on Tomcat, which is an open-source implementation of Java Servlet and JavaServer Pages technologies. The web server provides a Secure Socket Layer (SSL) certificate that users must accept to access the XOS web server. If you choose to purchase a certificate, you can use a public CA such as VeriSign (at www.verisign.com), Thawte (at www.thawte.com), Baltimore (at www.baltimore.com), or various other public CAs. To control the certification process, you can become your own CA, which requires that you install certificate server software and issue your own certificates. When you submit a request for a server certificate from a CA, you can use the CAs web site to generate part of the certificate, such as the identification information, the public key, and the private key. You then submit the identification information and the public key to the CA for signing. If you generate the certificate request through a web browser, you submit a .PEM or .DER file that contains the encoded PKCS10 information, which is your identification information and the public key. Once you generate the certificate request, submit the request to the CA for signing. When the certificate returns, you can download it out of the directory the CA specified and copy it into a text editor. The signed certificate contains your identification information, your public key, and the CAs signature. This part of the certificate is still in .PEM or .DER format, but it is now encoded X.509 information. If you generated your certificate request in a browser, you can export a PKCS12 file from your browser, which includes your private key and your certificate. You export the file as a password protected PKCS12 file with a .p12 file extension (or a .pfx file extension if you export it using Internet Explorer). You can then import this file into the CA server. The procedure for getting your certificate signed depends on the CA you use and whether your organization generates and signs its own certificates. If you chose to use a public CA, go to the CAs web site to get a signed certificate. You can submit the certificate that you generated to your CA over the Internet. They will then contact you with information on how to get your signed certificate. For instructions on generating a new certificate and key, refer to the following web site: http://jakarta.apache.org/tomcat/tomcat-3.2-doc/tomcat-ssl-howto.html#s6
43
In this example, the keystore is file /var/tomcat/conf/keystore. The keystore password is changeit. Once you have the certificate and key, copy the new keystore file to a safe location on the X-Series Platform then modify server.xml file to point to the new keystore file. The following example shows the default location on the X-Series Platform: <Parameter name="keystore" value="/usr/os/web/conf/keystore" /> If you used a password other than changeit, edit this line in server.xml: <Parameter name="keypass" value="changeit"/>
2.
44
5
Configuring VAP Groups
A Virtual Application Processor (VAP) is the application operating environment running on an APM. A VAP consists of the OS, the system software, and an application installed and running on the APM. VAP groups consist of one or more APMs running the same application. XOS provides the ability to perform load balancing and high availability within a VAP group. An X-Series Platform supports a maximum of 10 VAP groups. This chapter contains the following main topics:
z z z z z z z
Overview of VAP Groups in XOS on page 45 Overview of IPv6 Traffic on page 51 Configuring a VAP Group on page 52 VAP Group Example on page 55 Virtual Environment VAP Groups on page 58 Displaying VAP Group Parameters on page 59 Displaying VAP Group Mapping on page 60
45
When decrementing the vap-count the max-load-count must be adjusted accordingly downward.
Master VAP
When members of a VAP group load onto APMs, the first VAP to become available is designated the Master VAP. The main function of the Master VAP is to handle routing protocols. For example, the OSPF daemon only runs on the Master VAP to prevent multiple routing tables should the daemon run on all VAPs. The Master VAP is also used for various protocol responses, such as ARP and Spanning Tree. For example, all VAPs respond to an ARP request, but only the Master VAPs response is sent out by the X-Series Platform. Should the Master VAP fail, another VAP in the group is elected Master.
46
Standby VAP
The standby VAP is not part of a VAP group. This VAP runs on an APM, checking the hardware integrity. If an APM running a VAP in a group fails, the standby VAP is dynamically allocated to the VAP group. The standby VAP is preempted and rebooted to run the image of the failed VAP. As an alternative to configuring a standby VAP, preemption priority can be assigned to each VAP group. This allows you to configure an application in a VAP group as a higher or lower priority compared to another application. Should a higher priority VAP group have a failure, it takes a VAP from the lower priority group. This configuration works well when you have a mission critical application and a non-mission critical application running in the same X-Series Platform.
IPv6 Traffic
Use the enable-ipv6 command from the vap-group context to enable IPv6 support on the VAP group. A non-ip-flow-rule is automatically configured and activated, passing IPv6 traffic directly to the Master VAP for processing by the application. After IPv6 is enabled on the VAP group, the user configures circuits, interfaces, and static routes for handling IPv6 traffic. For more information about IPv6 traffic, see Overview of IPv6 Traffic on page 51.
Load Balancing
With load balancing, the NPM distributes the traffic across multiple VAPs, maximizing the overall performance of the X-Series Platform. If a VAP fails, the NPM reclassifies the traffic flow and load balances it among the remaining VAPs. In addition, use the load-balance-vap-list parameter to define the APMs that are allowed to receive new flows. To gracefully shut down a VAP, remove its entry from this list. Existing flows will continue to be handled by the VAP, but once these flows cease the VAP will have no traffic.
Flow Rules
A flow rule determines how a new traffic flow is processed when it arrives on a logical interface. A traffic flow is identified by a set of parameters in the flow rule, which is configured by the user. There are flow rules for IP and non-IP traffic. Refer to Configuring Flow Provisioning on page 95 for information.
47
Two hard drives are required in an APM-8600, APM-8650, and APM-9600 to use the RAID feature. Use the show module status disk command to check for the presence and size of the disk drives. Both disks must be of the same type and have identical partition sizes. Use the cat /proc/partitions (from root) command to check them.
RAID Settings
Configure RAID settings using the raid parameter of the configure vap-group command. There are three possible RAID settings:
z
configure vap-group <vapgroupname> no raid This command turns raid operation off. The drives function independently. This is the default setting. configure vap-group <vapgroupname> raid 0 This command configures the system to write to whichever drive of the pair is not currently busy. This setting increases efficiency and speed but does not duplicate data. Also, both drives are required in order to access the full content of the stored data.
configure vap-group <vapgroupname> raid 1 This command configures the system to write the same data to both disks, creating a complete backup in case of one drives failure.
See RAID-Related Hard Drive Configuration and Repair on page 241 for more information on RAID configuration.
Table 9.
Name xslinux_v3 xslinux_v5
xslinux_v5_64 xsve
You can create different VAP groups running different kernels in one X-Series Platform. Refer to the XOS V9.5 Release Notes or specific application installation guides for additional information.
48
Application Monitoring
Application monitoring is enabled by default, and directs XOS to poll application health on each VAP in a group every five seconds to verify that every application is able to process traffic. If the application is not active on a VAP in the group, the system notifies the NPM to stop new flows (load balancing) to that VAP. The NPM performs this process dynamically. When a VAP is booted, the NPM will wait until the application is fully operational before sending traffic to the VAP. When Application Monitor is disabled, the NPM sends traffic to the VAP immediately upon the APM being Up, regardless of the application state. If the application goes down, the NPM will continue to send traffic as long as the APM remains up, and there is no change in load balancing. With the master-failover-trigger application command configured on the VAP group, XOS will re-elect a new master VAP any time application monitoring detects an application failure on the master VAP. NOTE: Application monitoring cannot detect process hangs. If a process is not functioning but the application is running, the XOS health system continues to report that the application is running.
49
Command: CBS# configure circuit mgmt CBS(conf-cct)# 2. Assign a device name to the circuit. For clarity, the device name should be the same as, or based on, the circuit name.
Command: CBS(conf-cct)# device-name mgmt CBS(conf-cct)# 3. Associate the VAP group with a circuit. Some applications (such as IBM ISS) require that you designate this circuit as the management-circuit. Refer to the application documentation for more information.
Command: CBS(conf-cct)# vap-group bluefw CBS(conf-cct-vapgroup)# management-circuit CBS(conf-cct-vapgroup)# 4. Assign an IP address for VAP group management. Use increment-per-vap to assign a unique IP address per VAP member, allowing individual management connections. When configuring the management IP addresses it is recommended to leave some unused IP addresses so that additional APMs and VAPs can be added as the system grows.
50
Load Balancing
IPv6 traffic is not load-balanced across all VAPs in the group. However, IPv6 traffic can be load-balanced across multiple cores on a the master VAP, reducing resource utilization and increasing throughput. Use the multi-proc-processing parameter under the core-assignment context to modify the default IPv6 non-ip flow rule (ipv6_rule). This parameter will configure load balancing across multiple processors and multiple cores on the master VAP. For core-assignment configuration steps, refer to Configuring a VAP Group on page 52. For a list and explanation of each of the core-assignment parameters, refer to Chapter 6 of the Command Reference Guide.
Enable IPv6 on the VAP group before assigning an IPv6 address to the circuit. If IPv6 is not enabled, a warning will be displayed when the IPv6 address is assigned to the circuit. IPv6 addressing may be used on VLANs and virtual IP addresses. Increment-per-vap cannot be configured for an IPv6 address. IPv6 addressing is not supported on the management network. You must specify an IP address for a circuit as an IPv4 address before assigning an IPv6 address or alias address on that circuit. If you specify the circuit address as IPv6, all alias addresses for the circuit must be IPv6 addresses. The minimum MTU size for IPv6 enabled circuits is 1280 and the maximum is 9000. An error message appears when enabling IPv6 on a circuit with an MTU of less than 1280, or when setting the MTU to less than 1280 on an IPv6-enabled circuit. The Crossbeam default MTU value is 1500. IPv4 / IPv6 mixed mode addresses cannot be configured using the CLI. For example, configuring the following address on a circuit will result in an error. FC00:0:0:0:0:FFFF:204.9.54.119
51
The process uses a dual stack router or a firewall on either side of an IPv4 network. These serve as endpoints for the tunnel. IPv6 traffic is encapsulated within IPv4 traffic, and crosses the network as native IPv4 traffic. When the encapsulated packets reach the destination router or firewall, the IPv6 packets are de-encapsulated and routed appropriately. For additional tunnel information, refer to IPv6 Tunneling on page 217
52
4.
Assign APMs to support the VAP group. This command specifies the list of APMs to be loaded. All VAP members should be running on identical APMs. Use show module status from the CLI to verify the configuration of each APM. Command: CBS(config-vap-grp)# ap-list ap3 ap4 ap5 CBS(config-vap-grp)# NOTE: Use the show chassis command to determine the module names and types associated with each APM. Use the ap-list parameter to associate like module types (for example, just APM-8650s) into a VAP group of identical module types.
5.
Define the VAP group load-balance-vap-list. The load-balance-vap-list is a list of VAP indexes that the NPM uses to load balance new flows. For example, if you have a VAP group with 3 VAPs (bluefw_1, bluefw_2, and bluefw_3), the NPM load-balances over all three VAPs by default. Use the load-balance-vap-list to force the NPM to load balance over specific VAPs as follows. Command: CBS(config-vap-grp)# load-balance-vap-list 1 2 3 CBS(config-vap-grp)# The NPM ignores indexes included in the command that do not exist. For example, the NPM will ignore indexes 4 5 6 7 8 9 in the command for a VAP group that only has 3 indexes.
6.
Enable IPv6 address support if required. If you do not require IPv6 support, skip to Step 8. CBS(config-vap-grp)# enable-ipv6 Enabling IPv6 automatically configures the following non-ip-flow-rule: non-ip-flow-rule ipv6_rule encapsulation ethernet type 34525 action pass-to-master activate
7.
Use the core-assignment parameter to load-balance IPv6 traffic across multiple processors and multiple cores on the master VAP. CBS(config-vap-grp)# non-ip-flow-rule ipv6_rule core-assignment multi-proc-processing
8.
Configure the default flow-rule for the VAP group and return to the VAP group context. There are four steps to configure the load balancing flow rule.
Create the load balancing flow rule for the bluefw VAP group. Set flow rule action to load-balance traffic to all available VAP members. Set the activate flag to enable the action. Return to the main CLI context to prepare for the next step.
CBS(config-vap-grp)# ip-flow-rule bluefw_lb CBS(ip-flow-rule)# action load-balance CBS(ip-flow-rule)# activate CBS(ip-flow-rule)# exit CBS(config-vap-grp)# 9. Define the VAP group load-priority level. This command determines which VAP group is given priority when assigning VAPs to physical APMs. Valid values are 0 to 255, with 0 being the default value. A zero sets the lowest priority level. Command: CBS(config-vap-grp)# load-priority 5 CBS(config-vap-grp)#
53
10. Define the VAP group preemption-priority level. The application running on one VAP group is assigned a higher priority than an application on another VAP group (for example, a firewall assigned a higher priority than an IPS). If the higher priority VAP group requires additional APMs to load its VAPs, this value determines from which group APMs can be taken. If the preemption priority for this group is higher than the load priority for a currently running VAP, that VAP is shutdown and an APM is loaded to the higher priority VAP group instead. Additionally, should a higher priority VAP group have a failure, it takes a VAP from a lower priority group. This configuration works well when you have a mission critical application and a non-mission critical application running in the same X-Series Platform. Valid values are 0 to 255, with 0 being the default value. A zero sets the lowest priority level. Command: CBS(config-vap-grp)# preemption-priority 5 CBS(config-vap-grp)# 11. Define the delay period this VAP group waits before load balancing. Assign the <interval> (number of seconds) a VAP group waits before beginning load balancing. Valid values are from 1 to 3600 seconds, with a default value of no delay. Command: CBS(config-vap-grp)# delay-flow 10 CBS(config-vap-grp)# 12. Enable or disable the Reverse Path (RP) filter. Disabling rp-filter allows a management server external to the network to enter through the load balancing filter and access the correct VAP. This anti-spoofing mechanism is resident in the Linux kernel. Disable the rp-filter using the no command. Command: CBS(config-vap-grp)# no rp-filter CBS(config-vap-grp)# 13. Enable or disable logging of martians (packets with a source IP address but no known route). Packets with source addresses not routable by the system are referred to as martians (packets from Mars) on the grounds that they are of no evident terrestrial (that is, normal) source. Martian packets can occur from network equipment malfunction, mis-configuration of a host, or simple coexistence of two logical networks on a single physical layer. For example, if the IP networks 192.168.35.0/24 and 10.1.2.0/24 operate on the same Ethernet segment, packets from 10.1.2.5 are martians to system 192.168.35.8, and vice versa. When enabled, martians are logged to syslog. Command: CBS(config-vap-grp)# log-martians CBS(config-vap-grp)# 14. Configure vg-reset-wait-time. This command sets the wait time (in seconds) before resetting a VAP when no connectivity to the VAP has been detected. In the case of an application that is busy processing and fails to send heartbeats for a period of time, this command will extend the wait time before the VAP resets. Command: CBS(config-vap-grp)# vg-reset-wait-time 15 CBS(config-vap-grp)# 15. Configure the reload-timeout value. By default, the system waits 300 seconds for a VAP group to reload. If the reload does not occur, the system resets the slot. For some system configurations, you may need to have the system wait a specific number of seconds for the VAP group to reload. For example, a firewall application may only require the system to wait 120 seconds before reloading. Valid values are 60 to 18000 seconds. Command CBS(config-vap-grp)# reload-timeout 120 CBS(config-vap-grp)#
Configuring VAP Groups 54
Figure 3.
Computer
15.0.0.193
Internet
The following is an example of the commands in a configuration based on this figure: CBS# configure vap-group redfw Are you sure you want to create a new vap-group with OS version xslinux_v3? <Y or N> [Y]: Y Creating vap-group Firewall. May take several minutes.................... %WARNING: X-Series xslinux_v3 is not supported on APM9600 or above CBS(config-vap-grp)# max-load-count 1 CBS(config-vap-grp)# load-priority 2 CBS(config-vap-grp)# ap-list ap1 CBS(config-vap-grp)# ip-flow-rule Firewall_lb CBS(ip-flow-rule)# action load-balance CBS(ip-flow-rule)# activate CBS(ip-flow-rule)# exit CBS(config-vap-grp)# jumbo-frame CBS(config-vap-grp)# exit
XOS Configuration Guide 55
CBS# configure vap-group bluefw Are you sure you want to create a new vap-group with OS version xslinux_v3? <Y or N> [Y]: Y Creating vap-group Firewall. May take several minutes.................... %WARNING: X-Series xslinux_v3 is not supported on APM9600 or above CBS(config-vap-grp)# max-load-count 1 CBS(config-vap-grp)# load-priority 5 CBS(config-vap-grp)# preemption-priority 2 CBS(config-vap-grp)# ap-list ap2 CBS(config-vap-grp)# ip-flow-rule Firewall_lb CBS(ip-flow-rule)# action load-balance CBS(ip-flow-rule)# activate CBS(ip-flow-rule)# exit CBS(config-vap-grp)# exit CBS# configure circuit purple CBS(conf-cct)# vap-group redfw CBS(conf-cct-vapgroup)# ip 10.133.2.193 255.255.255.0 CBS(conf-cct-vapgroup)# end CBS# configure circuit red CBS(conf-cct)# vap-group bluefw CBS(conf-cct-vapgroup)# ip 20.0.0.193 255.0.0.0 CBS(conf-cct-vapgroup)# end CBS# configure circuit yellow CBS(conf-cct)# vap-group redfw CBS(conf-cct-vapgroup)# ip 15.0.0.183 255.0.0.0 CBS(conf-cct-vapgroup)# end CBS# configure circuit blue CBS(conf-cct)# vap-group bluefw CBS(conf-cct-vapgroup)# ip 44.0.0.195 255.0.0.0 CBS# configure interface gigabitethernet CBS(conf-intf-gig)# logical log11 CBS(intf-gig-logical)# circuit purple CBS(intf-gig-log-cct)# end CBS# configure interface gigabitethernet CBS(conf-intf-gig)# logical log12 CBS(intf-gig-logical)# circuit red CBS(intf-gig-log-cct)# end CBS# configure interface gigabitethernet CBS(conf-intf-gig)# logical log13 CBS(intf-gig-logical)# circuit yellow CBS(intf-gig-log-cct)# end CBS# configure interface gigabitethernet CBS(conf-intf-gig)# logical log14 CBS(intf-gig-logical)# circuit blue CBS(intf-gig-log-cct)# end CBS# 1/1
1/2
1/3
1/4
You can use the show running-config vap-group <name> command to view the VAP group configuration to verify your steps. Similarly, use the show running-config command with circuit <name>, vrrp-failover-group <name>, or group-interface <name> parameters to view specific running configurations for those parameters.
56
The following is an example of the commands to create an IPv6 configuration based on Figure 3 on page 55: CBS# configure vap-group redfw xslinux_v5 Are you sure you want to create a new vap-group with OS version xslinux_v5? <Y or N> [Y]: CBS(config-vap-grp)# max-load-count 1 CBS(config-vap-grp)# load-priority 2 CBS(config-vap-grp)# ap-list ap1 CBS(config-vap-grp)# enable-ipv6 CBS(enable-ipv6)# end CBS# configure vap-group bluefw xslinux_v5 Are you sure you want to create a new vap-group with OS version xslinux_v5? <Y or N> [Y]: CBS(config-vap-grp)# max-load-count 1 CBS(config-vap-grp)# load-priority 5 CBS(config-vap-grp)# preemption-priority 2 CBS(config-vap-grp)# ap-list ap2 CBS(config-vap-grp)# enable-ipv6 CBS(enable-ipv6)# end CBS# configure circuit purple CBS(conf-cct)# vap-group redfw CBS(conf-cct-vapgroup)# ip 2002:C:4:0:0:0:0:B3/64 %WARNING: IPv6 primary address was configured. No allowed for this circuit. CBS(conf-cct-vapgroup)# end CBS# configure circuit red CBS(conf-cct)# vap-group bluefw CBS(conf-cct-vapgroup)# ip 2002:1:F:0:0:0:0:F5/32 %WARNING: IPv6 primary address was configured. No allowed for this circuit. CBS(conf-cct-vapgroup)# end CBS# configure circuit yellow CBS(conf-cct)# vap-group redfw CBS(conf-cct-vapgroup)# ip 2002:C:4:0:0:0:0:B8/64 %WARNING: IPv6 primary address was configured. No allowed for this circuit. CBS(conf-cct-vapgroup)# end CBS# configure circuit blue CBS(conf-cct)# vap-group bluefw CBS(conf-cct-vapgroup)# ip 2002:1:F:0:0:0:0:11/32 %WARNING: IPv6 primary address was configured. No allowed for this circuit. CBS# configure interface gigabitethernet CBS(conf-intf-gig)# logical log11 CBS(intf-gig-logical)# circuit purple CBS(intf-gig-log-cct)# end CBS# configure interface gigabitethernet CBS(conf-intf-gig)# logical log12 CBS(intf-gig-logical)# circuit red CBS(intf-gig-log-cct)# end CBS# configure interface gigabitethernet CBS(conf-intf-gig)# logical log13 CBS(intf-gig-logical)# circuit yellow CBS(intf-gig-log-cct)# end CBS# configure interface gigabitethernet CBS(conf-intf-gig)# logical log14 CBS(intf-gig-logical)# circuit blue CBS(intf-gig-log-cct)# end CBS# 1/1
1/2
1/3
1/4
57
Additional Commands
The following commands are used when configuring virtual environment VAP groups. These commands fall under the configure vap-group context. For additional information on these and other virtual environment-specific commands, refer to the XOS Command Reference Guide or to the individual application installation and configuration guide.
Flow Proxy
In a virtualized environment, the flow-proxy parameter changes the flow processing algorithm to improve performance. IMPORTANT: This parameter is disabled by default, but is required for any VAP group that uses the XSVE VAP operating system. CBS# configure vap-group vbluefw CBS(config-vap-grp)# flow-proxy CBS(config-vap-grp)# To disable the flow-proxy command after it has been enabled, use the no flow-proxy parameter.
Fail to Host
In a case where the virtual application (guest) fails, fail-to-host reroutes traffic through the host, allowing packets to be forwarded by the VAP. This parameter is disabled by default and should only be enabled when required by an application (guest). Refer to your application information for specific requirements. CBS# configure vap-group vbluefw CBS(config-vap-grp)# fail-to-host CBS(config-vap-grp)# To disable the fail-to-host command after it has been enabled, use the no parameter.
58
59
Backup Mode Reload Timeout (seconds) RP Filter (true/false) Log Martians (true/false) DHCP Relay Server List RAID Jumbo Frame (true/false) Scatter Gather (true/false) Master HoldDown Timer (in seconds) Master Failover Trigger Application Monitoring (true/false) IPv6 Enabled (true/false) IPv6 IP Forwarding (true/false) Fail To Host (true/false) Flow Proxy (true/false) Reset Wait Time (seconds) (1 row)
: : : : : : : : : : : : : : : :
60
6
Configuring Interfaces
The physical data interfaces are located on the Network Processor Modules (NPMs). An XOS system can be configured with only one NPM type; however, the NPM type must also be defined in the software using the configure operating-mode command. This chapter includes the following major topics:
z z z z z z
Data Interface Overview on page 61 Configuring Interfaces on the NPM on page 66 Packet Mirroring on the NPM Interfaces on page 73 Configuring Chassis Resource Protection on page 78 Configuring Redundant Interfaces on page 83 Configuring a Multi-Link Group Interface on page 85
Figure 4.
Data Interfaces
VAP Group
VND1
Logical
Circuit
VND1
VND1
NPM
APM
APM
APM
61
Physical Interfaces
The physical data interfaces on the NPMs are identified by type (gigabitethernet or 10gigabitethernet), chassis slot number of the NPM, and physical port number. For example, the gigabitethernet interface on the fourth port of the NPM in slot 1 would be designated as gigabitethernet 1/4. Depending on the NPM model, the physical interface can be a copper or fiber interface and support speeds to 10 Gb.
Logical Interfaces
Physical interfaces are mapped to logical interfaces. A physical interface can be mapped to several logical interfaces. The application has no knowledge of the physical interface being used. When a physical interface fails, the logical interface and any circuits configured to that logical interface can be moved to another physical interface.
Interface Internal
Serial connections between VAP groups, and connections between individual VAPs for synchronization are configured using the interface-internal command.
Circuits
The circuit provides the path packets follow from the physical interfaces on the NPMs to the VAP groups. These paths are dynamically updated each time a VAP boots onto an APM. When a circuit connects a physical interface to a VAP group, the state of the circuit depends on the physical link state. The circuit goes down when the physical interface fails or is unavailable. Circuits can also provide internal communication channels between VAPs in a VAP group (synchronization traffic), serial connections for packets to travel between different applications on separate VAP groups, and parallel connections to multiple VAP groups sending traffic to more than one application simultaneously. Circuits between VAPs (sync circuits) or between VAP groups (serial or parallel circuits) are configured on an interface-internal. When Dual-box High Availability is configured, an external interface is needed to provide connectivity to the sync circuit between VAP groups on separate systems. In this case, the sync circuit is configured using the link-state-resistant parameter. This parameter allows the circuit to continue passing internal traffic between the VAP members, even when the communication between systems stops due to a physical interface failure.
Multiple addresses associated with a circuit on a VAP is often referred to as aliasing or multi-netting. The first IP address configured on a circuit is the primary IP; the remaining addresses are aliases. These IP addresses can either be the same across VAPs, or different. This configuration is identical for all VAPs within a VAP group. It is possible to have all VAPs use the same primary IP address. All VAPs within the same group can be assigned the same IP address associated with the circuit.
Create a circuit by specifying a circuit name for the circuit. Then map the circuit to a VAP group and assign an IP address. Optionally, you can place the circuit into a VLAN by specifying a default outbound VLAN tag.
Configuring Interfaces
62
VLANs
A logical interface can be configured to pass traffic with a specific VLAN tag, a range of VLAN tags, or all VLAN and non-VLAN traffic. The ingress-vlan-tag parameter for the configure interface...logical or configure group-interface...logical command associates a VLAN tag or range of tags to circuits. NOTE: Logical interfaces with overlapping VLAN ID ranges cannot coexist on the same physical interface. Additionally, when using interface redundancy, the backup interface cannot be assigned a VLAN ID that is assigned to the master interface. The logical-all parameter for the configure interface command configures a logical interface to pass all VLAN and non-VLAN traffic. Each physical interface can have only one logical interface configured with the logical-all parameter. In a VLAN configuration using an 802.1q trunk, a single physical interface may handle several subnets. The X-Series Platform can be configured to handle a VLAN trunk by assigning many logical interfaces to a single physical interface. Each logical interface is associated with a VLAN tag or range of VLAN tags. On ingress, a tagged packet is passed only to the logical interface that allows that VLAN tag. The logical interface then passes the packet to its configured circuit, which sends the packet to a VAPs VND interface. The VND interface strips the VLAN tag and passes the normal IP packet to the VAPs IP stack. By using the default-egress-vlan-tag parameter with the configure circuit command, egress packets can be tagged by associating a VLAN tag with the circuit. When a packet egresses through a particular VND, that VND will assign a tag to that packet based on the circuits associated VLAN. The tagged packet is passed to the circuit, then to the logical interface which sends the tagged packet out the corresponding physical interface. Use the hide-vlan-header optional argument under the default-egress-vlan-tag parameter to remove the VLAN tag from the header. This is used with any application where the VLAN tag must be removed for proper operation. Use the replace-vlan-tag <id> parameter with the configure circuit <name> vap-group command to replace an existing VLAN tag on the circuit traffic with another VLAN tag. This is useful to map traffic at an incoming port with a VLAN ID of x to a VLAN ID of y, especially if connected to an external switch. For security, the X-Series Platform drops any incoming packet tagged with a VLAN tag that is not associated with any of the configured logical interfaces.
XOS Configuration Guide 63
In the following example, a single physical interface has 2 logical interfaces, and each logical interface has a single circuit. The physical interface is connected to a VLAN trunk that carries VLANs 400 and 500. interface gigabitethernet 1/9 logical vlan400 ingress-vlan-tag 400 circuit vlan_400 logical vlan500 ingress-vlan-tag 500 circuit vlan_500 In this example, when a tagged packet comes into the physical interface, logical interfaces are checked for associated VLAN tags. A packet tagged with VLAN 400 is passed to circuit vlan_400. A packet tagged with VLAN 500 is passed to circuit vlan_500.
Configuring Interfaces
64
Domains
A domain is used to differentiate traffic that uses overlapping IP addresses. For example, gigabitethernet 1/2 and gigabitethernet 1/3 both receive traffic from an IP address of 10.10.101.10; however, the sources are from different LANs. This can occur in an ISP configuration. To differentiate traffic, assign Domain 1 to the gigabitethernet 1/2 circuit and Domain 2 to the gigabitethernet 1/3 circuit. A domain ID can also be used to differentiate multicast traffic, where one incoming packet goes out on multiple interfaces. For example, the X-Series Platform configured with PIM-SM passes ICMP multicast traffic. This traffic may be sent out on different interfaces for clients that have joined a multicast group. To differentiate the traffic, you assign a different domain ID for each circuit carrying the multicast traffic. In this case, you would also need to create an IP flow rule that specifies the domain ID or range of domains.
Group Interfaces
The X-Series Platform supports grouping multiple physical ports into a multi-link group interface using LACP (Link Aggregation Control Protocol, IEEE 802.3ad). Configure the group interface as you would a physical interface, by assigning the group to logical interfaces and assigning the logical interfaces to circuits. To create a multi-link group, you must first create a non-VLAN circuit to use for that group. The X-Series Platform supports assigning a multi-link group interface to multiple VAP groups, which allows you to tap traffic from the group interface. There is a limit of 8 ports to a group interface. Circuits used in one group-interface cannot be used in another group-interface. For scalability, you can add a multi-link group interface to a bridge or transparent interface. This allows greater throughput of traffic. However, the multi-link group cannot have any configured logical interfaces. Refer to Configuring Bridge Mode on page 115 for more information on bridge and transparent modes.
Redundant Interfaces
A physical interface can be configured as a backup for another physical interface in case of failure. By specifying a backup physical interface, logical interfaces assigned to the master physical interface are also backed up. Switching to the backup interface is transparent to the application. Failover occurs very quickly since the physical interface state is monitored by the X-Series Platform controller daemon. NOTE: The failover succeeds only if the backup interface is in the UP state. When failover occurs, the backup port always assumes the master ports MAC address, and sends a gratuitous ARP to update Layer 2 switch tables. NOTE: A Master interface cannot be part of a mode multi-link group-interface. The backup interface can be configured as a Standby or Active interface. If configured as active and the master interface fails, the backup interface assumes the failed interfaces traffic in addition to its own. This is known as an active-active configuration. A backup interface in an active-active configuration cannot be configured to pass the same type of traffic as the master interface. This means that both the master and backup interfaces cannot be configured to pass the same VLAN traffic, or pass untagged traffic. An example of a valid active-active configuration would be to have an interface passing VLANs tagged 100 be a backup to an interface passing VLANS tagged 300.
3. 4. 5.
Overlapping VLANS are checked for ALL involved logicals. Masters can be part of a group-interface. Validation is done in all paths including configuring redundancy-interfaces, set/unset standby-only, add/remove VLANs.
VND Tap
A VND tap enables an application, such as IDS, to view traffic on the circuit specified. Configuring a circuit between two VAP groups allows serial communication between them, as described in Configuring Circuits on page 68. To configure a VND tap, add a third VAP group to the circuit and configure the VAP group for promiscuous mode. When a tap is configured while there are existing traffic flows, the tap will not see the established flows. If it is necessary to view established flows, use the clear flow-active command. IMPORTANT: Using the clear flow-active command halts all traffic to the system for approximately 60 to 90 seconds. Do not use this command unless necessary. A flow rule is required to see any traffic on a tap interface. Adding a tap to a logical line requires that the VAP group be added to the parent circuit first. There are four steps to create a flow-rule for the tap VAP group.
z z z z
Create the default flow rule for the tap VAP group. Set flow rule action to load-balance tap traffic to all available VAP members. Set the activate flag to enable the action. Return to the main CLI context to prepare for the next step. CBS(config-vap-grp)# ip-flow-rule tap_lb CBS(ip-flow-rule)# action load-balance CBS(ip-flow-rule)# activate CBS(ip-flow-rule)# end CBS#
Configuring Interfaces
66
Table 10.
Setting
auto-negotiate
duplex-mode
logical <name> Defines a logical interface. Enter a unique name to create a logical interface, or specify ingress-vlan-tag an existing logical name to change its settings. <low> [<high>] The ingress-vlan-tag passes VLAN traffic with a specific VLAN ID, as specified by [circuit <name>] <low>, or a range of VLAN IDs, as specified by <low> and <high>. Valid values are 0 to 4094. Optionally, the circuit parameter assigns an existing circuit to the logical interface. logical-all media-speed pause-frame standby-only Configures a logical interface to pass traffic regardless of VLAN tags. A physical interface can have only one logical interface configured with the logical-all. Configures media speed; only applicable to gigabitethernet ports configured for a copper connection. This setting overrides the auto-negotiation speed. Configures pause frame, also known as flow control. Only use if the interface is a backup in an interface redundancy configuration. The interface will not be used for active traffic unless the master interface fails.
You can disable and enable any interface with the [no] enable command. The following example is a simple gigabitethernet interface configuration. The NPM is in slot 1 and the physical interface is port 4. By default, the interface is enabled, auto-negotiation is enabled, duplex mode is full, and the interface is not in standby mode. CBS# configure interface gigabitethernet 1/4 Use the show command in the config-intf context to display the current configuration. For example: CBS# configure interface gigabitethernet 1/4 CBS(conf-intf-gig)# show Interface : gigabitethernet 1/4 Enable (true/false) : t Auto Negotiate Enabled (true/false) : t Media Speed (Mbits) : auto Duplex Mode : auto Pause Frame (true/false) : t Standby Only (true/false) : f To display a physical interfaces current operational status, use the show interface command.
Interface-Internal
An interface-internal is created to provide internal connectivity between VAPs (synchronization or sync circuits) or between VAP groups (serialization). An interface-internal can be segmented into logical lines in the same way physical interfaces are assigned logical lines, and handles VLAN traffic, non-VLAN traffic, or all traffic. The following example configures an interface-internal to pass all traffic. CBS# configure interface-internal serial CBS(conf-intf-internal)# logical-all log_ser CBS(conf-intf-internal-log-all)# circuit serialize CBS(conf-intf-int-log-all-cct)# end CBS#
67
Configuring Circuits
The circuit provides the path packets must take from the physical interfaces on the NPMs to the VAP groups. To configure circuits using EMS, open Configuration > Interfaces > Data Interfaces > Circuits. Use the New button to create a circuit or to map the circuit. Use the Help button for details. To create a circuit using the CLI, use the configure circuit <circuit-name> command, where circuit-name is the unique name given to the circuit. Use additional parameters to further define the circuit. To configure or re-configure an existing circuit, specify the circuits name, and use additional parameters to further define the circuit.
A circuit cannot be added to more than one logical interface. Enable IPv6 on the VAP group before you assign an IPv6 address to the circuit. If IPv6 is not enabled, a warning will be displayed when the IPv6 address is assigned to the circuit. IPv6 addressing may be used on VLANs and virtual IP addresses. Increment-per-vap cannot be configured for an IPv6 address. IPv6 addressing is not supported on the management network. If you specify the IP address for a circuit as an IPv4 address, alias addresses for that circuit can be any mixture of IPv4 and IPv6 addresses. If you specify the circuit address as IPv6, all alias addresses for the circuit must be IPv6 addresses. The minimum MTU size for IPv6 enabled circuits is 1280. An error message appears when enabling IPv6 on a circuit with an MTU of less than 1280, or when setting the MTU to less than 1280 on an IPv6-enabled circuit. The Crossbeam default MTU value is 1500. IPv4 / IPv6 mixed mode addresses cannot be configured using the CLI. For example, configuring the following address on a circuit will result in an error. FC00:0:0:0:0:FFFF:204.9.54.119
Circuit Parameter
Table 11 lists the parameters available for configuring circuits in the NPM Mode.
Table 11.
NPM Circuits
Parameter Definition (Optional) User-defined domain (default is 1). (Optional) Circuit ID to be used, advised to use range <1-1024>
Configuring Interfaces
68
Parameter device-name
Definition Configures device name, also known as interface name. The device-name of a circuit or interface cannot be lo, gre0, or sit0. Device names cannot begin with eth. If necessary, specify an Incoming Circuit Group (ICG) identifier for the circuit. The ICG is used by flow rules as an additional method to identify traffic from one or more specific circuits. Valid values are 2 to 255. When enabled, Proxy ARP allows the circuit to reply to all ARP requests with known IP addresses. Specifies an existing VAP group to assign to this circuit.
Table 12.
increment-per-vap <end-ip-addr>
Assigns an alias IP address as the primary IP address for the VAP group. The VAP group must have a previously defined IP address. For example, this command assigns an IP address to 3 members of a VAP group: CBS(conf-cct-vapgroup)# ip 20.2.2.102/24 increment-per-vap 20.2.2.104 CBS(conf-cct-vapgroup-ip)# alias 20.2.2.101/24 NOTE: If you specify the IP address for a circuit as an IPv4 address, alias addresses for that circuit can be any mixture of IPv4 and IPv6 addresses. If you specify the circuit address as IPv6, all alias addresses for the circuit must be IPv6 addresses The floating parameter assigns the alias IP address to the master VAP, allowing traffic, cluster management, and synchronization communication to go directly to the master VAP. If a new master VAP is elected, the address floats to the new master. NOTE: Only one floating address can be used on a circuit. This parameter cannot be used with increment-per-vap.
69
Definition (Optional) Define the egress VLAN tag, where id is an integer value ranging from 0-4094. By default, packets are sent without VLAN tags. NOTE: Some vendors do not tag VLAN 1 packets going over a VLAN trunk because they handle all non-tagged packets as VLAN 1. If the X-Series Platform is configured to look only for tagged packets, it will drop these untagged packets. To avoid this situation, configure two circuits on the same subnet, where one looks for VLAN 1 tagged packets and the other looks for non-tagged packets. [hide-vlan-header] - Optional argument under default-egress-vlan-tag. Removes the VLAN tag from the header. Used with any application where the VLAN tag must be removed for proper operation.
dhcp-relay-server-list <IP_address> <IP_address> dhcp-relay icmp-redirect ip-flow-rule-priority <value> ip-forwarding mac-addr <addr> [system-reserved]
Specify the IP addresses of the DHCP relay servers that the VAP group will use. See Note below. Enables the specified circuit to pass DHCP traffic to a relay server. See Note below. Enables ICMP Redirect Change the default IP flow rule priority. Valid values are 0 to 31. Default is 21. Use no to restore the default value. Enables IP forwarding on the circuit. System generated MAC addresses are selected from the range 00:03:D2:EX:XX:YY to 00:03:D2:FX:XX:YY. The MAC addresses in the system-reserved address pool have sequential values for X:XX, starting at 0:01. The value for YY is the system ID assigned to the X-Series Platform. Use the system-reserved parameter to specify a user-defined MAC address that is within the range of MAC addresses generated by the system. Using the existing format, change the X:XX values as required. The YY value must match the system ID, and is updated automatically when the system ID is changed. The MAC address should be changed only if there are external devices that expect a specific MAC address.
Maps a management circuit to a VAP group. Use no to delete the mapping. Specifies the MTU size for the circuit on that VAP group. The same circuit with a different VAP group can have a different MTU. Default is 1500. IPv6 circuits must have an MTU size equal to or greater than 1280.
promiscuous-mode [active]
Circuits configured in promiscuous mode receive copies of all the data packets on the logical interconnect; other circuits only receive packets destined to that VAP. Circuits with ip-forwarding should use no promiscuous-mode. Circuits used as members in a bridge should use promiscuous-mode active. Circuits used in a tap configuration should use promiscuous-mode.
replace-vlan-tag <id>
Specifies a VLAN tag that the circuit will use to replace the existing VLAN tag on the circuit traffic. This is useful to map traffic at an incoming port with a VLAN ID of x to a VLAN ID of y, especially if connected to an external switch. The <id> is a value in the range of 1 to 4094.
70
Configuring Interfaces
Definition Directs the VAP group that you are configuring to verify connectivity to the specified next-hop IP address and to perform a redundant interface failover in the event that a next-hop IP address health check fails. This option is effective only if the circuit is assigned to an interface that has been configured for redundancy. IPv6 addresses can be used if at least one address (primary or alias) is an IPv6 address.
NOTE: To enable a VAP group to use DHCP relay servers, first configure circuits with the dhcp-relay parameter, and then map those circuits to the interfaces for the DHCP server and DHCP client. Then use the dhcp-relay-server-list parameter under configure vap-group to configure the VAP group to use one or more specific DHCP servers. The following is an example of one-to-one mapping. This example ties the first gigabitethernet interface in slot 1 to a circuit called dmz with an IP address of 192.168.30.1. This circuit will appear as an interface on each of the VAPs in the VAP group called firewall. Running the ifconfig command from the CLI for each VAP in the group would show the same interface with the same IP address on each VAP. CBS# configure circuit dmz CBS(conf-cct)# device-name dmz CBS(conf-cct)# vap-group firewall CBS(conf-cct-vapgroup)# ip 192.168.30.1/24 CBS(conf-cct-vapgroup-ip)# end CBS# configure interface gigabitethernet 1/1 CBS(conf-intf-gig)# logical dmz CBS(intf-gig-logical)# circuit dmz CBS(intf-gig-log-cct)# end The following example configures the same circuit, but assigns increment-per-vap and an alias. CBS# configure circuit dmz CBS(conf-cct)# device-name dmz CBS(conf-cct)# vap-group firewall CBS(conf-cct-vapgroup)# ip 101.1.1.2/24 increment-per-vap 101.1.1.4 alias 101.1.1.1/24 CBS(conf-cct-vapgroup-ip)# end CBS# configure interface gigabitethernet 1/1 CBS(conf-intf-gig)# logical dmz CBS(intf-gig-logical)# circuit dmz CBS(intf-gig-log-cct)# end The following example configures a circuit between two VAP groups to serialize traffic: CBS# configure circuit serialize CBS(conf-cct)# device-name serialize CBS(conf-cct)# vap-group iss CBS(conf-cct-vapgroup)# promiscuous-mode active CBS(conf-cct-vapgroup)# exit CBS(conf-cct)# vap-group firewall CBS(conf-cct-vapgroup)# ip 2.2.2.1/24 increment-per-vap 2.2.2.2 CBS(conf-cct-vapgroup-ip)# end CBS# configure interface-internal serial CBS(conf-intf-internal)# logical-all log_ser CBS(conf-intf-internal-log-all)# circuit serialize The following example assigns a circuit to two VAP groups to parallelize traffic. Traffic coming into the circuit goes to both VAP groups simultaneously.
71
CBS# configure circuit circuit1 CBS(conf-cct)# vap-group firewall CBS(conf-cct-vapgroup)# ip-forwarding CBS(conf-cct-vapgroup)# ip 100.123.10.1/8 CBS(conf-cct-vapgroup-ip)# end CBS# configure circuit circuit1 CBS(conf-cct)# vap-group ids CBS(conf-cct-vapgroup)# promiscuous-mode CBS(conf-cct-vapgroup)# end The following example configures a circuit for synchronization between VAPs in the VAP group, firewall. The device-name parameter changes the Linux interface name from vndxxxx to sync. CBS# configure circuit fw_sync CBS(conf-cct)# device-name sync CBS(conf-cct)# vap-group firewall CBS(conf-cct-vapgroup)# ip 2.2.2.1/24 increment-per-vap 2.2.2.2 CBS(conf-cct-vapgroup-ip)# end CBS# configure interface-internal sync_circuit CBS(conf-intf-internal)# logical-all sync_circuit CBS(conf-intf-internal-log-all)# circuit fw_sync Use the show running-config circuit <name> command to display the circuit configuration parameters.
IPv6 Examples
To run traffic using IPv6 addressing, the following example assumes that the VAP group has IPv6 enabled (see IPv6 Traffic on page 47). The difference is the IP address specified for the circuit. CBS# configure circuit dmz CBS(conf-cct)# device-name dmz CBS(conf-cct)# vap-group firewall CBS(conf-cct-vapgroup)# ip fd00:1545:be72:e5af::cf33:54aa/64 CBS(conf-cct-vapgroup-ip)# end CBS# configure interface gigabitethernet 1/1 CBS(conf-intf-gig)# logical dmz CBS(intf-gig-logical)# circuit dmz CBS(intf-gig-log-cct)# end The following example configures an IPv4 address on a VAP group that has previously been IPv6 enabled, and assigns an IPv6 alias. CBS# configure circuit dmz CBS(conf-cct)# device-name dmz CBS(conf-cct)# vap-group firewall CBS(conf-cct-vapgroup)# ip 101.1.1.2/24 CBS(conf-cct-vapgroup-ip)# alias fd00:1545:be72:e5af::cf33:33ff/64 CBS(conf-cct-vapgroup-ip)# end CBS# configure interface gigabitethernet 1/1 CBS(conf-intf-gig)# logical dmz CBS(intf-gig-logical)# circuit dmz CBS(intf-gig-log-cct)# end Use the show running-config circuit <name> command to display the circuit configuration parameters.
Configuring Interfaces
72
configure acl-interface
The configure acl-interface command creates and configures a new ACL filter. This command is also used to modify an existing ACL filter. Use the show acl-interface command to display the filtering criteria defined for each ACL filter that is currently configured on the X-Series Platform. Use the no parameter to delete the specified ACL filter. Before deleting an ACL filter, all interface ACL definitions that include that filter must be deleted. Use the show acl-interface-mapping command to display a list of the ACLs defined for each physical interface and group interface configured on the X-Series Platform. configure [no] acl-interface <ACL_filter_name>
Filters
You can define the following filters for an ACL:
z
Direction
ingress-only: NPM applies ACL action only to traffic flowing into the X-Series Platform. This is the default flow direction filtering criteria defined when you create a new ACL filter. egress-only: NPM applies ACL action only to traffic flowing out of the X-Series Platform. bidirectional: NPM applies ACL action to all traffic flowing into and out of the X-Series Platform. <VLAN_tag> Defines VLAN tag filtering criteria, using the specified VLAN tag. The NPM applies the ACL action to a packet passing through the interface only if the packets VLAN tag matches the specified VLAN tag. The VLAN tag is specified in decimal (0 to 4095) or hexidecimal (0x000-0xFFF) format.
VLAN
73
<VLAN_tag> <mask> Defines VLAN tag filtering criteria, using the specified VLAN tag and mask.The NPM applies the ACL action to a packet passing through the interface only if the packets VLAN tag matches the specified VLAN tag when the specified mask is applied. The X-Series Platform applies the mask in binary format, where 0s indicate wildcard bits. A packets VLAN tag matches the specified VLAN tag if all their non-wildcard bits match. To apply the ACL action only to packets with the specified VLAN tag, use a mask of 0xFFF. To apply the ACL action without considering a packets VLAN tag, use a mask of 0x000.
<Ethernet_type_code> Defines Ethernet type filtering criteria. Specify the Ethernet type code in hexidecimal format. Valid values are from 0x0000 to 0xFFFF. The NPM applies the ACL action to a packet passing through the interface only if the packets Ethernet type code matches the specified Ethernet type code. <Ethernet_type_code> <mask> Defines Ethernet type filtering criteria, using the specified Ethernet type code and the specified mask. specify the Ethernet type code and mask in hexidecimal format. Valid values for <Ethernet_type_code> are from 0x0000 to 0xFFFF, valid values for <mask> are from 0x0000 to 0xFFFF. The X-Series Platform applies the mask in binary format, where 0s indicate wildcard bits. A packets Ethernet type code matches the specified Ethernet type code if all their non-wildcard bits match. To apply the ACL action only to packets with the specified Ethernet type code, use a mask of 0xFFFF. To apply the ACL action without considering a packets Ethernet type code, use a mask of 0x0000.
Source-mac
<source_MAC_address> The NPM applies the ACL action to a packet only if its source MAC address matches the specified source MAC address. Specify the source MAC address using the standard hexidecimal address format (aa:bb:cc:dd:ee:ff). NOTE: Configure an ACL filter with the source-mac command using the direction ingress-only command. A warning will be displayed if the direction is specified as egress-only or bidirectional.
<source_MAC_address> <mask> You must specify the source MAC address and mask using the standard hexidecimal address format (aa:bb:cc:dd:ee:ff). NOTE: The X-Series Platform applies the mask in binary format, where 0s indicate wildcard bits. A packets source MAC address matches the specified source MAC address if all their non-wildcard bits match. To apply the ACL action only to packets with the specified source MAC address, use a mask of ff:ff:ff:ff:ff:ff. To apply the ACL action without considering a packets source MAC address, use a mask of 00:00:00:00:00:00.
Destination-mac NOTE: Configure an ACL filter with the destination-mac command using the direction ingress-only command. A warning will be displayed if the direction is specified as egress-only or bidirectional.
<destination_MAC_address> The NPM applies the ACL action only to packets whose destination MAC addresses match the specified filtering criteria. You must specify the destination MAC address using the standard hexidecimal address format (aa:bb:cc:dd:ee:ff). <destination_MAC_address> <mask> The NPM applies the ACL action to a packet only if its destination MAC address matches the specified destination MAC address when the specified mask is applied. You must specify the destination MAC address and mask using the standard hexidecimal address format (aa:bb:cc:dd:ee:ff). NOTE: The X-Series Platform applies the mask in binary format, where 0s indicate wildcard bits. A packets destination MAC address matches the specified destination MAC address if all their non-wildcard bits match. To apply the ACL action only to packets with the specified destination MAC address, use a mask of ff:ff:ff:ff:ff:ff. To apply the ACL action without considering a packets destination MAC address, use a mask of 00:00:00:00:00:00.
Configuring Interfaces
74
Actions
The actions direct the NPM about how to handle the traffic that meets the ACL filter criteria, and are specified inline while configuring the ACL with the interface. See Packet Mirroring on the NPM Interfaces on page 73 for details about each of the actions and configuring the interfaces.
Mirror: This action copies packets to one or more interfaces. Often the interface is connected to an IDS or packet sniffer that performs an analysis of the interface traffic. This functionality is identical to SPAN port functionality. Pass-through: This action will bypass any applications or functions of the X-Series Platform and will pass traffic directly to an outgoing interface or interfaces. One consideration when using pass-through; Pass-through traffic will not be sent to internal interfaces or VAPs. This includes traffic for protocols that are critical to network and interface connectivity, such as LACP and ARP. Do not configure an ACL to filter and pass-through all traffic on an interface or the network may shut down. Drop: Instructs the NPM to drop traffic that meets the filter criteria. If traffic coming from a VLAN, or originating from a MAC address has been identified as malicious, the ACL can specify that location and instruct the NPM to drop the traffic. As with the pass-through action, use care when specifying the drop action. If necessary network protocol information is dropped from the interface it may cause the network, or section of the network, to shut down. Capture: Primarily a troubleshooting function, it instructs the NPM to copy all packets that match the criteria defined in the ACL filter to the local eth2 interface on the NPM. You can use tcpdump to inspect packets captured. By default, the eth2 interface is down. You will have to use ifconfig to bring the eth2 interface up and perform the tcpdump. Once the dump is complete, return the eth2 interface to the down state.
Remote mirroring (the mirrored port is on a different NPM than the source port) is not supported. Remote pass-through (the destination port is on a different NPM than the source port) is not supported. An interface or multi-link group-interface must be configured before it is used as a target to pass-through or mirror traffic. Multiple ACL filters can be configured for the same interface. When a packet arrives on an interface, the NPM applies the filters to the packet one at a time, in the order that the filters were configured. To reconfigure the precedence of acl-interface-mappings, delete the mappings and redefine them in the order you want. Multiple interfaces can be configured with the same ACL filter. An ACL filter can be configured to mirror traffic to multiple interfaces on the same NPM. An interface cannot mirror or pass-through traffic to itself. An interface can be configured to mirror or pass-through traffic on a port that is part of a multi-link group-interface, so long as both interfaces are on the same NPM. A multi-link group-interface can mirror traffic to a single interface, if all group member interfaces and the target mirror interface are on the same NPM.
75
An interface which is part of a multi-link group interface cannot mirror traffic to another interface. Instead, mirror the traffic from the whole group to another interface
Use the no acl-interface command to remove the specified ACL from a physical interface. IMPORTANT: If multiple ACLs are defined for the physical interface, the no parameter will only delete the most recently defined ACL. Use the following show commands to view the criteria for the ACL:
z z z
show running-config to determine the order in which ACLs are defined for a physical interface. show acl-interface to display the conditions defined for each ACL that is currently configured on the X-Series Platform. show acl-interface-mapping to display a list of the ACLs assigned to each physical interface, and display the action configured for each ACL.
CBS(conf-acl-map-intf-gig-mirror)# 10gigabitethernet 1/12 CBS(conf-acl-map-intf-gig-mirror)# end The show command displays the ACL configuration: CBS# show acl-interface-mapping Primary (interface/group) : gigabitethernet 1/1 ACL Interface : multiple_acl action : mirror Destination interface(s) : gigabitethernet 1/10, 10gigabitethernet 1/11, 10gigabitethernet 1/12 (1 row)
Configuring Interfaces
78
UDP and ICMP flows are stateless, and do not have flow setup or termination schemes. New flows are assigned the idle time-out specified in the ip-flow rule. By specifying flow table limits on each flow type, these flows do not consume critical NPM resources, preventing the setup of other flows.
Figure 5.
3.
Double-click on the pie chart to open the Flow Utilization by Protocol graph. Use this tool to monitor traffic on the X-Series Platform. For additional information on configuring specific utilization graphs, refer to the Greenlight User Assistance.
Figure 6.
79
Use the following list to understand the type of traffic your network is processing, and the type of traffic that could be a threat.
What is the most common type of traffic: TCP, UDP, ICMP, or Other-IP. Identify a baseline for normal traffic. Use the Historical data option to look back over time. Identify the high end of a range. Are there consistent spikes or low spots in the data?
Use the information gathered to configure parameters to monitor, pass, or drop traffic of a specific protocol based on the number of flows passing through the system. For example, if the flow table limit action is set to drop UDP traffic, the following scenario occurs: When the number of new UDP flows reaches a preliminary threshold, new flows are monitored (counted). As the number of new flows increases toward the user-defined limit, the chance of the preemptive dropping of a new flow increases. When the total number of active flows reaches the predefined limit, all new UDP flows will be dropped. Traffic associated with established flows will continue to pass. The system default is to pass all traffic. If the flow table limit is configured for a protocol, and the action is set to pass, then new flows of that protocol will not be dropped even when the protocol flow table limit is passed. Traffic will continue to pass until the flow table resources are consumed.
Fragment Handling
With IP traffic, packets are mapped to a flow based on protocol, source and destination IP addresses, and source and destination ports. Mapping TCP and UDP packets to flows requires the source and destination port. When TCP and UDP packets are fragmented, the individual fragments must be associated with source and destination ports before mapping the fragments to flows. Some fragmented TCP and UDP traffic is expected and is handled without impact on the system. A high number of fragmented packets will consume resources and reduce the effective throughput of traffic. Examples of fragmented or nonconforming packets that may be part of an attack are packets with:
z z z z z
Bad or overlapping offsets Spoofed packet size High numbers of missing fragments Duplicate Head of Packet A high number of small fragments
Fragment handling employs heuristics to process the fragments. This logic makes decisions whether to drop fragments, aggressively age-out fragmented packets, or forward the fragments. When under processing pressure, nonconforming packets are more likely to be dropped. The fragment handling heuristics are off by default. Crossbeam recommends enabling fragment handling on your X-Series Platform. Once enabled, it can be specifically disabled on a per-logical line basis. For instance, for an IPS application that inspects all traffic, disable fragment handling on the interfaces or logical lines attached to the application. NOTE: IPv6, ICMP, and Other-IP traffic are not affected by fragment handling settings.
TCP/IP header information TCP/IP checksum IP option length Packet size Flags
A parameter of drop or pass is configured for invalid packets. The default action is to pass all packets. Statistics are maintained for all packet validation checks regardless of the drop or pass parameters.
Configuring Interfaces
80
81
6.
Configure the action to be taken when UDP partition limit is reached. Set the action to drop. Command: CBS(conf-flow-table-partition)# flow-table-profile udp CBS(conf-rp-table-profile)# table-limit action drop CBS(conf-rp-table-profile)# exit CBS(conf-flow-table-partition)# end CBS#
7.
Configure TCP/IP packet validation, and set the following actions to drop. Command: CBS# configure packet-validation CBS(conf-pkt-validation)# validate-tcp-packet action drop CBS(conf-pkt-validation)# validate-tcp-checksum action drop CBS(conf-pkt-validation)# validate-ip-packet action drop CBS(conf-pkt-validation)# end CBS# When packet validation is enabled, the individual validation checks are enabled with a default action of pass. These checks verify that the packets are well-formed, and are not corrupted. Setting the action to drop removes invalid packets at the NPM interface and reduces resource consumption on the APMs and the end-hosts. Statistics are maintained for all checks regardless of the configured action. These checks are applied to all circuits that are connected to external interfaces. Individual circuits can be configured independently of the global settings.
8.
Configure fragment handling parameters. Fragment handling settings are designed to identify common anomalies and, under stressful conditions allow NPM resources to be directed toward good traffic. It is recommended to enable fragment handling on the X-Series Platform. In the case of an IPS application that requires visibility into all the traffic, this functionality can be disabled. Command: CBS(conf-resource-protection)# fragment-handling-options CBS(conf-rp-frag-handling)# exit CBS(conf-resource-protection)# end CBS# Fragment handling settings are set globally and may be disabled per logical interface.
Resource protection is now configured globally on your X-Series Platform. All traffic will be subject to these parameters.
Workflow
To disable individual flow table limit action settings on an existing, configured interface, use the following steps: 1. From the CLI, enter the configure interface context. CBS# configure interface gig 1/1
Configuring Interfaces 82
2.
Enter the logical and circuit for the interface. CBS(conf-intf-gig)# logical mgmt CBS(intf-gig-logical)# circuit mgmt
3. 4.
Override the flow table limit action for the individual management circuit. CBS(intf-gig-log-cct)# no flow-table-limit Use end to return to the main CLI context. Repeat the steps for each interface required. CBS(intf-gig-log-cct)# end CBS#
Additional resource protection settings can be disabled on individual interfaces using the procedure above. CBS# configure interface gig 1/1 CBS(conf-intf-gig)# logical mgmt CBS(intf-gig-logical)# circuit mgmt CBS(intf-gig-log-cct)# ? [no] flow-table-limit [no] fragment-handling-options Overrides the global configuration and disables flow table limit per interface Overrides the global configuration and disables fragment handling options per interface Overrides the global configuration and disables packet-validation per interface
[no] packet-validation
Table 13.
83
Parameter preemption-off
Definition Upon failure of the master physical interface, the backup interface services traffic. The original Master does not resume being Master when it becomes available, unless the backup fails. Upon failure of the master physical interface, the backup interface services traffic. However, the traffic does not switch over to the original master even should the backup interface fail.
manual-swback
The following example configures the interface at port 1 of the NPM in slot 1 to be backed up by port 2 of the same NPM. Should the master interface fail, the backup interface services traffic but the traffic does not switch back to the original master should the backup fail. CBS# configure redundancy-interface master gigabitethernet 1/1 backup gigabitethernet 1/2 mac-usage master CBS(conf-intf-redun)# failovermode manual-swback NOTE: The mac-usage master parameter is required for the redundancy-interface command. Here is an example of configuring an interface for redundancy: CBS# configure interface gigabitethernet 4/6 CBS(conf-intf-gig)# logical ispxena2 CBS(intf-gig-logical)# circuit ispxena2 CBS(intf-gig-logical)# end CBS# configure interface gigabitethernet 4/7 CBS# configure redundancy-interface master gigabitethernet 4/6 backup gigabitethernet 4/7 mac-usage master failovermode preemption-off If you configure a bridge-mode interface for redundancy, the backup interface must be configured as standby-only, as shown in the following example: CBS# configure interface gigabitethernet 4/6 CBS(conf-intf-gig)# logical ispxena2 CBS(intf-gig-logical)# circuit ispxena2 CBS# configure interface gigabitethernet 4/7 CBS(conf-intf-gig)# standby-only CBS# configure redundancy-interface master gigabitethernet 4/6 backup gigabitethernet 4/7 mac-usage master failovermode preemption-off To display the currently configured redundant interface, use the following command: CBS# show redundancy-interface Master Intf Backup Intf Active Intf ------------------------------gig 1/3 gig 2/3 Master gig 1/7 gig 2/7 Backup MacUsage -------master master FailOverMode -----------preemption-on preemption-off
Configuring Interfaces
84
Table 14.
interface-type auto-negotiate
Specify the physical interface type for the group. Choices are gigabitethernet or 10gigabitethernet. All interfaces in the group must be the same type. Configured under the interface-type context; defaults set based on interface type (gigabitethernet or 10gigabitethernet). Matches best speed for multi-speed devices and uses automatic sensing to support full duplex operation. If using fiber gigabitethernet ports, auto negotiation must be enabled. Configured under the interface-type context; defaults set based on interface type (gigabitethernet or 10gigabitethernet). Configures half or full duplex mode. For gigabitethernet ports, this is only applicable when the interface is configured for a copper connection. Configured under the interface-type context; defaults set based on interface type (gigabitethernet or 10gigabitethernet). Configures media speed. For gigabitethernet ports, this is only applicable when the interface is configured for a copper connection. This setting overrides the auto-negotiation speed. Configured under the interface-type context; defaults set based on interface type (gigabitethernet or 10gigabitethernet). Configures pause frame, also known as flow control. Configured under the interface-type context. The group interface can be disabled or enabled. Default is enabled. Add individual interfaces to the group. Settings applied to the group are automatically written to the individual interfaces. Configured under each interface context. An interface is enabled if both the group interface and individual interface are enabled. Individual physical interfaces may also be disabled / enabled independent of the group interface.
85
duplex-mode
media-speed
pause-frame
You can disable and enable a group interface with the [no] enable command: CBS# config group-interface test interface-type gigabitethernet no enable You can enable or disable individual physical devices using the enable command, once the device has been specified: CBS# config group-interface test interface 1/1 no enable NOTE: When configuring physical link parameters such as speed, MAC address, auto-negotiate, duplex mode, and pause frame for the group interface, the parameters are applied to each physical interface in the group. By default, the interface is enabled, auto-negotiation is enabled, duplex mode is full, and the interface is not in standby mode. The following example configures circuit1 for VLAN 2, and configures a second non-VLAN circuit (required). The non-VLAN logical line must be created before the VLAN logical line. When specifying the group interface mode, you must specify a circuit. The circuit is automatically configured with a logical interface that passes all VLAN and non-VLAN traffic. CBS# configure group-interface lab CBS(conf-group-intf)# interface-type gigabitethernet CBS(conf-grp-intf-gig)# exit CBS(conf-group-intf)# mode multi-link circuit circuit2 CBS(conf-group-intf)# interface 1/1 CBS(conf-grp-intf-intf)# exit CBS(conf-group-intf)# interface 1/2 CBS(conf-grp-intf-intf)# exit CBS(conf-group-intf)# interface 1/3 CBS(conf-grp-intf-intf)# exit CBS(conf-group-intf)# interface 1/4 CBS(conf-grp-intf-intf)# exit CBS(conf-group-intf)# logical logical11 ingress-vlan-tag 2 CBS(conf-group-intf-logical)# circuit circuit1 To have traffic coming into this group interface directed to two applications, assign Circuit1 to two VAP groups. For example: CBS# configure circuit circuit1 CBS(conf-cct)# vap-group firewall CBS(conf-cct-vapgroup)# default-egress-vlan-tag 2 CBS(conf-cct-vapgroup)# ip-forwarding CBS(conf-cct-vapgroup)# ip 100.123.10.1/8 CBS(conf-cct-vapgroup-ip)# exit CBS# configure circuit circuit1 CBS(conf-cct)# vap-group ids CBS(conf-cct-vapgroup)# promiscuous-mode In the example of directing traffic to two or more VAP groups, you must also assign the LACP circuit to all the VAP groups. Continuing the previous example, Circuit2 is the LACP circuit, and you would assign Circuit2 to both VAP groups as follows: CBS# configure circuit circuit2 CBS(conf-cct)# vap-group firewall CBS(conf-cct-vapgroup)# ip-forwarding CBS(conf-cct-vapgroup)# exit CBS# configure circuit circuit2 CBS(conf-cct)# vap-group ids CBS(conf-cct-vapgroup)# promiscuous-mode To view existing group interfaces from the CLI, use the show group-interface command.
Configuring Interfaces
86
87
Configuring Interfaces
88
7
Configuring Management Interfaces
This chapter provides information on configuring interfaces, including access lists. It includes the following major topics:
z z z z z
Physical Management Interfaces on page 89 Configure Management Physical Interfaces on page 90 Configure Access Lists on page 91 Define an Access List to a Management Interface on page 94 Display Management Access Lists on page 94
Table 15.
X80 / X60 X20/X30 X80-S Chassis Chassis Port # Interface Type Chassis Slot # Slot Slot # 13 13 14 14 6 6 7 7 7 7 1 2 1 2 gigabitethernet gigabitethernet gigabitethernet gigabitethernet
Description
Gigabit Ethernet management port Gigabit Ethernet logging port on CP1 Gigabit Ethernet management port Gigabit Ethernet logging port on CP2
NOTE: Inside NAT does not failover from one CPM management interface to the other CPM. The inside NAT should be explicitly configured identically on both CPM management interfaces. IMPORTANT: If you configure two management interfaces on the same slot, they cannot be on the same subnet.
89
90
Access to the system (ssh, telnet, https) The ability to transfer files or policies (scp/ftp) ICMP to ping the system when troubleshooting A list of the management source addresses with access to the system Permissions for those ip addresses
During the XOS Install Interview, you can choose to allow all traffic, which will automatically create an allow/all rule. This may be safest in a non-production environment, where external access to the system is limited. The following is an example of an allow/all access list. configure access-list 1001 permit ip source-ip 0.0.0.0 255.255.255.255 destination-ip 0.0.0.0 255.255.255.255 configure access-list 1002 permit ip source-ip 0.0.0.0 255.255.255.255 destination-ip 0.0.0.0 255.255.255.255 TCP/UDP configure access-list <number> {deny|permit} {tcp|udp} {{source-ip <src-ip-address> <source-wildcard>}|source-any} {source-port-any|source-port-name <name>|source-port <0-65535> [<0-65535>]} {{destination-ip <des-ip-address> <destination-wildcard>}|destination-any} {destination-port-any|destination-port-name <name>| destination-port <0-65535> [<0-65535>]} [log] ICMP configure access-list <number> {deny|permit} icmp {{source-ip <src-ip-address> <source-wildcard>}|source-any} {{destination-ip <des-ip-address> <destination-wildcard>}|destination-any} {icmp-message <message>|icmp-type <0-255>} [log] IP/Protocol Number configure access-list <number> {deny|permit} {ip|protocol-number <0-255>} {{source-ip <src-ip-address> <source-wildcard>}|source-any} {{destination-ip <des-ip-address> <destination-wildcard>}|destination-any} [log] NOTE: A wildcard setting of 255.255.255.255 permits any address regardless of the IP address configured. To configure the access list to permit a specific host address, the wildcard used should be 0.0.0.0. Where: <number> deny permit ip|tcp|udp|icmp <src-ip-address> <source-wildcard> Number of an access list. This is a decimal number from 0 through 65535. Denies access if the conditions are matched. Permits access if the conditions are matched. Protocol name or number. IP address of the network or host from which the packet is being sent. Use a 32-bit quantity in four-part dotted-decimal format. Wildcard bits applied to the source. Use a 32-bit quantity in four-part dotted-decimal format. Places ones in the bit positions you want to ignore.
91
Abbreviation for a source and source-wildcard of 0.0.0.0 255.255.255.255. Configures the source port to be any. Specifies the source low/high port-name; names are as follows:
z z z z z z z z z z z z z z z z z z z z
source-port <number> Source low/high port-number value. Valid numbers are from 0 - 65535 ftp-data File Transfer Protocol Data (20) ftp File Transfer Protocol (21) ssh Secure SHell (22) telnet Telecommunications Network Protocol (23) smtp Simple Mail Transfer Protocol (25) time Time (37) domain Domain Name Server (53) bootps Bootstrap Protocol Server Protocol (67) bootpc Bootstrap Protocol Client Protocol (68) tftp Trivial File Transfer Protocol (69) http Hyper Text Transfer Protocol or www or www-http (80) rtelnet Remote Telecommunications Network Protocol (107) pop3 Post Office Protocol Version 3 (110) nntp Network News Transfer Protocol (119) ntp Network Time Protocol (123) imap Internet Message Access Protocol (143) snmp Simple Network Management Protocol (161) ldap Lightweight Directory Access Protocol (389) https Secure Hyper Text Transfer Protocol (443) isakmp Internet Security Association and Key Management Protocol (500)
<des-ip-address>
IP address of the network or host receiving the packet being sent. There are two alternative ways to specify the destination:
z z
Use a 32-bit quantity in four-part dotted-decimal format Use any as an abbreviation for a source and source-wildcard of 0.0.0.0 255.255.255.255
<destination-wildcard> Wildcard bits applied to the destination. Use a 32-bit quantity in four-part dotted-decimal format. Places ones in the bit positions you want to ignore. destination-any destination-port-any destination-port-name <name> destination-port <number> Abbreviation for a destination and destination-wildcard of 0.0.0.0 255.255.255.255. (TCP/UDP Only) Configures the destination port to be any. (TCP/UDP Only) Specifies the destination low/high port-name. Names are the same as the source-port names. (TCP/UDP Only) Specifies the destination low/high port number. Values are 0 to 65535.
92
icmp-message <message-name>
Valid message names as listed below: NOTE: Enter the text string, for example, network-redirect. As an alternative, see the next row in this table for information on how to enter the icmp-type followed by the type number. A list of names, types, and codes is located here: http://www.iana.org/assignments/icmp-parameters
z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z z
echo-reply echo-reply (type 0) destination-unreachable unreachable (type 3) network-unreachable net-unreachable (type 3, code 0) host-unreachable host-unreachable (type 3, code 1) protocol-unreachable protocol-unreachable (type 3, code 2) port-unreachable port-unreachable (type 3, code 3) fragmentation-needed packet-too-big (type 3, code 4) source-route-failed source-route-failed (type 3, code 5) network-unknown network-unknown (type 3, code 6) host-unknown host-unknown (type 3, code 7) network-prohibited dod-net-prohibited (type 3, code 9) host-prohibited dod-host-prohibited (type 3, code 10) TOS-network-unreachable net-tos-unreachable (type 3, code 11) TOS-host-unreachable host-tos-unreachable (type 3, code 12) communication-prohibited administratively-prohibited (type 3, code 13) host-precedence-violation host-precedence-unreachable (type 3, code 14) precedence-cutoff precedence-unreachable (type 3, code 15) source-quench source-quench (type 4) redirect redirect (type 5) network-redirect net-redirect (type 5, code 0) host-redirect host-redirect (type 5, code 1) TOS-network-redirect net-tos-redirect (type 5, code 2) TOS-host-redirect host-tos-redirect (type 5, code 3) echo-request echo (type 8) router-advertisement router-advertisement (type 9) router-solicitation router-solicitation (type 10) time-exceeded time-exceeded (type 11) ttl-zero-during-transit ttl-exceeded (type 11, code 0) ttl-zero-during-reassembly reassembly-timeout (type 11, code 1) parameter-problem parameter-problem (type 12) ip-header-bad general-parameter-problem (type 12, code 0) required-option-missing option-missing (type 12, code 1) timestamp-request timestamp-request (type 13) timestamp-reply timestamp-replace (type 14) address-mask-request mask-request (type 17) address-mask-reply mask-reply (type 18)
93
icmp-type <type-number>
Configures the ICMP message matching criteria for the ACL to include only packets with the specified message type. The X-Series Platform applies the ACLs action (deny or permit) to a packet only if its message type number matches the specified message type number. Valid message type numbers are from 0 to 255.
log
Final Steps
If you are going to be managing the X-Series Platform from an external subnet, you must configure a management port default gateway. While this is generally understood for external management, it is included in the Install Interview questions, and worth noting here. Command: CBS# configure management default-gateway 172.16.19.63 CBS(conf-mgmt)# end CBS#
94
8
Configuring Flow Provisioning
This chapter describes using and creating IP and non-IP flow rules and QoS rate-limiter rules. It contains the following major topics:
z z z z
Flow Rule Overview on page 95 Configuring IP Flow Rules on page 101 Configuring System IP Flow Rules on page 103 Configuring System Non-IP Flow Rules on page 106
IP Flow Rule - processes IP traffic at the VAP level. Non-IP Flow Rule - processes non-IP traffic at the VAP level. System IP Flow Rule - affects all IP traffic at the system level, which affects all VAPs. System Non-IP Flow Rule - affects all non-IP traffic at the system level.
All IP flow rules are part of the IP flow classifier system module. The IP flow classifier is designed to be an IP delivery, policy enforcement, and provisioning module. Its default behavior is to direct IP traffic destined to the X-Series Platform to the correct slot (or VAP) for all the configured IP addresses.
IP source address IP destination address Protocol, which indicates the destination upper-layer protocol layer for this datagram. For example, ICMP is 1, IGMP is 2, TCP is 6, and UDP is 17. The default is all protocols (1-255). Source port Destination port
In addition, traffic can be identified by the Domain ID and Incoming Circuit Group (ICG) values that define the physical location of the flow in the X-Series Platform. Each of these values can be a single value or a range of values. For example, a flow rule can be applied to a range of IP source addresses such as 192.100.100.000 to 192.100.100.255. This would be noted in CIDR format as 192.100.100.000/24.
95
The Incoming Circuit Group (ICG) is used by the NPM as an additional method to classify traffic for one or more circuits. When an ICG number is assigned or changed in the circuit configuration, it will impact flow classification on the NPM. If you change an ICG circuit assignment, verify that the appropriate flow rules have been configured or updated. The flow of traffic through a VAP or VAP group can be configured using the following actions and other criteria:
z z z z z z z z z z z z z z
load-balance drop allow pass-to-master pass-to-vap broadcast direction skip-port-protocol generate-reversed-flow source-addr destination-addr source-port destination-port core-assignment
Refer to Chapter 6 of the XOS Command Reference Guide for detailed information configuring flow rules. Each flow rule is assigned a priority, as described in Priorities for IP Flow Rules on page 100. A flow can match different flow rules. However, only the flow rule with the highest priority is used. It is possible to have many rules at the same priority as long as they do not conflict. Flow rules are considered to be in conflict if they have the same priority, are assigned to the same VAP group, and a packet could match both flow rules. For example, these two flow rules are in conflict if they are applied to the same VAP group:
z z
Since it is possible to receive a packet destined to 20.0.0.1 on port 80, the rules are in conflict. Simply changing the priority of either rule removes the conflict. To check for flow rule conflicts, enable the check-flow-rule command. When enabled, each time a flow rule is activated, XOS checks for policy conflicts between that flow rule and the flow rules that are currently activated on the X-Series Platform. If XOS detects a policy conflict, the activate operation fails and the CLI issues an error message. NOTE: If flow rule checking has been disabled and is then enabled, all the activated flow rules are checked for conflicts. The following parameters are secondary actions that can be configured for flow rules:
z
The skip-port-protocol parameter is often used for load balancing purposes. When enabled (default), the NPM ignores the destination port, source port, and protocol in the IP packet when deciding how to load balance a new flow. Therefore, any flows with the same source and destination IP addresses will be assigned to the same VAP. The timeout for a VAP-level IP flow rule determines the idle timer for a flow. If traffic for any flow is idle for this period of time, the NPM deletes that flow from the Active Flow Table. If another packet belonging to that flow is sent after this deletion, the NPM considers this an unknown flow and processes the packet to determine which flow rules apply and where to send the flow. This could result in moving the flow to another VAP, which could be a problem when using a stateful firewall.
96
Timeout values can be set from 30 seconds to 1 hour, or auto (default). The auto timeout value is set by the system. By default, the system defines a timeout value of 10 minutes for all TCP packets, 1 minute for UDP packets, and 30 seconds for all other protocols. VAP IP flow rules are configured with the configure vap-group <group-name> ip-flow-rule <name> command. After creating a flow rule, you must use the activate command to enable it; otherwise the flow rule does not take affect. When you activate a flow rule, it is not applied to existing flows, it only affects new flows.
action drop action broadcast action pass-to-master encapsulation ethernet encapsulation lsap encapsulation snap activate core-assignment
The VAP non-IP flow rule settings can be seen with the show non-ip-flow command. Refer to Chapter 6 of the XOS Command Reference Guide for detailed information configuring flow rules.
97
z z z
The IP Flow Rule action will be set to broadcast when the IP address subnet is set to a broadcast address. Secondary actions are set to default and the priority is 21. For other IP addresses, the action is to load balance, using the IP address as the destination address. Secondary actions are set to default and the priority is 21. When using the IP address with increment-per-vap, the original address is sent to VAP index 1. The next IP address in sequential order is sent to VAP index 2, and so on. The flow is not load balanced. Secondary actions are set to default, timeout is set to auto, and the priority is 21. When using the IP address with increment-per-vap, the IP flow rule action is set to broadcast for packets with a broadcast address. Otherwise, the default flow-rule is used. Priority is 21.
These rules cannot be modified directly; however, you can modify the default priority using the ip-flow-rule-priority parameter when assigning a circuit to a VAP group. For example, you can change the default priority of 21 using the following command: configure circuit <name> vap-group <name> ip-flow-rule-priority <value> Use the show default-ip-flow-rule command to view the default IP flow rule settings.
drop allow pass-to-masters broadcast direction skip-port-protocol generate-reversed-flow source-addr destination-addr source-port destination-port
Refer to Chapter 6 of the XOS Command Reference Guide for detailed information configuring flow rules. System IP flow rules have the same parameters as the VAP IP flow rules, which are discussed in the previous section. When a flow matches a system flow rule and a VAP-level flow rule, the flow rule with the higher priority takes precedence. If the priority is the same, the system IP flow rule applies. The exceptions, such as the timeout value, are explained in Interaction Between System and VAP IP Flow Rules on page 99. System IP flow rules must be configured when local IP host addresses (or pools of addresses) exist on the X-Series Platform by virtue of a third party proxy or VPN application that are not otherwise visible to the X-Series Platform configuration.
98
The default system IP flow rule settings can be seen with the show default-ip-flow-rule command. You can also change the default timeout values for specific IP addresses, destination ports, and so on. Refer to the XOS Command Reference Guide for details on XOS command usage, syntax, options, and output. CBS# show system-ip-flow-rule System IP Flow Rule Destination Address Destination Address High Destination Port Destination Port High Source Address Source Address High Source Port Source Port High Incoming Circuit Group Protocol Protocol High Domain Domain High Action Activate (true/false) Priority Skip Protocol (true/false) Skip Port (true/false) Skip Port Protocol (true/false) Timeout : : : : : : : : : : : : : : : : : : : : : myrule 0.0.0.0 255.255.255.255 0 65535 0.0.0.0 255.255.255.255 0 65535 1 1 255 1 4095 drop f 10 t t t auto
If the default timeout value for a specific rule is changed, you must verify that the timeout is set properly for all return flows. In the following example, the system default has been changed to 1 hour for all TCP packets. Because HTTP (TCP port 80) typically has short timeouts, create a higher priority rule with a destination port of 80 for the TCP packets, and assign a timeout value of 3 minutes. You must also create a flow rule using source port 80 with a timeout of 3 minutes. Without this flow rule, the return flow, which is not bound for destination port 80, resets the timeout of the active flow entry from 3 minutes to 1 hour. This occurs because the original flow and the return flow share the same active flow entry even though they use two different rules.
99
Merging matched IP flow rules from different VAP groups results in different actions, selected based on the circuit of the classified packet. Classification always occurs on a particular interconnect of the X-Series Platform and is a function of the VAP group reachability from this interconnect. Table 16 summarizes the merger/match process.
Table 16.
Circuit of the VAP group is in promiscuous mode. Circuit of the VAP group is in non-promiscuous mode; destination MAC-address is local or broadcast.
Result of the basic match from this VAP group is considered. Result of the basic match from this VAP group is considered only if the primary action is of the highest priority in comparison with other matches; otherwise, the result is the same as for a NOT directly reachable VAP group. None of the rules are considered.
When matches from multiple groups are merged, secondary actions are merged based on the secondary action merge flow rule. Each primary action from selected matches is considered in the context of the corresponding VAP group.
The system non-IP flow rule settings can be seen with the show system-non-ip-flow-rule command.
100
NOTE: The ip-flow-rule-priority parameter is used when assigning a circuit to a VAP group. This is the only time you can configure a priority for a flow rule. The priority ranges are 10-20 and 25-30. The lower range of priority (10 through 20) is designed for all normal operations of the X-Series Platform. You can define flow rules to load-balance traffic across particular VAPs of the VAP group or select VAPs based on other criteria, like load. The higher range (25 to 30) is designed to over-write the system default configuration; to redefine normal IP forwarding rules; or to restrict a particular type of the traffic. Flow rules with priorities in this range are considered critical rules. NOTE: If there is an overlap of a VAP group level flow rule and a system non-IP flow rule where both handle protocol or encapsulated traffic, the VAP group flow rule always has the higher priority. In addition, a flow rule that contains a specific protocol or encapsulation type has a higher priority than a flow rule that uses the any parameter to specify the protocol or encapsulation type.
101
vap-group vap1 xslinux_v3 max-load-count 1 ap-list ap3 ap4 ap5 ap6 ap7 ap8 ap9 ap10 load-balance-vap-list 1 2 3 4 5 6 7 8 9 10 ip-forwarding ip-flow-rule vap1_lb action load-balance activate ip-flow-rule ftp_data_src action pass-to-vap 1 priority 11 source-port 20 20 activate ip-flow-rule ftp_data_dst action pass-to-vap 1 priority 12 destination-port 20 20 activate ip-flow-rule ftp_ctrl_src action pass-to-vap 1 priority 11 source-port 21 21 activate ip-flow-rule ftp_ctrl_dst action pass-to-vap 1 priority 12 destination-port 21 21 activate Use the show ip-flow-rule <flow-rule-name> command to display an IP flow rule and its parameters. If no flow rule is specified, all system IP flow rules are displayed. CBS# show ip-flow-rule IP Flow Rule VAP Group Destination Address Destination Address High Destination Port Destination Port High Source Address Source Address High Source Port Source Port High Incoming Circuit Group Protocol Protocol High Domain Domain High Action Activate (true/false) Priority Skip Protocol (true/false) Skip Port (true/false) Skip Port Protocol (true/false) Timeout Trace (true/false) Generate Reversed Flow (true/false) Direction Bypass-tcp-flow-setup-validation (true/false) Core Assignment : : : : : : : : : : : : : : : : : : : : : : : : : : : flow1 fw 0.0.0.0 255.255.255.255 0 65535 0.0.0.0 255.255.255.255 0 65535 1 1 255 1 4095 load-balance t 10 t t t auto f f both f random-single-core
102
103
Troubleshooting IP Flows
You can trace VAP group and system IP flow rules using the trace option. When the trace option is enabled on an ip-flow-rule (configure vap-group <group-name> ip-flow-rule <name> -t), the system marks all new flows established using the specified flow rule with a trace flag. The trace flag is cleared only when the flow is cleared from the flow table by either timing out or by issuing the clear flow-active command.
104
Dropping Flows
Flows can be dropped for several reasons, as listed below. Use the show flow active command to display information currently stored in the Active Flow Table (AFT) on the Network Processor Modules (NPMs) running on the X-Series Platform. The verbose parameter display additional information, including Drop reasons about all active flows. For a list of filter parameters to use with the show flow active command, see Chapter 6 of the XOS Command Reference Guide. Possible values for <drop_reason_ID> are:
No L2 policy match The destination MAC in the packet did not match the MAC address of any VND on the circuit where the packet entered the system. NOTE: Circuit information is not displayed for flows with this drop reason ID. No L3 policy match There are no IP flow rules that apply to this layer 3 flow. NOTE: Circuit information is not displayed for flows with this drop reason ID. L3 drop policy This layer 3 flow matches the conditions defined in the access control list (ACL) for an IP flow rule configured with the action, drop. PS2Master failed A VAP group IP flow rule configured with the action, pass-to-master, or a system-level IP flow rule with the action, pass-to-masters, applies to this flow. The NPM attempted to send this flow to one or more master VAPs, but the operation failed because none of the master VAPs were in the Active state. PS2IDX failed A VAP group IP flow rule configured with the action, pass-to-vap, applies to this flow. The NPM attempted to send this flow to the appropriate VAP, but the operation failed because the VAP was not in the Active state. Load-balance failed A VAP group IP flow rule configured with the action, load-balance, applies to this flow. The NPM attempted to load balance this flow across the VAPs in the appropriate VAP group, but the operation failed because there were no active VAPs in the group or because there were no VAPs in the VAP groups load-balance VAP list. Broadcast failed A flow rule configured with the action, broadcast, applies to this flow. The NPM attempted to broadcast this flow to all VAPs in one VAP group or to all VAPs in all VAP groups, but the operation failed because none of the VAPs to which the NPM sent the flow were in the Active state. No Reason One or more flow rules were successfully applied to this flow, and none of those IP flow rules are configured with the action, drop.
105
106
9
Configuring Protocols
This chapter contains the following major topics:
z z z z z z z z z z
Configuring Static IP Routes on page 107 Configuring ARP Entries on page 109 Displaying ARP Entries on page 109 Configuring Neighbor Discovery on page 109 Displaying Neighbor Discovery on page 110 Configuring a RADIUS Server Host on page 110 Configuring an LDAP Server on page 111 Defining the LDAP Version Number on page 111 Configuring RSA SecurID to Authenticate Administrative Users on page 112 Configuring RSA SecurID to Authenticate Remote Users on page 113
107
IP address of the next hop that is used to reach that network. User defined domain, ranging from 1 to 4095, with a default value of 1. Name of the circuit. VAP group for this address. Default value is all VAP groups. Metric value that you want to assign to the static IP route that you are configuring. Valid values are: IPv4: 1 to 255, inclusive, with a default of 0 (zero) IPv6: 257 to 511, inclusive with a default value of 256
verify-next-hop
Verifies a next hop route for a default network before using it.
The following example configures a static route, its netmask, and the address of the next hop: CBS(config)# ip CBS(config-ip)# route 190.1.1.0 255.255.255.0 192.213.212.111 The following example configures the same static route, but also verifies the health of the next hop: CBS(config)# ip CBS(config-ip)# route 190.1.1.0 255.255.255.0 192.213.212.111 vap-group firewall verify-next-hop The following example configures an IPv6 static route and verifies the health of the next hop: CBS(config)# ip CBS(config-ip)# route 2002:BA95:AC10:0:CF6A:D:2145:3000/64 FC00:C959:CC10:0:CF6A:D:2145:0700 vap-group firewall circuit thru1 verify-next-hop To display configured static routes, use the following command: show ip route [<destination-ip> | <first-destination-ip> <last-destination-ip>] [sort-by-destination-address] The following is an example display of the show-ip-route command. Module group1_1 group1_1 group1_1 group1_1 group1_1 group1_1 Destination 192.168.20.30/32 30.1.0.0/16 20.0.0.0/8 21.0.0.0/8 22.0.0.0/8 23.0.0.0/8 Gateway 30.1.0.20 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 Metric 0 0 0 0 0 0 Device eth0 eth0 vnd1 vnd2 vnd3 vnd4
If you have IPv6 configured, show ip route will display the IPv6 routing table. NOTE: XOS will restrict IP routes whose destination network is the same or a more specific network match with the system internal network IP address. For example, the route a.b.c.0/24 is a more specific match than route a.b.0.0/16. XOS displays the following error when a conflict is found: CBS# config management ip-route 1.1.1.234 255.255.255.255 192.168.32.2 %CONF-ERR: Invalid value Detail: Conflict found with internal network 1.1.0.0 255.255.0.0 CBS#
Configuring Protocols
108
CBS# configure neighbor-discovery fd00::330:f3cb:fb31:56ab 00:03:d2:00:02:0d vap-group testvapgroup circuit testcct CBS# NOTE: You cannot specify a MAC address that contains only 0s or only fs.
Configuring Protocols
110
Where: <hostname> <ip-address> DNS name of the RADIUS server host. IP address of the RADIUS server host. The IP address of the RADIUS server host can be on the same network as a management interface or circuit. However, the IP address:
z z
Cannot be on the XOS system's internal network, as defined by the configure system-internal-network command Cannot be an address that is already defined in the XOS configuration, such as a circuits address or a management address.
<auth-port-value> UDP destination port for authentication requests. Valid values are 0 to 65535. Default is 1812. <timeout-value> <key-word> Number of seconds the X-Series Platform waits for a RADIUS server host to reply before timing out. Valid values are 0 to 3600 seconds. Default is 3 seconds. Authentication and encryption key used for all RADIUS communications between the host and the RADIUS daemon. This key must match the encryption used on the RADIUS daemon.
NOTE: Configuration for the LDAP Server are written to the /etc/ldap.conf.This file will be overwritten when the CPM is rebooted. To preserve these files, execute the CLI command copy running-config.
111
Configuring Protocols
112
8.
In some cases, the agent libraries (client side) use the wrong interface IP address in the decryption and authentication fails. To overcome this issue, place a new text file sdopts.rec next to sdconf.rec with the following line included: CLIENT_IP=x.x.x.x Where x.x.x.x is the agents primary IP address, as defined on the server (the IP of the interface to which the server is routed).
4.
113
3. 4. 5.
Configuring Protocols
114
10
Configuring Bridge Mode
You can configure the X-Series Platform for Layer 2 bridging. This chapter describes the components used to configure bridges in XOS.
z z
NOTE: There are restrictions to the number of circuits that can be assigned to a bridge. Refer to Circuit Restrictions for Bridges on page 117. If you are using EMS, open Configuration > Interfaces > Data Interfaces > Bridge Mode. To create a bridge-mode bridge using the CLI, complete the following: 1. Configure a circuit to be used as the bridge-mode bridge. CBS# configure circuit <bridge_circuit_name> CBS(conf-cct)# 2. Configure a device name for the bridge. CBS(conf-cct)# device-name <device_name> CBS(conf-cct)# 3. Assign a VAP group to the circuit: CBS(conf-cct)# vap-group <vapgroupname> CBS(conf-cct-vapgroup)# NOTE: For applications requiring an IP address on the bridge, assign the IP address to the template circuit before creating the bridge. If the application does not specifically require an IP address on the bridge, do not assign a primary IP address to the template circuit. Refer to your application documentation for IP address requirements. 4. Configure the IP address if required. CBS(conf-cct-vapgroup)# ip 10.70.10.1/24 10.70.10.255 CBS(conf-cct-vapgroup-ip)# end CBS# 5. Configure the first of two member circuits. CBS# configure circuit <name1> CBS(conf-cct)#
115
6.
7.
Assign the bridged VAP group to the circuit. CBS(conf-cct)# vap-group <vapgroupname> CBS(conf-cct-vapgroup)#
8.
Set the circuit on the VAP group to promiscuous mode active. Do not configure IP information, as these circuits will be grouped into the above circuit by using the bridge-mode feature. CBS(conf-cct-vapgroup)# promiscuous-mode active CBS(conf-cct-vapgroup)#
9.
Repeat steps 4 through 7 for the second member circuit. Proceed with Step 9 after the second circuit has been configured.
10. Assign these circuits to the physical interfaces, using the following command: CBS# configure interface gigabitethernet 1/1 logical-all <logical name> circuit <name1> CBS(intf-gig-log-cct)# end CBS# configure interface gigabitethernet 1/2 logical-all <logical name> circuit <name2> CBS(intf-gig-log-cct)# end CBS# 11. Group the circuits into bridge-mode, using the following command: CBS# configure bridge-mode <bridge_circuit_name> CBS(conf-bridge-mode)# circuit <name1> CBS(conf-bridge-mode)# circuit <name2> CBS(conf-bridge-mode)# end CBS# The following is an example of a bridge-mode configuration: CBS# configure circuit bridgecct CBS(conf-cct)# device-name bridgecct CBS(conf-cct)# vap-group ids CBS(conf-cct-vapgroup)# ip 10.70.10.1/24 10.70.10.255 CBS(conf-cct-vapgroup-ip)# end CBS# configure circuit circuit1 vap-group ids promiscuous-mode CBS# configure circuit circuit2 vap-group ids promiscuous-mode CBS# configure interface gigabitethernet 1/1 logical logical_1 circuit1 CBS(intf-gig-log-cct)# end CBS# configure interface gigabitethernet 1/2 logical logical_2 circuit2 CBS(intf-gig-log-cct)# end CBS# configure bridge-mode bridgecct CBS(conf-bridge-mode)# circuit circuit1 CBS(conf-bridge-mode)# circuit circuit2 active active circuit
circuit
116
Additional Configurations
The following section provided examples of additional bridge-mode bridge configurations. These include a basic bridge configuration, a VLAN configuration, and a bridge configuration using multi-link group interfaces. A bridge can be connected to another application in a different VAP group. To do this, configure an interface-internal to connect the bridge to the applications VAP group. Also, you can direct traffic to the applications VAP group circuits based on VLAN tags using a combination of ingress-vlan-tag in the logical line and default-egress-vlan-tag in the circuit configuration.
A circuit should not be assigned to more than one bridge if it also mapped to a physical interface. A circuit should not be assigned to more than one bridge if the circuit and VAP group pair is configured for no promiscuous-mode.
NOTE: If you disable a bridge that has attached multi-link group-interfaces, the attached interfaces are not disabled automatically. NOTE: If you enable an MLT group-interface that is attached to a bridge that is disabled, the bridge will remain disabled. Before creating a bridge configuration, you need to determine:
z z
Whether the application requires bridge or transparent mode for the bridge-mode configuration Whether VLAN support is required
Basic Configuration
The following configuration example provides a basic bridge configuration using the transparent mode. vap-group is1 xslinux_v3 vap-count 2 max-load-count 2 ap-list ap4 ap5 load-balance-vap-list 1 2 3 4 5 6 7 8 9 10 11 12 ip-flow-rule def_rule_is1 action load-balance priority 15 activate circuit bridge10 device-name bridge10 vap-group is1 circuit vpt1_1 device name vpt1_1 vap-group is1 promiscuous-mode active circuit vpt1_2 device-name vpt1_2
117
vap-group is1 promiscuous-mode active interface gigabitethernet 1/1 logical-all vpt1_1 circuit vpt1_1 interface gigabitethernet 1/2 logical-all vpt1_2 circuit vpt1_2 bridge-mode bridge10 transparent circuit vpt1_1 circuit vpt1_2
VLAN Configuration
The following configuration example expands the basic configuration so that traffic is serialized from an IPS application to a firewall. VLANs are also supported. vap-group is2 xslinux_v3 vap-count 5 max-load-count 2 ap-list ap7 ap8 ap9 ap10 load-balance-vap-list 1 2 3 4 5 6 7 8 9 10 delay-flow 120 reload-timeout 1200 ip-flow-rule ips_def_rule_is2 action load-balance priority 15 activate vap-group fw xslinux_v3 vap-count 3 max-load-count 2 ap-list ap2 ap3 ap4 load-balance-vap-list 1 2 3 4 5 6 7 8 9 10 delay-flow 120 reload-timeout 1200 ip-flow-rule fw_def_rule action load-balance priority 15 activate system-non-ip-flow-rule IS_stp encapsulation lsap dsap 66 ssap 66 action broadcast activate circuit fwext device-name fwext vap-group fw ip-forwarding ip 172.16.11.10/24 172.16.11.255 circuit vlanbridge1 device-name vlanbridge1 vap-group is2 circuit intvlancirc1 device-name intvlancirc1 vap-group fw
118
ip-forwarding vap-group is2 promiscuous-mode active circuit vlan20 device-name vlan20 vap-group fw default-egress-vlan-tag 20 ip-forwarding ip 172.16.20.10/24 172.16.20.255 circuit vpt1_5 device-name vpt1_5 vap-group is2 promiscuous-mode active interface gigabitethernet 1/2 logical FWEXT circuit fwext interface gigabitethernet 1/5 logical vpt1_5 circuit vpt1_5 interface-internal GRBR5 logical-all GRBR5 circuit intvlancirc1 logical vlan20 ingress-vlan-tag 20 20 circuit vlan20 bridge-mode vlanbridge1 transparent circuit intvlancirc1 circuit vpt1_5
119
circuit MLTBRIDGE1 device-name MLTBRIDGE1 vap-group is1 group-interface MLT1 interface-type gigabitethernet mode multi-link circuit MLTa gigabitethernet 1/1 gigabitethernet 1/2 gigabitethernet 1/3 group-interface MLT2 interface-type gigabitethernet mode multi-link circuit MLTb gigabitethernet 2/1 gigabitethernet 2/2 gigabitethernet 2/3 bridge-mode MLTBRIDGE1 transparent circuit MLTa circuit MLTb
120
11
Configuring CPM Redundancy
This chapter explains how to configure redundant CPMs. It includes the following major topics:
z z z z z z z
Overview on page 121 Installing CPMs and Configuring Redundancy in a New System on page 124 Installing a Second CPM into an Existing System on page 125 Managing CP Redundancy on page 125 Troubleshooting CP Redundancy on page 126 Using the CBS PSI Tool on page 127 Configuring a Redundant CPM Management Virtual IP Address on page 128
NOTE: APM redundancy is covered by creating redundant VAPs, as described in Configuring VAP Groups on page 45. NPM redundancy is covered by creating redundant interfaces, as described in Configuring Interfaces on page 61 Multi-system redundancy allows one X-Series Platform to be redundant for another, which is accomplished using VRRP, as described in Configuring Multi-System High Availability on page 129.
Overview
CPMs provide physical resources, data, and services to the X-Series Platform, as well as outside management clients. To provide continuous operation of the system in the event of a CPM failure, CP redundancy should be configured between CPMs. The X-Series Platform architecture supports a Primary and a Secondary CPM. Whenever two CPMs are present in the X-Series Platform, the CPMs (and other modules in the system) learn about each others states through periodic heartbeat messages. Either CPM can act as the Primary/Secondary (Active/Standby) CPM from either slot. However, at any given time, the system can have only one Primary CPM. If the Primary CPM detects a catastrophic module failure and crashes; or if the Secondary CPM detects that the Primary CPM is no longer operational, the following occurs:
z z z z z
Secondary CPM forces a hardware reset of the Primary CPM slot. Secondary CPM declares itself as the new Primary CPM. Primary CPM IP address is installed on the control bus IP interface of the Secondary CPM. New Primary CPM sends out a gratuitous ARP message with its own MAC address. New Primary CPM starts all daemons that run on the Primary CPM.
To make the failover virtually transparent to the other modules in the system, the Primary and Secondary CPMs are assigned unique IP addresses on the control network. These addresses are role based, not slot based. This makes the Primary CPM control network IP address the same, independent of the slot where the CPM resides. (This is different than the management interfaces IP address, which is slot-based.) To the APMs and NPMs, the CPM failover looks like a quick CPM reboot.
121
NOTE: When using a Primary/Secondary in the admin state for two CPMs and the Primary CPM is rebooted, the Secondary CPM attempts to become the Primary. During this process, if the Primary finishes rebooting before the Secondary becomes the Primary, the Secondary is put into the single user mode, making it inaccessible and displaying the following message: An error occurred during the file system check. Dropping you to a shell. Use the fsck command ... Use caution when using the Primary/Secondary admin state, and if this scenario occurs, use the commands displayed in the error message to place the Secondary CPM back online. Configure the IP NAT inside and outside settings on each management interface. When configuring for redundancy, make sure that the IP NAT settings are the same for the interfaces on both CPMs.
Heartbeat Driver - Maintains the state of all the modules in the system and implements the Primary CPM election protocol. Two-Port Multiplexor Driver (TPM) - Creates an abstraction of one reliable control network out of two control Ethernets. CPRM (Control Processor Redundancy Management) Daemon (cbscprmd) - Executes the CP redundancy state machine. Disk Mirroring Driver (drbd) - Executes disk mirroring. Shell Scripts - Execute procedures necessary for CP redundancy state transitions.
Backplane EEPROM should be identical on both CPM slots. To check the backplane EEPROMs, use the following command: /usr/os/bin/eepromdiag -c backplane -rs NOTE: Execute this command on both CPMs to ensure that the results are the same.
Valid board EEPROM on both CPMs. To check the board EEPROMs, use the following command: /usr/os/bin/eepromdiag -c board -rs Partition size must be identical on both CPMs. Use the following command to perform the check: cat /proc/partitions
Both CPMs must have identical RAID hard disk drive (HDD) configurations A mix of non-RAID and RAID configurations is not supported in CP redundancy. The mirrored partition sizes on each HDD on both CPMs must be identical. If you add a CPM-8600 to an X-Series Platform with an existing CPM-8600, you must make sure the new CPM-8600 has the same configuration as the original. To configure CP redundancy with RAID, perform a fresh install on each CPM-8600.
122
Unknown The CPM is in an unknown state and may be in the process of booting. If the offline CPM is in an Unknown state for a long period of time, use the cp-unknown-state command to instruct the primary CPM to ignore the offline CPM. Initialization The CPM is in its initial state. Un-synchronized
z z
Occurs when the CPM crashes during re-synchronization of the mirrored disk partitions. After going into this state, the CPRM daemonizes itself and allows normal Linux initialization to complete. Occurs during the repair process, if the Primary CPM crashes.
In both cases, the CPRM waits for another CPM to become the Primary CPM. The CPRM learns about this event from the heartbeat driver. The CPRM on the un-synchronized CPM makes sure the control network interface has the same subnet mask as that of the Primary CPM and reconfigures it if it does not. The CPRM then goes into the Repair state and waits for the connection from the Primary CPM.
z
Repair The Secondary CPM is being synchronized to the Primary CPM. When the CPRM goes into the Repair state it allows Linux initialization to complete. The CPRM then waits for a TCP connection to be established from the Primary CPM. After TCP connection is established, the CPMs exchange information to access what repairs are needed. During synchronization, any commands issued against the CPM are blocked to prevent the disruption of the synchronization process. This includes attempting to execute the following commands:
upgrade reload cpm modules change cp-redundancy setting, including disabling or setting either CPM offline.
Offline The X-Series Platform is operating in the stand-alone CPM state. The CPRM goes into the Offline state either during initialization or when the System Administrator requests it through the CLI. When the CPM is in this state, other system processors ignore it as if the module is not plugged into the chassis. The only XOS subsystem that runs on the CPM in this state is the heartbeat driver, as it needs to communicate the Offline state to the other CPM to avoid the other CPM from causing a reboot. The Offline state is useful in preventing hard drive data corruption when a CPM is accidentally plugged into the wrong chassis or when the System Administrator needs to perform diagnostics or maintenance operations. To return the Offline CPM to another state, the module must be rebooted or plugged into the proper chassis. Primary The Primary CPM runs all software subsystems and replicates all data on mirrored partitions and configuration data on the CPM system partition. At 10 second intervals, the CPRM updates the Persistent State Information (PSI) with a new timestamp. The CPRM, on the Primary CPM, also learns through the heartbeat driver the state of the other CPM. States include: a. b. c. CPM is in the Offline state or not plugged in. This module is ignored. CPM is in the Un-synchronized or Election state. If this persists for the configured timeout (the default value is 60 seconds), the other CPM is reset. CPM is in the Primary state. A major error has occurred. When this occurs there is connectivity to other processing elements and many of them agree that the current primary is correct and that the second CPM is reset. If however, the majority of elements point to the second CPM as the primary, the current primary is reset. If no other processing elements are running, the CPM with a smaller slot number resets the other CPM. CPM is in the Repair state. In this case, the CPRM establishes a TCP connection to the other CPM and exchanges information to determine what repairs are needed. The CPRM then starts data replication once it learns from the other CPM that it is ready to do so. It also informs the other CPM when data replication is complete.
d.
123
e. f.
z
CPM is in the Secondary state. In this case, the CPRM watches the Secondary CPM to determine if it is healthy. The CPRM resets the Secondary CPM if it is found to be unhealthy or failed. CPM is plugged in but does not come up for more than the configured timeout (Default value is 20 minutes). The CPM is reset.
Secondary The CPM is a standby, ready for fail-over state. The CPM in this state maintains a replicated copy of data on mirrored partitions and configuration data on the CPM system partition. At 10 second intervals, the CPRM updates the CP_PSI with a new timestamp. The goal of the Secondary CPM is to determine when the Primary CPM fails or becomes unavailable in another manner. When the CPRM on the Secondary CPM detects such a condition, it resets the Primary CPM and sets the Secondary CPM to the Primary state. This change of the system state is propagated through the heartbeat to other processing elements. The CPM components also learn about the state change from the heartbeat driver and take appropriate component specific actions. In particular, the CPRM instructs the mirroring driver (DRBD) to run in primary mode and mount the corresponding devices. It then assigns a CPM the Primary CPM IP address to a control network interface.
Managing CP Redundancy
For redundancy purposes, each CPM can be administratively configured to the following states:
z z
Election The CPMs determine the correct Primary CPM. Offline A CPM is set to offline for offline work.
125
Operational State: CP1 (this cp) is PRIMARY CP2 (other cp) is REPAIR CP Redundancy is ENABLED Synchronization Status: Disk synchronization is 20% completed NOTE: If the show cp-redundancy command is executed during an In Service Upgrade, the following warning message will be displayed: WARNING: In-Service Upgrade Is in Progress.
To take a CPM out of the offline state, execute the following commands on the Offline CP: CBS# configure cp-redundancy set this_cp election CBS# copy running-config startup-config If there is a Primary CPM in this system, the configuration on the Primary CPM must match the configuration on the other CPM. To ensure this, execute the following command on the Primary CPM: CBS# configure cp-redundancy set other_cp election After executing the previous command, reboot the offline CPM. If the configuration of the CPM being rebooted does not match that of the Primary CPM, the CPM being rebooted comes up in an offline state.
Troubleshooting CP Redundancy
To troubleshoot potential CP redundancy, use the following commands and tools:
z z z
show cp-redundancy command from the CLI Persistent State Information tool (PSI) CPRMD log files located in /usr/os/logs/cbscprmd.log and cbscprmd.log.saved.
To use the PSI tool use the following command: [root@xxxxx /root]# /usr/os/bin/cbspsitool <options> The PSI usage options are: -r, rbcnt <value>. Sets the reboot count to the designated value. -x, xos <ser_num>. Sets the XOS serial number to the designated serial number, which is described in Using the CBS PSI Tool on page 127. -g, debug <level>. Executes the program with debug set to the specified level.
126
-v, version. Displays the version of this program and exits the PSI tool. -h, help. Prints this help message and exits the PSI tool. The PSI.dat file contains the count of successive unsuccessful reboots. If there are excessive reboots, the CPM automatically goes into the Offline state. If this occurs, use the following command to reset the count to zero: /usr/os/bin/cbspsitool -r 0 The /usr/os/logs/cbscprmd.log and cbscprmd.log.saved files contain important CPRM log messages for the current and previous versions of the CPRM daemon, respectively.
127
Limitations
The following lists the management VIP address restrictions:
z z z
The underlying management interface must already be defined and assigned a static IP address. If an active / standby CPM is present, both the primary and the secondary static management IP address must be on the same network as each other. The management VIP address must have the same network as the underlying static management IP address. Although the management VIP address inherits its subnet mask from the static management IP address, the management VIP address itself must be different from the static management IP address. The specified management VIP address must not already be in use:
On another management interface As a hop in the management routing table In the management host table As a management ip-alias
z z
The management VIP address is only used for the management interface, it is not used for any of the other interfaces on the CPM. In a dual-system configuration, the management VIP address cannot be the same as any CPM IP address used in the configure remote-box command.
12
Configuring Multi-System High Availability
This chapter provides information about configuring two or more X-Series platforms in a redundant manner using VRRP and Failover Groups to achieve a Multi-System High Availability configuration. The following topics are covered in this chapter:
z z z z z
VRRP Components on page 129 VRRP Configurations on page 133 Example Dual Box High Availability Configuration on page 143 Example VRRP Configurations on page 144 Configuring VRRP and Automatic ARP for NAT on page 148
You can configure multiple X-Series Platforms for High Availability (HA) using the Virtual Router Redundancy Protocol (VRRP). However, you do not need to configure one chassis as master and another as standby. Instead, create a failover group containing one or more VAP groups and circuits, and create a similar failover group with the same ID on one or more separate chassis. Should one group fail, the counterpart group on another chassis becomes master. For detailed steps to configure an Active-Standby or an Active-Active Dual-box, high availability configuration, refer to the Multi-System High Availability Configuration Guide provided with your XOS documentation.
VRRP Components
The following sections describe the various components used when configuring VRRP.
Failover Group
Failover groups and Virtual Routers (VRs) are used only in High Availability configurations. A failover group is a grouping of one or more VRs. A VR identifies the circuits and associated VAP groups for high availability. Only a failover group, not the entire system or an individual VAP group, can fail over to a backujp failover group on another system. Failover groups operate in pairs, one on each chassis, and are usually assigned different VRRP priorities. The failover group with the higher priority is the master. Each failover group needs a counterpart failover group on another chassis participating in VRRP multi-system redundancy. For example, a failover group on an X-Series Platform may contain the VAP groups and circuits used for a firewall application. The same firewall application and configuration would be on a second X-Series Platform, also contained in a failover group. Both failover groups must have the same group identifier; however, they must have different priority values. The failover group with the higher value assumes Master status. You cannot use two failover groups on the same chassis to back up one another.
129
VRRP Priority
Each failover group is assigned a VRRP priority. The failover group with the higher priority is designated as the Master. All failover groups with the same ID must be configured with different VRRP priorities. A failure within a failover group does not necessarily cause a failover to another chassis. Instead, the VRRP priority is reduced by a pre-configured value, called a priority-delta. This minimizes or eliminates the problem of failing over to a chassis that has an even more diminished capacity. After the failure has been rectified, the VRRP priority returns to its configured value. Each of the following events can be assigned a priority-delta:
z
Failure of an interface that is associated with a monitored VR circuit Examples include a redundant interface, an LACP interface, or a bridge interface. If the chassis has been configured with redundant interfaces, as described in Redundant Interfaces on page 65, an interface failure that causes a failover to a redundant interface in an UP state does not cause the VRRP priority to be decremented.
Unreachable next hop IP address Failure to reach the next-hop IP address is based on the ability of the address to answer ARPs or, for IPv6, neighbor solicitations. The next-hop IP to be verified is configured within the VRRP/virtual-router/ VAP group. If you configure a failover group with a next hop health check and you also configure a monitored circuit with an associated interface, an unreachable next hop caused by a failure of the interface does not cause two decrements of the VRRP priority delta (one for the interface failure and one for the next hop becoming unreachable). The VRRP priority delta is decremented once for the interface failure and XOS prevents two decrements of the VRRP priority for a single cause. NOTE: If you configure redundant interfaces and associate them with a monitored interface, and both the master and backup interfaces fail, the situation is the same as that described in the previous paragraph. If the redundant interface passes a subsequent next hop health check, the VRRP priority is restored to its previous value.
Less than the desired number of active VAPs per VAP group You can configure the minimum number of active VAPs that you require in the VAP group. If the VAP group is configured as part of the failover group, then when the number of VAPs falls below the limit, the VRRP priority of the failover group is decremented.
Interface failure in a monitored circuit. Circuits that connect physical interfaces to VAP groups can be monitored using VRRP. If a failure on the monitored circuit is detected, the priority delta (value) decreases the configured priority (value) of the failover group. If the priority delta drops below the priority of the failover group on the other chassis, the failover group loses its master status, and fails over to the backup. With preemption enabled, after the monitored circuit recovers, the failover group resumes its role as master. NOTE: By default, preemption is OFF to prevent the second failover (with its associated delay) that would restore the original Master Failover Group as Master.
When an event causes a failover, the Interface Redundancy Manager (IRM) daemon deactivates IP addresses in the Master failover group then activates those IP addresses in the backup failover group.
130
VRRP Example
Systems do not have to be configured with identical failover groups. For example, as shown in Figure 7 System A has these failover groups:
z z z z
Failover Group 1 contains the VAP group and circuits used for a firewall and has VRRP priority 150. Failover Group 2 contains the VAP group and circuits used for an intrusion prevention system application and has VRRP priority 150. Failover Group 3 contains the VAP group and circuits used for a URL filtering application and has VRRP priority 100. Failover Group 4 contains the VAP group and circuits used for a web security application and has VRRP priority 100.
System B has:
z z z z
Failover Group 1 contains the VAP group and circuits used for a firewall and has VRRP priority 100. Failover Group 2 contains the VAP group and circuits used for an intrusion prevention system application and has VRRP priority 100. Failover Group 5 contains the VAP group and circuits used for an e-mail security application and has VRRP priority 150. Failover Group 6 contains the VAP group and circuits used for an intrusion detection system application and has VRRP priority 150.
131
System C has:
z z z z
Failover Group 5 contains the VAP group and circuits used for an e-mail security application and has VRRP priority 100. Failover Group 6 contains the VAP group and circuits used for an intrusion detection system application and has VRRP priority 100. Failover Group 3 contains the VAP group and circuits used for a URL filtering application and has VRRP priority 150. Failover Group 4 contains the VAP group and circuits used for a web security application and has VRRP priority 150.
Figure 7.
VRRP Example
System A
System B
System C
Failover Group 1: Firewall Failover Group 2: IPS Failover Group 3: URL Filter Failover Group 4: Web Security
Priority 100
Priority 100 Failover Group 5: E-mail Security Priority 150 Failover Group 6: IDS Priority 150
Layer 2 Switch
In this example, each of the systems hosts two Master failover groups and two backup failover groups. Under normal operating conditions, System A runs the Firewal and IPS applications, System B runs the E-mail Security and IDS applicaitons, and System C runs the URL Filter and Web Security applications.. With all systems running properly, a catastrophic problem with System A causes Failover Groups 1 and 2 to fail over to System B. Similarly, with all systems running properly, a catastrophic failure on System B causes Failover Groups 5 and 6 to fail over to System C. If System A suffers an interface failure within Failover Group 1, reducing its VRRP priority to 125, no failover would occur. If additional failures on System A reduce the VRRP priority of Failover Group 1 below 100, a failover to System B would occur. NOTE: This example shows independent applications, where none of the configurations serialize traffic from one application to another. When traffic is serialized between two applications, such as Firewall and IPS, both applications are placed in the same failover group.
132
VRRP Configurations
There are two basic configurations: Active-Standby and Active-Active. In both configurations, one failover group is Master and the counterpart failover group is in backup mode. With Active-Standby, the failover group on one chassis passes traffic while the backup group on the other chassis does not. With Active-Active, the Master failover group on each chassis passes traffic. The corresponding failover groups on each chassis are in backup mode. To achieve an Active-Active configuration, attach one circuit to two VRs, where each VR is in a different failover group. The basic configuration, as shown in Figure 8, includes:
z
Failover Group 1:
On System A, this failover group has a VR attached to a circuit connected to a VAP group. Since the circuit does not have an IP address assigned, the VR assigns a primary IP address. On System B, the failover group has a VR with the same configuration; however, the VR assigns a virtual IP address, which is the same as the primary IP address on System As VR. The failover group on System A is given a higher VRRP priority than System Bs failover group. Thus System As failover group is initially the Master. On System B, this failover group has a VR attached to a circuit connected to a VAP group. Since the circuit does not have an IP address assigned, the VR assigns a primary IP address. On System A, the failover group has a VR with the same configuration; however, the VR assigns a virtual IP address, which is the same as the primary IP address on System Bs VR. The failover group on System B is given a higher VRRP priority than System As failover group. Thus System Bs failover group is Master.
Failover Group 2:
In this configuration, each Master group has a unique IP address; thus, traffic can flow to both addresses. Should one group fail, the failover group on the other chassis automatically handles all traffic going to both addresses. Should the circuit be configured with an IP address in this configuration, both VRs would assign virtual addresses instead of one VR assigning a primary address.
Figure 8.
133
Which X-Series Platforms are to be involved What applications or configurations require redundancy Definition of each failover group Which X-Series Platform will host the master failover group, and which will host the bacup failover group
Next, perform the following steps, described in the subsequent sections: 1. 2. 3. Physically cable and configure the High Availability ports. Create failover groups. Configure VRRP on the VAP groups.
IMPORTANT: Each X-Series Platform must have a unique identifier to be in a VRRP configuration, which is set with the configure system-identifier <system-id> command. NOTE: A VRRP Virtual Router (VR) configuration can have only one VAP group assigned. A VAP group is assigned to a VR using the vrrp virtual-router vrrp-id <id> vap-group <name> command. During the XOS upgrade you will be prompted to change your configuration. If you do not make this change, the system keeps only the first vap-group and issues a warning message.
In a dual-system configuration, the High Availability ports can be connected directly to each other or can be connected using a switch. For 3 or more systems, the High Availability ports are connected to a switch as shown in Figure 7 on page 132. If you have CP redundancy, you can connect all four High Availability ports (2 chassis, with primary and secondary CPMs on each chassis) into a single switch. This allows physical connectivity between the two primary CPMs, one in each chassis. Should a primary CPM fail in one chassis, the backup CPM will still be able to communicate with the remote chassis. To prevent packet loops, the secondary CPM automatically drops all packets coming into its High Availability port.
Figure 9.
134
Link Qual 0 0
135
For the High Availability port, specify the internal ip address (1.1.46.20) associated with the remote Primary CPM (obtained by running show-internal-ip on the remote chassis). For the management ports, specify the external IP addresses associated with the ports. Ideally, specify all three addresses associated with the remote primary CPM and the two management addresses associated with the remote secondary CPM. Crossbeam recommends that you connect the CPMs using separate network broadcast domains for each type of port (the HA ports, the Management 1 ports, and the Management 2 ports) on both the Primary CPMs and the Secondary CPMs. Connecting the ports directly can lead to scenarios that do not provide full redundancy.
CBS# configure remote-box 46 10.10.46.20 192.168.50.46 192.168.51.56 CBS(conf-remote-box)# end NOTE: The example configure remote-box command specifies only the IP addresses of the management 1 and 2 interfaces for the primary CPM on chassis 2. Crossbeam recommends that you connect the management interfaces of the other CPM on Chassis 2 and that you add the IP addresses for those interfaces to the configure remote-box command.
136
1.
At the Top-level menu, enter: bridge multicastFilter routerPort addPort Select router unit (1):
2. 3.
Enter the unit number (1). The following prompt is displayed: Select router port (1-48): Enter the desired router port number.
Syntax: advertise-interval <seconds> Command: CBS(conf-vrrp-group)# advertise-interval 30 CBS(conf-vrrp-group)# 5. Configure preemption to specify how you want VRRP to function on failure. When preemtion is enabled, failure of the master failover group causes traffic to be re-routed to the backup failover group (which then becomes Master). The original Master resumes Master status when it becomes available. When disabled (using no), upon failure of the master failover group, the backup failover group services traffic. The original Master does not resume being Master when it becomes available, unless the backup fails. NOTE: By default, preemption is OFF to prevent the second failover (with its associated delay) that would restore the original Master Failover Group as Master. The examples in this chapter do not enable preemption. 6. Determine which circuits to monitor and set a priority-delta for each circuit. A monitored circuit can affect the failover group VRRP priority; however, monitored circuits (usually a physical interface) do not fail over when VRRP switches to a backup failover group. The priority-delta decrements the failover group VRRP priority whenever an interface on the monitored circuit fails. In this example, physical interfaces are given a priority-delta of 30. When an interface failure occurs, the priority value (150) is decremented by the priority-delta (30) to 120. Since this is not less than 100 (priority on Chassis B), failover will not occur until more than one circuit has failed. Only then does the failover group on Chassis B becomes the master. The priority-delta is added back to the priority when the interface returns to the Up state.The priority-delta can be 0 to 255. Default is 1. Syntax: monitor-circuit <circuit_name> priority-delta <0-255> Command: CBS(conf-vrrp-group)# monitor-circuit lan02 CBS(conf-vrrp-failover-cct)# priority-delta 30 CBS(conf-vrrp-failover-cct)# exit CBS(conf-vrrp-group)# monitor-circuit lan03 CBS(conf-vrrp-failover-cct)# priority-delta 30 CBS(conf-vrrp-failover-cct)# exit CBS(conf-vrrp-group)# monitor-circuit lan04 CBS(conf-vrrp-failover-cct)# priority-delta 30 CBS(conf-vrrp-failover-cct)# exit CBS(conf-vrrp-group)# NOTE: If your system incorporates group interfaces, use the monitor-group-interfaces parameter in this context to set a priority delta. Additionally, you can set a minimum number of ports (in the group interface) using the dist-port-threshold parameter to monitor. If the number of ports in that state falls below this threshold, the priority delta value is subtracted from failover group priority. See the XOS Command Reference Guide for specific command information. 7. Create a Virtual Router, assign an ID, and attach it to an existing circuit. If more than one VR is attached to the same circuit, each VR must have a unique ID. Syntax: virtual-router vrrp-id <1-4096> circuit <circuit_name> Command: CBS(conf-vrrp-group)# virtual-router vrrp-id 101 circuit v101 CBS(conf-vrrp-failover-vr)# a. If you require the VR circuit interface to remain in an UP state when the failover group is in backup mode, use the backup-stay-up command. The circuit does not send or receive traffic while in the backup state. CBS(conf-vrrp-failover-vr)# backup-stay-up
Configuring Multi-System High Availability 138
NOTE: In a VSX configuration, VSX automatically enables backup-stay-up for all VLAN interfaces that are part of a VRRP group. b. Assign a MAC address to the VRRP circuit. Use the vrrp-mac feature to automatically generate a unique vrrp-mac. In the event of a failover, the MAC address moves with the virtual IP address to the new chassis. By keeping the MAC address consistent, it reduces the time it takes for upstream routers to converge routing tables. Alternatively, use interface (default) to use the MAC address configured on the physical interface. Syntax: mac-usage {vrrp-mac|interface} Command: CBS(conf-vrrp-failover-vr)# mac-usage vrrp-mac c. Assign a priority-delta to the VR. In this serialized topology, each virtual router is given a priority-delta of 55. When a VR fails, the failover groups VRRP priority of 150 is decremented by the priority-delta value of 55 to a new priority value of 95. Since this is less than 100 (the priority on Chassis B), the failover group on Chassis B becomes the master. The priority-delta is added back to the priority when the VR recovers. Syntax: priority-delta <1-255> Command: CBS(conf-vrrp-failover-vr)# priority-delta 55 CBS(conf-vrrp-failover-vr)# d. Assign a VAP group to the VR. Specifying the VAP group of the VR allows you to assign a virtual IP address to the VAP group. The circuit must already be mapped to the VAP group with the configure circuit <name> vap-group <name> command. Syntax: vap-group <vap-group-name> Command: CBS(conf-vrrp-failover-vr)# vap-group fw CBS(conf-vrrp-vr-vapgroup)# exit CBS(conf-vrrp-failover-vr)# e. Assign a unique IP address to the virtual router only when its circuit is NOT configured with an IP address. This address is considered to be the primary address. The no parameter deletes the IP address. Syntax: ip {<ip-addr> <netmask>|<ip-addr/netmask>} [<broadcast-ip-addr>] [increment-per-vap <ip-addr>] This command assigns the fw VAP group to the virtual router and an IP address of 172.16.20.103 with a mask of 24 in CIDR format. Command: CBS(conf-vrrp-failover-vr)# vap-group fw CBS(conf-vrrp-vr-vapgroup)# ip 172.16.20.103/24 CBS(conf-vrrp-vr-vapgroup)# f. If the circuit already has an assigned IP address, assign a virtual IP address as follows. Note that the number of virtual IP addresses assigned to an IP address is limited to 99. NOTE: Use the same format to assign virtual IPv6 addresses. Syntax: virtual-ip {<ip-addr> <netmask>|<ip-addr/netmask>} [<broadcast-ip-addr>] [increment-per-vap <ip-addr>]}
139
Command: CBS(conf-vrrp-vr-vapgroup)# virtual-ip 10.0.101.1/24 CBS(conf-vrrp-vr-vapgroup)# exit The optional floating parameter assigns the virtual IP address to the master VAP, allowing traffic, cluster management, and synchronization communication to go directly to the master VAP. If a new master VAP is elected, the address floats (is assigned) to the new master. In a VRRP configuration, the floating parameter assigns the virtual IP address to the master VAP on the new master chassis in the event of a failover. g. Configure a next hop health check and a priority-delta. The next hop health check is an optional setting to verify IP connectivity to the next hop gateway. In this example, the gateway is given a priority-delta of 55. If the next hop health check fails, the failover group VRRP priority of 150 is decremented by the priority-delta value of 55 to a new priority value of 95. Since this is less than 100 (the priority on Chassis B), the failover group on Chassis B becomes the master. The priority-delta is added back to the priority when the interface recovers. Specify the IP address of an external host (external to the X-Series Platform). The IP address 10.10.101.20 is used here as an example. Using exit twice returns you to the correct CLI context to repeat the VR configuration process. NOTE: An IP route whose next-hop destination network is exactly the same (same network and netmask) as the circuit's or virtual circuit's network is considered to be invalid. If you try and set such a next hop destination, an error message is displayed. Command: CBS(conf-vrrp-vr-vapgroup)# verify-next-hop-ip 10.10.101.20 CBS(conf-vrrp-vr-verify-next-hop)# priority delta 55 CBS(conf-vrrp-vr-verify-next-hop)# exit CBS(conf-vrrp-vr-vapgroup)# exit CBS(conf-vrrp-group)# h. 8. Repeat Step 6, a through g, to add additional VRs to the failover group. Note that each VR can be assigned to only one VAP group.
4.
Optionally, set the active VAP threshold and return to the main CLI context. The active-vap-threshold monitors the number of active VAPs in the VAP group. If the number of active VAPs drops below the threshold, the failover groups priority value is decremented by the priority-delta (defined in Step 5) and a comparison is done between the priorities of the failover groups on the two chassis. Failover occurs when the priority-delta decrements the priority value of the master failover group below the priority value of the backup group. CBS(conf-vrrp vap-group)# active-vap-threshold 3 CBS(conf-vrrp vap-group)# end CBS#
5.
Set the priority-delta value for the VAP group (optional). Assign a priority-delta to the VAP group. VRRP decrements the priority of the failover group whenever the number of active VAPs falls below the active-vap-threshold. The priority-delta value can be any number between 1 and 255 and the default value is 1. When the VAP returns to the Active state, the priority-delta value is added back to the priority value. CBS(conf-vrrp-vap-group)# priority-delta 60 CBS(conf-vrrp-vap-group)#
141
Figure 10.
You can also view the status of VRRP components and connections using the following XOS CLI commands:
z z z
show vrrp status [<failover_group_id>] show vrrp detail-status [<failover_group_name>] show remote-box
See View VRRP Status on page 178 for details on using these commands. Also, see the XOS Command Reference Guide for all information regarding usage, options, and syntax for these commands.
142
143
Simple Configuration
The following is a simple example of two chassis in an active-active configuration: System A vrrp failover-group firewall failover-group-id 1 priority 101 monitor-circuit firewall virtual-router vrrp-id 100 circuit gig21 vap-group fw virtual-ip 192.250.10.100/24 192.250.10.255 virtual-router vrrp-id 101 circuit gig22 vap-group fw virtual-ip 192.251.10.100/24 192.251.10.255 vrrp failover-group ips failover-group-id 2 priority 201 virtual-router vrrp-id 200 circuit gig31 vap-group ips virtual-ip 192.150.10.100/24 192.150.10.255 virtual-router vrrp-id 201 circuit gig32 vap-group ips virtual-ip 192.151.10.100/24 192.151.10.255 # vrrp vap-group fw priority-delta 2 active-vap-threshold 3 # vrrp vap-group ips priority-delta 2 active-vap-threshold 3 System B vrrp failover-group firewall failover-group-id 1 priority 201 virtual-router vrrp-id 100 circuit gig11 vap-group fw virtual-ip 192.250.10.100/24 192.250.10.255 virtual-router vrrp-id 101 circuit gig12 vap-group fw virtual-ip 192.251.10.100/24 192.251.10.255 vrrp failover-group ips failover-group-id 2 priority 101 virtual-router vrrp-id 200 circuit gig31 vap-group ips virtual-ip 192.150.10.100/24 192.150.10.255 virtual-router vrrp-id 201 circuit gig32 vap-group ips virtual-ip 192.151.10.100/24 192.151.10.255
Configuring Multi-System High Availability 144
Complex Configuration
The following is a example of two chassis in an Active-Standby configuration with VLANs.
Figure 11.
System A vap-group fw xslinux_v3 # circuit inside3 circuit-id 1025 device-name inside3 vap-group fw default-egress-vlan-tag 3 hide-vlan-header ip 192.168.1.10/24 192.168.1.255 circuit inside4 circuit-id 1026 device-name inside4 vap-group fw default-egress-vlan-tag 4 hide-vlan-header
145
ip 4.4.4.10/24 4.4.4.255 circuit outside5 circuit-id 1027 device-name outside5 vap-group fw default-egress-vlan-tag 5 hide-vlan-header ip 5.5.5.10/24 5.5.5.255 circuit outside6 circuit-id 1028 device-name outside6 vap-group fw default-egress-vlan-tag 6 hide-vlan-header ip 10.10.1.10/24 10.10.1.255 interface gigabitethernet 1/1 logical inside3 ingress-vlan-tag 3 3 circuit inside3 logical inside4 ingress-vlan-tag 4 4 circuit inside4 interface gigabitethernet 1/2 logical outside5 ingress-vlan-tag 5 5 circuit outside5 logical outside6 ingress-vlan-tag 6 6 circuit outside6 vrrp failover-group left failover-group-id 1 priority 200 monitor-circuit inside3 priority-delta 10 monitor-circuit inside4 priority-delta 10 monitor-circuit outside5 priority-delta 10 monitor-circuit outside6 priority-delta 10 virtual-router vrrp-id 103 circuit inside3 priority-delta 20 mac-usage vrrp-mac vap-group fw virtual-ip 192.168.1.50/24 192.168.1.255 virtual-router vrrp-id 104 circuit inside4 priority-delta 20 mac-usage vrrp-mac vap-group fw virtual-ip 4.4.4.50/24 4.4.4.255 virtual-router vrrp-id 105 circuit outside5 priority-delta 20 mac-usage vrrp-mac vap-group fw virtual-ip 5.5.5.50/24 5.5.5.255 virtual-router vrrp-id 106 circuit outside6 priority-delta 20 mac-usage vrrp-mac vap-group fw virtual-ip 10.10.1.50/24 10.10.1.255 # vrrp vap-group fw priority-delta 20 active-vap-threshold 3 System B vap-group fw xslinux_v3
146
# circuit inside3 circuit-id 1025 device-name inside3 vap-group fw default-egress-vlan-tag 3 hide-vlan-header ip 192.168.1.11/24 192.168.1.255 circuit inside4 circuit-id 1026 device-name inside4 vap-group fw default-egress-vlan-tag 4 hide-vlan-header ip 4.4.4.11/24 4.4.4.255 circuit outside5 circuit-id 1027 device-name outside5 vap-group fw default-egress-vlan-tag 5 hide-vlan-header ip 5.5.5.11/24 5.5.5.255 circuit outside6 circuit-id 1028 device-name outside6 vap-group fw default-egress-vlan-tag 6 hide-vlan-header ip 10.10.1.11/24 10.10.1.255 interface gigabitethernet 1/1 logical inside3 ingress-vlan-tag 3 3 circuit inside3 logical inside4 ingress-vlan-tag 4 4 circuit inside4 interface gigabitethernet 1/2 logical outside5 ingress-vlan-tag 5 5 circuit outside5 logical outside6 ingress-vlan-tag 6 6 circuit outside6 vrrp failover-group right failover-group-id 1 priority 190 monitor-circuit inside3 priority-delta 10 monitor-circuit inside4 priority-delta 10 monitor-circuit outside5 priority-delta 10 monitor-circuit outside6 priority-delta 10 virtual-router vrrp-id 103 circuit inside3 priority-delta 20 mac-usage vrrp-mac vap-group fw virtual-ip 192.168.1.50/24 192.168.1.255 virtual-router vrrp-id 104 circuit inside4 priority-delta 20 mac-usage vrrp-mac vap-group fw virtual-ip 4.4.4.50/24 4.4.4.255 virtual-router vrrp-id 105 circuit outside5 priority-delta 20 mac-usage vrrp-mac vap-group fw virtual-ip 5.5.5.50/24 5.5.5.255 virtual-router vrrp-id 106 circuit outside6 priority-delta 20
147
mac-usage vrrp-mac vap-group fw virtual-ip 10.10.1.50/24 10.10.1.255 # vrrp vap-group fw priority-delta 20 active-vap-threshold 3
148
VRRP Configuration
To prevent the VRRP backup circuit from responding to automatic ARP requests, legacy style VRRP should be used. Legacy VRRP uses the IP address at the circuit level. There is no concept of virtual and interface level IP addresses; only the virtual IP (VIP) address. When the circuit is in backup, the VND remains down, not populating the routing table or responding to ARP/IP requests. The user also has the option of configuring both a circuit level IP address and a VIP. However, in this scenario the circuit level ip address should not be defined, nor should the VRRP backup-stay-up command be used. When configuring legacy VRRP the IP is no longer defined at the circuit level, but at the VRRP VAP group level as an IP address (not a virtual-ip.). virtual-router vrrp-id 2 circuit outside vap-group fw ip 192.168.102.1/24 192.168.102.255 After the legacy VRRP option has been defined, allowing the addition of more IP addresses, you can create more VRRP failover groups and define additional virtual-ip addresses. Both the legacy and virtual (sub interface) circuits will remain down when VRRP is in backup. From the CLI: vrrp failover-group fw failover-group-id 1 virtual-router vrrp-id 2 circuit outside vap-group fw ip 192.168.102.1/24 192.168.102.255 vrrp failover-group fw2 failover-group-id 2 virtual-router vrrp-id 3 circuit outside vap-group fw virtual-ip 192.168.102.2/24 192.168.102.255 One drawback to this type of configuration is not being able to use the VRRP next hop health check. VRRP next hop health check uses the circuit level IP address to check the availability of a pre-configured gateway. If the IP address is not reachable, a priority-delta is deducted.
149
150
13
Configuring Secure Flow Processing
You can configure the X-Series system to run multiple applications in series and in parallel. This chapter includes the following major topics:
z z z z z
What Is Secure Flow Processing on page 151 Serial Traffic and Circuits on page 151 Managing Serialized VAPs on page 153 Secure Flow Processing on Layer 3 on page 154 Parallel Traffic Flow on page 156
The ability to move traffic / data between VAP groups within the X-Series Platform. There is no requirement of a physical interface to pass traffic between the APMs. Once IP traffic has been classified by the NPM, serialized traffic uses the speed of the data plane to move between APMs; it is not limited to the speed of the physical interface.
Serialization provides the ability to configure and link multiple VAP groups running different applications. These specific applications are linked in series, allowing traffic to be inspected by each application. Multiple VAP groups are created (one per application) with circuits configured between the VAP groups. Traffic is passed from one VAP to the next, allowing for multi-layered, in-depth inspection by best-of-breed security applications within a single device. Previous versions of XOS that supported serialization were restricted to certain applications working on a Layer 3 routing level. XOS provides numerous enhancements to allow secure flow processing by bridging Layer 2 applications linked to Layer 3 applications. For detailed serialization configuration information, refer to the Multi-Application Serialization Configuration Guide.
151
IPv6 addressing is supported on serialized configurations, with an IPv6-enabled VAP group. This configuration can include VLANs and virtual IP addresses. IPv6 is not supported on the management network.
LAN (on the client subnet side) Br1 (the layer two bridge) Ser1 (the serial circuit between the VAP groups) WAN (connected to an external network) Br1 (bridge-mode transparent) LAN (physical interface) WAN (physical interface) Interface-Internal (the interface that connects the circuit internally to the VAP groups and the bridge)
2. 3.
Configure Interfaces
152
A sample Layer 2 to Layer 3 serialization configuration: circuit LAN device-name LAN vap-group IPS promiscuous-mode active circuit Br1 device-name Br1 vap-group IPS circuit Ser1 device-name Ser1 vap-group IPS promiscuous-mode active vap-group FW circuit WAN device-name WAN vap-group FW ip 172.16.20.7/24 # bridge-mode Br1 transparent circuit LAN circuit Ser1 # interface gigabitethernet 1/1 logical LAN circuit LAN interface gigabitethernet 2/1 logical WAN circuit WAN interface-internal Br1 logical-all Ser1 circuit Ser1
153
Figure 12.
1.
Create individual VAP groups. vap-group L3_VAP_1 vap-count 2 max-load-count 2 ap-list ap1 ap2 ip-flow-rule L3_default action load-balance activate # vap-group L3_VAP_2 vap-count 1 max-load-count 1 ap-list ap3 ip-flow-rule L3_default_2 action load-balance activate #
2.
Create a circuit for incoming traffic. circuit incoming device-name incoming vap-group L3_VAP_1 ip 10.0.0.1/24
154
3.
Create a circuit between VAP groups, and associate the circuit with both VAP groups. circuit l2l3 device-name l2l3 vap-group L3_VAP_1 ip 5.5.5.1/24 vap-group L3_VAP_2 ip 5.5.5.2/24
4.
Create a circuit for outgoing traffic, and associate it with the VAP group it will be leaving through. circuit outside device-name outside vap-group L3_VAP_2 ip 20.0.0.1/24
5.
Define an interface-internal and assign the serial circuit l2l3. interface-internal l2l3 logical-all l2l3 circuit l2l3
6.
Configure the route between VAPS config ip route 20.0.0.1/24 ip 5.5.5.2 vap-group L3_VAP_1 config ip route 10.0.0.1/24 ip 5.5.5.1 vap-group L3_VAP_2
7.
Create and configure management circuit. circuit mgmt device-name mgmt vap-group L3_VAP_1 ip 192.168.0.1/24 increment-per-vap 192.168.0.3 vap-group L3_VAP_2 ip 192.168.0.6/24 increment-per-vap 192.168.0.8
8.
Create the interfaces for each circuit. interface gigabitethernet 1/1 logical incoming circuit incoming interface gigabitethernet 2/1 logical outside circuit outside interface gigabitethernet 1/8 logical management circuit mgmt This will create a unique IP address on each VAP in the group, which is required for a management circuit. The circuit must have the increment-per-vap parameter, even if the VAP group contains only one VAP. Once the VAP groups, circuits, management circuits, and all interfaces are configured, you can install the applications on each VAP. Refer to your application documentation for installation information.
155
Figure 13.
1.
First, create individual VAP groups. vap-group L3_FW vap-count 2 max-load-count 2 ap-list ap1 ap2 load-balance-vap-list 4 5 6 7 8 9 10 1 2 3 ip-flow-rule L3_default action load-balance activate # vap-group IDS_VAP vap-count 1 max-load-count 1 ap-list ap3 load-balance-vap-list 4 5 6 7 8 9 10 1 2 3 ip-flow-rule L3_default_2 action load-balance activate #
156
2.
Next create a circuit for incoming traffic. circuit incoming device-name incoming
3.
The following example assigns a circuit to two VAP groups to parallelize traffic. Traffic coming into the circuit goes to both VAP groups simultaneously. configure circuit incoming vap-group L3_FW ip 10.10.10.20/24 vap-group IDS_VAP promiscuous-mode
4.
Create a circuit for outgoing traffic, and associate it with the VAP group it will be leaving through. circuit outgoing device-name outgoing vap-group L3_FW ip 5.5.5.15/24
5.
Create and configure management circuit. circuit mgmt device-name mgmt vap-group L3_FW ip 192.168.0.1/24 increment-per-vap 192.168.0.3 vap-group IDS_VAP ip 192.168.0.6/24 increment-per-vap 192.168.0.8
6.
Associate virtual circuits with physical interfaces. Interface gigabit 1/1 logical incoming circuit incoming interface gigabit 1/2 logical outgoing circuit outgoing interface gigabit 1/3 logical mgmt circuit mgmt
7.
Once the VAP groups, circuits, and management circuits are configured, you can install the applications on each VAP. Refer to your application documentation for installation information.
157
158
14
Configuring RMON and SNMP Traps
The X-Series Platform supports Remote Monitoring (RMON) Event and Alarm groups. You can configure Remote Monitoring (RMON) and simple network management protocol (SNMP) to monitor your X-Series Platform. Use RMON for industry-standard management information base (MIB) entries and use SNMP traps to implement Crossbeam MIB entries for system monitoring. The following topics are covered in this chapter:
z z z z z z z z z z z z
System Owned RMON Alarms and Events on page 159 Configuring RMON Events on page 160 Configuring RMON Alarms on page 160 Displaying RMON Alarms, Events, and Logs on page 161 Displaying Disk Monitoring Event and Alarm Entries on page 162 Configuring Simple Network Management Protocol (SNMP) on page 163 Supported SNMP Traps on page 164 SNMP Traps and Informs on page 164 Configuring Trap Destinations on page 165 Displaying the SNMP Trap Log on page 165 SNMP MIB Dependencies on page 166 Allowing SNMPv3 User Access on page 167
Refer to Crossbeam SNMP MIB Reference on page 267 for a comprehensive guide to Crossbeam MIB entries and their corresponding object identifiers (OIDs).
Configuring RMON
NOTE: RMON configuration is not supported on an offline CPM.
159
Use the event action types to configure the RMON Alarm entries, and dictate the action taken by the RMON agent when an alarm entry crosses its configured threshold. After you configure RMON, save the configuration settings with copy running-config start-config so that the configuration persists across system restarts. To configure the RMON event action type, use the following commands: configure rmon event 1 trap <community-string> description trap only configure rmon event 2 log description log only owner <name> configure rmon event 3 log trap <community-string> description log and trap For example: CBS# configure rmon event 1 trap public description "trap only" CBS# configure rmon event 2 log description "log only" owner user1 CBS# configure rmon event 3 log trap public description "log and trap" NOTE: The community string cannot contain whitespace characters (space or tab).
SNMP variable Sampling interval Delta vs. absolute value Rising and falling threshold values Rising and falling event entries Optionally the owner for the entry
To configure RMON alarms, use the following command: configure rmon alarm <number> <variable> <interval> {delta|absolute} rising-threshold <value> [<event-number>] falling-threshold <value> [<event-number>] [owner <owner>] For example: CBS# configure rmon alarm 1 ifEntry.ifInOctets.1 10 absolute rising-threshold 80 3 falling-threshold 60 3 owner user1 CBS# configure rmon alarm 2 ifOutUcastPkts.1 10 delta rising-threshold 80 3 falling-threshold 60 3 owner user1
160
CBS# show rmon alarms Alarm No. : 65000 Interval (secs) : 60 Variable : .1.3.6.1.4.1.2021.9.1.9.1 Sample Type : Absolute Value : 28 Startup : rising Rising Threshold : 70 Falling Threshold : 60 Rising Event : 65000 Falling Event : 65001 Owner : system Entry Status : valid Alarm No. Interval (secs) Variable Sample Type Value Startup Rising Threshold Falling Threshold Rising Event Falling Event Owner Entry Status Alarm No. Interval (secs) Variable Sample Type Value Startup Rising Threshold Falling Threshold Rising Event Falling Event Owner Entry Status : : : : : : : : : : : : : : : : : : : : : : : : 65001 60 .1.3.6.1.4.1.2021.9.1.9.2 Absolute 26 rising 70 60 65000 65001 system valid 65002 60 .1.3.6.1.4.1.2021.9.1.9.3 Absolute 29 rising 70 60 65000 65001 system valid
161
Alarm No. : 65003 Interval (secs) : 60 Variable : .1.3.6.1.4.1.2021.9.1.9.4 Sample Type : Absolute Value : 17 Startup : rising Rising Threshold : 70 Falling Threshold : 60 Rising Event : 65000 Falling Event : 65001 Owner : system Entry Status : valid (4 rows) CBS# show rmon events Event Number : 65000 Event Type : Log_n_trap Community : Last Time Sent : 00:00 Owner : system Description : Disk Usage Crossed Upper Threshold Event Number Event Type Community Last Time Sent Owner Description (2 rows) : : : : : : 65001 Log_n_trap 00:00 system Disk Usage Crossed Lower Threshold
The X-Series Platform also monitors the dskPercent for these four partitions using system owned RMON alarm entries. dskTable.dskEntry.dskPercent.1 dskTable.dskEntry.dskPercent.2 dskTable.dskEntry.dskPercent.3 dskTable.dskEntry.dskPercent.4 You can display RMON alarms and events, as described in Displaying RMON Alarms, Events, and Logs on page 161.
162
Table 17.
Parameter
<community_string>
<IP_address>
Configures the SNMP community to include the SNMP agent on the X-Series Platform (the SNMP server) and the single SNMP management station (SNMP client) with the specified IP address. Configures the SNMP community to include the SNMP agent on the X-Series Platform (the SNMP server), and the SNMP management station within the specified IP address range. You can specify the IP network and subnet mask address in CIDR format (for example, 10.15.0.0/16), or non-CIDR format (for example, 10.16.0.0 255.255.0.0).
163
SNMP Traps and Informs on page 164 Supported SNMP Traps on page 164 Configuring Trap Destinations on page 165 Displaying the SNMP Trap Log on page 165 SNMP MIB Dependencies on page 166 Allowing SNMPv3 User Access on page 167
Refer to Crossbeam SNMP MIB Reference on page 267 for a list of Crossbeam-specific MIB entries and their corresponding object identifiers (OIDs). Refer to SNMP MIB Dependencies on page 166 for a list of the SNMP MIB dependencies and compile orders required by some SNMP applications. Refer to the SNMP application documentation for specific requirements.
Cold and warm starts. Chassis temperature exceeded/normal - indicates the chassis temperature status, as measured at the upper fan tray. This is indicated as normal or exceeded. System alarm state - indicates the highest current alarm state of the X-Series Platform. Module temperature exceeded/normal - indicates the module temperature status as normal or exceeded. Module insert/remove - indicates that a module has been removed or inserted in the XOS backplane. Module state changes - indicates the various states of each module in the X-Series Platform. Valid states include: unavailable, down, initializing, up, standby, and bootwait. CPU load exceeded/normal - indicates the CPU load of the processor modules and indicates whether the CPU is seeing normal or excessive loads. This is the current value of the one minute load on the CPU module that is experiencing normal or excessive loads. Link State - indicates the operational state (up or down) of the control link. Power supply failed/recovered - indicates that a redundant power supply has either failed or been replaced. Power supply feed failed/recovered - indicates that a redundant power supply feed has either failed or become operational. Fan tray insert/remove - indicates that a fan tray has been removed or inserted in the X-Series Platform.
164
z z z z
z z z z z z z z
Fan failed and recovered - indicates the various states of each fan in the fan trays. Voltage - Indicates whether CPU and Module voltages are within or exceeding normal ranges. Module Memory Usage - indicates memory usage per module. CPU Utilization - indicates usage of all cores on the specified module. CPU Core Utilization - indicates percentage of total use of CPU core, per core, on a specified module. CPU core utilization can be tracked for APMs and CPMs. NPM Flow Table Usage - indicates total flow table usage. NPM Flow Table Protocol - indicates the flow table limit status (exceeded / met / normal) of flows by protocol. Protocols include TCP, UDP, ICMP, and Other. Module SDRAM check
The SNMP Host IP Address Specify the SNMP Version (V1 or V2c) Notification Type (traps or informs) Community String to identify the trap.
To configure a trap destination, use the following command: configure snmp-server host <host_ip_addr> [traps|informs] [version 1|2c] <community-string> [udp-port <port-number>] NOTE: The community string cannot contain whitespace characters (space or tab). For example: configure snmp-server host 10.1.1.29 traps version 1 private configure snmp-server host 10.1.1.29 informs version 2c public To delete a host, use: configure no snmp-server host <host_ip_addr> <community-string> NOTE: If the host that you wish to delete currently receives informs, you must specify the informs parameter with this command.
165
Trap Description Trap OID sysUpTime Time & Date Num of variables Variable 1 Variable 2 Other Variables
: : : : : : : :
NOTE: The sysUpTime value is the time accumulated since the SNMP agent was configured.
SNMPv2-SMI: root SNMPv2-TC: SNMPv2-SMI SNMPv2-CONF: SNMPv2-SMI SNMPv2-MIB: SNMPv2-SMI, SNMPv2-TC, SNMPv2-CONF IANAifType-MIB: SNMPv2-SMI, SNMPv2-TC IF-MIB: SNMPv2-SMI, SNMPv2-TC, SNMPv2-CONF, SNMPv2-MIB, IANAifType-MIB INET-ADDRESS-MIB: SNMPv2-SMI, SNMPv2-TC HOST-RESOURCES-MIB: SNMPv2-SMI, SNMPv2-TC, SNMPv2-CONF, IF-MIB
CROSSBEAM-SYSTEMS-MIB: SNMPv2-SMI CBS-HARDWARE-MIB: SNMPv2-SMI, SNMPv2-TC, HOST-RESOURCES-MIB, CROSSBEAM-SYSTEMS-MIB CBS-MODULE-RESOURCES-MIB: SNMPv2-SMI, SNMPv2-TC, HOST-RESOURCES-MIB, CROSSBEAM-SYSTEMS-MIB, CBS-HARDWARE-MIB CBS-VAPGROUP-MIB: SNMPv2-SMI, SNMPv2-TC, HOST-RESOURCES-MIB, CROSSBEAM-SYSTEMS-MIB, CBS-HARDWARE-MIB CBS-VRRP-MIB: SNMPv2-SMI, SNMPv2-TC, HOST-RESOURCES-MIB, CROSSBEAM-SYSTEMS-MIB, CBS-HARDWARE-MIB, INET-ADDRESS-MIB, CBS-VAPGROUP-MIB
Compile order based upon above dependencies (items on same line may be compiled in any order): 1. 2. 3. 4. 5. 6. 7. 8. SNMPv2-SMI SNMPv2-TC, SNMPv2-CONF, CROSSBEAM-SYSTEMS-MIB SNMPv2-MIB, IANAifType-MIB, INET-ADDRESS-MIB IF-MIB HOST-RESOURCES-MIB CBS-HARDWARE-MIB CBS-MODULE-RESOURCES-MIB, CBS-VAPGROUP-MIB CBS-VRRP-MIB
166
numeric oids, such as .1.3.6.1 fully qualified oid names, such as .iso.org.dod names directly under mib-2, such as system, interfaces, at, and ip
167
168
15
Using UNIX Commands on VAP Groups and Upgrading Applications
This chapter describes the UNIX commands used on all VAPs within a VAP group. It contains the following major topics:
z z
Executing UNIX Commands on a Designated VAP on page 169 Executing UNIX Commands on All VAPs on page 170
The /usr/os/bin/cbs_rsh tool can be used to execute any interactive UNIX command on all available VAPs in a VAP group or on a particular VAP within a VAP group.
169
Table 18.
Copying a File from the CPM to all the VAPs in a VAP Group
To copy a file from the CPM to all the VAPs within a VAP group, use the cbs_cp command at the VAP group prompt. The following example copies the file SomeFile to the VAPs in the FW VAP group. 1. Issue the cbs_rsh command with the desired VAP group (FW in our example) to access the VAP group prompt. Help for the cbs_rsh commands is displayed along with the VAP group prompt: [root@xxxxx admin]# /usr/os/bin/cbs_rsh FW !p quit/q cbs_cp cbs_start_s cbs_stop_s FW>> 2. Enter the cbs_cp command at the VAP group prompt; the system prompts for the source of the file to be copied. Enter the source with its full path as shown in the example below. FW>>cbs_cp Source File on CPM (with full path) :/tftpboot/.private/home/admin/SomeFile 3. When prompted, enter the full destination path. Destination File on VAP (with full path) :/root/SomeFile ----------Execute previous UNIX command Exit this program Copy a file on CPM to all vaps within a vap-group Start saving commands for VAPs currently not present Stop saving commands for VAPs currently not present
170
4.
The system then issues a copy command for each VAP in the VAP group by appending VAP group index number to the VAP group name (in this example: FW_1, FW_2, etc).
The full example is shown below: [root@xxxxx bin]# /usr/os/bin/cbs_rsh FW !p Execute previous UNIX command quit/q Exit this program cbs_cp Copy a file on CPM to all vaps within a vap-group cbs_start_s Start saving commands for VAPs currently not present cbs_stop_s Stop saving commands for VAPs currently not present FW>>cbs_cp Source File on CPM (with full path) :/tftpboot/.private/home/admin/SomeFile Destination File on VAP (with full path) :/root/SomeFile Copying :/tftpboot/.private/home/admin/SomeFile to /tftboot/FW_1//root/ SomeFile Copying :/tftpboot/.private/home/admin/SomeFile to /tftboot/FW_2//root/ SomeFile FW>> quit [root@xxxxx admin]#
171
172
16
Viewing Performance, Statistics, and Status
This chapter describes how to view the XOS performance, statistics, and status. It contains the following major topics:
z z z z z z z z z
Using GEM to View Module Information and Status on page 173 Viewing Module Information and Status on page 174 Viewing Disk Usage on page 175 Viewing Heartbeat Status on page 175 Viewing Module Utilization and Load Averages on page 176 Viewing Interface Statistics on page 177 Viewing Switch Data-Path (SDP) Statistics on page 178 View VRRP Status on page 178 Viewing Flow Distribution on page 180
173
174
ap2d Link CPU Speed CPU Up Time Threshold Acceleration Card 1 Acceleration Card 2 Ethernet Daughter Card
Down 2327 MHz 96179 secs Not Present Not Present Not Present
EMS provides a Module Memory Usage graph under Status > System Status in the navigation tree.
In case of critical disk errors, you can configure the CPM to automatically go offline as follows: CBS# configure cp-action {cp1|cp2} disk-error offline
175
To view the Heartbeat Status using EMS, open Status > System Status > Heartbeat Status in the navigation tree. For the CLI, use the following command: CBS# show heartbeat Link Quality TO: 1 FROM 1 2 ON ports CB A: NA 100% CB B: NA NA DP A: 100% 100% DP B: NA NA DP C: NA NA DP D: NA NA
3 100% NA 100% NA NA NA
4 100% NA 100% NA NA NA
5 100% NA NA NA NA NA
6 NA NA NA NA NA NA
7 100% NA NA NA NA NA
8 100% NA 100% NA NA NA
9 100% NA NA NA NA NA
10 100% NA 100% NA NA NA
11 100% NA 100% NA NA NA
12 NA NA NA NA NA NA
13 100% NA 100% NA NA NA
14 NA NA NA NA NA NA
176
CPU load average for ap2: for last 1 minute: 0.00 for last 5 minutes: 0.00 for last 15 minutes: 0.00 CPU load average for ap4: for last 1 minute: 0.00 for last 5 minutes: 0.00 for last 15 minutes: 0.00 CPU load average for cp2: for last 1 minute: 0.00 for last 5 minutes: 0.00 for last 15 minutes: 0.00 Slot Module CPU User Nice Syst Idle Irq SfIrq Iowt ---- ------ ----- ----- ----- ----- ----- ----- ----- ----3 ap1 CPU 0.0 0.0 0.0 100.0 0.0 0.0 0.0 3 ap1 CPU0 0.0 0.0 0.0 100.0 0.1 0.1 0.0 3 ap1 CPU1 0.0 0.0 0.0 100.0 0.0 0.0 0.0
Slot Module CPU User Nice Syst Idle Irq SfIrq Iowt ---- ------ ----- ----- ----- ----- ----- ----- ----- ----4 ap2 CPU 0.0 0.0 0.0 100.0 0.0 0.0 0.0 4 ap2 CPU0 0.0 0.0 0.0 100.0 0.0 0.0 0.0 4 ap2 CPU1 0.0 0.0 0.0 100.0 0.0 0.0 0.0 Slot Module CPU User Nice Syst Idle Irq SfIrq Iowt ---- ------ ----- ----- ----- ----- ----- ----- ----- ----13 cp1 CPU 0.1 0.0 0.0 0.0 0.0 0.1 98.4
177
Physical slot number Module type Switch data path number Number of packets received Number of packets received with errors Number of packets dropped while receiving packets Number of packets sent Number of errors occurring during transmission Number of drops occurring during transmission
To clear these counters, use the following command: clear switch-data-path {all|module <low> [<high>]} Where: all <low> <high> Clears the counters from all modules. A specific module. Valid values are 1 to 14. If high is not specified, this is the only module. The low parameter specifies the first module (lowest number) and high specifies the last module (highest number). All modules in the range are included. Valid values are 1 to 14.
See Configuring Multi-System High Availability on page 129 for details on configuring VRRP.
CBS# show vrrp status Priority is Actual/Configured FG-ID Priority Status Preempt 2 200/200 Master on 5 0/100 Down off (2 rows)
The Status column displays the state of the failover group, which can be:
z z z z z
backup Failover group is in backup mode. down Failover group is not functioning. init Failover group is initializing. master Failover group is in master mode. unknown The state of the failover group cannot be determined.
The Priority column displays the failover groups current priority / configured VRRP priority, in that order. If everything is running normally, these numbers are the same. Otherwise, one or more events caused the priority to be decremented by pre-configured priority-deltas, as described in VRRP Priority on page 130. If there is a problem, use the ID in the Sys ID column and enter the show vrrp virtual-router <id> or show vrrp circuit-ip vr-id <id> command. These displays will provide additional information to help you determine which event caused the priority to be decremented. If necessary, use the show vrrp vap-group <vap-group-name>, show vrrp verify-next-hop, and show vrrp monitor-circuit commands to find the problem. If using EMS, you can access the VRRP status by opening Status > Network Status > VRRP Stats in the navigation tree.
179
z z z z z z z z
By default, this command lists the active flows in the order in which they appear in the AFT. Use the sort parameter to sort the list of flows.
180
Syntax
show flow active [source-address {<IP_address> | <lowest_IP_address> <highest_IP_address>} ] [destination-address {<IP_address> | <lowest_IP_address> <highest_IP_address>}] [source-port {<port_number> | <lowest_port_number> <highest_port_number>}] [destination-port {<port_number> | <lowest_port_number> <highest_port_number>}] [protocol {<protocol_number> | <lowest_protocol_number> <highest_protocol_number>}] [domain {<domain_ID_number> | <lowest_domain_ID_number> <highest_domain_ID_number>}] [circuit-id {<circuit_ID_number> | <lowest_circuit_ID_number> <highest_circuit_ID_number>}] [module {<npm_slot_number> | <lowest_npm_slot_number> <highest_npm_slot_number>}] [master-npm {<npm_slot_number> | <lowest_npm_slot_number> <highest_npm_slot_number>}] [fast-path-only] [verbose] [poll <polling_interval>] [sort] [validated] [validation-pending] [no-validation]
Default Output
By default, the show flow active command displays information in a table, using the following format: . Module <NPM_or_VAP_name1> Source <IP>:<port> Destination <IP>:<port> Prot <#> Dom TTI/MAX <ID#> <mm:ss>/<mm:ss> rx packets <#>
Modules <VAP_name1>, <VAP_name2> ... rx circuit <ID#> Master <NPM_name> <NPM_or_VAP_name2> <IP>:<port> <IP>:<port>
The format shown in the entry for <NPM_or_VAP_name1> is used if the flow is received by an NPM or VAP and then transferred to a VAP for processing. The format shown in the entry for <NPM_or_VAP_name2> is used if the flow is received by an NPM or VAP and then rerouted to an external system or dropped. For detailed information about this command and parameters, refer to the XOS Command Reference Guide.
181
Information Provided Amount of time that the NPM has been in the UP state, in days, hours, and minutes. Hours and minutes are expressed in the format: mm:ss. For example, 9 hours and 7 minutes is 09:07. Slot number for the APM assigned to the VAP to which the NPM assigns flows. Name of the VAP to which the NPM assigns flows. A VAP name has the format: <VAP_group_name>_<VAP_Index_Number> Use the show ap-vap-mapping command to display the index numbers assigned to the VAPs in each VAP group configured on the X-Series Platform.
Slot VAP
The change in the number of new flows assigned to the VAP, since the last second. The change in the number of existing flows assigned to the VAP, since the last second. Total number of flows currently assigned to the VAP.
There are two parameters for sorting the show flow distribution output:
z z
sort vap-group sorts flows by vap-group name, then index-in-group, then apm slot sort apm-slot sorts flows by apm-slot, then vap-group name, then index-in-group
The following is an example: CBS# show flow distribution New Flows Rate ========== 0 7344 0 6340 0 5733 0 5223 Aged Flows Rate ========== 0 5133 0 5538 0 5670 0 5041 Flows ========= 0 72043 0 79002 0 69182 0 68423
0 3 0 3 0 3 0 3
Uptime days, 00:00 days, 19:17 days, 00:00 days, 19:17 days, 00:00 days, 19:17 days, 00:00 days, 19:17
Slot 7 7 7 7 8 8 8 8
Flow classification information source and destination IP addresses, source and destination port numbers, protocol number, and domain ID number Network Processor Module (NPM) on which the active flow enters the X-Series Platform Circuit(s) on which the active flow enters an active virtual application processor (VAP) group(s) Active VAP(s) that processes the flow NPM interface on which the active flow leaves the X-Series Platform
182
By default, this command displays information only about the initial entry path and the final egress NPM interface for each flow. That is, the command displays information only about the NPM, circuit, and VAP on which the flow first enters the X-Series Platform and the NPM interface on which the flow exits the X-Series Platform. Use the show flow-path active command output to determine whether NPMs are dropping flows when they arrive on the X-Series Platform, to make sure traffic is successfully passing through the X-Series Platform, and to determine where the NPM sends flows that it does not drop. Use the verbose parameter to display information about the full path for each active flow, from the ingress NPM to the egress NPM interface. Use this parameter to monitor flows when:
z z
The flows pass through more than one VAP group configured on the X-Series Platform. The flows pass through a VAP group that is configured with separate circuits and NPM interfaces for ingress and egress traffic.
The show flow-path active command is a snapshot of the current state of the active flows when the command is issued. Information is not updated when the state of an existing flow changes or when a new flow arrives on the X-Series Platform. Use the poll parameter to continuously poll the NPMs and display updated information at regular intervals. Use this parameter to continuously monitor traffic over time, observing changes in the states of existing flows and obtaining flow path information for new flows that arrive on the X-Series Platform. NOTE: Press Ctrl-y to stop updating the command output and return to the CLI prompt. By default, this command displays flow path information for all active flows. You can use one or more of the following parameters to filter the command output to display flow path information only for active flows that match the criteria that you specify with the parameters:
z z z z z
z z z z z
By default, this command lists the active flows in the order in which they appear in the AFT.
Syntax
show flow-path active [verbose] [source-address {<IP_address> | <lowest_IP_address> <highest_IP_address>}] [destination-address {<IP_address> | <lowest_IP_address> <highest_IP_address>}] [source-port {<port_number> | <lowest_port_number> <highest_port_number>}] [destination-port {<port_number> | <lowest_port_number> <highest_port_number>}] [protocol {<protocol_number> | <lowest_protocol_number> <highest_protocol_number>}] [domain {<domain_ID_number> | <lowest_domain_ID_number> <highest_domain_ID_number>}] [circuit-id {<circuit_ID_number> | <lowest_circuit_ID_number> <highest_circuit_ID_number>}] [module {<npm_slot_number> | <lowest_npm_slot_number> <highest_npm_slot_number>}] [master-npm {<npm_slot_number> | <lowest_npm_slot_number> <highest_npm_slot_number>}] [fast-path-only]
183
Default Output
By default, the show flow-path active command displays information in a table, using the following format: Module <NPM_name1> Source:port <IP>:<port> Destination:port <IP>:<port> Prot <#> Dom <ID#>
rx circuit <ID#> rx active <VAP_name> [rx passive] tx_port <slot>_<port> master <NPM_name> <NPM_name2> <IP>:<port> <IP>:<port> <#> <ID#>
Drop(<drop_reason>)
The output has the format shown in the entry for <NPM_name1> if the originating NPM transfers the flow to a VAP for processing. The output has the format shown in the entry for <NPM_name2> if the originating NPM drops the flow. The following example displays the initial entry path and the egress NPM interface for every active flow that the X-Series Platform is currently processing. In this example, a VAP group called testvapgroup is currently configured on the X-Series Platform and is running a firewall application. CBS# show flow-path active This command may take a few minutes. Do you want to continue? <Y or N> [Y]: Y Module Source:port Destination:port Prot Dom np2 172.16.10.100:2009 172.16.20.240:80 6 1 rx circuit 1027 rx active testvapgroup_2 tx_port 4_2 master np2 np4 172.16.20.240:80 rx passive
172.16.10.144:53814 rx passive
rx circuit 1028 rx active testvapgroup_1 tx_port 2_2 master np2 np2 rx circuit 1029 master np2 CBS# 172.16.10.207:31754 Drop(PS2IDX failed)
172.16.20.240:80
For additional detailed information about the parameters used with this command, as well as additional examples, refer to the XOS Command Reference Guide.
184
17
Viewing Alarms, Events, and Logs
This chapter describes how to view the X-Series Platform message and audit logs. It contains the following major topics:
z z z z
Viewing Alarms on page 185 Configuring a Remote Syslog Server on page 190 Viewing Message Logs on page 190 Viewing Audit Logs on page 192
Viewing Alarms
XOS records alarm data and the Alarms Manager provides the data to GEM, the CLI, SNMP, and system log files for end user consumption. GEM provides extensive alarm information in multiple views in the user interface including the Alarms Panel, the Alarm Details view, and the XOS Alarms Model Information Pages. The CLI provides several options under the show alarms command, providing the same level of granularity as the GEM Alarm views. The Message Log maintains a history of software events that have occurred on the XOS console. This historical log can be searched and the information displayed as well. SNMP traps and MIB tools can be configured to output system alarms into third party tools.
Figure 14.
185
Using GEM
In GEM, the Alarms Panel displays information about each of the alarms logged on the X-Series Platform. The list includes active alarms and optionally, historical alarms. To show historical alarms, check the Include Historical Alarms check box. The alarm list can be filtered to show all alarms, or only alarms related to Dual-box high availability (DBHA). Click the Reset Filter button to remove the filter from the alarm list. The Alarms Panel displays the columns listed below by default, and is updated when a new alarm is generated. To sort a column, click on the header.
z z z z z
ID: The number assigned to the alarm by XOS. Date: Date and Time of alarm. Severity: Critical, Major, Minor, Info, or Clear (indicates the alarm has been cleared). Source: The location where the alarm occurred. The location can be a module or an assembly. Description: A brief description of the alarm.
Colors highlight the alarm severity; red indicates a critical alarm, orange indicates a major alarm, yellow indicates a minor alarm, green indicates a cleared alarm, and gray indicates an informational alarm. To mark one or more alarms as read, right-click the alarm and select Mark as Read. For additional details on an alarm, double-click the alarm to open the Alarm Details view. Additional columns are available by clicking the down arrow in the a column header and selecting from the secondary list. These columns display information that may be specific to certain types of alarms. For more information, refer to the GEM user assistance.
Alarm Details
The Alarm Details window displays additional information to support the data shown in the Alarms panel, including a probable cause and suggested repair actions. The Probable Cause is a starting point for investigating the alarm, and the information should be used with the Suggested Repair Actions to resolve the issue. Repair information may include how to clear the alarm, CLI commands to gather more information about the alarm conditions, and suggestions to prevent the alarm from occurring again.
Clearing Alarms
A small set of informational alarms are clearable using the XOS CLI. These are listed in the optional User Clearable column. Other alarms can only be cleared through user action, such as a configuration change or rebooting a module. For alarm repair actions, refer to the Suggested Repair information in the Alarm Details view. Double clicking any alarm in the Alarms View will display the Alarm Details view.
186
Historical Data
Displaying historical data allows you to look back over a period of time, up to and including the current GEM session. It provides perspective on current conditions, and can help identify trends or events that resulted in an alarm.
XOS displays a summary of all alarm levels, showing the module and the number of alarms for each alarm severity. View specific alarm information by including the alarm category in the show alarm command, as follows: CBS# show alarms active major Active Alarms Summary: Source -----cp2 np1 uprfan Total Critical -------1 0 0 1 Major ----3 0 1 4 Minor ----0 2 0 2
187
* indicates an alarm that can be cleared with the 'clear alarms' CLI command Major: ID -96 *95 94 69 Date ---Nov 11 Nov 11 Nov 11 Nov 10 Source -----cp2 cp2 cp2 uprfan Description ----------Failover group xyz priority 49 Failover group xyz status master No remote box configured Fan tray mismatch
XOS displays the alarm status summary for each module. The alarm status summary is followed by information for each active alarm in the category specified. Use the verbose parameter to display complete alarm information, including suggested repair actions: CBS# show alarms active major verbose Active Alarms Summary: Source -----cp2 np1 uprfan Total Critical -------1 0 0 1 Major ----2 0 1 3 Minor ----0 2 0 2
Major: ================================================================================ Alarm Id : 94 Brief Description : No remote box configured Date : Thu Nov 11 15:34:10 2010 Severity : Major Alarm Name : noRemoteBoxConfigured Alarm Source : cp2 Slot : slot 7 Module : cp2 Information : Probable Cause : Configuration Or Customization Error Event Type : other User Clearable : false Extended Description : VRRP is configured but no remote box is configured, : which could indicate an incomplete configuration. Repair Action : If you have VRRP configured, you must configure at : least one remote box. Either add a remote box or : delete the VRRP configuration. -------------------------------------------------------------------------------You can further filter the data by source, ID, or date and time by using additional parameters. See the XOS Command Reference Guide for detailed syntax, usage, and parameter explanations of this command.
7 7 7 7 7 7
Description ----------Power supply missing Power supply failure Firmware mismatch slot: 1,5,13 New system alarm level (major) Fan tray mismatch Flow table median threshold(tcp)
XOS displays a summary of all alarms, starting with the most recent. Use additional parameters to filter the output of the show alarms history command by ID, severity, source, and date. Use the verbose parameter to display complete alarm information, including suggested repair actions. See the XOS Command Reference Guide for detailed syntax, usage, and parameter explanations of this command.
189
Cleared alarms remain in the alarms history, and can be viewed by executing the show alarms history CLI command. Use the clear-alarms command to clear these alarms. You can clear all alarms by using the all parameter, or you can specify an alarm or group of alarms by using the id parameter. The following command clears the user-clearable alarm with ID 95. CBS# clear alarms id 95 CBS# When you clear an alarm, a new alarm appears in the alarms history with a severity of Clear. The cleared alarm (ID 95) remains in the alarm history. See the XOS Command Reference Guide for detailed syntax, usage, and parameter explanations of this command. NOTE: The system also clears alarms automatically, either because the condition that generated the alarm no longer exists, or because the alarm has been superseded by a later alarm.
CBS# show logging console Jul 7 20:33:33 crossbeam Received msg from hm with Jul 7 20:33:33 crossbeam 512->1024 Jul 7 20:33:33 crossbeam unknown slot 3 Jul 7 20:33:33 crossbeam Received msg from hm with Jul 7 20:33:33 crossbeam Received msg from hm with Jul 7 20:33:35 crossbeam unknown slot 7 Jul 7 20:33:35 crossbeam unknown slot 3 Jul 7 20:33:35 crossbeam unknown slot 7
cbssysctrld[1777]: [W] int CHmSession::read () opcode=5 0 entries cbssysctrld[1777]: [W] HM Reallocating sbd cbssysctrld[1777]: [W] pollHiChange Poll rx'd from cbssysctrld[1777]: [W] int CHmSession::read () opcode=5 0 entries cbssysctrld[1777]: [W] int CHmSession::read () opcode=5 0 entries cbssysctrld[1777]: [W] pollHiChange Poll rx'd from cbssysctrld[1777]: [W] pollHiChange Poll rx'd from cbssysctrld[1777]: [W] pollHiChange Poll rx'd from
Console debug messages for the APMs and NPMs are disabled by default. To enable console messaging from the APM enter the Linux command: echo "6 4 1 7" > /proc/sys/kernel/printk NOTE: To make this change permanent following a reboot, edit the APM /etc/rc.local file by commenting out the line echo "1 2 1 1" > /proc/sys/kernel/printk. Reporting messages to the console may cause performance degradation. Excessive verbose messaging may cause the module to reset. Kernel messages can always be viewed in dmesg on the APM and the system log on the CPM.
16:08:31
16:09:23
16:09:23
16:09:29
16:09:39
191
Nov 20 17:37:34 TechPubs-X45 cbsalarmlogrd: AlarmID 88 | Sat Nov 20 18:37:34 2010 | clear | uprfan | fanTrayIncompatible | Fan tray mismatch | CorrelationID 53 Nov 20 17:37:37 TechPubs-X45 cbsalarmlogrd: AlarmID 89 | Sat Nov 20 18:37:37 2010 | major | uprfan | fanTrayIncompatible | Fan tray mismatch To see the CLI command show alarms in the messges file, grep the output for "| major |" [root@TechPubs-X45 admin]# grep AlarmID /var/log/messages | grep major systemAlarm | New system alarm level (major) Nov 20 15:08:31 TechPubs-X45 cbsalarmlogrd: AlarmID 82 | Sat Nov 20 16:08:31 2010 | major | cp2 | vrrpFailGroupStatusChange | Failover group vrrp_fw status down Nov 20 15:09:23 TechPubs-X45 cbsalarmlogrd: AlarmID 84 | Sat Nov 20 16:09:23 2010 | major | cp2 | vrrpFailGroupPriorityChange | Failover group vrrp_fw priority 199 Nov 20 15:09:23 TechPubs-X45 cbsalarmlogrd: AlarmID 85 | Sat Nov 20 16:09:23 2010 | major | cp2 | noRemoteBoxConfigured | No remote box configured Nov 20 15:09:29 TechPubs-X45 cbsalarmlogrd: AlarmID 86 | Sat Nov 20 16:09:29 2010 | major | cp2 | vrrpFailGroupStatusChange | Failover group vrrp_fw status master Nov 20 15:09:39 TechPubs-X45 cbsalarmlogrd: AlarmID 87 | Sat Nov 20 16:09:39 2010 | major | cp2 | vrrpFailGroupPriorityChange | Failover group vrrp_fw priority 100 Nov 20 17:37:37 TechPubs-X45 cbsalarmlogrd: AlarmID 89 | Sat Nov 20 18:37:37 2010 | major | uprfan | fanTrayIncompatible | Fan tray mismatch Nov 20 20:37:39 TechPubs-X45 cbsalarmlogrd: AlarmID 91 | Sat Nov 20 21:37:39 2010 | major | uprfan | fanTrayIncompatible | Fan tray mismatch Nov 22 14:06:37 TechPubs-X45 cbsalarmlogrd: AlarmID 92 | Mon Nov 22 15:06:37 2010 | major | cp2 | vrrpFailGroupStatusChange | Failover group xyz status down
192
Aug 23 14:05:12 REG80A1 cli: USER: admin, COMMAND: CBS# configure ip ftp > configure ip ftp Aug 23 14:05:13 REG80A1 cli: USER: admin, COMMAND: CBS# configure system-identifier > configure system-identifier 101 #Warning: WARNING: Command takes effect next system reload Aug 23 14:05:14 REG80A1 cli: USER: admin, COMMAND: CBS# configure operating-mode > configure operating-mode quad-np series-6 #Warning: WARNING: Command takes effect next system reload Aug 23 14:05:15 REG80A1 cli: USER: admin, COMMAND: CBS# configure access-list ip source-ip destination-ip > configure access-list 1001 permit ip source-ip 0.0.0.0 255.255.255.255 destination-ip 0.0.0.0 255.255.255.255 Aug 23 14:05:16 REG80A1 cli: USER: admin, COMMAND: CBS# configure access-list ip source-ip destination-ip > configure access-list 1002 permit ip source-ip 0.0.0.0 255.255.255.255 destination-ip 0.0.0.0 255.255.255.255
193
194
18
Upgrading XOS Software and Firmware
This chapter provides migration and upgrade information. It includes the following major topics:
z z z z
XOS Automated Workflow System on page 195 XOS shar Upgrade on page 196 Upgrading the XOS Firmware on page 200 XOS Migration on page 204
If you are upgrading to XOS 9.5.x on an X-Series Platform currently running XOS 9.0 or above, use the Automated Workflow System to perform an upgrade. If you are upgrading to XOS 9.5.x on an X-Series Platform currently running XOS 8.x, use the Migration Process to upgrade to XOS 9.5.x.
Select a submenu to view available automated workflows. Enter x to exit or ? for help. Please Enter Selection: Enter your selection to begin the automated process. Help is available at each level by using the ?. AWS supports five automated workflows:
z z
Software upgrade: This feature is available to upgrade from XOS V9.0 to a future release. You cannot upgrade to XOS V9.0 using AWS. Firmware compatibility check: The firmware compatibility check compares the current versions of installed firmware against the recommended version, and displays the result (Up to date, or Update required). Firmware update: This workflow will perform the firmware update automatically. Prepare for Rollback: This workflow saves the currently installed XOS version to a separate distribution (distribution two) on the disk. Distribution one is prepared for the installation of a new version of XOS. Rollback: This workflow will return the X-Series Platform to the previous version of XOS should an upgrade fail.
z z z
Information generated during an automated workflow is saved to the AWS log file, available at /var/log/aws.log. You can also watch the progress during a workflow using the show automated-workflow-progress command. During the upgrade process, AWS will lock the configuration. If a user attempts to access the configuration file to make changes during the upgrade, an error message stating the configuration is locked by the Automated Workflow System will be displayed.
196
3. 4. 5. 6.
FTP or copy the xos-upgradepack-A000-X.Y.Z-W.shar.gz file from your XOS CDROM or software package to /usr/os/rpm. Note that A000-X.Y.Z-W represents Ocode-Major.Minor.Maintenance-Kit.shar Enter the following command at the root prompt while in /usr/os/rpm: # gzip d xos-upgradepack-A000-X.Y.Z-W.shar.gz Change the extracted file to an executable as follows: # chmod 777 xos-upgradepack-A000-X.Y.Z-W.shar Once the above command completes, enter the following command: # ./xos-upgradepack-A000-X.Y.Z-W.shar
To upgrade a Dual CPM configuration: 1. Start a CLI session on the primary CPM.
197
2. 3. 4. 5. 6. 7.
If you are using CP redundancy, bring the secondary CPM offline. CBS# configure cp-redundancy set other_cp offline Start the CLI on the secondary CPM. Note that it may take a moment or two for the secondary CPM to come offline. Perform the Copying and Extracting the shar File on page 196 to copy the file to the offline CPM. From within the CLI on the offline CPM, enter the Upgrade context using the following command: CBS# upgrade From the secondary CPM, display the available software versions as follows: CBS(upgrade)# show new-release From the secondary CPM, enter the desired software version. For example: CBS(upgrade)# install <xos_version> Where xos_version is the specific version of the software that you wish to load. Answer the questions as prompted.
8. 9.
Configure the secondary CPM for election. CBS# configure cp-redundancy set this_cp election Save the configuration on the secondary CPM.
10. Start the CLI on the primary CPM then configure the secondary CPM for election from the primary CPM. CBS# configure cp-redundancy set other_cp election 11. Reload the secondary CPM: CBS# reload offline-cp 12. Reload all APM and NPM modules. For the X80 system, reload modules 1 to 12 as follows; otherwise, reload modules 1 to 5. This command takes all modules offline; no traffic is processed during this time. CBS# reload modules 1 12 13. Take the Primary CPM offline. CBS# configure cp-redundancy set this_cp offline 14. When prompted, log back in to the CPM that was the original Primary CPM. 15. Save your configuration. CBS# copy running-config startup-config NOTE: The secondary CPM reloads with the new version of the XOS software and becomes the Primary CPM. 16. Connect to CLI on the current Primary CPM and verify that the system is operating correctly before upgrading the other CPM. 17. Repeat the procedure in Copying and Extracting the shar File on page 196 on the offline CPM. 18. From within the CLI on the offline CPM, enter the Upgrade context using the following command: CBS# upgrade 19. From the offline CPM, display the available software versions as follows: CBS(upgrade)# show new-release 20. From the offline CPM, enter the desired software version. For example: CBS(upgrade)# install <xos_version> Where xos_version is the specific version of the software that you wish to load. Answer the questions as prompted. 21. Set the offline CPM to Election mode. CBS# configure cp-redundancy set this_cp election
Upgrading XOS Software and Firmware 198
22. Save your configuration. CBS# copy running-config startup-config 23. Connect to the current Primary CPM and reload the offline CPM. The CPM becomes the secondary CPM. CBS# reload offline-cp After the reload is complete CPM redundancy is restored. The CPM roles are reversed from when you started this procedure.
For CBI: 1. 2. Copy the .cbi bundle to /usr/os/apps/archive/ on the primary CPM only. Install the application from the CLI as normal.
Table 19.
Directory /tmp
/usr/os/logs
cli_conversion_log SystemSoftwareReleaseHistory
/var/log
cli-upgrade-errors
199
Caution: Manual Firmware and FPGA upgrades must be executed at the same time before reloading. Attempting to reboot the system after a firmware upgrade without the corresponding FPGA upgrade will fail.
Use /crossbeam/bin/revs_check to display the current status of the firmware on your system. Information is provided for each installed module (NPM, CPM, APM). Additionally, you can review the Firmware Status view in the Greenlight Element Manager for the same information. There are two types of firmware to upgrade: FPGA and FLASH. To see the current firmware status, the minimum revision necessary, and the recommended version from the command line, execute the revs_check command from the /crossbeam/bin directory with the following parameters:
-c: Display the current firmware revision. -m: Display modules which do not meet minimum requirement. -u: Display modules whose firmware revisions are not up-to-date. -h: Display latest version of the files.
CBS# unix su [root@xxxx admin]# cd /crossbeam/bin [root@xxxx admin]# ./revs_check -c -m -u The flashit tool needed to perform an upgrade is located within the /crossbeam/bin directory. If there are multiple flash or FPGA files, the file ending in the highest number is the latest. If you are unsure of the type of firmware, enter -h to determine the usage.
200
5.
Telnet to the NPM. [root@xxxx admin]# telnet npm<slot> The NPM can be in slots 1-4. For example, enter npm1 to connect to the NPM in slot 1.
6.
Run the flashit -w <filename> command for each file. The following filenames are examples only: /# flashit -w /cbs/shared/npm6xbprc_R0010_130.dat /# flashit -w /cbs/shared/npm6FlashImage0014.dat /# flashit -w /cbs/shared/npm6sysctrl_R04.dat
7. 8.
When the upgrade is completed, return to the CPM prompt: /# exit Verify that the upgrade completed successfully. a. b. Make sure that there were no NPM error messages during the flashit command. Check the syslog for the message, npm<slot> flashit: program terminates normally.
9.
10. Enable the module. CBS# configure module <slot-number> enable 11. Use the show version detail command to verify that the firmware is upgraded. For example: CBS# show version detail Copyright (c) 2000-2011 by Crossbeam Systems, Inc. All rights reserved. Version: XOS 9.5.x [Mar 1 2011 13:56:26] (bldmgr) gcc: gcc version 2.96 20000731 (Linux 7.3 2.96-112) CVS_Label: XOS-9_5_x_x-20101205_2 Kit_Number: 88 CPU at 1995 Mhz processor with 3592316K bytes of memory 3566660K bytes of memory in use Uptime is 3 day(s) 21 hour(s) 40 min(s) 36 sec(s) Hard disk is 120(GB) Second Hard disk is not present Flash is not present
Details per slot: Revision for slot 1 Boot Strap version Bootloader version Diagnostics version SysCtl FPGA version Focus FPGA version CPLD version Board version Board serial number Board type Board part number : : : : : : : : : : 2.0.0.10 2.0.0.8 2.1.0.2 0x4 0xa 0x5 F G801B022 NP8600 003927
201
202
1. 2. 3.
After the success messages display, halt the CPM as follows: # halt Press the reset pin located at the front of the CPM to reboot it, or remove and re-seat the CPM. After the CPM reboots successfully, verify that the firmware is upgraded: CBS# show module status revision {cp1|cp2}
10. After the CPM reboots successfully, verify that the firmware is upgraded. From the primary CPM use the following CLI command: CBS# show module status revision {cp1|cp2} NOTE: At the completion of this procedure, the CPMs have swapped their Primary and Secondary states. To restore the Primary state to the original CPM, wait for CPM synchronization, and then reboot the current Primary CPM.
XOS Migration
Starting with XOS V9.0, Crossbeam implemented the RHEL5 64-bit kernel and compatible userspace packages. These improvements provide updated support and additional security provisions. Versions of XOS prior to V9.0 use a 32-bit operating system. Upgrading from XOS V8.x or earlier to V9.5.x requires running the XOS migration feature. The migration process combines elements of a fresh installation with the upgrade process to automatically migrate your applications and system configuration to the latest XOS software. The following migration scenarios are supported:
z z z
XOS V8.5 to XOS V9.x XOS V8.x with Series-6 (86xx and higher) hardware to XOS V9.x XOS V7.3 on a CPM-86xx with no configuration to XOS V9.x
X-Series Platforms with older modules (pre-86xx) require upgrades prior to migration. Migration is an automated process that takes place in three stages. 1. 2. 3. Stage One saves the existing configurations and necessary files, and prepares the new distribution. Stage Two copies the required files to the new distribution, and converts files to the RHEL5 kernel. Stage Three converts the configuration file, upgrades all VAPs, saves the configuration, and reboots the system.
Because the migration process is an automated task, user input must be provided for the following items before the migration begins.
z z
A system reboot is required at the end of the first stage of the process. Choose whether to automatically reboot the system, or to halt the system and perform the reboot manually. If an error occurs during migration, choose whether to halt the migration and remain incomplete with the new version while repairing the error, or revert to the previous version.
Throughout the migration process, the current state of the CPM is saved in a system file. The CPM invokes different scripts during the process, using responses to the above questions when required.
Hardware modules (APM, CPM, and NPM) of 8600 or above CPM-8600 or later with 4GB RAM (four 1-Gigabit DIMMs)
If your X-Series Platform is not running 86xx-series modules, you must upgrade the modules before migrating to V9.x. Additionally, the CPM-86xx must have four 1-Gigabit DIMMs installed to meet the memory requirements. Refer to the hardware upgrade instructions and RAM upgrade instructions provided with the modules for upgrade procedures. Once your system meets these minimum requirements, follow the appropriate procedure in the Workflows section to perform the migration. The migration process performs a number of system checks, and provides information when user action is required. If the application versions currently installed on your X-Series Platform are not supported on 9.x, you will be asked to exit the migration process and upgrade the applications. See Applications Supported for Migration for application information.
Upgrading XOS Software and Firmware 204
If your current configuration requires changes, you will be asked to exit the migration process and update the configuration. For information on configuration requirements for migration, see Upgrade Considerations on page 208.
Check Point SecurityGateway R70/R71 Check Point VPN-1 Power NGX R65 Check Point VPN-1 Power VSX NGX R65/R67 Imperva SecureSphere 7.0 IBM Proventia N-IPS 2.0 Trend IWSS 3.1 Trend IMSS 7.0 Websense 6.3.2 RSW 8.0
Workflows
The following workflows provide information and steps to execute the migration process.
205
!!! WARNING !!! !!!!!!!!!!!!!!! If you use acl-interface to mirror or pass-through traffic from the source interface to the target interface, you must ensure that the target acl-interface is configured. If you fail to configure the target interface, the migration will proceed but your acl-interface configuration will not transfer into XOS V9.5.x. Please see the Release Notes or Configuration Guide for more information. Would you like to proceed? (y/n):y Any unsaved configurations will be lost during migration process. Do you want to save the configuration before continuing? (y/n):y [I] Saving configuration. CBS# copy running-config startup-config Saving configuration ... Please be patient... . [I] Performing pre-migration checks. [I] Executing pre_upgrade_check. WARNING !!! WARNING: XOS 9.5.x only supports the following modules: * CPM-8600 * APM-8600, APM-8650, APM-9600 * NPM-8600, NPM-8620, NPM-8650, NPM-9600 Only supported modules will boot after upgrading to XOS 9.5.x. Do you want to reboot the CPM automatically, when the migration process requires a reboot? (y/n):y If an error occurs during the migration process, do you want to revert to the existing XOS release? (y/n):y The system performs the migration, saves your configuration and reloads all modules at the completion of the process.
6. 7.
Start the CLI on the offline (secondary) CPM. Note that it may take a moment or two for the secondary CPM to come offline. Execute the following commands to begin migration: [root@xxxxx admin]# cd /crossbeam/rpm [root@xxxxx rpm]# chmod 777 xos-migratepack-9.5.x-xxx [root@xxxxx rpm]# ./xos-migratepack-9.5.x-xxx The script executes. Several system checks are performed, and mesages are displayed when the migration requirements are not met. The system provides information in many cases about the recommended course of action. After each requirement is met, restart the migration process.
8.
When all checks are passed, the following general messages will appear: !!!!!!!!!!!!!!! !!! WARNING !!! !!!!!!!!!!!!!!! Distribution 2 will be overwritten by the migration process. Would you like to proceed? (y/n):y Any unsaved configurations will be lost during migration process. Do you want to save the configuration before continuing?(y/n):y [I] Saving configuration. CBS# copy running-config startup-config Saving configuration ... Please be patient... . [I] Performing pre-migration checks. [I] Executing pre_upgrade_check. WARNING !!! WARNING: XOS 9.5.x only supports the following modules: * CPM-8600, CPM-9600 * APM-8600, APM-8650, APM-9600, APM-2030 * NPM-8600, NPM-8620, NPM-8650, NPM-9600, NPM-20, NPM-30 Only supported modules will boot after upgrading to XOS 9.x.x. Do you want to reboot the CPM automatically, when the migration process requires a reboot? (y/n):y If an error occurs during the migration process, do you want to revert to the existing XOS release? (y/n):y The system performs the migration.
9.
From the CLI on the offline CPM, configure the offline (secondary) CPM for election. CBS# configure cp-redundancy set this_cp election
10. Save the configuration on the offline (secondary) CPM. CBS# copy running-config startup-config 11. From the primary CPM, configure the offline (secondary) CPM for election. CBS# configure cp-redundancy set other_cp election 12. From the primary CPM, reload the offline (secondary) CPM: CBS# reload offline-cp 13. From the primary CPM, verify the offline (secondary) CPM is rebooting.
XOS Configuration Guide 207
CBS# show chassis 14. From the primary CPM, set the primary CPM to offline. This may take a few moments. CBS# configure cp-redundancy set this_cp offline The secondary CPM reloads with the new version of the XOS software and becomes the primary CPM. 15. Save your configuration. CBS# copy running-config startup-config 16. Connect to the CLI on the new primary CPM and reload the NPMs and APMs to run with the XOS 9.x software. CBS# reload all 17. Verify that the system is operating correctly before upgrading the offline CPM. 18. Repeat Step 7 and Step 8 on the offline CPM. 19. Enter the CLI on the primary CPM, and set the secondary CPM to election. CBS# configure cp-redundancy set other_cp election 20. From the primary CPM, reload the secondary CPM. CBS# reload offline-cp
Upgrade Considerations
When migrating XOS, a script checks the configuration file for compatibility problems. If any issues are discovered, you have the option of stopping the upgrade and correcting them. You can also perform these checks manually before migrating. The following checks are performed by the migration script:
z
Interfaces with overlapping ingress VLANs cannot be redundant and must be reconfigured. A backup interface in an active-active configuration cannot be configured to pass the same type of traffic as the master interface. This means that both the master and backup interfaces cannot be configured to pass the same VLAN traffic, or pass untagged traffic. An example of a valid active-active configuration would be to have an interface passing VLANs tagged 100 be a backup to an interface passing VLANS tagged 300. Refer to VLANs on page 63 for more information.
208
If your configuration uses the acl-interface command to mirror or pass-through traffic from a source interface to a target interface, the following configurations must be updated. If these configurations are not updated, your acl-interface configuration will not transfer into XOS V9.x:
The target acl-interface must be configured. Remote mirroring and pass-through (when the target port is on a different NPM than the source port) is not supported. An interface cannot mirror or pass-through traffic to itself.
z z
The MTU setting is no longer applicable to interfaces. Instead, the MTU must be assigned to circuit and VAP group with the circuit <name> vap-group <name> MTU command. Virtual router configurations can no longer have multiple VAP groups mapped to a single circuit. Make sure that all virtual routers have only one VAP group assigned. A VAP group is assigned to a virtual router using the vrrp virtual-router vrrp-id <id> vap-group <name> command. The promiscuous-mode active parameter should be used for circuits used as members in a bridge. Previously, the member circuits were set to promiscuous-mode using the circuit <name> vap-group <name> command. The system ID must be configured if upgrading to the NPM-8600. You can configure the system ID with the configure system-identifier <system-id> command, where valid values are 1 to 255. CPM versions prior to CPM-8600 are not supported. Upgrades from a version prior to XOS V8.0 are not supported, with the exception of an unconfigured XOS V7.3. The series-2 operating-mode is not supported. Please configure the operating-mode to series-6 prior to upgrading. The xslinux_v1 VAP OS is not supported. Please remove any VAP groups using the xslinux_v1 OS. The xslinux_v4 VAP OS is not supported. Please remove any VAP groups using the xslinux_v4 OS. UNI kernels are not supported. Please change these VAP groups to 'kernel-smp auto' A system-identifier of 0 is not supported. Please configure the system-identifier to <1-255> prior to upgrading. During an upgrade or migration, if your running configuration includes a flow rule with either a source or destination IP address in the form a.b.c.d/0 where a.b.c.d is not 0.0.0.0, the address will be converted to 0.0.0.0/0. Only the following modules are supported on XOS V9.5.x:
z z z z z z z z z
CPM-8600, CPM-9600 APM-8600, APM-8650, APM-9600, APM-2030 NPM-8600, NPM-8620, NPM-8650, NPM-20, NPM-30
Refer to the XOS Command Reference Guide for a list of all commands that have changed in XOS V9.5.x.
Log Files
Major milestones on the migration process are logged in the syslog of the running distribution. More detailed information is logged into the following files: /crossbeam/logs/migration_s1.log This log file will contain information for stage one of the migration process. It will be created and updated on the old distribution, and then copied to the new distribution at the end of stage one. /crossbeam/logs/migration_s2.log This log file will contain information for stages two and three of the migration process. It will be created and updated on the new distribution. The log files include a time and date stamp for each event.
209
210
19
Configuring Routing Protocols
This chapter describes how to install routing protocols on the X-Series Platform. The routing protocols include:
z z z z z z
Routing Information Protocol Version 2 (RIPv2) Routing Information Protocol Version Next Generation for IPv6 (RIPng) Open Shortest Path First (OSPF) Open Shortest Path First for IPv6 (OSPFv3) Border Gateway Protocol (BGP) Protocol Independent Multicast-Sparse Mode (PIM-SM)
Crossbeam provides these routing protocols in a Routing Software (RSW) package that is sold and installed separately from XOS. Refer to the RSW Installation Guide for detailed information. This chapter contains the following major topics:
z z z z z
Routing Software Overview on page 211 Installing Routing Protocols on page 213 Installing a Routing Protocol on a VAP Group on page 214 Managing Routing Configurations on page 214 IPv6 Tunneling on page 217
211
3.
4.
Configuring Interfaces
NOTE: If any routes are invalid, the XOS CLI returns an error message. 3. Copy the running-config to startup-config: CBS# copy running-config startup-config CBS#
213
2.
Caution: Restoring an RSW configuration file from a lower or higher RSW version may cause unpredictable results.
status Displays the status of a routing protocol on a VAP group.
The following commands write the protocol status to the XOS running-config and take the related action on the protocol daemon. configure routing-protocol <protocol> vap-group <vap-group-name> {start|restart|stop}
Configuring Interfaces 214
Where: <protocol> start stop restart Can be rip, ripng, ospf, ospf6, pim, or bgp. Starts the protocol. Stops the protocol. Restarts the protocol. This forces a running protocol, such as OSPF, to rebuild its routing table.
The following command enables access to the routing protocol NSM daemon on the master VAP from the CLI. routing-protocol-services vap-group <VAP_group_name> configure Any changes made to NSM are written to all active VAP group members. In NSM you can modify ACLs, configure FIB Retain, and troubleshoot general routing issues.
Accessing NSM
Use the following steps to access the CLI for NSM. 1. From the XOS CLI command prompt, enter: CBS# routing-protocol-services vap-group <VAP_group_name> configure Password: Enter the password (default is admin): Password: ***** Router> Enter privileged mode: Router>enable Password: Enter the privileged mode password (default is admin): Password: ***** Router#
2.
3.
4.
215
1. 2. 3.
From the XOS CLI command prompt, enter: CBS# routing-protocol-services vap-group <VAP_group_name> configure Enter the password (default is admin): Password: ***** Enter privileged mode: Router>enable Password: Enter the privileged mode password (default is admin): Password: ***** Router# Enter the configure terminal context to configure the FIB Retain value: Router#configure terminal Router(config)# Enter the FIB Retain configuration context: Router(config)#fib retain {time <number_of_seconds> | forever} Router(config)# Enter either the number of seconds or forever to retain the FIB values.
4.
5.
6.
7.
Exit the terminal configuration context: Router(config)#end Router# Write the configuration to nsm.conf: Router#write Configuration saved to /usr/os/etc/zebos/nsm.conf Router# Exit NSM to synchronize the changes to all VAP members: Router#exit CBS#
8.
9.
10. CBS#
Redistributing Routes
Protocols in the X-Series Platforms can be configured to redistribute routes to other protocols. Refer to the RSW Installation Guide for information on how to access the protocol and turn on route redistribution.
Configuring Interfaces
216
IPv6 Tunneling
IPv6 tunneling provides a method to transmit and receive IPv6 traffic over an IPv4 network. Typically, this kind of tunnel is used to connect to an IPv6-enabled destination (host or network). In the Crossbeam implementation of IPv6 tunneling, one end of the tunnel is a Crossbeam X-Series chassis and the other end is a dual stack router. IPv6 traffic is encapsulated in IPv4 packets and passed over the IPv4 network. When an IPv4 packet reaches the destination, it is unencapsulated and the IPv6 packet is routed appropriately. On the X-Series chassis, the traffic-processing VAP group must be configured to handle IPv6 traffic.
6to4 Tunnel
One IPv6 tunneling protocol is 6to4 tunneling. Using 6to4, you do not have to specify the destination address of the tunnel. You configure the local (source) end of tunnel with an IPv4 address and an IPv6 address. The IPv6 address contains an encoding of the IPv4 address. The major steps to configure the local/source end of the tunnel are:
z z z z
Create a VAP group and enable it to handle IPv6 traffic. Create a circuit with an IPv6 address and associate it with the VAP group. Create a circuit with an IPv4 address and associate it with the VAP group. Create the tunnel, specifying 6to4 as the tunnel type, associating the tunnel with the VAP group and the IPv6 circuit, and specifying the address of the IPv4 circuit as the source-address.
Figure 15.
6to4 Tunnel
Example
To configure a 6to4 tunnel using the parameters in Figure 15, perform these steps: 1. On the X-Series chassis configure a VAP group, and enable IPv6 traffic processing. CBS# configure vap-group vg1 enable-ipv6
217
NOTE: A non-ip flow rule is automatically configured with these parameters: non-ip-flow-rule ipv6_rule encapsulation ethernet type 34525 action pass-to-master activate 2. Identify the IPv4 address that you want the VAP group to use to send traffic over the IPv4 network. In this example, the local IPv4 address is 172.16.20.30.
NOTE: This address will be the source address that you specify when configuring the 6to4 tunnel. 3. Configure the first of two circuits with these characteristics: a. b. c. Choose a name for the circuit (in this example, tunnel_a). CBS# configure circuit tunnel_a Associate the circuit with the VAP group (in this example, vg1) CBS(conf-cct)# vap-group vg1 Assign an IPv6 address to the circuit. The address must be constructed as follows:
The first 16-bit field must be 2002 to identify the IPv6 address as a 6to4 tunnel address. The next two fields must contain a decimal-to-hexadecimal conversion of the IPv4 address that you identified in Step 2. In this example, converting 172.16.20.30 to two hexadecimal numbers results in AC10:141E (172 converts to AC, 16 converts to 10, and so on). In the last 16-bit field, specify the host address that you want to associate with this circuit (for example, 3).
CBS(conf-cct-vapgroup)# ip 2002:AC10:141E:0:0:0:0:3/48 %WARNING: IPv6 primary address was configured. No IPv4 aliases will be allowed for this circuit CBS(conf-cct-vapgroup-ip)# end 4. Configure a second circuit with these characteristics:
Choose a name for the circuit (in this example, tunnel_b). CBS# configure circuit tunnel_b Associate the circuit with the VAP group (in this example, vg1) CBS(conf-cct)# vap-group vg1 Assign the local IPv4 address that is being used by the VAP group to send traffic to the external IPv6 network. CBS(conf-cct-vapgroup)# ip 172.16.20.30/24 CBS(conf-cct-vapgroup-ip)# end
5.
Configure the 6to4 tunnel. CBS# configure ipv6-tunnel 6to4 circuit tunnel_a vap-group vg1 CBS(conf-tunnel-6to4)# source-address 172.16.20.30 CBS(conf-tunnel-6to4)#
6.
Optionally, configure a time-to-live value for packets sent through the tunnel. Values range from 1 to 256 seconds, and the default is 64. CBS(conf-tunnel-6to4)# time-to-live 120 Optionally, enable Maximum Transmission Unit (MTU) discovery for the path that the tunnel uses. Discovery of the MTU helps to avoid fragmentation. CBS(conf-tunnel-6to4)# path-mtu-discovery CBS(conf-tunnel-6to4)# end CBS#
7.
Configuring Interfaces
218
ISATAP Tunnel
ISATAP (Intra-Site Automatic Tunnel Address Protocol) is used for a site that has not fully implemented an IPv6 network. An ISATAP host talks to an ISATAP router through the ISATAP automatic tunnel over the existing IPv4 network. Typically, this kind of tunnel enables IPv6-enabled hosts to communicate over a local IPv4 network. The ISATAP tunnel interface treats underlying IPv4 as an NBMA (Non Broadcast Multi Access) network. Each ISATAP interface is assigned the same IPv6 prefix. The Router Advertisements (RA) are used to automatically assign prefixes. The major steps to configure the local/source end of the tunnel are:
z z z z
Create a VAP group and enable it to handle IPv6 traffic. Create a circuit with an IPv6 address and associate it with the VAP group. Create a circuit with an IPv4 address and associate it with the VAP group. Create the tunnel, specifying isatap as the tunnel type, associating the tunnel with the VAP group and the IPv6 circuit, and specifying the address of the IPv4 circuit as the source-address.
Figure 16.
ISATAP Tunnel
Example
To configure an ISATAP tunnel using the parameters in Figure 16, perform these steps: 1. On the X-Series chassis configure a VAP group, and enable IPv6 traffic processing. CBS# configure vap-group vg2 enable-ipv6 NOTE: A non-IPv4 flow rule is automatically configured with these parameters: non-ip-flow-rule ipv6_rule encapsulation ethernet type 34525 action pass-to-master activate
219
2.
Identify the IPv4 address that the you want the VAP group to use to send traffic over the IPv4 network. In this example, the local IPv4 address is 172.32.30.40.
NOTE: This address will be the source address that you specify when configuring the ISATAP tunnel. 3. Configure the first of two circuits with these characteristics: a. b. c. Choose a name for the circuit (in this example, tunnel_1). CBS# configure circuit tunnel_1 Associate the circuit with the VAP group (in this example, vg2) CBS(conf-cct)# vap-group vg2 Assign an IPv6 address to the circuit. The address must be constructed as follows:
The prefix fields can be any valid IPv6 prefix, but must include the reserved identifier for ISATAP, which is 0:5efe. This example uses FC00:0:0:0:0:5EFE: as the prefix. The last four fields must contain a decimal-to-hexadecimal conversion of the IPv4 address that you identified in Step 2. In this example, converting 172.32.30.40 to two hexadecimal numbers results in AC20:1E28: (172 converts to AC, 32 converts to 20, and so on).
CBS(conf-cct-vapgroup)# ip FC00:0:0:0:0:5EFE:AC20:1E28/16 %WARNING: IPv6 primary address was configured. No IPv4 aliases will be allowed for this circuit CBS(conf-cct-vapgroup-ip)# end 4. Configure a second circuit with these characteristics:
Choose a name for the circuit (in this example, tunnel_2). CBS# configure circuit tunnel_2 Associate the circuit with the VAP group (in this example, vg2) CBS(conf-cct)# vap-group vg2 Assign the local IPv4 address that is being used by the VAP group to send traffic to the external IPv6 network. CBS(conf-cct-vapgroup)# ip 172.32.30.40/24 CBS(conf-cct-vapgroup-ip)# end
5.
Configure the isatap tunnel. CBS# configure ipv6-tunnel isatap circuit tunnel_1 vap-group vg2 CBS(conf-tunnel-isatap)# source-address 172.32.30.40 CBS(conf-tunnel-isatap)#
6.
Optionally, configure a time-to-live value for packets sent through the tunnel. Values range from 1 to 256 seconds, and the default is 64. CBS(conf-tunnel-isatap)# time-to-live 120 Optionally, enable Maximum Transmission Unit (MTU) discovery for the path that the tunnel uses. Discovery of the MTU helps to avoid fragmentation. CBS(conf-tunnel-isatap)# path-mtu-discovery CBS(conf-tunnel-isatap)# end CBS#
7.
NOTE: For ISATAP hosts to obtain automatic IPv6 addresses, you must turn on Router Advertisements in the RSW software on the X-Series chassis. See the RSW documentation for details.
Configuring Interfaces
220
IPv6IP Tunnel
An IPv6IP tunnel requires that you configure an IPv4 address for both ends of the tunnel (on the X-Series chassis and on the destination router). Typically, this kind of tunnel is used as a static connection between two IPv6-enabled networks that are separated by an Ipv4 network. The major steps to create the local/source end of the tunnel are:
z z z z
Create a VAP group and enable it to handle IPv6 traffic. Create a circuit with an IPv6 address and associate it with the VAP group. Create a circuit with an IPv4 address and associate it with the VAP group. Create the tunnel, specifying ipv6ip as the tunnel type, associating the tunnel with the VAP group and the IPv6 circuit, specifying the address of the IPv4 circuit as the source-address, and specifying the IPv4 address of the destination router as the destination-address.
Figure 17.
IPv6IP Tunnel
Example
To configure an IPv6IP tunnel using the parameters in Figure 17, perform these steps: 1. On the X-Series platform configure a VAP group, and enable IPv6 traffic processing. CBS# configure vap-group vg3 enable-ipv6 NOTE: A non-IPv4 flow rule is automatically configured with these parameters: non-ip-flow-rule ipv6_rule encapsulation ethernet type 34525 action pass-to-master activate 2. Identify the IPv4 address that the you want the VAP group to use to send traffic over the IPv4 network. In this example, the local IPv4 address is 172.48.40.50.
NOTE: This address will be the source address that you specify when configuring the IPv6IP tunnel. 3. Configure the first of two circuits with these characteristics: a. b. c. Choose a name for the circuit (in this example, tunnel_x). CBS# configure circuit tunnel_x Associate the circuit with the VAP group (in this example, vg3) CBS(conf-cct)# vap-group vg3 Assign an IPv6 address to the circuit (in this example, FD00:BC00:FFFF:2:0:0:0:2/48).
221
NOTE: Unlike the IPv6 addresses that are associated with 6to4 and ISATAP tunnels, this address has no pre-defined prefix and does not contain any encoding of the IPv4 source-address. CBS(conf-cct-vapgroup)# ip FD00:BC00:FFFF:2:0:0:0:2/48 %WARNING: IPv6 primary address was configured. No IPv4 aliases will be allowed for this circuit CBS(conf-cct-vapgroup-ip)# end 4. Configure a second circuit with these characteristics:
Choose a name for the circuit (in this example, tunnel_y). CBS# configure circuit tunnel_y Associate the circuit with the VAP group (in this example, vg3) CBS(conf-cct)# vap-group vg3 Assign the local IPv4 address that is being used by the VAP group to send traffic to the external IPv6 network. CBS(conf-cct-vapgroup)# ip 172.48.40.50/24 CBS(conf-cct-vapgroup-ip)# end
5.
Configure the IPv6IP tunnel. CBS# configure ipv6-tunnel ipv6ip circuit tunnel_x vap-group vg3 source-address 172.48.40.50 destination-address 172.48.40.51 CBS#
6.
Optionally, configure a time-to-live value for packets sent through the tunnel. Values range from 1 to 256 seconds, and the default is 64. CBS# configure ipv6-tunnel ipv6ip circuit tunnel_x vap-group vg3 time-to-live 120 CBS#
7.
Optionally, enable Maximum Transmission Unit (MTU) discovery for the path that the tunnel uses. Discovery of the MTU helps to avoid fragmentation. CBS# configure ipv6-tunnel ipv6ip circuit tunnel_x vap-group vg3 path-mtu-discovery CBS#
GRE Tunnel
A GRE tunnel requires that you configure an IPv4 address for both ends of the tunnel (on the X-Series chassis and on the destination router). Typically, this kind of tunnel is used as a static connection between two IPv6-enabled networks that are separated by an Ipv4 network. The major steps to create the local/source end of the tunnel are:
z z z z
Create a VAP group and enable it to handle IPv6 traffic. Create a circuit with an IPv6 address and associate it with the VAP group. Create a circuit with an IPv4 address and associate it with the VAP group. Create the tunnel, specifying gre as the tunnel type, associating the tunnel with the VAP group and the IPv6 circuit, specifying the address of the IPv4 circuit as the source-address and the IPv4 address of the destination router as the destination-address.
Configuring Interfaces
222
Figure 18.
GRE Tunnel
Example
To configure a GRE tunnel using the parameters in Figure 18, perform these steps: 1. On the X-Series chassis configure a VAP group, and enable IPv6 traffic processing. CBS# configure vap-group vg4 enable-ipv6 NOTE: A non-IPv4 flow rule is automatically configured with these parameters: non-ip-flow-rule ipv6_rule encapsulation ethernet type 34525 action pass-to-master activate 2. Identify the IPv4 address that the you want the VAP group to use to send traffic over the IPv4 network. In this example, the local IPv4 address is 172.64.50.60.
NOTE: This address will be the source address that you specify when configuring the IPv6IP tunnel. 3. Configure the first of two circuits with these characteristics: a. b. c. Choose a name for the circuit (in this example, tunnel_m). CBS# configure circuit tunnel_m Associate the circuit with the VAP group (in this example, vg4) CBS(conf-cct)# vap-group vg4 Assign an IPv6 address to the circuit (in this example, FD00:DE00:AAAA:5:0:0:0:5/48).
NOTE: Unlike the IPv6 addresses that are associated with 6to4 and ISATAP tunnels, this address has no pre-defined prefix and does not contain any encoding of the IPv4 source-address. CBS(conf-cct-vapgroup)# ip FD00:DE00:AAAA:5:0:0:0:5/48 %WARNING: IPv6 primary address was configured. No IPv4 aliases will be allowed for this circuit CBS(conf-cct-vapgroup)# end 4. Configure a second circuit with these characteristics:
Choose a name for the circuit (in this example, tunnel_n). CBS# configure circuit tunnel_n
223
Associate the circuit with the VAP group (in this example, vg4) CBS(conf-cct)# vap-group vg4 Assign the local IPv4 address that is being used by the VAP group to send traffic to the external IPv6 network. CBS(conf-cct-vapgroup)# ip 172.64.50.60/24 CBS(conf-cct-vapgroup-ip)# end
5.
Configure the GRE tunnel. CBS# configure ipv6-tunnel gre circuit tunnel_m vap-group vg4 source-address 172.64.50.60 destination-address 172.64.50.61
6.
Optionally, configure a time-to-live value for packets sent through the tunnel. Values range from 1 to 256 seconds, and the default is 64. CBS# configure ipv6-tunnel gre circuit tunnel_m vap-group vg4 time-to-live 120 CBS#
7.
Optionally, enable Maximum Transmission Unit (MTU) discovery for the path that the tunnel uses. Discovery of the MTU helps to avoid fragmentation. CBS# configure ipv6-tunnel gre circuit tunnel_m vap-group vg4 path-mtu-discovery CBS#
Configuring Interfaces
224
20
Backups, Upgrades, and Reinstallation
This chapter describes how to backup the configuration, upgrade XOS hardware, and reinstall XOS software. This information is provided to assist with upgrading to 86xx modules so that migration to XOS V9.x can take place. You cannot use the upgrade or reinstallation procedures to upgrade to XOS V9.x. The major topics in this chapter include:
z z z z z
VAP Backup on page 225 Preparing for Safe Upgrade on page 226 Upgrading to CPM-8600 or APM-8600 Modules on page 229 Creating a New Configuration Database on page 230 Reinstallation on page 230
VAP Backup
The Backup tool can backup everything under the specified directory tree for a CPM or all members of a VAP group. This information is tarred and zipped, with the output being placed in /root. To use the Backup tool, complete the following: 1. Log in as root. CBS# unix su Password: [root@xxxxx admin]# 2. Enter the following command at the root prompt. /usr/os/bin/archive_dir -v <vap-group-name> -d <directory-name> Command line options: -v <vap-group-name> -d <directory-name> -h -V If the -v option is used, you must specify the <vap-group name>. If the -v option is not used, then the CPM will be archived. Default = /usr/os (the directory may show as /crossbeam; it is the same as / usr/os) Help version
If you do not provide any options at the command line, the Backup tool runs in interactive mode and prompts for the VAP group name, directory to be backed up, and archive name. If you leave VAP group name blank, the directory from CPM is backed up. In backing up a VAP group, enter the path as it would show while logged in to a VAP. To restore a file: 1. 2. Unzip the file gzip d <targz_file> Move to: /tftpboot/[<vap-group-name>_<index>]
XOS Configuration Guide 225
3.
Untar the file: tar xvf <tar_file> If restoring a VAP group directory, repeat this process for all the VAP group indexes, including the <vap-group-name>_common directory.
NOTE: If you backed up a <vap-group-name> / without specifying another directory, you may see a Cannot mkdir: No such file or directory message. This can be ignored.
Select a submenu to view available automated workflows. Enter x to exit or ? for help. 2. Select 2. Upgrade XOS software and firmware... Please Enter Selection: 2 Automated Workflow Menu: Upgrade XOS software and firmware 1. 2. 3. 4. Upgrade XOS software and install recommended firmware Prepare system for a possible rollback Install XOS firmware only Roll back XOS software and firmware
226
5. Verify XOS software and firmware compatibility Select a task to execute an automated workflow. Enter b to go back, x to exit or ? for help. 3. Choose 2. Prepare system for a possible rollback Please Enter Selection: 2 Automated Workflow: Prepare system for a possible rollback Press ? for assistance on questions Analyzing system configuration... VRRP State : non-master CPM Redundancy Status : single Current XOS Software Release : 9.5.x-67 All external management interfaces will be shut off. Please use the console interface to monitor the system. WARNING: Rollback preparation will automatically reload the chassis! Begin rollback preparation now (y/n)? [n]: y Once the rollback (safe upgrade) procedure completes, return to the main AWS menu and perform the XOS upgrade.
Prerequisites
z
Perform the following steps: 1. 2. 3. 4. 5. 6. Reboot the CPM. Watch carefully for the GRUB menu. At the GRUB menu, type p on the keyboard then enter the password, x40rocks. At the GRUB prompt, type e to edit. Change the line number by pressing the down arrow until you reach the grub line starting with kernel. Add single to the end of this line, and press Enter to save the edit. Type b to boot the CPM in single user mode. Run the following command to copy from distribution 1 (d 1) to distribution 2 (d 2): /usr/os/bin/xos-copy-dist -d 2 Everything on the running partition is copied to the other partition. This could take up to two hours. 7. Reboot the CPM. The GRUB boot loader will show the option to boot from the second distribution.
227
8.
In dual CPM system, repeat this procedure to partition the disk in the second CPM. However, the CPM being partitioned must not be monitored by the other CPM for redundancy. To prevent monitoring, enter: CBS# cp-unknown-state {cp1|cp2} ignore For example, the following command forces CP2 to take no action while CP1 is being partitioned: CBS# cp-unknown-state cp2 ignore You would repeat this step when the other CPM is being partitioned, for example: CBS# cp-unknown-state cp1 ignore After the partitioning, you need to have the CPMs monitor each other for redundancy: CBS# cp-unknown-state {cp1|cp2} monitor
To change or list the kernel from either partition (d1 or d2) to be used on next boot: /usr/os/bin/xos-toggle-boot {d1|d2} When using ./xos-toggle-boot from the /crossbeam/bin directory to switch distributions and boot into another version of XOS, use ./xos-toggle-boot -l to see all the kernel versions available. When you are in XOS V8.x, V9.x will not be specified in the list. The kernel will be available, but XOS V8.x will not recognize it as V9.x. Always choose the first kernel listed without an XOS version number. Under XOS V8.x: [root@xxxxx bin]# ./xos-toggle-boot -l System is running on Distribution 1(Release 8.5.0) Default kernel for next boot is Distribution 1 1: Linux (2.4.21-47.ELuni) (Distribution 1 - 8.5.0) Available kernels: 0: Linux (2.4.21-47.EL) (Distribution 1 - 8.5.0) 1: Linux (2.4.21-47.ELuni) (Distribution 1 - 8.5.0) 2: Linux (2.4.21-47.ELuni) (Distribution 1 - 8.5.0) 3: Linux (2.6.18-53.el5_64smp) (Distribution 2) <-- Choose this kernel 4: Linux (2.6.18-53.el5_64smp) (Distribution 2) [root@TechPubs-X45 bin]# Under XOS V9.x: [root@xxxxx bin]# ./xos-toggle-boot -l System is running on Distribution 2 (Release 9.x.x) Default kernel for next boot is Distribution 2 3: Linux (2.6.18-53.el5_64smp) (Distribution 2 - 9.x.x) Available kernels: 0: Linux (2.4.21-47.EL) (Distribution 1 - 8.5.0) 1: Linux (2.4.21-47.ELuni) (Distribution 1 - 8.5.0) 2: Linux (2.4.21-47.ELuni) (Distribution 1 - 8.5.0) 3: Linux (2.6.18-53.el5_64smp) (Distribution 2 - 9.x.x) 4: Linux (2.6.18-53.el5_64smp) (Distribution 2 - 9.x.x) [root@xxxxx bin]# To change the default kernel from the CLI, use the cp-next-boot {cp1|cp2} distribution x command, where x is 1 or 2, then reboot. The show cp-next-boot CLI command displays which partition will be used to boot the CPM the next time the CPM boots.
228
NOTE: If you are using xos-copy-dist to copy from D2 to D1, the default boot disk will be D2 at the completion of the command. This is not the case if you are copying from D1 to D2.
Enable the Safe Upgrade feature This feature enables you to install a future upgrade on one partition of the CPM hard disk, while your existing XOS version and configuration remain on the other partition. You can then choose to boot the CPM in either partition. This enables you to try a new version while having the option to easily return to your existing version in case of issues.
z z
Run the same XOS version on both partitions and use the partitions to try different configurations. Create a backup of the partition.
NOTE: Dividing the CPM hard disk into 2 partitions does not degrade system performance. For a detailed partitioning procedure, refer to Manual Safe Upgrade Procedure on page 227. NOTE: If you are using xos-copy-dist to copy from D2 to D1, the default boot disk will be D2 at the completion of the command. This is not the case if you are copying from D1 to D2.
229
The following procedure assumes there are two empty slots. To upgrade APM-8400 to APM-8600, complete the following steps: 1. 2. 3. 4. Upgrade all existing APM modules to XOS Version 8.1 or later. Install the first new APM-8600 into an empty APM slot. Refer to the X80 Platform Hardware Installation Guide for more information about installing modules. Configure the APM-8600 into the VAP group. Bring down an APM-8400 module using the following command: configure module <slot-number> maintenance This command automatically initializes an APM-8600 into the VAP group. NOTE: For more information about the use of maintenance mode, see Maintenance Mode on page 297. 5. 6. Remove the APM-8400 that is in maintenance mode and replace it with another APM-8600. Repeat steps 3 through 5 for each APM-8400 until all new members in the VAP group are APM-8600 modules.
Reinstallation
Reinstallation is accomplished through the use of either the Install Server, or the USB Installer (USBI).For complete information on using the Install Server, refer to the Install Server User Guide. For complete information on using the USB Installer, refer to the USB Installer User Guide. If you have previously configured and run the Install Server, you may use the following procedure to re-install the XOS software. If you have not created your Install Server, refer to the Install Server User Guide. 1. From the system console on the CPM, reboot the CPM and issue an <Esc> <Ctrl-r> command during the reboot as follows: a. To reboot the CPM, issue the command: reload module <slot # x> Where x the slot number of your master CPM. b. At the start of the reboot process and during the reboot you will need to respond to prompts including: Do you want to save (your configuration) to startup-config? ... Proceed with reload? c. During the reboot process, there is a momentary pause with a message similar to the following: Crossbeam System, Inc. Bootstrap Complete Rev x.x.x.x This is described as the spinning | prompt. d. At the spinning | prompt, press <Esc> <Ctrl-r>.
230
e.
From the system console, use the following command to boot the XOS diskless CPM: ROM> boot net The boot net command sends out a broadcast message to locate the Install Server. The X-Series Platform is forced to boot from the Install Server, using the diskless partition with the matching MAC address.
2. 3.
From the system console, login as root. The default password is admin. Install the XOS system software, as follows, where <system dirname> is the directory name containing the system software release to be installed. # /usr/os/bin/install-xos /common/<system dirname> [-r1] NOTE: The -r1 is a RAID option. Prerequisites and RAID details are provided in RAID-Related Hard Drive Configuration and Repair on page 241. RAID options can only be enabled on a CPM during an install or reinstallation, as follows: default, no switch included, the system writes only to the primary drive. -r1, dual disk drives in a CPM-8600, the system writes identical data to both drives, creating a complete backup in case of one drives failure. You can use the RAID-1 option (-r1) in combination with the CPM SYNC feature.
4.
When the install-xos script completes, enter reboot at the prompt. The CPM then reboots from its own disk and prompts you for a login name and password.
231
232
A
In-Service Upgrade
This appendix describes In-Service Upgrades (ISU), an alternate method of upgrading XOS software while minimizing downtime. It includes the following major topics:
z z z z z z
In-Service Upgrade (ISU) Overview on page 233 In-Service Upgrade Process Overview on page 234 Modes of In-Service Upgrade on page 234 Understanding Optimal Batch Configuration on page 235 Executing a Sample In-Service Upgrade on page 236 Executing a Non-Interactive In-Service Upgrade on page 240
Prerequisites
The ISU feature has several requirements for successful completion, including redundant CPMs, APMs, and NPMs. The following are the minimum prerequisites to perform an In-Service Upgrade.
z z z z z
XOS V8.0 or later. Two CPMs. Two (or more) APMs per VAP group are recommended. Circuits configured with redundancy across two (or more) NPMs are recommended. If needed for applications, configure Application Monitor.
Verify that CPM redundancy is enabled and that CPMs are synchronized. Note that CPM synchronization may take between 45 and 90 minutes depending on your systems configuration. Verify that both CPMs are in election mode. Verify that the current boot partition is the same as cp-next-boot setting. Verify that adequate disk space (greater than 2GB) is available.
233
Limitations
The following are limitations of In-Service Upgrade:
z z z z z z z
Applications are not upgraded during the process only the XOS operating system. Dynamic routing tables are not preserved during upgrade. The XOS chassis does not operate at full capacity during the upgrade. No CPM redundancy exists during the upgrade. There is no state sharing between the upgraded and un-upgraded CPMs within a chassis. The configuration database is locked during the In-Service Upgrade. Interfaces without redundancy are not supported.
Prepare for the upgrade Copy, unzip, set permissions, and unpack the shar file Enter In-Service Upgrade Configure batches Issue the install command through CLI Save system configuration Save the batch configuration Transition the secondary CPM into offline mode and upgrade Reload the offline CPM into primary state Move batches Upgrade the old CPM
Configuration Analyzer
The Configuration Analyzer creates a default batch list using a predefined logic. Review the Understanding Optimal Batch Configuration on page 235 before proceeding. The default batch list can be viewed by executing the following commands: CBS# upgrade in-service CBS(in-service-upgrade)# show default-batches To use the default batch list, execute the following command to set the batch list: CBS# upgrade in-service CBS(in-service-upgrade)# batch-default
235
Standby and down modules are the first to be moved since these modules are not passing traffic. These modules are placed in the first batch, which cannot be modified. To view the modules in this batch, enter the following commands: CBS# upgrade in-service CBS(in-service-upgrade)# show standby-modules
Figure 19.
In-Service Upgrade
236
The example configuration contains a single VAP group consisting of two members and redundant circuits split across NPM1 and NPM2. 1. The shar file contains the files needed to execute the upgrade. These files must be copied to the correct location (/usr/os/rpm), unpacked, and have the correct permissions applied (chmod 777). This step must be performed on the primary CPM only. For more information, see Backups, Upgrades, and Reinstallation on page 225. At the unix prompt on one of the CPMs, execute the following commands: [root@xxx admin]# echo isu_child_tmo=10800 >> /usr/os/etc/cbscprmd.cf [root@xxx admin]# killall -HUP cbscprmd 3. 4. Repeat the previous step for the other CPM. Begin an Interactive In-Service Upgrade as shown below. The command batch-default clears any custom batches, and uses only system generated batches. CBS# upgrade in-service CBS(in-service upgrade)# batch-default Batch1: FW_1(3) Batch2: np2(2) Batch3: np1(1) Batch4: FW_2(4) CBS(in-service upgrade)# install <XOS version> The system displays informational messages regarding verifications and checks. Correct any issues before proceeding with the In-Service Upgrade. 5. Save the configuration to ensure that the upgraded half of the chassis is synchronized with the running configuration. Any unsaved configuration will be lost. Do you want to save it to startup-config? <Y or N>[Y]: Enter Y to save the configuration. 6. The current batch configuration is displayed as shown in the following example: Do you want to save the current batch configuration? <Y or N>[Y]: Batch1: fw_1(3) Batch2: np2(2) Batch3: np1(1) Batch4: fw_2(4) Done with batches? <Y or N> [Y]: Enter Y to indicate that you are done with batches or enter N to reconfigure the batches. NOTE: Please review the batch order, it cannot be changed during the In-Service Upgrade following completion of this step. 7. To continue the In-Service Upgrade, the secondary CPM will be reloaded into offline mode and upgraded, enter Y at the system prompt to continue. Proceed with install? <Y or N>[Y]: NOTE: The system automatically copies the shar file to the new CPM, the new CPM goes offline and performs the upgrade. This step takes about 30 minutes to complete. During this time, a series of informational messages are displayed to indicate progress. 8. You are prompted to bring the other CPM to Primary. Enter Y to continue. Continue with in-service upgrade to bring other CP to Primary? <Y or N>[Y]: NOTE: The new CPM will be rebooted into Primary CPM mode running the upgraded XOS software. 9. You are prompted to execute the next batch. This is the first batch to be moved that consists of the resources configured in Batch1. Continue with in-service upgrade to execute next batch? <Y or N>[Y]:
2.
237
The module in Batch1 is moved from the old CPM to the new CPM as shown in the following illustration.
Figure 20.
Batch1 Operation
NOTE: When all resources in the batch have been successfully moved to the upgraded half of the chassis, a successful completion message is displayed. The resources are now running the upgraded software, but are not processing traffic. 10. You are prompted to continue with the next batch. This is the second batch consisting of the resources configured in Batch2. The following illustration shows Batch2 moved to the new CPM.
Figure 21.
Batch2 Operation
NOTE: During this batch, the first NPMs are moved to the upgraded half of the chassis. After this transition, the interfaces are active, however, traffic is not processed by the new half of the chassis. Restart applications that do not tolerate an interface state transition after completion of this batch. 11. You are prompted to continue with the next batch. This is the third batch consisting of the resources configured in Batch3. The following illustration shows Batch3 moved to the new CPM.
In-Service Upgrade
238
Figure 22.
Batch3 Operation
NOTE: During this step, the second half of the NPMs are transitioned to the upgraded half of the chassis. This transition triggers the traffic flows to move from the old half to the new half of the chassis. All traffic is then processed by the upgraded half of the chassis and full interface redundancy is restored. 12. You are prompted to continue with the next batch. This is the fourth batch consisting of the resources configured in Batch4. The following diagram shows Batch4 moved to the new CPM.
Figure 23.
Batch4 Operation
NOTE: During this step, the remaining APMs transition to the new half of the chassis. This restores full APM capacity to the chassis. 13. Choose an option to complete or abort the In-Service Upgrade:
z z z
Option 1 aborts the In-Service Upgrade transitioning all NPMs and APMs to the old CPM and transitioning the new CPM offline. An interruption in service occurs during this transition. Option 2 transitions the old CPM into offline state, however the In-Service Upgrade remains in progress. Option 3 results in the old CPM upgrading to the new software and reloading into CPM secondary mode. This restores full redundancy to the chassis running the new software.
239
2.
Review the batch order. Once the batch order is agreed to, it cannot be modified during the rest of the In-Service Upgrade. Enter Y to indicate that you are done with batches or enter N to reconfigure the batches. For more information, see Custom Batch List on page 236. 7. You are then prompted to continue with the upgrade, CLI sessions will be terminated, and there will be a loss of CPM redundancy if you continue at this point. Enter Y to continue.
In-Service Upgrade
240
B
RAID-Related Hard Drive Configuration and Repair
With the dual drive and RAID capabilities in the APM-8600, APM-8650, APM-9600, CPM-8600, and CPM-9600, there exists a number of possible scenarios for upgrading, repairing, replacing, swapping, and otherwise changing drive configurations in these modules. This appendix provides information and procedures that deal with the following scenarios:
z z z z
Going from a non-RAID configuration to a RAID configuration Going from one RAID configuration to a different RAID configuration Going from a RAID configuration to a non-RAID configuration Correcting RAID drive failures
NOTE: Configuring RAID 1 with only a single drive installed is not supported. This chapter contains the following major topics:
z z z z z z z z z z z z
RAID Feature Definitions on page 242 Additional Documentation on page 242 Prerequisites for RAID on page 242 Important RAID Information on page 243 Obtain Hard Drive Information on page 244 Error Situations and Error Messages on page 247 Configure RAID on an Existing Non-RAID System on page 248 Change the Existing RAID Setting on a CPM-8600 on page 250 Change the Existing RAID Setting on the APM-8600s, APM-8650s, or APM-9600s in a VAP Group on page 251 Configuring Non-RAID on a CPM-8600 with Existing RAID 1 on page 251 Detect and Replace Failed Drives on an Existing RAID System on page 253 Identifying Drives in an APM-8600, APM-8650, or APM-9600 with Non-RAID Configured on page 255
241
Non-RAID The system writes only to the primary disk (on CPM-8600s), or to the disks independently (on APM-8600s, APM-8650s, and APM-9600s). RAID 0 The APMs write to both drives in a process called striping. This arrangement produces maximum speed/efficiency of operation, but the data is not duplicated and both disks are required to access the full content of the data. RAID 1 The CPMs or APMs write the same data to each disk at the same time, providing a complete, ongoing backup in case of one drives failure. You can use the RAID 1 option in combination with the CPM SYNC feature.
Additional Documentation
This appendix only covers RAID configuration. For related information, refer to the following information:
z z
For XOS and module upgrades, refer to the upgrade sections of this configuration guide. For information about removing and reinserting CPM and APM modules and physically inserting hard drives, refer to the APM-9600, APM-8650, APM-8600, CPM-9600, and CPM-8600 Hard Disk Replacement and Upgrade Guide. For Install Server information, refer to the Install Server User Guide. For information on using the USB Installer, refer to the USB Installer User Guide.
z z
CPM-8600s, CPM-9600s, APM-8600s, APM-8650s, and/or APM-9600s (with various RAID and non-RAID standard configurations). RAID 0 or RAID 1 requires two hard drives of the same capacity. Console connection to issue CLI and UNIX commands to modules. One of these methods of installing XOS software
Install Server Software with diskless partition that allows the CPM-8600 to boot from the server The latest XOS USB Installer, plugged into the CPM USB port.
242
Disk Drive and RAID Information for CPM-8600s, APM-8600s, and APM-8650s
The following information will help you understand the various RAID scenarios explained in this document.
z
On CPM-8600s, APM-8600s, and APM-8650s, the two drive slots are labeled SATA1 (the inside slot) and SATA2 (the outside slot). Refer to the hard drive diagram in Identifying Drives in an APM-8600, APM-8650, or APM-9600 with Non-RAID Configured on page 255. If you are installing only a single drive into a CPM-8600 or APM-8600, install the drive into the SATA1 position (inside slot).
To install RAID, change the RAID setting to a different RAID type, or uninstall RAID, you must do an XOS reinstallation. The RAID/non-RAID setup is part of the installation process and part of the installation command. If you are converting to a RAID configuration from non-RAID, you must add a blank drive to the SATA2 drive slot. If you are converting back to non-RAID from a RAID configuration, Crossbeam recommends that you remove the SATA2 hard drive. If you do not remove the second drive, and later the non-RAID SATA1 drive fails, you must move the SATA2 bootable drive to the SATA1 position. If you replace the failed SATA1 drive with a blank drive, the CPM-8600 will mistakenly boot from the original SATA2 RAID 1 drive, or display an error message.
z z
Always use a blank drive to repair a failed RAID 1 drive situation. This ensures that the system will boot from the existing, working RAID 1 drive as intended.
243
On an APM-8600, APM-8650, or APM-9600, RAID (or non-RAID) is configured for an entire VAP group, not for individual APMs, and is set up using the configure vap-group command, not by XOS reinstallation. When an installed APM-8600, APM-8650, or APM-9600 becomes an active part of the VAP group, its drives, if present, are automatically set up for the RAID operation established for that VAP group.
NOTE: APM-8600s, APM-8650s, and APM-9600s cannot be configured in the same VAP group. Crossbeam recommends that all APMs in a VAP group have the same configuration.
Table 20.
Command or Tool show module status show module status disk cat /proc/mdstat
Type of RAID set up (raid1) Names, numbers, and positions of the drives as follows: sda which is SATA1, the inside drive slot sdb which is SATA2, the outside drive slot Refer to the diagram in Identifying Drives in an APM-8600, APM-8650, or APM-9600 with Non-RAID Configured on page 255.
Total number of drives in the RAID group ( [2/2] ) v3_2 (cpm): root$ cat /proc/mdstat Personalities : [raid0] [raid1] read_ahead 1024 sectors Event: 3 md1 : active raid1 sdb1[1] sda1[0] 93433920 blocks [2/2] [UU]
244
md5 : active raid1 sdb5[1] sda5[0] 2104448 blocks [2/2] [UU] md6 : active raid1 sdb6[1] sda6[0] 2104448 blocks [2/2] [UU] ...... unused devices: <none> NOTE: MD1 is always configured as raid1, regardless of the RAID0 or RAID1 configuration.
z
An indication that both drives are in sync: [UU] or, as in the following partial example, one drive is degraded [_U] (not in sync or failed): md1 : active raid1 sdb1[1] sda1[0] 93433920 blocks [2/1] [_U] [===>.................] recovery = 17.8% (16638196/93433920) finish=127.9
NOTE: If a RAID drive has failed, the output of the cat /proc/mdstat command includes (F) next to the failed drive information. For example: Personalities : [raid1]md0 : active raid1 sda1[0] sdb1[1](F) 71681920 blocks [2/1] [U_] In this example, the [U_] indicates that sdb1 is either degraded or has failed. The (F) indicates that it is failed, not degraded. The following example shows a CPM-8600, previously set up for RAID 1. One drive failed and was replaced (Part 1) but the drives are not synchronized. The xos-raid-add command is issued (Part 2) and the system begins the synchronization process for the two drives. In the example, md1 is 47% synchronized (Part 3). Part 1: New drive inserted but drives are not synchronized [root@mysysCPM2 admin]# cat /proc/mdstat Personalities : [raid0] [raid1] read_ahead 1024 sectors Event: 5 md1 : active raid1 sda1[0] 104320 blocks [2/1] [U_] md5 : active raid1 sda5[0] 505920 blocks [2/1] [U_] md6 : active raid1 sda6[0] 1003904 blocks [2/1] [U_] md7 : active raid1 sda7[0] 8008256 blocks [2/1] [U_] md8 : active raid1 sda8[0] 28001152 blocks [2/1] [U_] unused devices: <none> Part 2: Second drive is added to the RAID1 pair [root@mysysCPM2 admin]# /usr/os/bin/xos-raid-add Duplicating firsSCSI device sdb: 195371568 512-byte hdwr sectors (100030 MB) t drive partition Table... SCSI device sdb: 195371568 512-byte hdwr sectors (100030 MB) Hot adding secondary drive... /dev/md1 /dev/md5 /dev/md6 /dev/md7 /dev/md8
245
Part 3: Check synchronization progress, md1 shows 47% complete [root@mysysCPM2 admin]# more /proc/mdstat Personalities : [raid0] [raid1] read_ahead 1024 sectors Event: 11 md1 : active raid1 sdb1[2] sda1[0] 104320 blocks [2/1] [U_] [=========>...........] recovery = 47.0% (50096/104320)
246
Table 21.
SATA1
CPM-8600 Drive Mismatch Situations: Disk config mismatch RAID 1 non-RAID SATA1:RAID1 and SATA2:non-RAID SATA1:non-RAID and SATA2:RAID1 If you are configuring RAID, reverting to non-RAID, or changing to a different RAID setting, unless there is a drive you need to remove to preserve, just continue with the configuration process and the system will reconfigure the mismatched drive as needed.
non-RAID RAID 1
CPM-8600 Conversion from RAID to non-RAID without Removing the SATA2 Drive RAID 1 RAID 1 Warning Message (see text below)a If the system proceeds with a normal XOS installation, the first drive will become non-RAID and you will end up with a non-RAID/RAID 1 drive mismatch. So the system stops the reinstallation process with the warning message (detailed below the table). At this point, if you want to preserve SATA2, respond q to quit the install process, then remove the drive. Otherwise, respond y to continue the install and allow the rewrite. If the second drive was bootable, it will be made non-bootable. CPM-8600 RAID 1 Failed Drive and Missing Drive Situations Failed RAID 1 Replacing the drive with a non-blank drive will cause a mismatch error, or the CPM will boot from the wrong drive. You must replace the failed drive with a blank drive. If you place another bootable drive in the SATA1 position, the system will not boot off your good, SATA2 RAID 1 drive.
a. Warning message received when converting from RAID to non-RAID on a CPM-8600 and user fails to remove the SATA2 RAID-configured drive.
WARNING: This is a non-RAID CPM install and a second drive is present. To make the first drive bootable, we must rewrite the second drive's MBR to make it non-bootable. Respond 'y' to continue with the rewrite, respond 'n' to leave the MBR alone (you know it is non-bootable), or 'q' to quit the install and remove the drive. (y|n|q)? [y]
247
If you need physical installation instructions, refer to the more complete instructions in the APM-9600, APM-8650, APM-8600, CPM-9600, and CPM-8600 Hard Disk Replacement and Upgrade Guide. 6. When you reinsert the CPM-8600, the CPM-8600 boots as usual and you must stop the boot process so you can issue the install command. In this case, from the console, as soon as the Spinning Pipe prompt displays, type: <ESC><Ctrl-r> You will see the ROM> prompt. NOTE: If the CPM-8600 does not boot as usual, contact Crossbeam Customer Support. 7. At the ROM> prompt, you have two ways to install the XOS software:
Use an Install Server. See Installing XOS Using an Install Server, next. Use the Crossbeam USB Installer (USBI). See Installing the XOS Software Using the Crossbeam USB Installer (USBI) on page 249.
248
Repeat these steps if you are installing RAID on a second CPM-8600. NOTE: If you have two CPM-8600s, follow the CPM redundancy process as detailed in Configuring CPM Redundancy on page 121 to set up two CPM-8600s in sync with each other or to resynchronize the two CPM-8600s.
Installing the XOS Software Using the Crossbeam USB Installer (USBI)
1. 2. 3. At the ROM> prompt, type boot usb. When the menu appears, select either Install XOS Release 9.x or Later or Install XOS Release 8.x or 7.x, depending on the XOS version you want to install. The USBI boots the appropriate kernel version. Enter the login and password provided, accept the license if required, and follow the on-screen instructions:
Select the XOS version to install. Answer the hard disk configuration questions. (The USBI presents only valid hard disk options.) Install XOS. Installing from the USBI takes 10 to 20 minutes, on average.
4.
When the installation completes, select an option from the menu. Crossbeam recommends that you halt the CPM. When the system has halted, unseat the CPM, remove the USBI device, and then reseat the CPM to reboot it.
Warning: Do not remove the USBI while the CPM is booted from the device. Do not leave the USBI in the CPM during normal operation. Either action can compromise the integrity of the USBI device.
NOTE: After the system halts, you may see one or more error messages, and the Active LED on the CPM may blink. If you received the System halted message, you can ignore the errors and the blinking LED and safely reboot the CPM.
249
4. 5.
After reinserting the APM, the next time that APM is used in the VAP group, the system detects the changes and reconfigures the drive(s) as needed for the new RAID setting. Continue this process until you have added the needed hard drives to each of the APMs.
Use an Install Server. See Installing XOS Using an Install Server, next. Use the Crossbeam USB Installer (USBI). See Installing the XOS Software Using the Crossbeam USB Installer (USBI) on page 250.
Repeat these steps if you are installing RAID on a second CPM-8600. NOTE: If you have two CPM-8600s, follow the CPM redundancy process as detailed in Configuring CPM Redundancy on page 121 to set up two CPM-8600s in synchronization with each other or to resynchronize the two CPM-8600s.
Installing the XOS Software Using the Crossbeam USB Installer (USBI)
1. 2. 3. At the ROM> prompt, type boot usb. When the menu appears, select either Install XOS Release 9.x or Later or Install XOS Release 8.x or 7.x, depending on the XOS version you want to install. The USBI boots the appropriate kernel version. Enter the login and password provided, accept the license if required, and follow the on-screen instructions:
250
Select the XOS version to install. Answer the hard disk configuration questions. (The USBI presents only valid hard disk options.) Install XOS. Installing from the USBI takes 10 to 20 minutes, on average.
4.
When the installation completes, select an option from the menu. Crossbeam recommends that you halt the CPM. When the system has halted, unseat the CPM, remove the USBI device, and then reseat the CPM to reboot it.
Warning: Do not remove the USBI while the CPM is booted from the device. Do not leave the USBI in the CPM during normal operation. Either action can compromise the integrity of the USBI device.
NOTE: After the system halts, you may see one or more error messages, and the Active LED on the CPM may blink. If you received the System halted message, you can ignore the errors and the blinking LED and safely reboot the CPM.
Change the Existing RAID Setting on the APM-8600s, APM-8650s, or APM-9600s in a VAP Group
Caution: Setting or changing the RAID settings on the VAP group deletes everything on the hard drives in that group.
To change the RAID setting on the APMs in a VAP group, complete the following steps: 1. From the CLI, configure the desired RAID feature setting to one of the following. non-RAID Drives work independently, or device can work with only one drive. CBS# configure vap-group <VAP_group_name> no raid RAID 0 Drives work at maximum speed and efficiency with different data written to each drive. Both working drives are required to access the data. CBS# configure vap-group <VAP_group_name> raid 0 RAID 1 Drives work as a single drive with the same data written to both drives (data is duplicated). CBS# configure vap-group <VAP_group_name> raid 1 2. (Change From one RAID Setting to Another) Reload the APMs so that the configuration takes effect. To minimize traffic interruption, reload slot-by-slot as follows: CBS# reload module <slot#> 3. To make this configuration permanent, save the configuration.
NOTE: If you convert from RAID to non-RAID, and leave the second hard drive installed, be aware that the second drive is accessed as /mnt/aplocaldrive_2. Refer to Identifying Drives in an APM-8600, APM-8650, or APM-9600 with Non-RAID Configured on page 255.
251
To convert from RAID to non-RAID on a CPM-8600, follow these steps: 1. 2. 3. Log on to the console port as admin. Back up the Systems Running Configuration (if desired) using the CLI: CBS# copy running-config <file-name> FTP the configuration file to a workstation or server or transfer the configuration file to an external storage device. By default, the configuration file is stored in the following location: /tftpboot/.private/home/admin/<file-name> 4. Shut down or reboot the system from the CPM-8600 using one of the following CLI commands:
Use the shutdown command if you want to remove the second hard drive from the CPM-8600. This is recommended. However, if you do leave the second drive in, the install process will make the drive non-bootable (after warning you). CBS# shutdown Remove the module and remove the second hard drive. If you need physical installation instructions, refer to the more complete instructions in the APM-9600, APM-8650, APM-8600, CPM-9600, and CPM-8600 Hard Disk Replacement and Upgrade Guide. document.
Use the reload all command if you choose to leave the second drive in the CPM-8600. CBS# reload all
5.
When you reinsert the CPM-8600 (or issue the reload all command) the module reboots. You must stop the boot process so you can issue the install command. From the console, as soon as the Spinning Pipe prompt displays, type: <Esc><Ctrl-r> You will see the ROM> prompt.
6.
At the ROM> prompt, you have two ways to install the XOS software:
Use an Install Server. See Installing XOS Using an Install Server, next. Use the Crossbeam USB Installer (USBI). See Installing the XOS Software Using the Crossbeam USB Installer (USBI) on page 252.
Repeat these steps if you are installing RAID on a second CPM-8600. NOTE: If you have two CPM-8600s, follow the CPM redundancy process as detailed in Configuring CPM Redundancy on page 121 to set up two CPM-8600s in sync with each other or to resynchronize the two CPM-8600s.
Installing the XOS Software Using the Crossbeam USB Installer (USBI)
1. 2. At the ROM> prompt, type boot usb. When the menu appears, select either Install XOS Release 9.x or Later or Install XOS Release 8.x or 7.x, depending on the XOS version you want to install. The USBI boots the appropriate kernel version.
252
3.
Enter the login and password provided, accept the license if required, and follow the on-screen instructions:
Select the XOS version to install. Answer the hard disk configuration questions. (The USBI presents only valid hard disk options.) Install XOS. Installing from the USBI takes 10 to 20 minutes, on average.
4.
When the installation completes, select an option from the menu. Crossbeam recommends that you halt the CPM. When the system has halted, unseat the CPM, remove the USBI device, and then reseat the CPM to reboot it.
Warning: Do not remove the USBI while the CPM is booted from the device. Do not leave the USBI in the CPM during normal operation. Either action can compromise the integrity of the USBI device.
NOTE: After the system halts, you may see one or more error messages, and the Active LED on the CPM may blink. If you received the System halted message, you can ignore the errors and the blinking LED and safely reboot the CPM. 5. If your system has a second CPM-8600, repeat the above steps to convert it to non-RAID.
253
CBS# shutdown 6. 7. 8. 9. Remove the CPM-8600 with the bad drive from the system. Remove the failed drive from the CPM-8600 board by removing the four screws using a Phillips #1 screwdriver (or a small flat blade screwdriver if necessary). Install a blank replacement drive. Reinsert the CPM-8600 into the chassis.
10. To sync the drives on CPM-8600 with the replacement HDD, connect to the CPM-8600 using the console connection and log into XOS as root: 11. Log into XOS as root: CBS# unix su Password: [root@xxxxx admin]# 12. Issue the command: /usr/os/bin/xos-raid-add
254
Table 22.
Position on the Board (see diagram below) SATA1 (inside slot) SATA2 (outside slot)
You can determine a drives slot position by examining the /proc/scsi/scsi file as follows: 1. Log on to the CLI and use the following command to see information about the APM-8600s. CBS# show ap-vap-mapping Module Slot Status VAP IP Address AP6 8 Up 1.1.2.101 2. VAP Group v3 Index 1 Master true
Use the VAP IP address information to log in to the VAP group from the Unix prompt and access the / proc/scsi/scsi file. CBS# uni su [root@mycomputer admin]# rsh 1.1.2.101 Last login: Sat Apr 28 14:36:35 on ttyS0 v3_1 (mycomputer): root$ cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: ATA Model: HTE721010G9SA00 Rev: Type: Direct-Access ANSI Host: scsi3 Channel: 00 Id: 00 Lun: 00 Vendor: ATA Model: HTE721010G9SA00 Rev: Type: Direct-Access ANSI fw_1 (10PercentCPM2): root$
The example above shows the /proc/scsi/scsi file with two disks installed. The scsi0 drive refers to the drive in the SATA1 slot; scsi3 refers to SATA2, the drive in the outside slot. Refer to the diagram below.
255
Figure 24.
Module Disk-Drives
Figure 25.
Disk Drives
256
C
Swatch Dynamic Display Tool
This chapter describes the Swatch tool, used to display dynamically-changing data related to the X-Series Platform operation. This chapter includes the following major topics:
z z z z z z z z
Overview on page 257 Understanding the Swatch Tool on page 258 Starting and Stopping the Swatch Tool on page 259 Using Single Key Commands on page 259 Swatch Tool Configuration Guidelines on page 260 Performance Considerations on page 264 Using Existing Swatch Tool Configuration Files on page 264 Troubleshooting the Swatch Tool on page 265
Overview
The XOS Open Security Appliance Swatch Dynamic Display Tool (Swatch) is a Linux tool designed to display dynamically-changing data on a terminal screen in a customized display format. The Swatch tool runs from the UNIX prompt and the XOS CLI. Originally designed to format and display device packet statistics from Linux/proc files, the Swatch tool now allows you to easily spot changes in your system status and can display any type of data that can be obtained from an ASCII file or by executing any Linux command that writes to a standard output. The Swatch tool supports the following data types:
z z z z
The Swatch tool can also perform simple arithmetic operations on data, such as rate, min, max, sum, and diff. All data can be reset (resets min, max, rate) and counter data can be zeroed out.
257
Parses the file using a TCL interpreter, allowing you to use any TCL commands. After parsing the configuration files, the Swatch tool displays it on the first screen. Defines one or more acquisition files to obtain data from. The Swatch tool periodically reads all fields from acquisition files into Swatch variables in memory. Defines one or more virtual screens that can be displayed. The Swatch tool periodically displays values of Swatch variables on a virtual screen.
Data from APMs can be displayed using the Swatch tool by using shell commands such as telnet or rsh. These commands allow you to log in to a remote slot and then execute a command on that slot.
4.
5. 6.
258
259
Use the first few lines of the file to set default values for TCL variables, which can be overridden by using a -D option on the Swatch command line. You can use -Dline=x to limit the output display. For example, ./swatch -Dline=10 interrupts will display the interrupt stats from line 10 onwards. Minimize the number of swacquire commands within a given configuration file. Minimize the number of lines and columns displayed on a virtual screen. Place a Title line at the top of each virtual screen. Use unique virtual screen names to allow users to easily identify the screen. Use the counter option on all swread commands to indicate if an item is a counter. Use the once option on swread commands if the item value does not change. Define only one or two different screen types per configuration file.
z z z z z z z
swacquire Syntax
swacquire [file <filename>] [shell <shell>] [shellinit <prompt> <resp>] [shellcmd <prompt> <resp>] [period <poll-period>] [delim <delim-chars>] Where: file parameter is the existing files (including /proc files) or you can specify a file that saves the shell command output. shell parameter designates the running commands that generate output. shellinit parameter defines a one-time dialog. For example, use this parameter to specify a login-prompt/username or password-prompt/password. shellcmd parameter defines a dialog at each poll period. For example, use this parameter to specify a shell prompt/command executed in a telnet session. delim parameter specifies a set of characters used as a delimiter between fields. The following example specifies that the file /proc/net/dev is read every 2 seconds: swacquire file /proc/net/dev period 2
260
swread Syntax:
swread <varname> <line-spec> <field-spec> <fmt> [counter] [once] Where: <varname> is a Swatch tool variable name that holds values read from a file. <line-spec> and <field-spec> define the line# and field# position within a file. <fmt> defines how a data value is read. This is the same value as the scanf() function. counter parameter indicates that the data item is a counter. Note, this value can be zeroed out. once parameter indicates that a data item is read one-time only. NOTE: All swread commands are relative to the last swacquire command The following example defines an integer variable pktdrops at line 2; field 1 is read from the previous acquisition file with a format of %u. This variable is a counter. swread pktdrops 2 1 %u counter
swcalc Syntax
swcalc <varname> <operation> <operand> [<operand> ...] Where: <varname> is the result variable name. If this is an array, the number of array indices in the operands must match the number of array indices in the result. <operation> can be rate, min, max, add, or sub. <operand> is the name of Swatch tool variable used as a source for the operation. If this is an array, the number of array indices in the operands must match the number of array indices in the result. The following example defines an array drop rate that is calculated by computing the rate of the values in the pktdrops array. swcalc droprate(1:10) rate pktdrops(1:10)
261
swaggr Syntax
swaggr <varname> <operation> <operand> [<operand> ...] Where: <varname> is the result variable name. This must be a scalar value. <operation> is the sum or diff operation. <operand> is the name of the Swatch tool variable used as the source for operation. This can also be an array. The following example defines a scalar variable totdrops that is calculated by computing the sum of all values in the pktdrops array. swaggr totdrops sum pktdrops(1:10)
swscreen Syntax
swscreen <screenname> [period <n>] Where the period parameter defines the screen refresh rate in seconds. The default value is 1 second. The following example defines a virtual screen named devpktcnt that when displayed, refreshes every 2 seconds. swscreen devpktcnt 2
swdisplay Syntax
swdisplay <line-spec> <col-spec> <size> <fmt> [<varname>] [scale <scale-factor>] Where: <line-spec>, <col-spec> parameter defines the position of the display item on the virtual screen. <size> is the total width of the display item. <fmt> is the format used for writing a display item. This value is the same as the printf function. <varname> is the name of the previously defined Swatch tool data variable. scale parameter defines the scale factor applied to the data variable prior to output. NOTE: All swdisplay commands are relative to last swscreen command. The following example displays the values of the array pktdrops at column 15 on lines 4-13, with a width of 10 characters. swdisplay 4@1 15 10 %u pktdrops(1:10)
262
SLOT_IP(1)..SLOT_IP(14), contains the IP address of slot or the value 0.0.0.0 if no slot is present. SLOT_NAME(1)SLOT_NAME(14), contains the host name of the slot or unknown if the slot is not present.
Variable names can be any alphanumeric string. For example, pktdrops. Variables can be either scalar or arrays. Variables are only visible in current configuration file, unless they are prefixed with global tag. Array elements are specified as <varname>(<index>) where the index is a non-negative integer. The notation varname(<index1>:<index2>) is shorthand, which expands the command for each variable instance between varname(index1) and varname(index2) inclusive.
263
apmdevstats.swc - displays packet statistics per APM slot (one screen for each selected network device). Use a Ddevs value of <dev1>, <dev2>, and so on to specify the desired devices. The default value is devs=sdp0. apmdevstats_slot.swc - displays packet statistics per device slot (one screen for each selected APM slot). Use a Dslots value of <slot1>, <slot2>, and so on to specify a list of slots. Valid slot values are from 3 to 12. apmfwstats.swc - displays firewall statistics per APM slot in a single screen display. Use a Dslots value of <slot1>, <slot2>, and so on to specify a list of slots. Valid slot values are from 3 to 12. apmfwstats_slot.swc - displays firewall stats per device (one screen per selected APM slot). Use a Dslots value of <slot1>, <slot2>, and so on to specify a list of slots. Valid slot values are from 3 to 12. apmsnmpstats.swc - displays IP, ICMP, TCP, and UDP statistics and rates for the APMs. cbsinitdstats.swc - displays a list of Crossbeam daemons and their status. fabricstats.swc - displays NPM statistics and rates for the switched data path fabric on the dataplane. flowcalcstats.swc - displays information on flow calculation statistics. flowsched.swc - displays which member of a VAP Group is eligible for the next flow assignment. groupintstats.swc - displays statistics for group interface members. health_cpubsy.swc - displays CPU activity for the APMs and CPMs that are installed. health_cpumem.swc - displays CPU load, utilization, and memory information for each physical slot. health_temp.swc - displays CPU and Board minimum, maximum, and chassis current temperature information. moduleuptime.swc - displays the Linux up-time for each NPM and APM slot. netifstats.swc - displays packet statistics for all Linux devices on a current slot. This file can be run on a CPM or VAP. npmdevstats.swc - displays packet statistics for NPM physical interfaces. Use a Dslots value of <slot1>, <slot2>, and so on to specify a list of slots. npmfragstats.swc - displays virtual defragmentation (vdf) statistics per NPM.
z z z z z z z z z z z z z z z
Performance Considerations
The following are performance consideration to heed when using the Swatch tool.
There is one child process for computing all derived or calculated data it. For example, data it defined in swcalc or swaggr commands. There is one child process for each swacquire command in the configuration files listed on startup. Note, if a swacquire command has a shell option, an additional child process is created to execute the shell command in.
NOTE: Some shell commands may cause TCP/UDP connections to remote hosts or cause new processes to be created on a remote host.
264
For swacquire file commands, make sure the file exists. For swacquire shell commands, make sure that the shell command can be invoked manually. Run the Swatch tool with a -g <n> option to create debug files. Note, higher debug levels give more debug information. Debug files are located in the swatch.xxxxx.log, where the xxxxx is the child process ID.
Check the swdisplay line, column, and format options for the data item. Run the Swatch tool with a -x <n> option to download program objects. Note, higher dump levels give more dump information.
Reduce the number of Swatch tool programs being run simultaneously. Reduce the number of startup configuration files listed on Swatch tool command line. Reduce the polling rate for swacquire commands (period option). Reduce the display refresh rate for swscreen commands (period option).
Reduce the number of Swatch tool configurations that remotely access APMs or NPMs. Reduce the polling rate for swacquire commands that remotely access APMs or NPMs.
NOTE: Some CPM programs, such as apmdevstats and npmdevstats, query data on remote slots through the control bus.
265
266
D
Crossbeam SNMP MIB Reference
This chapter contains a reference to Crossbeam simple network management protocol (SNMP) management information base (MIB) files. The main topics in this appendix are:
z z z z z z z z z z z
Overview on page 267 New Crossbeam MIB Entries in XOS V9.5. on page 269 Greenlight Element Manager (GEM) MIB Reference on page 269 XOS Alarms and SNMP Traps on page 275 Using a MIB browser on page 268 CROSSBEAM-SYSTEMS-MIB Reference on page 280 CBS-HARDWARE-MIB Reference on page 281 CBS-MODULE-RESOURCES-MIB Reference on page 288 CBS-VAPGROUP-MIB Reference on page 293 CBS-VRRP-MIB Reference on page 294 Standard MIBs on the Crossbeam X-Series Platform on page 296
Overview
The following five Crossbeam SNMP MIB files are located in the /usr/share/snmp/mibs directory:
z z z z z
Each entry in the Crossbeam MIBs contain an object identifier (OID). The Crossbeam specific reference is 6848 as seen here: .1.3.6.1.4.1.6848 iso(1) org(3) dod(6) internet(1) private(4) enterprises(1) crossbeamSystems(6848) Entries in the Crossbeam MIBs are organized into branches with unique OIDs. For example: CBS-HARDWARE-MIB::cbsHardware .1.3.6.1.4.1.6848.2.1 iso(1) org(3) dod(6) internet(1) private(4) enterprises(1) crossbeamSystems(6848) cbsMgmt(2) cbsHardware(1) The information in this appendix describes a tree view into Crossbeam MIBs with a reference to the complete OID for each MIB entry. For comprehensive details, view each MIB entry in a MIB browser.
267
If you do not have access to a MIB browser, access the control processing module (CPM) from a command prompt and display the MIB files in /usr/share/snmp/mibs for details related to each MIB entry.
Ability to launch the Crossbeam Greenlight Element Manager (GEM) in a new browser window from HP OpenView. A node group representing all Crossbeam hardware making it easier to apply changes to only Crossbeam equipment. Access this node group from Inventory > Node Groups > Crossbeam Devices. Integration of proprietary Crossbeam MIBs into HP OpenView / NNMi, enabling the custom polling of Crossbeam MIBs, and provides information in addition to standard MIBs. Overall device status is indicated by icon color.
For information, see the Crossbeam Systems Integration Package V1.0 for HP OpenView Network Node Manager 9.00i Release Notes.
268
Table 23.
Fan Tray compatibility and status Firmware revision status CP Redundancy state Minor, Major, and Critical Alarms
CBS-MODULE-RESOURCES-MIB
CBS-VRRP-MIB
Table 24.
View / Component System View Hostname Chassis Type Alarms Hardware Properties Revision Serial Number Part Number Chassis Temp DBHA XOS Version Firmware Version Modules Module Name Module Status VAP Groups Name Application
MIB-II CBS-HARDWARE-MIB See Alarms View CBS-HARDWARE-MIB CBS-HARDWARE-MIB CBS-HARDWARE-MIB CBS-HARDWARE-MIB See DBHA View MIB-II See Firmware View CBS-HARDWARE-MIB CBS-HARDWARE-MIB CBS-VAPGROUP-MIB
sysName cbsHwSystemDescription
sysDescr
CBS-VAPGROUP-MIB CBS-VAPGROUP-MIB
cbsVgVapCount cbsVgMaxLoadCount
269
MIB CBS-HARDWARE-MIB
Compatible
CBS-HARDWARE-MIB
Revision
CBS-HARDWARE-MIB
Serial Number
CBS-HARDWARE-MIB
Part Number
CBS-HARDWARE-MIB
Power Type Power Supplies Power Supply Power Feed Firmware View Slot Module Type Board Revision Bootstrap Rev Current Required Bootloader Rev Current Required Ctrl FPGA revision Focus FPGA revision Current Required Current Required
CBS-HARDWARE-MIB CBS-HARDWARE-MIB CBS-HARDWARE-MIB CBS-HARDWARE-MIB CBS-HARDWARE-MIB CBS-HARDWARE-MIB CBS-HARDWARE-MIB CBS-HARDWARE-MIB CBS-HARDWARE-MIB CBS-HARDWARE-MIB CBS-HARDWARE-MIB
cbsHwModuleID cbsHwModuleDescription cbsHwModuleBoardRevision cbsHwModuleBootStrapRev cbsHwModuleReqBootStrapRev cbsHwModuleBootloaderRev cbsHwModuleReqBootloaderRev cbsHwModuleCtrlFpgaRev cbsHwModuleReqCtrlFpgaRev cbsHwModuleFocusFpgaRev cbsHwModuleReqFocusFpgaRev
DBHA View Failover Group ID CBS-VRRP-MIB crossbeamSystems.cbsMgmt.cbsVrr p.cbsVrrpFailoverGroupTable.cbsVrr pFailoverGroupEntry.cbsVrrpFailover GroupID crossbeamSystems.cbsMgmt.cbsVrr p.cbsVrrpFailoverGroupTable.cbsVrr pFailoverGroupEntry.cbsVrrpFailover GroupName
270
CBS-VRRP-MIB
MIB CBS-VRRP-MIB
MIB Object crossbeamSystems.cbsMgmt.cbsVrr p.cbsVrrpFailoverGroupTable.cbsVrr pFailoverGroupEntry.cbsVrrpStatus crossbeamSystems.cbsMgmt..cbsVrr p.cbsVrrpFailoverGroupTable.cbsVrr pFailoverGroupEntry.cbsVrrpPriority crossbeamSystems.cbsMgmt.cbsVrr p.cbsVrrpFailoverGroupTable.cbsVrr pFailoverGroupEntry.cbsVrrpAdminPr iority crossbeamSystems.cbsMgmt.cbsVrr p.cbsVrrpFailoverGroupTable.cbsVrr pFailoverGroupEntry.cbsVrrpMasterP riority
Actual Priority
CBS-VRRP-MIB
Configured Priority
CBS-VRRP-MIB
Master Priority
CBS-VRRP-MIB
NPM View Slot Module Type Hardware Properties Revision Serial Number Part Number Status Uptime Interfaces Label State BW Data Rate(In) Data Rate(Out) APM View Slot Module Type Vap Name Hardware Properties Revision Serial Number Part Number Module Status Uptime Application CBS-HARDWARE-MIB CBS-HARDWARE-MIB CBS-VAPGROUP-MIB CBS-HARDWARE-MIB CBS-HARDWARE-MIB CBS-HARDWARE-MIB CBS-HARDWARE-MIB cbsHwModuleID cbsHwModuleDescription cbsVmVapName cbsHwModuleBoardRevision cbsHwModuleSerialNumber cbsHwModulePartNumber cbsHwModuleStatus CBS-HARDWARE-MIB CBS-HARDWARE-MIB CBS-HARDWARE-MIB CBS-HARDWARE-MIB CBS-HARDWARE-MIB CBS-HARDWARE-MIB cbsHwModuleID cbsHwModuleDescription cbsHwModuleBoardRevision cbsHwModuleSerialNumber cbsHwModulePartNumber cbsHwModuleStatus
CBS-MODULE-RESOURCES cbsModuleUptime -MIB IF-MIB IF-MIB IF-MIB IF-MIB IF-MIB ifDescr ifOperStatus ifSpeed ifInOctets ifOutOctets
271
View / Component App Status Avg CPU Util Avg CPU Load Peak Core Util Total Memory
MIB
MIB Object
CBS-MODULE-RESOURCES cbsModuleAppNewState -MIB CBS-MODULE-RESOURCES cbsModuleCPUUtil5 -MIB CBS-MODULE-RESOURCES cbsModuleCPULoad5 -MIB CBS-MODULE-RESOURCES cbsModuleCpuCoreHiUtilPerc -MIB CBS-MODULE-RESOURCES cbsModuleMemoryTotal -MIB cbsModuleMemoryFree cbsModuleMemoryBuffer cbsModuleMemoryCached
Low Memory
CPM View Slot Module Type Hardware Properties Revision Serial Number Part Number Module Status CBS-HARDWARE-MIB CBS-HARDWARE-MIB CBS-HARDWARE-MIB CBS-HARDWARE-MIB CBS-HARDWARE-MIB CBS-HARDWARE-MIB cbsHwModuleID cbsHwModuleDescription cbsHwModuleBoardRevision cbsHwModuleSerialNumber cbsHwModulePartNumber cbsMgmt.cbsHardware.cbsCPRedun dancyState.cbsCP2RedundancyOper State or cbsCP1RedundancyOperState sysDescr
MIB-II
CBS-MODULE-RESOURCES cbsModuleUptime -MIB CBS-HARDWARE-MIB crossbeamSystems.cbsMgmt.cbsHar dware.cbsCPRedundancyState.cbsC PRedundancyAdminState crossbeamSystems.cbsMgmt.cbsHar dware.cbsCPRedundancyState.cbsC P1RedundancyAdminState crossbeamSystems.cbsMgmt.cbsHar dware.cbsCPRedundancyState.cbsC P2RedundancyAdminState
Sync state
CBS-HARDWARE-MIB
View / Component Avg CPU Load Peak Core Util Total Memory
MIB
MIB Object
CBS-MODULE-RESOURCES cbsModuleCPULoad5 -MIB CBS-MODULE-RESOURCES cbsModuleCpuCoreHiUtilPerc -MIB CBS-MODULE-RESOURCES cbsModuleMemoryTotal -MIB cbsModuleMemoryFree cbsModuleMemoryBuffer cbsModuleMemoryCached
Disk usage
CBS-MODULE-RESOURCES cbsModuleDURoot -MIB CBS-MODULE-RESOURCES cbsModuleDUBoot -MIB CBS-MODULE-RESOURCES cbsModuleDUCbconfig -MIB CBS-MODULE-RESOURCES cbsModuleDUTftpboot -MIB CBS-MODULE-RESOURCES cbsModuleDUMgmt -MIB CBS-HARDWARE-MIB CBS-HARDWARE-MIB cbsHwModuleRAIDStatus cbsHwModuleRAIDMode
RAID
Chassis Utilization
Flow Table Partition Threshold NPM Flow Table Critical Alarm NPM Flow Table Utilization NPM Flow Table Utilization TCP Flow Entries NPM Flow Table Utilization UDP Flow Entries NPM Flow Table UtilizationI CMP Flow Entries NPM Flow Table Utilization Other IP Flow Entries
CBS-MODULE-RESOURCES cbsFlowTablePartitionThreshold -MIB CBS-MODULE-RESOURCES cbsFlowTableCriticalAlarm -MIB CBS-MODULE-RESOURCES cbsFlowTableUtilization -MIB CBS-MODULE-RESOURCES cbsFlowTableUtilizationTcpFlowEntri -MIB es
273
View / Component NPM Slot ID TCP Current Flows UDP Current Flows ICMP Current Flows Other IP Current Flows New Flow Rate
MIB
MIB Object
CBS-MODULE-RESOURCES cbsNpmFlowDistTable.cbsNpmFlow -MIB DistEntry.cbsNpmSlotID CBS-MODULE-RESOURCES cbsNpmFlowDistTable.cbsNpmFlow -MIB DistEntry.cbsNpmProtoTcpCurrentFlo ws CBS-MODULE-RESOURCES cbsNpmFlowDistTable.cbsNpmFlow -MIB DistEntry.cbsNpmProtoTdpCurrentFl ows CBS-MODULE-RESOURCES cbsNpmFlowDistTable.cbsNpmFlow -MIB DistEntry.cbsNpmProtoIcmpCurrentFl ows CBS-MODULE-RESOURCES cbsNpmFlowDistTable.cbsNpmFlow -MIB DistEntry.cbsNpmProtoOtherIpCurren tFlows CBS-MODULE-RESOURCES cbsNpmFlowDistTable.cbsNpmFlow -MIB DistEntry.cbsNpmNewFlowRate
Aged Flow Rate CBS-MODULE-RESOURCES cbsNpmFlowDistTable.cbsNpmFlow -MIB DistEntry.cbsNpmAgedFlowRate VAP VapName Current Flows New Flow Rate CBS-MODULE-RESOURCES cbsVapFlowDistTable.cbsVapFlowDi -MIB stEntry.cbsVapNmae CBS-MODULE-RESOURCES cbsVapFlowDistTable.cbsVapFlowDi -MIB stEntry.cbsVapCurrentFlows CBS-MODULE-RESOURCES cbsVapFlowDistTable.cbsVapFlowDi -MIB stEntry.cbsVapNewFlowRate
Aged Flow Rate CBS-MODULE-RESOURCES cbsVapFlowDistTable.cbsVapFlowDi -MIB stEntry.cbsVapAgedFlowRatge Alarms View ID CBS-HARDWARE-MIB crossbeamSystems.cbsMgmt.cbsHar dware.cbsAlarmObjects.cbsActiveAla rmsTable.cbsActiveAlarmsEntry.cbsA ctiveAlarmId crossbeamSystems.cbsMgmt.cbsHar dware.cbsAlarmObjects.cbsActiveAla rmsTable.cbsActiveAlarmsEntry.cbsA ctiveAlarmDate crossbeamSystems.cbsMgmt.cbsHar dware.cbsAlarmObjects.cbsActiveAla rmsTable.cbsActiveAlarmsEntry.cbsA ctiveAlarmSeverity crossbeamSystems.cbsMgmt.cbsHar dware.cbsAlarmObjects.cbsActiveAla rmsTable.cbsActiveAlarmsEntry.cbsA ctiveAlarmSource crossbeamSystems.cbsMgmt.cbsHar dware.cbsAlarmObjects.cbsActiveAla rmsTable.cbsActiveAlarmsEntry.cbsA ctiveAlarmDescription
Date
CBS-HARDWARE-MIB
Severity
CBS-HARDWARE-MIB
Source
CBS-HARDWARE-MIB
Description
CBS-HARDWARE-MIB
274
MIB CBS-HARDWARE-MIB
MIB Object crossbeamSystems.cbsMgmt.cbsHar dware.cbsAlarmObjects.cbsActiveAla rmsTable.cbsActiveAlarmsEntry.cbsA ctiveAlarmDevice crossbeamSystems.cbsMgmt.cbsHar dware.cbsAlarmObjects.cbsActiveAla rmsTable.cbsActiveAlarmsEntry.cbsA ctiveAlarmSensor crossbeamSystems.cbsMgmt.cbsHar dware.cbsAlarmObjects.cbsActiveAla rmsTable.cbsActiveAlarmsEntry.cbsA ctiveAlarmIface crossbeamSystems.cbsMgmt.cbsHar dware.cbsAlarmObjects.cbsActiveAla rmsTable.cbsActiveAlarmsEntry.cbsA ctiveAlarmSubIface crossbeamSystems.cbsMgmt.cbsHar dware.cbsAlarmObjects.cbsActiveAla rmsTable.cbsActiveAlarmsEntry.cbsA ctiveAlarmDisk crossbeamSystems.cbsMgmt.cbsHar dware.cbsAlarmObjects.cbsActiveAla rmsTable.cbsActiveAlarmsEntry.cbsA ctiveAlarmPartition crossbeamSystems.cbsMgmt.cbsHar dware.cbsAlarmObjects.cbsAlarmSta ts.cbsActiveMinorNumber crossbeamSystems.cbsMgmt.cbsHar dware.cbsAlarmObjects.cbsAlarmSta ts.cbsActiveMajorNumber crossbeamSystems.cbsMgmt.cbsHar dware.cbsAlarmObjects.cbsAlarmSta ts.cbsActiveCriticalNumber
Sensor
CBS-HARDWARE-MIB
Interface
CBS-HARDWARE-MIB
Sub Interface
CBS-HARDWARE-MIB
Disk
CBS-HARDWARE-MIB
Partition
CBS-HARDWARE-MIB
CBS-HARDWARE-MIB
CBS-HARDWARE-MIB
CBS-HARDWARE-MIB
275
MIB CBS-HARDWARE-MIB
componentTemperatureExceeded
CBS-HARDWARE-MIB
cbsHwFPGATempExceeded cbsHwFPGATempNormal
cpuCoreUtilizationExceeded
CBS-MODULERESOURCES-MIB CBS-HARDWARE-MIB
cpuTempLimitExceeded
cpuUptimeLimitExceeded cpuUtilization15min cpuUtilization1min cpuUtilization5min diagsFailure diskConfigurationBad diskDriveError diskUtilizationBootExceeded CBS-MODULERESOURCES-MIB CBS-MODULERESOURCES-MIB CBS-MODULERESOURCES-MIB CBS-MODULERESOURCES-MIB CBS-MODULERESOURCES-MIB CBS-MODULERESOURCES-MIB CBS-HARDWARE-MIB cbsModuleDUBootHigh cbsModuleDUBootNormal cbsModuleDUCbconfigHigh cbsModuleDUCbconfigNormal cbsModuleDUCbMgmtHigh cbsModuleDUCbMgmtNormal cbsModuleDUCbRootHigh cbsModuleDUCbRootNormal cbsModuleDUTftpbootHigh cbsModuleDUTftpbootNormal cbsModuleDUVarHigh cbsModuleDUVarNormal cbsDbhaLinkDown cbsDbhaLinkUp exhaustAirTemperatureExceeded CBS-HARDWARE-MIB cbsHwExhaustTempExceeded cbsHwExhaustTempNormal fanFailure CBS-HARDWARE-MIB cbsHwFanFailed cbsHwFanRecovered fanTrayIncompatible CBS-HARDWARE-MIB CBS-MODULERESOURCES-MIB cbsNPMDiagFailure cbsCpmDiskCheck
diskUtilizationCbConfigExceeded
diskUtilizationMgmtExceeded
diskUtilizationRootExceeded
diskUtilizationTftpBootExceeded
diskUtilizationVarExceeded
dualBoxHaLinkFailure
276
MIB CBS-HARDWARE-MIB
firmwareMismatch flowTableFull CBS-HARDWARE-MIB cbsAFTUsageHigh cbsAFTUsageNormal flowTableMedianThresholdExcee ded CBS-MODULERESOURCES-MIB cbsNpmFTTcpMedianExceeded cbsNpmFTTcpMedianNormal cbsNpmFTUdpMedianExceeded cbsNpmFTUdpMedianNormal cbsNpmFTIcmpMedianExceeded cbsNpmFTIcmpMedianNormal cbsNpmFTOtherIpMedianExceeded cbsNpmFTOtherIpMedianNormal flowTableThresholdExceeded CBS-MODULERESOURCES-MIB cbsNpmFTTcpLimitExceeded cbsNpmFTTcpLimitNormal cbsNpmFTUdpLimitExceeded cbsNpmFTUdpLimitNormal cbsNpmFTIcmpLimitExceeded cbsNpmFTIcmpLimitNorma cbsNpmFTOtherIpLimitExceeded cbsNpmFTOtherIpLimitNormal fragPktRateExceeded CBS-MODULERESOURCES-MIB CBS-MODULERESOURCES-MIB CBS-MODULERESOURCES-MIB CBS-MODULERESOURCES-MIB IF-MIB cbsModuleFRHigh cbsModuleFRNormal cbsModuleFreePageAvailableHigh cbsModuleFreePageAvailableNorm cbsApmGuestHealthCheck cbsHwInTempExceeded cbsHwInTempNormal linkDown linkUp memoryConfiguration memoryMismatch moduleFailure CBS-MODULERESOURCES-MIB cbsModuleSdramCheck
freePageUtilization
guestHealthProblem intakeAirTemperatureExceeded
linkFailure
277
MIB CBS-HARDWARE-MIB
noRemoteBoxConfigured npmBuffersUsageHigh
npmOutOfMemory
CBS-HARDWARE-MIB
cbsHwPowerFeedFailed cbsHwPowerFeedRecovered
powerSupplyA_Bfailure
CBS-HARDWARE-MIB
cbsHwPowerSupplyFailed cbsHwPowerSupplyRecovered
powerSupplyMissing
CBS-HARDWARE-MIB
raidStatusChange resourceProtectionFlowThreshold Exceeded rswFail systemAlarm systemRestart vapStateChange CBS-VAPGROUP-MIB cbsVapStatusChanged CBS-MODULERESOURCES-MIB CBS-MODULERESOURCES-MIB CBS-HARDWARE-MIB cbsNpmFlowTableUsageHigh cbsNpmFlowTableUsageNormal cbsModuleRSWStateChange cbsHwSystemAlarmTrap
278
MIB CBS-HARDWARE-MIB
SNMP Trap cbsHw125VoltageNormal cbsHw125VoltageOutOfRange cbsHwModule1-2VNormal cbsHwModule1-2VOutOfRange cbsHwModule1-5VNormal cbsHwModule1-5VOutOfRange cbsHwModule12-0VNormal cbsHwModule12-0VOutOfRange cbsHw1-8VoltageNormal cbsHw1-8VoltageOutOfRange cbsHw2-5VoltageNormal cbsHw2-5VoltageOutOfRange cbsHw3-3VoltageNormal cbsHw3-3VoltageOutOfRange cbsHwCPUVoltageNormal cbsHwCPUVoltageOutOfRange cbsHwCPU2VoltageNormal cbsHwCPU2VoltageOutOfRange cbsHwFPGA1-8VoltageNormal cbsHwFPGA1-8VoltageOutOfRange cbsHwModuleETHSwVNormal cbsHwModuleETHSwVOutOfRange cbsHwModuleNP6EZDDRNormal cbsHwModuleNP6EZDDROutOfRange cbsHwModuleNP6EZCORENormal cbsHwModuleNP6EZCOREOutOfRange cbsHwModuleNP6EZHSTLNormacbsHw ModuleNP6EZHSTLOutOfRange cbsHwModuleNP6XBPRCNormal cbsHwModuleNP6XBPRCOutOfRange cbsHwModuleNP6OCTDDRNormal cbsHwModuleNP6OCTDDROutOfRange
voltageProblem (contd)
CBS-HARDWARE-MIB
vrrpFailGroupPriorityChange vrrpFailGroupStatusChange
CBS-VRRP-MIB CBS-VRRP-MIB
cbsVrrpTrapFailGrPriorityChanged cbsVrrpTrapFailGrStatusChanged
279
MIB CBS-VRRP-MIB
vrrpRemoteBoxNoSecondaryPath CBS-VRRP-MIB vrrpRemoteBoxNoStandbyPath vrrpRemoteBoxPathSharedSingle Intf vrrpRemoteBoxPathStatusChang e vrrpRemoteBoxRunLegacyXOS CBS-VRRP-MIB CBS-VRRP-MIB CBS-VRRP-MIB CBS-VRRP-MIB
CROSSBEAM-SYSTEMS-MIB Reference
The CROSSBEAM-SYSTEMS-MIB includes high-level entries that describe Crossbeam C-Series and X-Series chassis and related components. This section contains a tree view of the CROSSBEAM-SYSTEMS-MIB entries and traps with OID information. For comprehensive attributes and text descriptions, use a MIB browser or read the CROSSBEAM-SYSTEMS-MIB.txt file on your CPM at /usr/share/snmp/mibs.
280
5.cbsCPM9600 2. cbsAPModules 1.cbsAPM4100 2.cbsAPM4200 3.cbsAPM4250 4.cbsAPM8200 5.cbsAPM8400 6.cbsAPM8600 7.cbsAPM8650 8.cbsAPM9600 3. cbsNPModules 1.cbsNPM4100 2.cbsNPM4110 3.cbsNPM8200 4.cbsNPM8210 5.cbsNPM8600 6.cbsNPM8650 7.cbsNPM8620 2. cbsXSeries 1. cbsXChassis 1. 2. 3. 4. 5. 3. 1. cbsX45Chassis cbsX80Chassis cbsX60Chassis cbsX20Chassis cbsX30Chassis
CBS-HARDWARE-MIB Reference
The CBS-HARDWARE-MIB includes entries for Crossbeam specific hardware features. The features include system status, hardware components, temperature, voltage, power, and LED status. This section contains a tree view of the CBS-HARDWARE-MIB entries and traps with OID information. For comprehensive attributes and text descriptions, use a MIB browser or read the CBS-HARDWARE-MIB.txt file on your CPM at /usr/share/snmp/mibs.
281
CBS-HARDWARE-MIB entries
CBS-HARDWARE-MIB management OID: .1.3.6.1.4.1.6848.2.1 1. cbsHwSystem 1. 2. 3. 4. 5. 6. 2. 1. 2. 3. 4. 5. 6. 7. 8. 9. cbsHwSystemProductID cbsHwSystemDescription cbsHwSystemSerialNumber cbsHwSystemBackplaneRevision cbsHwSystemPartNumber cbsHwSystemIdentifier cbsHwSystemRedundantPowerSupplyStatus cbsHwSystemRedundantPowerFeedStatus cbsHwSystemChassisTemp cbsHwSystemUpperFanTray cbsHwSystemLowerFanTray cbsHwSystemAlarm cbsHwSystemPowerType cbsHwSystemRedundantACPowerSupplyState cbsHwSystemRedundantACPowerFeedStatus
cbsHwSystemStatus
10. cbsHwSystemDCPowerFilterA 11. cbsHwSystemDCPowerFilterB 12. cbsHwSystemDCPowerFeedA 13. cbsHwSystemACPowerFeedB 14. cbsHwSystemACPwrBay1Presence 15. cbsHwSystemACPwrBay2Presence 16. cbsHwSystemACPwrBay3Presence 17. cbsHwSystemACPwrBay4Presence 18. cbsHwSystemACPwrBay1Status 19. cbsHwSystemACPwrBay2Status 20. cbsHwSystemACPwrBay3Status
282
21. cbsHwSystemACPwrBay4Status 22. cbsHwSystemAftStatus 23. cbsHwSystemUpperFanTrayCompatible 24. cbsHwSystemUpperFanTrayRevision 25. cbsHwSystemUpperFanTraySerialNumber 26. cbsHwSystemUpperFanTrayPartNumber 27. cbsHwSystemLowerFanTrayCompatible 28. cbsHwSystemLowerFanTrayRevision 29. cbsHwSystemLowerFanTraySerialNumber 30. cbsHwSystemLowerFanTrayPartNumber 3. cbsFanStatusTable 1. cbsFanStatusEntry 1. 2. 3. 4. 1. cbsFanGroupIndex cbsFanIndex cbsFanStatus
cbsHwModuleTable cbsHwModuleEntry 1. 2. 3. 4. 5. 6. 7. 8. 9. cbsHwModuleID cbsHwModuleProductID cbsHwModuleDescription cbsHwModuleBoardRevision cbsHwModuleSerialNumber cbsHwModuleBootStrapRev cbsHwModuleBootloaderRev cbsHwModuleDiagnosticsRev cbsHwModuleModuleSDRAMSize
10. cbsHwModuleRDRAMSize 11. cbsHwModuleDiskAPresent 12. cbsHwModuleDiskBPresent 13. cbsHwModuleDuartAPresent 14. cbsHwModuleDuartBPresent 15. cbsHwModuleAccelCard1Present 16. cbsHwModuleAccelCard2Present 17. cbsHwModulePartNumber 18. cbsHwModuleReqBootStrapRev 19. cbsHwModuleReqBootloaderRev 20. cbsHwModuleReqDiagnosticsRev 21. cbsHwModuleCtrlFpgaRev 22. cbsHwModuleReqCtrlFpgaRev 23. cbsHwModuleFocusFpgaRev
283
cbsHwModuleStatusTable cbsHwModuleStatusEntry 1. 2. 3. 4. 5. 6. 7. 8. 9. cbsHwModuleStatus cbsHwModuleStatusActive cbsHwModuleCpuTemp cbsHwModuleFPGATemp cbsHwModuleInTemp cbsHwModuleInTempAlarm cbsHwModuleExhaustTemp cbsHwModuleExhaustTempAlarm cbsHwModuleCPUVoltage
10. cbsHwModule1-8Voltage 11. cbsHwModule3-3Voltage 12. cbsHwModule2-5Voltage 13. cbsHwModuleControlLinkA 14. cbsHwModuleControlLinkB 15. cbsHwModuleActiveLED 16. cbsHwModuleStandbyLED 17. cbsHwModuleFailedLED 18. cbsHwModuleCpu2Temp 19. cbsHwModuleCPU2Voltage 20. cbsHwModuleFPGA1-8Voltage 21. cbsHwModule125Voltage 22. cbsHwModule1-5V 23. cbsHwModuleBatteryVCCVoltage 24. cbsHwModuleSupplyFGVoltage 25. cbsHwModuleSupplyETHSwVoltage 26. cbsHwModuleSupplyPrismVoltage 27. cbsHwModule1-2V 28. cbsHwModule12-0V 29. cbsHwModuleSupplyNP6OCTDDRVolt 30. cbsHwModuleSupplyNP6EZCOREVolt 31. cbsHwModuleSupplyNP6EZDDRVolt 32. cbsHwModuleSupplyNP6EZHSTLVolt
284
33. cbsHwModuleSupplyNP6XBPRCVolt 34. cbsHwModuleRAIDStatus 35. cbsHwModuleRAIDMode 7. cbsHwSdpStatusTable 1. cbsHwSdpStatusEntry 1. 2. 3. 4. 8. 1. 2. 3. 4. 5. 6. 7. 9. 1. cbsHwSdpNpmSlot cbsHwSdpRemoteSlot cbsHwSdpNpmState cbsHwSdpRemoteState
cbsCPRedundancyState cbsCPRedundancyAdminState cbsCP1RedundancyAdminState cbsCP2RedundancyAdminState cbsCPRedundancyOperState cbsCP1RedundancyOperState cbsCP2RedundancyOperState cbsCPRedundancySync cbsActiveAlarmsTable 1. cbsActiveAlarmsEntry 1.cbsActiveAlarmIndex 2.cbsActiveAlarmId 3.cbsActiveAlarmDate 4.cbsActiveAlarmSeverity 5.cbsActiveAlarmSource 6.cbsActiveAlarmDescription 2. cbsAlarmStats 1. 2. 3. 1. cbsActiveMinorNumber cbsActiveMajorNumber cbsActiveCriticalNumber
cbsAlarmObjects
285
5. 6. 7. 8. 9.
10. cbsHwFanRecovered 11. cbsHwSystemAlarmTrap 12. cbsHwChassisTempExceeded 13. cbsHwChassisTempNormal 14. cbsHwModuleStatusChanged 15. cbsHwModuleInserted 16. cbsHwModuleRemoved 17. cbsHwModuleTempExceeded 18. cbsModuleTempNormal 19. cbsDbhaLinkUp 20. cbsDbhaLinkDown 21. cbsModuleCpu2TempExceeded 22. cbsModuleCpu2TempNormal 23. cbsAFTUsageHigh 24. cbsAFTUsageNormal 25. cbsHwSystemACPwrBay1Failed 26. cbsHwSystemACPwrBay1Recovered 27. cbsHwSystemACPwrBay2Failed 28. cbsHwSystemACPwrBay2Recovered 29. cbsHwSystemACPwrBay3Failed 30. cbsHwSystemACPwrBay3Recovered 31. cbsHwSystemACPwrBay4Failed 32. cbsHwSystemACPwrBay4Recovered 33. cbsNPPMDiagFailure 34. cbsNPMPrcLink13Down 35. cbsNPMPrcLink13Up 36. cbsNPMPrcLink14Down 37. cbsNPMPrcLink14Up 38. cbsHwInTempExceeded 39. cbsHwInTempNormal 40. cbsHwExhaustTempExceeded 41. cbsHwExhaustTempNormal 42. cbsHwFPGATempExceeded 43. cbsHwFPGATempNormal 44. cbsHwCPUVoltageNormal
286
45. cbsHwCPUVoltageOutOfRange 46. cbsHw1-8VoltageNormal 47. cbsHw1-8VoltageOutOfRange 48. cbsHw3-3VoltageNormal 49. cbsHw3-3VoltageOutOfRange 50. cbsHw2-5VoltageNormal 51. cbsHw2-5VoltageOutOfRange 52. cbsHwCPU2VoltageNormal 53. cbsHwCPU2VoltageOutOfRange 54. cbsHwFPGA1-8VoltageNormal 55. cbsHwFPGA1-8VoltageOutOfRange 56. cbsHw125VoltageNormal 57. cbsHw125VoltageOutOfRange 58. cbsHwBatteryVCCNormal 59. cbsHwBatteryVCCOutOfRange 60. cbsHwModule1-5VNormal 61. cbsHwModule1-5VOutOfRange 62. cbsHwModuleSupplyFGNormal 63. cbsHwModuleSupplyFGOutOfRange 64. cbsHwModule1-2VNormal 65. cbsHwModule1-2VOutOfRange 66. cbsHwModule12-0VNormal 67. cbsHwModule12-0VOutOfRange 68. cbsHwModuleNP6OCTDDROutOfRange 69. cbsHwModuleNP6OCTDDRNormal 70. cbsHwModuleNP6EZCOREOutOfRange 71. cbsHwModuleNP6EZCORENormal 72. cbsHwModuleNP6EZDDROutOfRange 73. cbsHwModuleNP6EZDDRNormal 74. cbsHwModuleNP6EZHSTLOutOfRange 75. cbsHwModuleNP6EZHSTLNormal 76. cbsHwModuleNP6XBPRCOutOfRange 77. cbsHwModuleNP6XBPRCNormal 78. cbsHwModuleETHSwVOutOfRange 79. cbsHwModuleETHSwVNormal 80. cbsHwModulePrismVOutOfRange 81. cbsHwModulePrismVNormal
287
CBS-MODULE-RESOURCES-MIB Reference
The CBS-MODULE-RESOURCE-MIB includes entries that describe module features such as CPU usage, memory usage, and other module characteristics. This section contains a tree view of the CBS-MODULE-RESOURCES-MIB entries and traps with OID information. For comprehensive attributes and text descriptions, use a MIB browser or read the CBS-MODULE-RESOURCES-MIB.txt file on your CPM at /usr/share/snmp/mibs.
CBS-MODULE-RESOURCES-MIB entries
CBS-MODULE-RESOURCES-MIB management OID: .1.3.6.1.4.1.6848.2.3 1. cbsModuleCPULoadTable 1. cbsModuleCPULoadEntry 1. 2. 3. 4. 5. 6. 7. 8. 2. 1. cbsModuleCPUSpeed cbsModuleCPUCount cbsModuleCPULoad1 cbsModuleCPULoad5 cbsModuleCPULoad15 cbsModuleCPUUtil1 cbsModuleCPUUtil5 cbsModuleCPUUtil15
3.
4.
cbsModuleDUTable 1. cbsModuleDUEntry
288
1. 2. 3. 4. 5. 1.
6.
cbsModuleCPUAvgUtilTable 1. CbsModuleCPUAvgUtilEntry 1. 2. 3. 4. 5. 6. 7. 8. 9. cbsModuleCPUAvgUtilCore1User cbsModuleCPUAvgUtilCore1Nice cbsModuleCPUAvgUtilCore1Syst cbsModuleCPUAvgUtilCore1Idle cbsModuleCPUAvgUtilCore1IRQ cbsModuleCPUAvgUtilCore1SoftIRQ cbsModuleCPUAvgUtilCore1IOWait cbsModuleCPUAvgUtilCore2User cbsModuleCPUAvgUtilCore2Nice
10. cbsModuleCPUAvgUtilCore2Syst 11. cbsModuleCPUAvgUtilCore2Idle 12. cbsModuleCPUAvgUtilCore2IRQ 13. cbsModuleCPUAvgUtilCore2SoftIRQ, 14. cbsModuleCPUAvgUtilCore2IOWait 15. cbsModuleCPUAvgUtilCore3User 16. cbsModuleCPUAvgUtilCore3Nice 17. cbsModuleCPUAvgUtilCore3Syst 18. cbsModuleCPUAvgUtilCore3Idle 19. cbsModuleCPUAvgUtilCore3IRQ 20. cbsModuleCPUAvgUtilCore3SoftIRQ 21. cbsModuleCPUAvgUtilCore3IOWait 22. cbsModuleCPUAvgUtilCore4User 23. cbsModuleCPUAvgUtilCore4Nice 24. cbsModuleCPUAvgUtilCore4Syst 25. cbsModuleCPUAvgUtilCore4Idle 26. cbsModuleCPUAvgUtilCore4IRQ 27. cbsModuleCPUAvgUtilCore4SoftIRQ 28. cbsModuleCPUAvgUtilCore4IOWait
289
29. cbsModuleCPUAvgUtilCore5User 30. cbsModuleCPUAvgUtilCore5Nice 31. cbsModuleCPUAvgUtilCore5Syst 32. cbsModuleCPUAvgUtilCore5Idle 33. cbsModuleCPUAvgUtilCore5IRQ 34. cbsModuleCPUAvgUtilCore5SoftIRQ 35. cbsModuleCPUAvgUtilCore5IOWait 36. cbsModuleCPUAvgUtilCore6User 37. cbsModuleCPUAvgUtilCore6Nice 38. cbsModuleCPUAvgUtilCore6Syst 39. cbsModuleCPUAvgUtilCore6Idle 40. cbsModuleCPUAvgUtilCore6IRQ 41. cbsModuleCPUAvgUtilCore6SoftIRQ 42. cbsModuleCPUAvgUtilCore6IOWait 43. cbsModuleCPUAvgUtilCore7User 44. cbsModuleCPUAvgUtilCore7Nice 45. cbsModuleCPUAvgUtilCore7Syst 46. cbsModuleCPUAvgUtilCore7Idle 47. cbsModuleCPUAvgUtilCore7IRQ 48. cbsModuleCPUAvgUtilCore7SoftIRQ 49. cbsModuleCPUAvgUtilCore7IOWait 50. cbsModuleCPUAvgUtilCore8User 51. cbsModuleCPUAvgUtilCore8Nice 52. cbsModuleCPUAvgUtilCore8Syst 53. cbsModuleCPUAvgUtilCore8Idle 54. cbsModuleCPUAvgUtilCore8IRQ 55. cbsModuleCPUAvgUtilCore8SoftIRQ 56. cbsModuleCPUAvgUtilCore8IOWait 7. CbsModuleSDPTable 1. CbsModuleSDPEntry 1. 2. 3. 4. 5. 6. 7. 8. 9. cbsModuleSDP0OutPkts cbsModuleSDP0OutOctets cbsModuleSDP0InPkts cbsModuleSDP0InOctets cbsModuleSDP1OutPkts cbsModuleSDP1OutOctets cbsModuleSDP1InPkts cbsModuleSDP1InOctets cbsModuleSDP2OutPkts
10. cbsModuleSDP2OutOctets
290
11. cbsModuleSDP2InPkts 12. cbsModuleSDP2InOctets 13. cbsModuleSDP3OutPkts 14. cbsModuleSDP3OutOctets 15. cbsModuleSDP3InPkts 16. cbsModuleSDP3InOctets 17. cbsModuleSDP4OutPkts 18. cbsModuleSDP4OutOctets 19. cbsModuleSDP4InPkts 20. cbsModuleSDP4InOctets 21. cbsModuleSDP5OutPkts 22. cbsModuleSDP5OutOctets 23. cbsModuleSDP5InPkts 24. cbsModuleSDP5InOctets 25. cbsModuleSDP6OutPkts 26. cbsModuleSDP6OutOctets 27. cbsModuleSDP6InPkts 28. cbsModuleSDP6InOctets 29. cbsModuleSDP7OutPkts 30. cbsModuleSDP7OutOctets 31. cbsModuleSDP7InPkts 32. cbsModuleSDP7InOctets 8. cbsModuleUptimeTable 1. 9. cbsModuleUptimeEntry 1. 1. cbsModuleUptime
10. CbsModuleAppMonTable CbsModuleAppMonEntry 1. 2. 3. 4. 5. 6. 7. 8. 9. cbsModuleAppName cbsModuleAppVersion cbsModuleAppRelease cbsModuleAppCPMHostName cbsModuleAppCPMIPAddress cbsModuleAppVAPGroupName cbsModuleAppVAPIndex cbsModuleAppOldState cbsModuleAppNewState
11. CbsModuleNtpdMonTable
291
1.
10. cbsModuleDUBootNormal 11. cbsModuleDUCbconfigHigh 12. cbsModuleDUCbconfigNormal 13. cbsModuleTftbootHigh 14. cbsModuleTftbootNormal 15. cbsModuleFreePageAvailableHigh 16. cbsModuleFreePageAvailableNormal 17. cbsModuleMUHigh 18. cbsModuleMUNormal 19. cbsModuleFRHigh 20. cbsModuleFRNormal 21. cbsModuleBUHigh 22. cbsModuleBUNormal 23. cbsModuleAppStateChange 24. cbsModuleNtpdMonStateChange 25. cbsModuleDUMgmtHigh 26. cbsModuleDUMgmtNormal 27. cbsModuleCpuCoreUtilExceeded 28. cbsModuleCpuCoreUtilNormal 29. cbsNpmFlowTableUsageHigh 30. cbsNpmFlowTableUsageNormal 31. cbsNpmFTUdpLimitExceeded 32. cbsNpmFTUdpLimitNormal 33. cbsNpmFTUdpMedianExceeded
292
34. cbsNpmFTUdpMedianNormal 35. cbsNpmFTTcpLimitExceeded 36. cbsNpmFTTcpLimitNormal 37. cbsNpmFTTcpMedianExceeded 38. cbsNpmFTTcpMedianNormal 39. cbsNpmFTIcmpLimitExceeded 40. cbsNpmFTIcmpLimitNormal 41. cbsNpmFTIcmpMedianExceeded 42. cbsNpmFTIcmpMedianNormal 43. cbsNpmFTOtherIpLimitExceeded 44. cbsNpmFTOtherIpLimitNormal 45. cbsNpmFTOtherIpMedianExceeded 46. cbsNpmFTOtherIpMedianNormal 47. cbsModuleSdramCheck
CBS-VAPGROUP-MIB Reference
The CBS-VAPGROUP-MIB includes entries that describe VAP features, configuration settings, and other details. This section contains a tree view of the CBS-VAPGROUP-MIB entries and traps with OID information. For comprehensive attributes and text descriptions, use a MIB browser or read the CBS-VAPGROUP-MIB.txt file on your CPM at /usr/share/snmp/mibs.
CBS-VAPGROUP-MIB entries
CBS-VAPGROUP-MIB management OID: .1.3.6.1.4.1.6848.2.3 1. cbsVapGroupTable 1. cbsVapGroupEntry 1. 2. 3. 4. 5. 6. cbsVgVapGroupID cbsVgVapGroupName cbsVgLoadPriority cbsVgPreemPriority cbsVgApmList cbsVgVapCount
293
7. 8. 9.
10. cbsVgIpForward 11. cbsVgRpFilter 12. cbsVgLogMartians 13. cbsVgReloadTimer 14. cbsVgRemoteBoxBackup 15. cbsVgDelayFlow 2. cbsVapMappingTable 1. cbsVapMappingEntry 1. 2. 3. 4. 5. 6. cbsVmVapGroupID cbsVmVapGroupName cbsVmVapName cbsVmVapIndex cbsVmVapStatus cbsVmSlotNumber
CBS-VRRP-MIB Reference
The CBS-VRRP-MIB includes entries for virtual routing redundancy protocol (VRRP). This section contains a tree view of the CBS-VAPGROUP-MIB entries and traps with OID information. For comprehensive attributes and text descriptions, use a MIB browser or read the CBS-VAPGROUP-MIB.txt file on your CPM at /usr/share/snmp/mibs.
CBS-VRRP-MIB entries
CBS-VRRP-MIB management OID: .1.3.6.1.4.1.6848.2.5 1. cbsVrrpOperations 1. cbsVrrpTrapNewMasterReason
294
2. 3. 4. 5. 6. 7. 8. 9.
10. cbsVrrpTrapFailGrOldPriority 11. cbsVrrpTrapFailGrNewPriority 12. cbsVrrpTrapFailGrPriorityChgReason 13. cbsVrrpTrapRemoteBoxPathOldStatus 14. cbsVrrpTrapRemoteBoxPathNewStatus 15. cbsVrrpRemBoxPathAddrs 2. cbsVrrpFailGrTable 1. cbsVrrpFailGrEntry 1. 2. 3. 4. 5. 6. 7. 8. 9. cbsVrrpFailGrID cbsVrrpFailGrName cbsVrrpFailGrStatus cbsVrrpFailGrConfigPriority cbsVrrpFailGrActualPriority cbsVrrpFailGrEnabled cbsVrrpFailGrPreemption cbsVrrpFailGrLastChangeTime cbsVrrpFailGrLastChangeReason
10. cbsVrrpFailGrMasterSysID 11. cbsVrrpFailGrMasterPriority 3. cbsVrrpFailGrCompTable 1. cbsVrrpFailGrCompEntry 1. 2. 3. 4. 5. 6. 4. 1. cbsVrrpFailGroupID cbsVrrpFailGroupName cbsVrrpFailGrCompIndex cbsVrrpFailGrCompType cbsVrrpFailGrCompDescr cbsVrrpFailGrCompDelta
295
4. 5. 6. 7. 8.
DISMAN-EVENT-MIB IF-MIB IP-FORWARD-MIB IP-MIB IPV6-MIB NOTIFICATION-LOG-MIB RFC1213-MIB RMON-MIB SNMPv2-MIB TCP-MIB UDP-MIB
To view specific MIB entries used by XOS, use an snmpwalk tool. For information on configuring SNMP on XOS, including SNMP server setup, see Configuring Simple Network Management Protocol (SNMP) on page 163.
296
E
Maintenance Mode
Using Maintentance Mode
Maintenance mode can be applied to Application Processor Modules (APMs) and to Network Processor Modules (NPMs) for these purposes:
z z z
Upgrading the firmware on the module (APM and NPM) Applying hotfixes or patches while upgrading an application (APM) Replacing an existing APM or NPM module with a newer version
When peforming firmware upgrade or patch/hotfix operations, the process involves these steps:
z z z
Configuring the module to place it in maintenance mode Performing the operation on the module Enabling the module after the operation has been completed
When replacing an APM or NPM module with a newer version the process involves these steps:
z z z
Placing the module in maintenance mode Removing the module Inserting the newer version of APM or NPM
297
Maintenance Mode
298
Glossary
The following terms are used throughout the X-Series Platform documentation set.
3DES
Triple Data Encryption Standard. Provides a stronger form of DES encryption where the algorithm is applied three times in order to encrypt data.
ACL
Access Control List. Provides packet filtering through the permission or denial of packets based on certain IP criteria, such as IP address, port, or protocol.
APM
Application Processor Module. The XOS Application Processor system module that provides application processing, status monitoring, and standard and application specific logging. The APM contains one or more CPUs to host applications and network services while processing packets belonging to individual flows.
ARP
Address Resolution Protocol. An Internet protocol used to map an IP address to a MAC address.
BOTW
Bump-on-the-Wire. A device with two or more interfaces that are transparent to the adjacent Layer 3 devices.
cbsflowagentd
Flow Agent daemon that collects statistics and runs on each VAP.
cbsflowcalcd
Flow Calculator daemon that runs the flow scheduling chow file and executes on the CPM.
circuit
An abstract object representing a logical network interface (network service access point). A circuit can be mapped to either single or multiple logical lines. Attributes of a circuit include: a set of physical line or channel pairs, a Layer 2 encapsulation type, a Layer 2 address, and an IP address (optional).
CLI
Command Line Interface.
CM
Configuration manager/monitor.
core-intf
An interface which is attached to the core-facing networks.
299
CPM
Control Processor Module. The XOS system module that coordinates the actions of all other modules, enables management access to the platform, and supports access to a local disk containing configuration files and databases necessary to execute the applications which reside on the platform.
DES
Data Encryption Standard. A popular algorithm for encrypting data. It is a product cipher that operates on 64-bit blocks of data, using a 56-bit key.
device
OS concept representing either a physical or logical I/O port connected to the APM.
domain
A set of interconnected IP networks belonging to a unique address space. A domain is uniquely identified within the X-Series Platform by a 8-bit domain ID. IP flows must be unique within a given domain.
DSA
Digital Signature Algorithm.
ECC
Error Checking and Correcting. A collection of methods to detect errors in transmitted or stored data and a means to correct them.
edge interface
An interface that is attached to edge-facing networks (typically where subscribers are located).
edge server
A server that is physically located close to its end users designed to deliver faster, higher quality transmissions, typically in a local commercial ISP facility. The number of edge servers in a region depends on the number of users in the locale.
FCAPS
Faults, Configuration, Accounting, Performance, and Security. The general requirements of a network management system as defined by the International Organization for Standardization.
FIB
Forwarding Information Base. A set of IP data structures replacing a route table in Linux.
firewall
A set of software tools that protects a company's internal network from unwanted entry by unauthorized external users. The firewall works in conjunction with a router program to filter incoming network packets and reject those of unknown origin.
Glossary
300
flow
Specific stream of data traveling between two endpoints across a network. Specified by source IP, destination IP, source port, destination port and IP protocol type.
flow rule
A filter rule specifying how a packet is processed.
flow specific
A stream of data traveling between two endpoints across a network. Specified by source IP, destination IP, source port, destination port and IP protocol type.
flow table
A table maintained on the NPM that maps individual flows to their respective processors.
FPGA
Field Programmable Gate Array. A gate array where the logic network can be programmed into the device after its manufacture. An FPGA consists of an array of logic elements, either gates or lookup table RAMs, flip-flops, and programmable interconnect wiring.
FTP
File Transfer Protocol.
gateway
A Layer 3 devices with at least two logical interfaces, that uses a routing table to forward packets between interfaces. Note that a gateway may also act as a multi-homed host.
GBIC
Gigabit Interface Converter. A transceiver that converts electric currents (digital highs and lows) to optical signals, and optical signals to digital electric currents. The GBIC is typically employed in fiber optic and Ethernet systems as an interface for high-speed networking. The data transfer rate is one gigabit per second (1 Gbps) or more.
GEM
Greenlight Element Manager. A GUI that provides a view into the components and health of your X-Series Platform.
GLM
Gigabit Link Module.
GRUB
GRand Unified Bootloader.
hash
A crytographic operation where an entire message is run through a mathematical operation that results in a fixed-length string that is unique.
HTTP
Hypertext Transfer Protocol.
301
IDEA
International Data Encryption Algorithm. A conventional encryption algorithm, using block cipher, operating on 64-bit blocks with a 128 bit key.
IDS
Intrusion Detection System.
IOP
I/O Processor.
IP Address
Internet Protocol (IP). A numerical address that identifies senders and receivers of Internet data. The address accompanies data packets, identifying a particular network on the Internet and the specific device (such as a server) from which it originated.
IPS
Intrusion Prevention System.
In-Service Upgrade
ISU is an alternate method of upgrading XOS software while minimizing downtime. This feature has several requirements for successful completion of an ISU, including redundant CPMs, APMs, and NPMs. During ISU, the chassis is virtually split in two halves during which time only one half of the chassis will be responsible for forwarding traffic.
LACP
Link Aggregation Control Protocol.
load balancing
Distributing flows in real time amongst multiple APMs.
load table
A table that maps flow profiles to weighted lists of virtual processors.
logical interface
A channelized interface on a physical interface. A subdivision of a physical interface. Currently supported logical interface types are default and VLAN.
logical line
A combination of a physical line and a sub-line (channel). A logical line is uniquely identified by a physical line ID or channel ID pair.
MD5
Message Digest 5. A one-way function that takes a variable-length message and produces a fixed-length hash.
MAC address
Media Access Control (MAC). A hardware address that uniquely identifies each node of a network. In IEEE 802 networks, the Data Link Control (DLC) layer of the OSI Reference Model is divided into two sub-layers: the Logical Link Control (LLC) layer and the Media Access Control (MAC) layer. The MAC layer interfaces directly with the network media. Consequently, each different type of network media requires a different MAC layer.
Glossary
302
MIB
Management Information Base.
MS
Management Server.
multi-homed host
A Layer 3 device with at least two logical interfaces that generate packets but does not forward the packets.
NMS
Network Management System. Platform that manages one or more X-Series Platforms in a networked environment.
NPM
Network Processor Module. The XOS module responsible for network interface access (up to 10 Gb/sec full-duplex), flow classification, distribution of flows to APMs, and load balancing of the APMs.
PGP
Pretty Good Privacy. A high-security RSA public-key encryption application that enables files or messages to be exchanged with privacy and authentication.
physical interface
The physical hardware connector on the NPM or CPM representing a network interface port.
POS
Packet Over Sonet.
POST
Power On Self-Test.
PPP
Point to Point Protocol.
RAID
Redundant Array of Inexpensive/Independent Drives. A data storage scheme used to allow multiple drives to work as a single drive. RAID level 0 and level 1 are supported by Crossbeam Systems in our newer modules. RAID 0 writes data to whichever drive is currently free. This method is used for greater data speed efficiency (however, all drives in the RAID are needed to fully access all the data). RAID 1 writes identical data to all the drives in the RAID grouping. This method is used for greater data integrity.
RDRAM
Rambus Direct Random Access Memory.
RMON
Remote Network Monitoring.
RPM
Red Hat Package Manager.
303
SCP
Secure copy.
SMP
Symmetric Multi Processor.
SNMP
Simple Network Management Protocol. The Internet standard protocol developed to manage and monitor nodes on an IP network.
SSH
Secure Shell. A powerful authentication and encryption program replacing older and less secure tools like Telnet. SSH provides both authentication and encryption and is therefore the preferred method of network access. SSH allows a secure connection to be established between a client computer and a server host. The X-Series Platform provides SSH server, SSH client, and scp capability.
SSL
Secure Socket Layer.
static route
A user-defined route that causes packets to move between a source and destination along a specific path.
sub-line
A multiplexed channel within a single line. Examples include: a DS0 channel within a T1/T3 serial interface, a ATM PVC, and a tagged VLAN. A sub-line is uniquely identified by a 32-bit channel ID.
SYSLOGD
System Logger Daemon.
Telnet
An administrator can enable Telnet as part of the boot dialogue, or by using a CLI command. Telnet comes disabled because traffic is not encrypted between the client and the X-Series Platform.
VAP
Virtual Application Processor. An application operating environment which can be run on an APM. A VAP consists of the OS, system software, and a set of applications which run concurrently.
VAP group
A virtual set of Application Processor Modules identically configured for load balancing and redundancy to process the same set of applications.
Glossary
304
VLAN
Virtual Local Area Network. A local area network with a definition that maps workstations on some other basis than geographic location (for example, by department, type of user, or primary application).
VND
Virtual Network Device. A Linux kernel object representing a logical network interface. A virtual network device is directly mapped to an NPM circuit.
VPN
Virtual Private Network. Consists of private lines, switching equipment and other networking equipment that are provided for the exclusive use of one customer. A VPN gives users a secure way to access resources over the Internet or other public or private networks using encryption, authentication, and tunneling.
VRRP
Virtual Router Redundancy Protocol. This protocol allows several routers on a multiaccess link to utilize the same virtual IP address. One router will be elected as a master with the other routers acting as backups in case of the failure of the master router. The protocol should also support the ability to load share traffic when both routers are up. A Virtual Router in XOS is an IP address or a set of IP addresses that can be instantiated on a circuit for a subset of the VAP groups on which the circuit is configured, and active only on one of the X-Series Platforms participating in multi-system High Availability configuration.
XML
Extensible Markup Language. The universal format for structured documents and data on the Web as defined by a set of specifications and recommendations from the W3C.
305
Glossary
306