Thisproductcomplieswiththefollowing:47 CFRParts2and15,CSA C108.8,89/336/EEC,EN 55022,EN55024,EN 61000‐3‐2,
EN 61000‐3‐3,AS/NZSCISPR22,andVCCIV‐3.
Compatibilidad Electromágnetica (EMC)
EsteproductodeEnterasyscumpleconlosiguiente:47CFRPartes2y15,CSAC108.8,89/336/EEC,EN 55022,EN 55024,
EN 61000‐3‐2,EN 61000‐3‐3,AS/NZSCISPR22,VCCI V‐3.
Elektro- magnetische Kompatibilität ( EMC )
DiesesProduktentsprichtdenfolgendenRichtlinien:47CFRParts2and15,CSAC108.8,89/336/EEC,EN55022,EN 55024,
EN 61000‐3‐2,EN61000‐3‐3,AS/NZSCISPR22,VCCIV‐3.
European Waste Electrical and Electronic Equipment (WEEE) Notice
ThisisaclassAproductbasedonthestandardoftheVoluntaryControlCouncilforInterferencebyInformationTechnol og y
Equipment(VCCI)V‐3.Ifthisequipmentisusedinadomesticenvironment,radiodisturbancemayarise.Whensuchtrouble
occurs,theusermayberequiredtotakecorrectiveactions.
Contents of the Guide ................................................................................................................................... xxvii
Conventions Used in This Guide ..................................................................................................................xxviii
Getting Help .................................................................................................................................................... xxx
Chapter 1: Overview
Chapter 2: Managing the XSR
Utilizing the Command Line Interface ............................................................................................................. 2-1
Connecting via the Console Port on XSR Series ..................................................................................... 2-1
Using the Console Port for Dial Backup on the XSR 1800 Series...................................................... 2-1
Using the Console Port to Remotely Control the XSR ....................................................................... 2-2
Connecting a Serial Interface to a Modem ......................................................................................... 2-2
Connecting via Telnet .............................................................................................................................. 2-3
Connecting via SSH ................................................................................................................................. 2-3
Accessing the Initial Prompt ..................................................................................................................... 2-4
Synchronizing the Clock ........................................................................................................................... 2-4
Managing the Session .............................................................................................................................. 2-5
Remote Auto Install .................................................................................................................................. 2-5
RAI Features and Requirements ........................................................................................................ 2-5
RAI Requirements on the XSR ........................................................................................................... 2-7
How RAI Components Work............................................................................................................... 2-7
Overview of LAN Interfaces ............................................................................................................................ 3-1
LAN Features ................................................................................................................................................. 3-1
Configuring the LAN ....................................................................................................................................... 3-2
Overview of WAN Interfaces .......................................................................................................................... 3-3
WAN Features ................................................................................................................................................ 3-3
Configuring the WAN ...................................................................................................................................... 3-4
Features ......................................................................................................................................................... 4-1
T3 Mode ................................................................................................................................................... 4-2
General IP Features ....................................................................................................................................... 5-1
ARP and Proxy ARP ................................................................................................................................ 5-4
Proxy DNS ............................................................................................................................................... 5-4
Trivial File Transfer Protocol (TFTP) ........................................................................................................ 5-7
IP Interface ............................................................................................................................................... 5-7
xiii
Secondary IP ............................................................................................................................................ 5-7
IP Routing Protocols ..................................................................................................................................... 5-10
RIPv1 and v2 .......................................................................................................................................... 5-11
Forwarding VLAN, PPPoE over VLAN ............................................................................................. 5-19
VLAN Processing Over the XSR’s Ethernet Interfaces .................................................................... 5-20
VLAN Processing: VLAN-enabled Ethernet to Standard LAN Interfaces ......................................... 5-20
VLAN Processing: VLAN-enabled Ethernet to WAN Interfaces ....................................................... 5-21
VLAN Processing: WAN Interface to a VLAN-enabled Ethernet Interface ....................................... 5-21
QoS with VLAN................................................................................................................................. 5-22
Policy Based Routing ............................................................................................................................. 5-22
Accessing the Global Routing Policy Table ...................................................................................... 5-22
Match Clauses.................................................................................................................................. 5-23
Set Clauses ...................................................................................................................................... 5-23
Router ID ................................................................................................................................................ 5-24
Real Time Protocol (RTP) Header Compression ................................................................................... 5-25
Features ........................................................................................................................................... 5-26
How the VRRP Works ...................................................................................................................... 5-29
Different States of a VRRP Router ................................................................................................... 5-29
VRRP Features ...................................................................................................................................... 5-30
Multiple Virtual IP Addresses per VR ............................................................................................... 5-30
Multiple VRs Per Router ................................................................................................................... 5-30
Configuring Unnumbered IP Serial Interface Example ................................................................................. 5-37
Configuring OSPF Example ......................................................................................................................... 5-37
Multiple NAT Pools within an Interface .................................................................................................. 5-41
Static NAT within an Interface ................................................................................................................ 5-42
NAT Port Forwarding ............................................................................................................................. 5-44
Configuring Policy Based Routing Example ................................................................................................. 5-44
Configuring VRRP Example ......................................................................................................................... 5-45
Chapter 6: Configuring the Border Gateway Protocol
Features ......................................................................................................................................................... 6-1
AS Path .............................................................................................................................................. 6-4
Next Hop............................................................................................................................................. 6-5
Local Preference ................................................................................................................................ 6-5
Community ......................................................................................................................................... 6-9
BGP Path Selection Process ................................................................................................................. 6-11
TCP MD5 Authentication for BGP Example ........................................................................................... 6-25
Configuring BGP Peer Groups ..................................................................................................................... 6-25
IBGP Peer Group Example .................................................................................................................... 6-25
EBGP Peer Group Example ................................................................................................................... 6-26
BGP Community with Route Maps Examples ........................................................................................ 6-26
Chapter 7: Configuring PIM-SM and IGMP
Features ......................................................................................................................................................... 7-1
Differences with Industry-Standard Approach .......................................................................................... 7-1
IP Multicast Overview ..................................................................................................................................... 7-2
Defining Multicast Group Addressing ....................................................................................................... 7-2
PPP Features ................................................................................................................................................. 8-1
Link Control Protocol (LCP) ..................................................................................................................... 8-2
Network Control Protocol (NCP) .............................................................................................................. 8-2
Configuring PPP with a Dialed Backup Line ................................................................................................. 8-10
Configuring a Synchronous Serial Interface ................................................................................................. 8-10
Configuring a Dialed Backup Line ................................................................................................................ 8-11
Configuring the Dialer Interface ............................................................................................................. 8-11
Configuring the Physical Interface for the Dialer Interface ..................................................................... 8-11
Configuring the Interface as the Backup Dialer Interface .......................................................................8-12
Configuring MLPPP on a Multilink/Dialer interface ....................................................................................... 8-13
Multilink Example ................................................................................................................................... 8-13
Dialer Example ....................................................................................................................................... 8-13
Frame Relay Features .................................................................................................................................... 9-3
Reports and Alarms ................................................................................................................................. 9-9
Multi-point to Point-to-Point Example ..................................................................................................... 9-11
Chapter 10: Configuring Dialer Services
Overview of Dial Services ............................................................................................................................. 10-1
Dial Services Features ........................................................................................................................... 10-1
Asynchronous and Synchronous Support .................................................................................................... 10-2
AT Commands on Asynchronous Ports ................................................................................................. 10-2
V.25bis over Synchronous Interfaces .................................................................................................... 10-2
DTR Dialing for Synchronous Interfaces ................................................................................................ 10-3
Time of Day feature ................................................................................................................................ 10-3
Typical Use for Dial Services ................................................................................................................. 10-3
Dialer Pool .............................................................................................................................................. 10-5
Point-to-Point with Matched Calling/Called Numbers ..................................................................... 10-12
Point-to-Point with Different Calling/Called Numbers ..................................................................... 10-12
Point-to-Multipoint with One Neighbor............................................................................................ 10-12
Point-to-Multipoint with Multiple Neighbors .................................................................................... 10-12
Overview of Dial Backup ............................................................................................................................ 10-13
Dial Backup Features ........................................................................................................................... 10-13
Sequence of Backup Events ...................................................................................................................... 10-13
Link Failure Backup Example ..................................................................................................................... 10-14
Configuring a Dialed Backup Line .............................................................................................................. 10-14
Configuring the Dialer Interface ........................................................................................................... 10-14
Configuring the Physical Interface for the Dialer Interface ................................................................... 10-15
Configuring Interface as the Backup Dialer Interface ...........................................................................10-15
Backup Using ISDN ............................................................................................................................. 10-37
Node A (Backed-up Node) Configuration ....................................................................................... 10-37
Node C (Called Node) Configuration ..............................................................................................10-38
Configuration for Backup with MLPPP Bundle .....................................................................................10-39
Node A (Backed-up Node) Configuration ....................................................................................... 10-39
Node C (Called Node) Configuration ..............................................................................................10-40
Configuration for Ethernet Failover ...................................................................................................... 10-40
Configuration for Frame Relay Encapsulation ..................................................................................... 10-41
Chapter 11: Configuring Integrated Services Digital Network
ISDN Features .............................................................................................................................................. 11-1
BRI Features .......................................................................................................................................... 11-2
PRI Features .......................................................................................................................................... 11-2
BRI (Switched) Configuration Model .................................................................................................... 11-10
PRI Configuration Model ...................................................................................................................... 11-12
Leased-Line Configuration Model ........................................................................................................ 11-14
More Configuration Examples .................................................................................................................... 11-15
T1 PRI .................................................................................................................................................. 11-15
E1 PRI .................................................................................................................................................. 11-15
BRI Leased Line ................................................................................................................................... 11-16
Traffic Shaping per Policy-Map .............................................................................................................. 12-8
Differences Between Traffic Policing and Traffic Shaping ..................................................................... 12-9
Traffic Shaping and Queue Limit ............................................................................................................ 12-9
Congestion Control & Avoidance ......................................................................................................... 12-10
Describing Queue Size Control (Drop Tail) .................................................................................... 12-10
Describing Random Early Detection...............................................................................................12-10
Describing Weighted Random Early Detection .............................................................................. 12-11
Configuration per Interface ................................................................................................................... 12-12
Suggestions for Using QoS on the XSR .............................................................................................. 12-13
QoS and Link Fragmentation and Interleaving (LFI) .................................................................................. 12-13
Configuring QoS with MLPPP Multi-Class ........................................................................................... 12-13
Configuring QoS with FRF.12 .............................................................................................................. 12-14
QoS with VLAN ........................................................................................................................................... 12-14
VLAN Packet with Priority Routed out a Fast/GigabitEthernet Interface ........................................ 12-15
VLAN Packet with Priority Routed out a Serial Interface ................................................................ 12-15
Non-VLAN IP Packet Routed Out a Fast/GigabitEthernet Interface............................................... 12-16
QoS with VLAN Configuration Process ................................................................................................ 12-16
QoS on Input .............................................................................................................................................. 12-17
QoS on VPN ............................................................................................................................................... 12-17
QoS over VPN Features ...................................................................................................................... 12-18
Configuring QoS on a Physical Interface ............................................................................................. 12-18
Configuring QoS on a Virtual Tunnel Interface .................................................................................... 12-18
QoS on a Virtual Interface Example ............................................................................................... 12-19
QoS and VPN Interaction ..................................................................................................................... 12-22
Configuring the Shaper on the VPN Interface ................................................................................ 12-23
Features ....................................................................................................................................................... 13-1
NIM Card .......................................................................................................................................... 13-5
ADSL on the Motherboard................................................................................................................ 13-6
ADSL Data Framing ............................................................................................................................... 13-6
ATM Support .......................................................................................................................................... 13-6
Internet Security Issues .......................................................................................................................... 14-1
How a Virtual Private Network Works .................................................................................................... 14-2
Ensuring VPN Security with IPSec/IKE/GRE ............................................................................................... 14-2
GRE over IPSec ..................................................................................................................................... 14-4
Digital Signatures ................................................................................................................................... 14-5
Machine Certificates for the XSR ........................................................................................................... 14-6
CA Hierarchies ....................................................................................................................................... 14-7
RA Mode ................................................................................................................................................ 14-8
Renewing and Revoking Certificates ..................................................................................................... 14-9
DF Bit Functionality ...................................................................................................................................... 14-9
Configuring OSPF Over Site-to-Central Site in Client Mode .......................................................... 14-14
Configuring OSPF over Site-to-Central Site in Network Extension Mode ...................................... 14-16
Server ............................................................................................................................................. 14-17
Configuring OSPF with Fail Over (Redundancy) ............................................................................ 14-17
xxii
Server 1 .......................................................................................................................................... 14-17
Server 2 .......................................................................................................................................... 14-18
XSR VPN Features ..................................................................................................................................... 14-18
Interoperability Profile for the XSR ............................................................................................................. 14-46
Scenario 1: Gateway-to-Gateway with Pre-Shared Secrets ................................................................ 14-46
Scenario 2: Gateway-to-Gateway with Certificates .............................................................................. 14-49
Chapter 15: Configuring DHCP
Overview of DHCP ....................................................................................................................................... 15-1
Features ....................................................................................................................................................... 15-1
DHCP Server Standards ........................................................................................................................ 15-2
How DHCP Works ........................................................................................................................................ 15-2
DHCP Set Up Overview ............................................................................................................................... 15-9
Features ....................................................................................................................................................... 16-1
Access Control Lists ............................................................................................................................... 16-1
LANd Attack ........................................................................................................................................... 16-2
Large ICMP Packets......................................................................................................................... 16-4
Ping of Death Attack......................................................................................................................... 16-4
Spurious State Transition ....................................................................................................................... 16-4
General Security Precautions ....................................................................................................................... 16-4
Connecting Remotely via SSH or Telnet with AAA Service ................................................................... 16-6
Firewall Feature Set Overview ..................................................................................................................... 16-9
Reasons for Installing a Firewall ............................................................................................................ 16-9
Types of Firewalls ................................................................................................................................ 16-10
ACL and Packet Filter Firewalls ..................................................................................................... 16-10
ALG and Proxy Firewalls ................................................................................................................ 16-11
Pre-configuring the Firewall ........................................................................................................................ 16-23
Steps to Configure the Firewall .................................................................................................................. 16-23
XSR with Firewall ................................................................................................................................. 16-24
XSR with Firewall, PPPoE and DHCP ................................................................................................. 16-26
XSR with Firewall and VPN .................................................................................................................. 16-27
Firewall Configuration for VRRP .......................................................................................................... 16-33
Firewall Configuration for RADIUS Authentication and Accounting ..................................................... 16-33
Appendix A: Alarms/Events, System Limits, and Standard ASCII Table
Recommended System Limits ........................................................................................................................ A-1
System Alarms and Events ............................................................................................................................ A-3
Firewall and NAT Alarms and Reports .........................................................................................................A-14
Standard ASCII Character Table ..................................................................................................................A-19
Appendix B: XSR SNMP Proprietary and Associated Standard MIBs
Service Level Reporting MIB Tables ..............................................................................................................B-1
This guide provides a general overview of the XSR hardware and software features. It describes
how to configure and maintain the router. Refer to the XSR CLI Reference Guide and the XSR Getting Started Guide for information not contained in this document.
This guide is written for administrators who want to configure the XSR or experienced users who
are knowledgeable of basic networking principles.
Contents of the Guide
Information in this guide is arranged as follows:
•Chapter 1,Overview, introduces key features of the XSR.
•Chapter 2,Managing the XSR, describes the three methods of managing the router along with
the control commands and tools available to accomplish that task including Remote Auto
Install (RAI) and memory management.
•Chapter 3, Managing LAN/WAN Interfaces, describes system FastEthernet/GigabitEthernet and
High Speed Serial features, how to configure them, and MIB-II statistics collected for LAN
interfaces.
•Chapter 4, Configuring T1/E1 & T3/E3 Interfaces, outlines XSR controller features, including the
Drop and Insert NIM, and how to configure and troubleshoot them.
Preface
•Chapter 5, Configuring IP, outlines a host of XSR IP protocol suite features, including Secondary
IP, VRRP, Proxy DNS, VLAN and Policy Based routing, Route Preference, multiple static
routes, CIDR, and their associated configuration.
•Chapter 6, Configuring the Border Gateway Protocol, describes XSR-supported BGP-4 features
including MIB tables defined in RFC-1657, BGP SNMP traps, protection of sessions,
capabilities advertisement, route reflection, communities, route refresh, route flap
dampening, AS confederations, and debug capability.
Mode (PIM-SM) and Internet Group Management Protocol (IGMP) configuration with these
features and how to configure them: IGMP versions 1, 2 and 3 (on LAN interface only), PIMSM version 2, Static IGMP group membership, Dynamic and Static RP, Register and Assert
Mechanism, Rendezvous Point Tree (RPT) Build-up, Shortest Path Tree (SPT) Build-up, RPT
to SPT Switch, Join/Prune Mechanism, and Source Specific Multicast (SSM) Support.
•Chapter 8, Configuring PPP, details XSR support for the PPP and Multi-link PPP protocols,
Multi-Class MLPPP, peer entity authentication, Bandwidth on Command (BAP), and how to
configure these features.
•Chapter 9, Configuring Frame Relay, details how to set up Frame Relay networks on the XSR,
including using rate enforcement (CIR) and congestion control (FECN and BECN), Discard
Eligibility, Frame Relay Inverse ARP, LMI support, and FRF.12 fragmentation.
•Chapter 10, Configuring Dial Services and Back Up, details background information about Dial
Services and Dial Backup across a PSTN, Ethernet failover, Dial on Demand (DoD) and
Bandwidth on Demand (BoD), Multi-link PPP, dialer interface spoofing, Dialer Watch, ISDN
callback, and the commands to configure these features.
XSR User’s Guide xxvii
Conventions Used in This Guide
•Chapter 11, Configuring ISDN, outlines how to set up the Integrated Services Digital Network
protocol on the XSR for BRI, PRI and leased line applications. ISDN protocol tracing and
partial decoding of Q921 and Q931 frames is also described.
•Chapter 12, Configuring Quality of Service, describes XSR support for QoS, including Random
Early Detection (RED), Weighted Random Early Detection (WRED), tail-drop, DSCP, IP
precedence, traffic policing and shaping, priority and CBWFQ queuing, and class-based traffic
shaping.
•Chapter 13, Configuring ADSL, details ADSL line operation over POTS and ISDN circuits,
ADSL data framing format ATM Frame UNI, OAM cell behavior, PDU encapsulation choices:
PPP over ATM (PPPoA), PPP over Ethernet (PPPoE), and Routed IP over ATM (IPoA).
•Chapter 14, Configuring the Virtual Private Network, outlines XSR support for Site-to-Site, Site-
to-Central-Site, and Remote Access VPN applications. Other supported functionality includes
RADIUS authentication, PKI authentication, NAT traversal, IP address management,
dynamic routing over VPN (remote access only), digital signature and certificate support,
GRE over IPSec, and AAA.
•Chapter 15,Configuring DHCP, details the router’s support for the Dynamic Host
Configuration Protocol including dynamic and manual IP address allocation, persistent
storage of client values, temporary or permanent network address allocation, and nested
scopes.
•Chapter 16, Configuring Security on the XSR, describes methods to protect the router against
hacker attacks and install strong security including ACLs, AAA service, firewall, and how to
configure these features.
•Appendix A, Alarms/Events and System Limits, lists the high, medium and low severity alarms
and events captured by the XSR as well as system limits for various XSR functions as a
function of installed memory.
•Appendix B, SNMP Proprietary and Associated Standard MIBs, lists and describes XSR-supported
SNMP tables and objects for the following standard (partial listing) and proprietary MIBS.
Conventions Used in This Guide
The following conventions are used in this guide
Note: Calls the reader’s attention to any item of information that may be of special importance.
Nota: Llama la atencion del lector a cierta información que puede ser de especial importancia.
Caution: Contains information essential to avoid damage to the equipment.
Precaución: Contiene información esencial para prevenir dañar el equipo.
Achtung: Verweißt auf wichtige Informationen zum Schutz gegen Beschädigungen.
Electrical Hazard: Warns against an action that could result in personal injury or death due to an
electrical hazard.
Riesgo Electrico: Advierte contra una acción que pudiera resultar en lesión corporal o la muerte
debido a un riesgo eléctrico.
Elektrischer Gefahrenhinweis: Installationen sollten nur durch ausgebildetes und qualifiziertes.
Personal vorgenommen werden.
xxviii Preface
Conventions Used in This Guide
Warning: Warns against an action that could result in personal injury or death.
Advertencia: Advierte contra una acción que pudiera resultar en lesión corporal o la muerte.
Warnhinweis: Warnung vor Handlungen, die zu Verletzung von Personen oder gar Todesfällen
führen können!
Bold/En negrillaText in boldface indicates values you type using the keyboard or select
using the mouse (for example, a:\setup). Default settings may also appear
in bold.
El texto en negrilla indica valores que usted introduce con el teclado o que
selecciona con el mouse (por ejemplo, a:\setup). Las configuraciones
default pueden también aparecer en en negrilla.
Italics/It áli caText in italics indicates a variable, important new term, or the title of a
manual.
El texto en itálica indica un valor variable, un importante nuevo término, o
el título de un manual.
SMALL CAPS/
MAYUSCULAS
Small caps specify the keys to press on the keyboard; a plus sign (+)
between keys indicates that you must press the keys simultaneously (for
example, CTRL+ALT+DEL).
Las mayusculas indican las teclas a oprimir en el teclado; un signo de más
(+) entre las teclas indica que usted debe presionar las teclas
simultáneamente (por ejemplo, CTRL+ALT+DEL).
Courier font/
Tipo de letra Courier
Text in this font denotes a file name or directory.
El texto en este tipo de letra denota un nombre de archivo o de directorio.
+Points to text describing CLI command.
Apunta al texto que describe un comando de CLI.
FastEthernetFastEthernet and GigabitEthernet references are generally
interchangeable throughout this guide.
Las referencias a los terminos FastEthernet y GigabitEthernet son
generalmente intercambiables en el contenido de esta guia.
XSR User’s Guide xxix
Getting Help
Getting Help
For additional support related to the XSR, contact Enterasys Networks by one of these methods:
World Wide Webhttp://www.enterasys.com
Phone(978) 684-1000
Internet mailsupport@enterasys.com
1-800-872-8440 (toll-free in U.S. and Canada)
For the Enterasys Networks Support toll-free number in your country:
http://www.enterasys.com/support/gtac-all.html
To expedite your message, please type [xsr] in the subject line.
techpubs@enterasys.com
To expedite your message, include the document Part Number in the
subject of your email.
Before contacting Enterasys Networks for technical support, have the following information
ready:
•Your Enterasys Networks service contract number
•A description of the failure
•A description of any action(s) already taken to resolve the problem (e.g., rebooting the unit,
reconfiguring modules, etc.)
•The serial and revision numbers of all relevant Enterasys Networks products in the network
•A description of your network environment (layout, cable type, etc.)
•Network load and frame size at the time of the problem
xxx Preface
•The XSR’s history (i.e., have you returned the device before, is this a recurring problem, etc.)
•Any previous Return Material Authorization (RMA) numbers
1
Overview
This chapter briefly describes the functionality of the XSR. Refer to the following chapters in this
manual for details on how to configure this functionality and the XSR CLI Reference Guide for a
description of associated CLI commands and examples.
The following functionality is supported on the XSR:
•System Management - The XSR’s resources can be managed via four methods: the Command
Line Interface (CLI) for full configuration, performance and fault management; the Simple
Network Management Protocol including SNMP v1/v2c/v3 agent, for remote monitoring;
the NetSight Atlas Router Services Manager application for firewall and ACL configuration;
and the Web to gather version information. These tools control the XSR’s many hardware and
software facilities. Also supported: memory management, SSH v2 server, full configuration
backup and restore, EOS Fallback for reliable image upgrades, Simple Network Time Protocol
(SNTP v3) client and server (unicast mode) external source synchronization, login banner, and
a host of proprietary and standard MIBs including Download, Syslog, Configuration
Management, Configuration Change, Timed Reset, Chassis, Persistence, Host Resource,
Enterprise Firewall and VPN, and Protocol MIBs (OSPF, RIP, Frame Relay, and PPP), SNMP
Informs and Service Level Agreement (SLA) agents. The XSR’s SNMP MIBs support readable
checksums on XSR configurations and the Enterasys Configuration Management MIB will TFTP
a file on-the-fly to the XSR Flash, load the file to running config and save it to startup-config. The
XSR also supports placing a hostname in the Syslog message header and configuring multiple
Syslog servers.
•Remote Auto Install (RAI) - automatically retrieves a centrally managed configuration
specifically created for a remote XSR by one of three methods: over a Frame Relay network
using the lowest numbered serial port, a PPP connection using the lowest numbered serial
port, or over an ADSL connection.
•Ethernet Interfaces - The XSR 1800 Series’ two 10/100 Base-T FastEthernet interfaces and XSR
3000 Series’ three 10/100/1000 BaseT GigabitEthernet interfaces handle the router’s LAN
traffic stream, with support for alarms and events, diagnostics, packet filtering and statistics
gathering, and Ethernet backup.
•T1/E1 & T3/E3 Interfaces - The XSR’s T1/E1 and T3/E3 subsystem on NIM-based I/O cards
handle the router’s WAN traffic with support for alarm detection and signaling, diagnostics,
line encoding, the Drop & Insert NIM, and a host of other functionality.
•SerialInterface - The XSR’s NIM serial interface typically supports PPP providing both
asynchronous and synchronous protocol support. The XSR’s Console port can also be used as
a Serial connection to the router for remote or backup dialin.
•PPP (WAN) -The Point-to-Point Protocol (PPP) provides a standard method for transporting
multi-protocol datagrams over point-to-point links. PPP defines procedures for the
assignment and management of network addresses, asynchronous and synchronous
encapsulation, link configuration, link quality testing, network protocol multiplexing, error
detection, and option negotiation for such capabilities as network-layer address negotiation
XSR User’s Guide 1-1
and data-compression negotiation. Also supported: PPPoE client and sub-interface
monitoring, and Multilink PPP protocols as well as Dial on Demand (DoD), Bandwidth on
Demand (BoD), Multi-Class MLPPP.
•IP Protocol - IP supports interconnected systems of packet-switched computer communication
networks. It uses a 32-bit addressing scheme where an IP address is represented by four fields,
each containing 8-bit numbers. Also supported: secondary IP addressing, CIDR, the Virtual
Router Redundancy Protocol (VRRP), Proxy DNS, VLAN and Policy Based routing, Route
Preference, multiple static routes, and AAA, PPP and OSPF debugging.
•DHCP - The XSR supports DHCP Server and Client on the trusted LAN to provide IP
addresses to computers on a customer's private LAN segment, temporary or permanent
network (IP) address and network configuration parameter assignment to clients, persistent
storage/database of network values for network clients - Bindings Database, persistent
storage of network client lease states kept after a system reboot, persistent and usercontrollable conflict avoidance to prevent duplicate IP address including configurable ping
checking, and visibility of DHCP network activity and leases through operator reports
statistics and logs.
•Network Address Translation - static NAT, Network Address Port Translation (NAPT) and
dynamic NAT by source/destination IP address, dynamic NAT pool mapping with overload,
PPTP/GRE ALG and arbitrary IP address for NAPT, on the interface and port-forwarded
static NAT, multiple NATs on an interface.
•IP Routing - The XSR supports RIP, OSPF and BGP4 dynamic routing, a vital function of the IP
protocol. Stored in a routing table, network data is used to determine the route for each packet
passing through the XSR. Also supported: route redistribution between OSPF and RIP, static
routes, multiple static routes to the same destination with different hops and distances,
Virtual Router Redundancy Protocol (VRRP) for default router redundancy and load
balancing, DNS proxy, Virtual Area Networks (VLAN 802.1Q), priority VLAN routing 802.1P,
policy based routing, route preference, multiple static routes, Protocol Independent Multicast
- Sparse Mode (PIM-SM), and configurable RIP and OSPF poll timers.
1-2 Overview
•Equal-Cost Multi-Path (ECMP) - per packet and per flow (round robin) support for OSPF, BGP
and static routes (RIP excluded).
•Border Gateway Protocol v4 - The XSR supports the following the BGP-4 features: all MIB tables
defined in RFC-1657 including BGP SNMP traps, protection of BGP sessions, capabilities
advertisement, route reflection, communities, route refresh, route flap dampening, AS
confederations, debugging, per neighbor configurable BGP timer and filter tags.
•PIM/IGMP - Protocol Independent Multicast - Sparse Mode (PIM-SM) and Internet Group
Management Protocol (IGMP) is supported with the following features: IGMP versions 1, 2
and 3 (on LAN interface only), PIM-SM version 2, static IGMP group membership, dynamic
RP (BootStrap without Admin Scope Zone support), static RP, register and assert mechanism,
Rendezvous Point Tree (RPT) and Shortest Path Tree (SPT) Build-up, RPT to SPT Switch,
Join/Prune Mechanism, and Source Specific Multicast (SSM).
•Frame Relay - The XSR provides this fast-packet switching method for wide-area networking.
Acting as a DTE, the router encapsulates data in a frame and transmits that data while serving
as a source device. When it is a destination device, it receives frames and de-encapsulates
them. The XSR’s implementation of Frame Relay employs DTE support of the User Network
Interface (UNI) for PVC (DLCI) connections with Committed Information Rate (CIR) traffic
shaping, BECN/FECN congestion control, standard LMIs ILMI, ANSI Annex D, CCITT
Annex A, FRF.12 fragmentation, periodic keep-alives, multi-protocol interconnect over Frame
Relay, Frame Relay Inverse ARP, multiple logical interfaces over the same physical port, QoS
including standard FIFO queuing or IP QoS on DLCIs, DCE support, and Frame Relay over
ISDN.
•Quality of Service - The XSR provides traffic classification using IP Precedence and DSCP bits,
bandwidth control via metered, policed and prioritized traffic queues, and queue
management utilizing Tail Drop, Random and Weighted Early Detection (RED, WRED). Also,
QoS on Input including classification based on class maps (similar to QoS on Output), marking
per traffic flow (DSCP and IP precedence fields), and policing per traffic class, and QoS over
VPN.
•ADSL - Three PDU encapsulation types are available for ADSL: PPP over ATM (PPPoA), PPP
over Ethernet (PPPoE), and Routed IP over ATM (IPoA). Also supported: POTS and ISDN
circuit support, ATM Frame UNI (FUNI) data framing format, OAM cells: AIS, RDI, CC,
Loopback over F4 and F5 flows, up to 30 ATM Permanent Virtual Circuits (PVCs), ATM UBR
traffic class, ATM Adaption Layers 0, 5, response to inverse ARP requests, and maintenance of
SNMP Interface and Interface Stack tables.
•Virtual Private Network - The XSR supports VPN tunnels using L2TP, PPP or IPSec protected
by DES, 3DES, RC4, MD5, AES or SHA-1 encryption. VPN tunnels are authenticated/
authorized for credentials using pre-shared keys or Public Key Infrastructure (PKI) certificates
(Microsoft and Verisign). Also supported: DF Bit override, OSPF over VPN, GRE over IPSec,
interaction between firewall/NAT/VPN, ToS bit preservation, IP helper on VPN interfaces,
IETF/Microsoft-compatible NAT traversal for L2TP, and QoS over VPN.
•Security - In its firewall feature set, the XSR provides stateful firewall protection against a
variety of Denial of Service attacks, FTP and H.323 ALG support, application command
filtering for FTP, SMTP, NNTP, HTTP, onboard URL filtering, firewall logging and
authentication, and supports standard and extended Access Control Lists to manage network
access. Also supported: AAA for firewall, Console/Telnet and SSHv2 users, and dynamic
reconfiguration of firewall policy without having to restart the code.
•Dialer Interface - Dial Services are a cost-saving alternative to the leased line connection
between two peers and they can be implemented for different types of media for both
inbound and outbound connections. The XSR supports incoming calls on analog modems.
•Dial Backup - The dialed backup feature provides a backup link over a dial line. The backup
link is brought up when a failure occurs in a primary link, and it is brought down when the
primary link is restored. This feature is supported for PPPoE to enable cable backup over
FastEthernet/GigabitEthernet sub-interfaces. Also supported: Dialer Watch, ISDN callback,
and dialer interface spoofing.
•ISDN - The XSR’s BRI and PRI switched and leased lines set up and tear down calls, usually
under the control of the Dialer. The XSR’s ISDN services BRI and PRI lines with a 1, 2 or 4 port
Channelized NIM card for PRI lines, 1 or 2 port BRI-S/T NIM card, or 1 or 2 port BRI U NIM
card. Also supported: Circuit Mode Data (CMD) channel (DS0s) switching by the CO to the
destination user for the duration of the call, outgoing calls supported for Backup, DoD/BoD,
incoming calls routed to the correct protocol stack based on called number/sub-address and
calling number/sub-address, permanent B-channel support, i.e. 64 or 128 kbps lease line (each
BRI port can be set for CMD or Leased-Line mode of operation), BRI supported switches:
ETSI, TEI auto-negotiated for BRI, automatic configuration of Q.921/Q.931 (Layer 2/Layer 3)
by selection of switch type, PRI supported switches: ETSI, NI, DMS100, NTT, automatic
configuration of PRI restart and maintenance modes, Fixed TEI of 0 for PRI, ISDN switched
and leased line connections, bandwidth optimization through Dial on Demand (DoD),
Bandwidth on Demand (BoD) and Bandwidth Allocation Protocol (BAP), security through
caller ID, call monitoring, ISDN callback, Multilink PPP (MLPPP), per call activation for NTT
switches, and Frame Relay over ISDN. The XSR also provides: asynchronous serial support
through an external modem, synchronous serial, Unnumbered Interface Addressing, PPP
encapsulation, authentication from XSR’s database for PAP and CHAP, dialer profile support,
configurable redialer, ISDN callback, dialer watch, and dialer interface spoofing.
XSR User’s Guide 1-3
1-4 Overview
The XSR can be managed via three interfaces with varying levels of control: the Command Line
Interface (CLI) for full configuration, performance and fault management; the Simple Network
Management Protocol (SNMP) for remote monitoring and firmware upgrades, and the Web for
gathering version information.
Utilizing the Command Line Interface
The Command Line Interface (CLI) is a widely used tool to access and control configurable
parameters of the XSR. You can access the CLI three ways:
•Directly connect to the Console port via an asynchronous terminal
•Over the network using Telnet or SSH via a LAN or WAN interface
Connecting via the Console Port on XSR Series
For ease of use when first setting up the XSR, you can directly connect the Console port to an
asynchronous terminal (via Microsoft’s HyperTerminal or other program) with the following
values: 8 data bits, no parity, 9600 bps, 1 stop bit, flow control - none. Because the Console port is
wired as a DCE with a DB-9 connector, a DB-9 null modem cable is needed to attach a standard PC
COM port to the Console port.
2
Managing the XSR
Although a login (admin) is required to make this connection, for additional security you can later
delete the admin user as well as disable Telnet sessions through the Console.
Using the Console Port for Dial Backup on the XSR 1800 Series
Optionally, you can set up the Console port as a dial-in WAN interface for dial backup purposes
(refer to the following Caution). This option is avaialable only on the XSR 1800 series. For details,
see Chapter 3 of the XSR Getting Started Guide.
Caution: When you enable the Console port as a WAN port, you can no longer directly
connect to it because it is in data communication mode. Your only access to the CLI will
be to Telnet/SSH to an IP address of a configured port. Also, if
set up any of the ports properly and sets up the console port as a serial port, you will no
longer be able to login and will have to press the Default button (1800 Series) to erase
your configuration. If you opt to connect a modem to the Console port with the required
straight-through cable, configure the sample settings described below.
Note: This feature is not supported on the XSR 3000 Series.
startup-config does not
XSR User’s Guide 2-1
Utilizing the Command Line Interface
Using the Console Port to Remotely Control the XSR
The XSR’s Console port can also be connected to a modem for the purpose of remote console
control. Make the connection with a straight-through cable and enter the following XSR commands:
The XSR supports attaching a Serial (RS-232) NIM interface and modem to accept inbound and
outbound data calls. Modem switches and the receiving-side XSR are configured exactly as
described in “Using the Console Port to Remotely Control the XSR” except that the
serial 0
cabling is required again for the connection.
On the calling-side XSR, enter the following commands:
And enter the following calling-side modem switch settings:
command must instead specify interface serial 1 (or higher). Straight-through
• DTR normal (DTR disconnects)
• Echo offline commands
• Verbal result codes
interface
2-2 Managing the XSR
• Display result codes
• Carrier Detect normal
• AT command mode enabled
Terminal Commands
If you want to display identification information about the current terminal connection, issue the
show whoami command. Refer to the XSR Getting Started Guide and XSR CLI Reference Guide for
more information on commands.
Connecting via Telnet
Once the XSR is properly configured with a valid IP address, you can remotely connect to the CLI
via Telnet using the default user admin with no password. Later, you can create users with the
username command.
Although up to five concurrent Telnet/SSH and one Console sessions are supported, if more than
one session is running simultaneously (including the Console session), only one session permits
configuration changes. Any other session could only view configuration settings. This prohibition
applies to all commands that make changes to the configuration and is limited to Global mode.
For example, if a user is in Global mode and another user tries to enter Global mode, the second
user will get the following error message:
XSR#config
Configuration is currently locked by user admin. Please try later.
Also, in order to ensure that an administrator can always login to the router, one of the five
permitted Telnet or SSH sessions is always reserved for the administrator.
Utilizing the Command Line Interface
That is, if the first four sessions are regular users, the fifth session will allow only the
administrator to login. But if one of the first four is logged in as administrator, then the fifth
session can be any user. You can also Telnet from the XSR to a server by using the
ip_address
command. It is a useful utility for diagnostics. Be aware that the router will try to
make a Telnet connection for 70 seconds.
Connecting via SSH
Secure Shell (SSH v2) encrypts the link to the XSR so it is a more secure alternative to Telnet for
remote connections. To activate SSH, invoke the following commands:
•Create a host key pair with
•Add an AAA user including a password and privilege level with aaa user, password and
privilege 15. You can also create a user in the CLI database with the username command.
•Enable SSH access with
•Enable local authentication with aaa client ssh
•Load an SSH client application on your PC to connect with the XSR
•Optionally, you can disable Telnet with
•Optionally, if you are enabling the firewall feature set you can configure an Access Control List
(ACL) to allow a single host SSH access to the XSR by entering these commands:
XSR(config)#access-list 100 deny tcp any host 192.168.1.10 eq 22
XSR(config)#access-list 100 permit ip any
XSR(config)#interface fastethernet 1
XSR(config-if<F1>)#ip access-group 100 in
telnet
crypto key dsa generate
policy ssh
ip telnet server disable for higher security
XSR User’s Guide 2-3
Utilizing the Command Line Interface
PuTTY and other shareware programs are compatible with the XSR’s SSH server.
Refer to the XSR Getting Started and CLI Reference guides for more details.
Accessing the Initial Prompt
The CLI is protected by security. Before you can access EXEC mode, you must enter a valid
password. This mode lets you test basic connectivity of the XSR but does not permit you to change
or monitor the router’s configuration. Access to enhanced commands is permitted only if you
enter Privileged EXEC mode by entering
while in EXEC mode. Refer to Tab le 2-1 for session limits.
Table 2-1 Session Limits
ParameterLimit
Total number of CLI Telnet/SSH sessions permitted5
SSH sessions permitted with 32 MBytes of memory1
Console sessions permitted1
Number of Telnet sessions reserved for administrators1
Terminal auto-logout timeout value (configurable)1800 seconds
The
show resources command displays all resources created and the memory utilized. Refer to
the XSR CLI Reference Guide for more details.
enable. You can logout at any time by entering exit
Synchronizing the Clock
XSR 1800 and 3000 Series routers have an on-board Real Time Clock (RTC) chip with which to
keep accurate time across the network. As an alternative to accessing a public time server, you can
utilize the RTC as a time reference for isolated networks employing the Simple Network Time
Protocol (SNTP). XSR 1200 Series routers do not carry an RTC chip, however, and for these you
must synchronize from an external source.
The XSR supports both SNTP v3 client and server (unicast mode) to synchronize logs on routers,
switches and other network devices. Scenarios include isolated “flat” or hierarchical topologies as
well as public time-server schemes. A flat scenario, for instance, might have Router A (XSR 3150)
acting as a server to both Router B (XSR-1220) and Router C (XSR-1220) which makes a client
request through Router B via an ISDN connection. A hierarchical scenario, on the other hand,
might have Router B acting as both SNTP client and server, making a client request of Router A
and taking a client request from Router C over ISDN.
Note: We recommend using an NTP time server over an SNTP server with an RTC as its primary
source for greater accuracy. In this respect, the default stratum is set internally to 10.
SNTP client and server are configured with the
A.B.C.D.][alternate | A.B.C.D.] and sntp-server enable commands, respectively. Also,
you can also set the interval between client requests with the
command.
Refer to the XSR Getting Started Guide for a configuration example and the XSR CLI Reference Guide
for command details.
sntp-client server [primary |
sntp-client poll-interval
2-4 Managing the XSR
Managing the Session
A first-time CLI session is set up with default attributes; e.g., the session is set to time out after
1800 seconds of idle time. You can reconfigure session values such as create users, passwords, and
login banners, and set Telnet and Web access. Refer to the XSR CLI Reference Guide for details
about these commands.
Remote Auto Install
The Remote Auto Install (RAI) feature automatically retrieves a centrally managed configuration
specifically created for the node’s operation in your network. Basically, RAI sends a configuration
file from a TFTP server for configuring the remote XSR. This file is then placed in the
directory as the
by one of three methods: over a Frame Relay network using the lowest numbered serial port, a
PPP connection using the lowest numbered serial port, a PPPoE connection using the ADSL
network, or over an LAN connection using the lowest number Ethernet port.
RAI simplifies management and deployment of the XSR. Because device configurations are stored
centrally on the TFTP server, re-configuring the XSR requires only a remote reboot. Installing the
device at a new location involves deploying a new
name (based on the serial number or hostname) and rebooting the XSR.
Described in further detail, these choices are:
startup-config and run via the normal startup process. RAI can be performed
Utilizing the Command Line Interface
Flash:
startup-config file with a corresponding
•RAI over Frame Relay is performed over a Frame Relay network. The RAI central site includes a
Bootp server on a DLCI to deliver the local IP address for the branch (remote) site in order to
communicate with the configuration management server.
•RAI over PPP can be performed over either leased or dial-up lines. Leased line RAI operates
similar to Frame Relay RAI in that it is perfomed over a serial link via a leased Telco line. Dialin RAI occurs where a designated port is configured and waiting for the central site to dial in.
Dial in can utilize a modem attached to the XSR’s serial or switched BRI/ PRI interfaces.
•RAI over ADSL can be performed over the ADSL network. XSR uses the auto discovery
mechanism to identify an existing PVC on the ADSL line and tries to retrieve the startup
configuration using PPPoE and TFTP over that PVC.
•RAI over Ethernet utilizes a DHCP client/server methodology to quickly retrieve a particular
file from a TFTP server that will be used to configure the remote XSR.
Refer to the “Software Configuration” chapter of the XSR Getting Started Guide for a RAI
configuration examples and phased output from the program.
RAI Features and Requirements
At the branch site, the XSR supports the following Frame Relay IETF features:
• Operates on Serial NIM interfaces only - lowest slot/card/port only.
• Standard physical Serial media-types.
• DTE LMI type ANSI, ILMI, Q933 supported.
• Up to 30 DLCIs supported on Frame Relay (FR) connection.
• Bootp client.
• Reverse DNS client.
• TFTP client.
XSR User’s Guide 2-5
Utilizing the Command Line Interface
• Backwardly compatible/transparent to those not requiring RAI.
• Console display of RAI progress.
• Console interrupt of RAI process at any time.
• CLI configurable RAI loading. Persistent, 5-minute try, and none (disable).
• No rebooting required to activate configuration.
• Hostname choices are flexible to include/exclude domain and canned names as well for the
configuration file.
• The configuration file is examined for the proper target node identification to minimize the
chance of being locked out of remote access.
At the central site, the XSR supports the following Frame Relay IETF serial interface features:
• Operational on all physical interfaces which support Frame Relay - T1, T3, and Serial.
• Bootp server configurable on a per DLCI basis.
• DLCI limit based on standard LMI limitation. (ILMI, AUTO - 190, ANSI, Q933A - 300)
• Bootp server.
• IP helper address for forwarding to DNS and TFTP servers.
• Configurable to Inverse ARP and No Inverse ARP on a DLCI basis.
At the branch site, the RAI ADSL has the following features:
• F5 OAM end-to-end or segment cells are used to discover the link VPI and VCI numbers.
• PVC connections should be set with the VPI ranging from 0 to 128 and VCI from 32 to 128.
• RAI requires the ADSL line to be connected to the first port of the ADSL card.
• ADSL RAI works with PPPoE SNAP or MUX. The PPPoE server must be reachable from the
DSLAM either by ATM or by bridging. ADSL RAI does not work with IPoA or PPPoA.
• The local IP address is obtained using PPPoE IP address negotiation.
• The serial number of the XSR is the initial username and password for CHAP/PAP PPPoE.
• The file name of the
startup-config sought from the TFTP server is the serial number of
the branch XSR.
At the central site, the RAI ADSL requires the following features:
• The device terminating the ADLS connection (mostly likely DSLAM), has configured and
enabled PVC with F5 OAM cells.
• The PPPoE server provides a pool of IP addresses for IP configuration of the remote XSR.
• The PPPoE server authenticates the remote XSR with CHAP or PAP using the XSR’s serial
number as the username (hostname) and password.
• On the interface where PPPoE is terminated, broadcasting should be allowed by helper
address or some other method in order for TFTP discovery packetsto find the TFTP server.
2-6 Managing the XSR
• The name of the
startup-config files stored on the TFTP server should match the serial
number of the branch XSR.
Utilizing the Command Line Interface
DHCP client over the LAN:
• Operational over an Ethernet interface only on the lowest slot/card/port only.
• Uses the options field for TFTP server, IP address, host name and config file.
• Optionally uses Reverse DNS if options are not populated.
At a branch site, the XSR supports the following features over a PPP IETF serial interface:
• Operational on Serial NIM interfaces only - Lowest slot/card/port only.
• Supports standard physical Serial media-types.
• Supports Sync/Async interface type.
• Supports the following clock rates (in bps) for the Async interface:
–9600, 14400, 33300, 28800, 57600, and 115200 baud.
• Supports PPP and MLPPP negotiation via LCP.
• Supports IP address negotiation via IPCP.
RAI Requirements on the XSR
The branch XSR retrieves the configuration file by means of a TFTP client. The TFTP transfer
requires a specific file name and unique local IP address to communicate with a remote server.
The branch XSR must get the local IP address from the central site. How it is done differs between
RAI methods. FR RAI uses the Bootp server residing on the central site node, RAI DHCP gets the
local IP through DHCP negotiation, while PPP-based RAIs facilitate PPP IP address negotiation.
At the end of the process, the interface on the branch XSR is configured with an IP address and can
communicate with the TFTP server.
The file name is the name of the startup file that is transferred from the TFTP server to the branch
XSR. It derives from the XSR hostname. As in the case of the local IP address, the branch XSR must
get the hostname from the central site. RAI uses the rDNS for this purpose. DNS servers map
nodenames/domains and IP addresses - typically, you provide a hostname and the DNS server
returns the IP address. But rDNS lookup used by RAI offers an IP address and DNS returns the
hostname.domain. RAI ADSL is an exception to this process since is not required to perform rDNS
during the RAI process because it uses the serial number of the XSR as the name of the
config
configuration file, no rDNS is required because
file. In the case of RAI over Ethernet, where DHCP is configured to provide the
config-file is the file name.
In general, accessing the DNS or TFTP server requires the client (in this case, the branch XSR) to
know the IP address of the server. Since the branch router has no configuration and no knowledge
of the server address, it must broadcast a request for DNS or TFTP access. For RAI to work
correctly, the terminator of the connection (other end of the FR DLCI, PPP or PPPoE point-to-point
connection) is required to channel the broadcast to a specific address. This is done by entering the
ip helper-address command at the central site.
How RAI Components Work
startup-
Frame Relay (Remote Router)
The FR interface keeps the FR link alive via proper protocol handling of LMI. If the connection
fails, or new DLCIs are added to the list, the FR interface will notify RAI of the changes.
XSR User’s Guide 2-7
Utilizing the Command Line Interface
RAI checks each DLCI, up to 30, on a given interface for a Bootp response, an rDNS server and a
TFTP server with a configuration file. The first DLCI that accomplishes this will be chosen. If the
connection fails, RAI will reset itself and restart at Phase 1, next media-type.
If the DLCI does not have all of the correct servers and responses, the next DLCI on that interface
is queried. The last DLCI in the list will loop around to the first DLCI to be continued indefinitely
in persistent mode and for five minutes in non-persistent mode as set by the
netload command.
A node with no
startup-config will default to persistent (forever) mode. A node with no Serial
NIM card installed will abort RAI processing immediately and proceed to the login prompt after
executing a local startup-config file if it exists.
While in RAI mode, inverse ARP, pings, and other packets entering the port may be optionally
responded to depending on the phase of the process. It is not recommended that you rely on the
proper response to these packets.
Bootp Client
The Bootp client sends up to five broadcast bootp requests with the MAC address of the first
Ethernet port in the node as the client's unique hardware address. The MAC address is chosen this
way for compatibility with bootp servers to be associated based on the hardware address. In
newer FR/routers which provide Bootp server functionality inside the FR configuration, this
hardware address field is ignored and responded to locally with static mapping.
In the Bootp response, the boot file provided is ignored by the client. The IP address assigned by
the Bootp server in the bootp reply is used as the client's IP address.
Reverse DNS Client
The rDNS client sends a broadcast request with the discovered IP address from bootp as the
source. This rDNS request occurs five times before quitting. The broadcast relies on the central site
router to have a helper IP address configured to forward to the correct server. Use the
helper-address
command to set the DNS server IP address.
ip
TFTP Client
The TFTP client broadcasts a request for the hostname-config file first. The TFTP server responds
with a unicast reply, from then on unicast is used for both the client and server. The TFTP
broadcast relies on the central site router to have a helper IP address configured on the
corresponding interface to forward to the correct server.
If the file is not found or is read-protected, the TFTP client will try the additional file types shown
below. Once all the names have been exhausted, the next DLCI from FR will be tried.
If the server does not respond, RAI tries the next DLCI, renegotiating bootp and rDNS as before.
Frame Relay (Central Site)
At the central site, the node is a fully configured router to accept broadcast bootp requests from a
remote router. If bootp service is to be provided by an external server then omit this parameter.
2-8 Managing the XSR
• Hostname-confg
• Hostname.domain-confg
• Hostname.cfg
• Hostname.domain.cfg
• enterasys-confg
• enterasys.cfg
Utilizing the Command Line Interface
With bootp enabled, DHCP relay and server functionality is disabled on this DLCI for broadcast
packets entering from this DLCI. Unicast bootp requests are still forwarded to the server.
Configuration on a DLCI by DLCI basis is supported for a bootp response, requiring that a
statically-mapped DLCI number be configured with a corresponding IP address. This mapping is
valid for both point-to-point and multi-point sub-interfaces.
Since the XSR does not support an internal rDNS or a TFTP server, you must map the helper
address to the appropriate server in sub-interface mode with
ip helper-address A.B.C.D.
DHCP over LAN (RAI over Ethernet)
The DHCP over LAN client/server RAI employs a very fast installation for providing a running
configuration to an XSR. RAI over Ethernet retrieves a particular file from a TFTP server that will
be used to configure the remote router. This file will then be copied to Flash as the
config
and executed via normal startup procedures.
DHCP Client must be set on the XSR’s first Ethernet port. It sends a DHCP request several times
up to 18 seconds and if no response is received, RAI will proceed to the next RAI connection type.
The DHCP Client seeks the following information:
•IP Address - This mandatory data is required because the DHCP Server must assign a static MAC address to the IP address
•Config file name - This optional data is needed otherwise a reverse DNS server is required.
startup-
•TFTP server address - This optional data is needed otherwise TFTP will send its initial message.
•Hostname - This optional data is not needed if the config file or an rDNS server are available
In practice, one of the following scenarios is played out:
•If the client receives an IP address only, it will request the hostname.domain via reverse DNS
and then a TFTP broadcast will be sent to find the file.
•If the client receives the config file name as well as the TFTP server address, then the TFTP
request will be initiated as a unicast message containing the DHCP config file name.
•If the client receives the hostname, reverse DNS will not be tried. The hostname will be used
only if the client config file name is not provided.
The DHCP application usually performs dynamic address assignment on a first-come, first-serve
basis from an address pool. For RAI to work properly, the DHCP server must statically map the
XSR’s MAC address to the IP address that will be used by reverse DNS. Failing to do so will cause
the XSR to try retrieving the wrong file from the TFTP server.
The DHCP Server seeks the following information:
•IP Address - This mandatory data is required because the DHCP Server must assign a static MAC address to the IP address
•Config file name - This optional data is supplied by DHCP Option 67.
•TFTP server address - This optional data is supplied by DHCP Option 150.
•Hostname - This optional data is supplied by DHCP Option 12.
The XSR’s DHCP server feature is used by RAI over Ethernet but if a PC/Unix/Linux-based
application is available and meets the criteria for static assignment of IP addresses based on MAC
addresses, it may be used.
XSR User’s Guide 2-9
Utilizing the Command Line Interface
PPP RAI over a Leased Line
PPP over a leased line performs similarly to Frame Relay RAI over a serial link via a leased Telco
line. When PPP negotiation is successful, a point-to-point connection is established from the
remote XSR to the central router. Then the remote XSR can obtain its IP address. But, you must
assign a default peer IP address in the central router to give the remote XSR a valid IP address.
After the remote XSR acquires the address, RAI proceeds by sending DNS and TFTP requests.
At the central site, the node will be fully configured with PPP encapsulation. In case multilink is
required, the PPP multilink option is enabled and a multilink interface created. The central router
is also configured with a default IP address over the serial interface for non-multilink PPP
circumstances and over a multilink interface for a multilink PPP scenario.
PPP RAI over a Dial-in Line
Dial-in PPP RAI is performed as a background task in that the designated port is configured and
waiting for the central site to dial in while the other RAI type (Ethernet/Frame Relay/PPP Leased
line) is still operating on the other ports. As soon as the dial-in port reaches a PPP up state, the rest
of the RAI process is terminated.
Dial-in line RAI requires either a modem attached to the serial interface or the switched BRI/PRI
interface. Similar to leased line PPP RAI, successful PPP negotiation provides the point-to-point
link from the remote XSR to the central router. Authentication may then be required by the central
site. After successful authentication, the remote XSR can obtain the IP address through negotiation
but a default peer IP address must be assigned in the central router to provide the remote XSR
with a valid IP address.
Dial-in PPP RAI is directed to a port by the following priority with only one port type defined:
•The first BRI port found in the XSR or,
•The first PRI port found in the XSR or,
•The second serial port found on the XSR (since the first serial is defaulted to be used for Frame-
Relay/PPP Leased line RAI).
The XSR’s Dialer interface (Dx) is configured to handle a dial-in call and set for PPP encapsulation
to accept either CHAP or PAP authentication. While being authenticated by the central site, the
serial number of the remote XSR will be used as the user name and the password. The central site
must decide which PPP authentication type to use or none at all.
The Dialer interface’s IP address is negotiated and is assigned via PPP negotiation similar to PPP
leased line RAI.
Refer to the XSR Getting Started Guide for configuration examples.
PPP RAI over ADSL
RAI ADSL is performed over the ADSL line using PPPoE. Similar to other RAI methods, RAI tries
to configure a point-to-point connection in order to download the startup file from the TFTP
server. To reach the TFTP server, RAI ADSL must connect to the DSLAM with a proper PVC and
establish the PPPoE session with the PPPoE server. The PPPoE server that terminates the PPPoE
connection for the XSR handles the TFTP request and directs it to a proper TFTP server (that may
or may not be on the same device as the PPPoE server).
When the XSR boots without the
method tried is RAI over ADSL. If that fails, RAI moves on to other available RAI methods. RAI
ADSL passes through four phases to configure the XSR during which it displays console messages
about the state of the process.
startup-config and the ADSL card is installed, the first RAI
2-10 Managing the XSR
Utilizing the Command Line Interface
The first phase establishes a physical connection (training) on the ADLS line. RAI ADSL attempts a
physical connection on the first port of the ADSL card, waiting one minute for training to succeed.
If it fails, RAI abandons ADSL RAI and moves to the next available RAI method.
After training with the DSLAM, RAI must configure a proper PVC channel on the ADSL line. In
this discovery hase, PVCs on a particular ADSL line are preconfigured on the DSLAM that
terminates the ADSL physical line. In order to discover VPI and VCI numbers for the PVC, RAI
ADSL sends F5 OAM cells on the line and collects responses (if any) from the the DSLAM. RAI
searches PVCs starting from VPI = 0/VCI = 30 and stops on VPI=128/VCI=128. Because ADSL
RAI conducts a linear search of the VPI/VCI space, searching for a PVC with high VPI/VCI
values can be lengthy. Currently, RAI does not support preconfigured VPI/VCI numbers.
RAI stays in discovery phase until it finds the first PVC that responds on OAM cells or until it
exhausts the PVC space in which case it abandons ADSL RAI and moves to the next available RAI
method.
In the port setting phase, RAI configures sub-interface 1 on the first port of the ADSL card (
0.1
) with the discovered PVC. If there is more than one discovered PVC, RAI begins with the first
one. ADSL RAI tries two PPPoE encapsulations - SNAP and MUX. If authentication is required,
RAI ADSL uses CHAP or PAP and takes the serial number of the XSR as its username and
password - the PPPoE server must be configured with the XSR serial number to authenticate
successfully. If authentication succeeds, the IP address is retrieved from the PPPoE server and the
IP layer comes up. RAI ADSL waits one minute for authentication and the IP connection to come
up. If it times out, it proceeds to the next encapsulation, or if both encapsulation types fail, for that
PVC to try the next discovered PVC. In a case where there are no other PVCs to try, RAI abandons
ADSL RAI and moves on to the next RAI method.
The final phase involves TFTP, where RAI downloads the startup file. This phase is common to
other RAI methods. Because TFTP broadcasts the request for the TFTP server, it is important that
the server terminating the PPPoE session direct this request to the TFTP server (using the IP helper
address). The startup file name is the serial number of the device.
If TFTP fails and PVCs exist that were not previously tried for configuration, RAI returns to
PPPoE negotiation and reconfigures the ATM 0.1 interface with a new PVC. Otherwise, it
abandons ADSL RAI and moves on to the next RAI method.
CLI Editing Rules
To use the CLI efficiently, be aware of the following rules:
•Case-sensitivity: CLI commands are not case-sensitive. For example, you can enter either
VERSION
case sensitive. For example, entering
snmp-server community PUblic
or show version to display the XSR's software revision. But, some parameters may be
atm
SHOW
snmp-server community public is different from
•Command Abbreviation: You can abbreviate commands and keywords to the minimum number
of characters that define a unique abbreviation. For example, you can abbreviate the
command to
the letters
hostn (but you cannot abbreviate to hos because other commands also start with
hos).
hostname
•Output Display: By default, output data are displayed one page at a time if the data occupies
more than one page. In this case, you can use the spacebar to scroll down to the next page or
press
ENTER to scroll down one line at a time. The default page size is 132 characters wide, 23
rows high and they are configurable in a range from 0 to 512 characters using the
terminal
command. Refer to the XSR CLI Reference Guide for more information about the command.
XSR User’s Guide 2-11
Utilizing the Command Line Interface
•Command Recall: Non-help commands are stored in the command history list buffer up to the
last 32 commands. You can recall and edit previous commands using shortcut keys. For
example:
applied repeatedly. The up-arrow or down-arrow keys provide the same feature if your
terminal supports these keys.
Ctrl+p/Ctrl+n will list the previous/next command respectively and can be
•Tab Completion: Pressing the
TAB key or CTRL+I completes a command. In case of an
ambiguous match, the word is completed up to the character which leads to ambiguity. For
example,
“command”
hostname and hostDos share the letters host, so tab completion completes the
ho to host.
•Carriage Return/Enter: Pressing the carriage return/ENTER key signals the end of a CLI
command.
•Help Symbol: At any point you can enter the
? character to prompt for a list of possible
commands/parameters at a particular mode.
•Error: Proper error messages are displayed if the command could not be issued due to syntax
errors or invalid values made by the user.
Typi n g the se ch aract ers w ill produce output as follows:
XSR#showFIioLLJl
XSR#showFIioLLJl
^
% invalid input detected at '^' marker
XSR#
•CLI Terminal Editing Command Keys: Refer to the following table for these useful shortcuts.
Table 2-2 CLI Shortcuts
CommandDescriptionCommandDescription
Ctrl + a
+ b
Ctrl
Ctrl + c
Ctrl + d
Ctrl + e
Ctrl
+ f
Ctrl + h
Ctrl
+ I
Ctrl
+ k
Ctrl + l
Ctrl
+ n
Move cursor to beginning of line
Move cursor back 1 character
Same as the CLI end command
Delete 1 character after cursor
Move cursor to end of line
Move cursor forward 1 character
Delete 1 character before cursor
Tab completionDelDelete a character
Delete all characters after cursor
Echo current line
Next CLI command in history
Setting CLI Configuration Modes
The CLI provides modes of operation permitting a subset of commands to be issued from each
mode. Also, you can issue any command and acquire any mode if the command entered or mode
acquired subscribes to the same parent. For example, you can issue the
command at Crypto Map mode because both Serial Interface and Crypto Map modes subscribe to
Global (config) mode. Table 2-3 describes a few primary modes of operation.
Ctrl + p
Ctrl + r
Ctrl + u
Ctrl + w
Ctrl + x
Ctrl + y
Ctrl + z
Esc + b
Esc + d
Esc + f
Previous CLI command in history
Echo current line
Delete all characters before cursor
Delete 1 word before cursor
Delete all characters before cursor
Restores the most recently deleted item
Same as the CLI end command
Move cursor back 1 word
Delete to end of word at cursor
Move cursor forward 1 word
interface serial
2-12 Managing the XSR
Utilizing the Command Line Interface
Table 2-3 CLI Configuration Modes
ModeFunctionAccess MethodPrompt
User EXECPassword-protected mode:
•Changes terminal settings
•Performs basic tests
•Displays system information
Privileged
EXEC
GlobalSets system-wide values. Save changes
InterfaceModifies/assigns port parameters on a
RouterSets RIP, OSPF or BGP parametersEnter router rip/ospf in Global mode XSR(config-router)#
This mode:
•Sets system operating values
•Shows configuration parameters
•Saves/copies configurations
after a reboot by copying the runningconfiguration to the startup-configuration
port-by-port basis
Login processXSR>
Enter enable in User EXECXSR#
Enter configure terminal in
Privileged EXEC
Enter interface interface-type
<port#> in Global mode
XSR(config)#
XSR(config-if<xx>)#
Refer to Figure 2-1 for a graphic example of configuration modes.
Figure 2-1 Partial Configuration Mode Tree
Login
EXEC
enable
Privileged EXEC
Crypto map
Interface if-type num
Config-if
show commands
Global Configuration
1
5
Router router-parameter
configure
4
show commands
Controller cont-parameter
Config-Router
5
3
T3/E3
Controller
T1/E1
2
The footnotes below refer to command options cited in the illustration.
1.The interface type can be one of the following: Serial, FastEthernet, GigabitEthernet, BRI,
loopback, Multilink, VPN, Dialer, or ATM
2.Router parameters can be: RIP, OSPF or BGP
3.Controller can be one of the following: T1, E1, T3 or E3
XSR User’s Guide 2-13
Utilizing the Command Line Interface
4.Some attributes can be set at this level without acquiring other modes. For example: access-
list access-list-num [deny | permit] [parameter [parameter…]]
5.Show commands can all be entered at EXEC, Privileged EXEC or higher modes.
User EXEC Mode
You enter User EXEC (or simply EXEC) mode after logging in. The following commands can be
entered in EXEC mode:
terminal
and traceroute.
Privileged EXEC Mode
In order to make configuration changes, you must enter PRIV EXEC mode. Some configuration
parameters specified in this mode apply to XSR global settings such as the system clock.
Supported privileged EXEC mode commands are:
In Global configuration mode you can configure many different resources such as ports,
interfaces, and routing tables. The following levels are provided at the Global configuration level:
•Interface Level: At this level you can modify/assign specific port parameters on a port-by-port
basis. You can enter this level by typing
Global configuration command prompt. For example, you can enter:
XSR(config)#interface gigabitethernet 3
The XSR will return the following prompt:
XSR(config-if<G3>)#
•Router level: At this level you can configure parameters associated with the RIP or OSPF
protocols. You reach this level by typing router [RIP, OSPF] in Global mode. For example:
XSR(config)#router rip
The XSR will return the following prompt:
XSR(config-router)#
•Several other levels are available in Global mode including AAA, Class-Map, Crypto, Dialer, IP,
and Map-Class. Many of these modes have additional levels nested within them.
Exiting From the Current Mode
Each of these commands exits from your mode but with different results:
•Exit: In each mode
•End:
end always returns to Privileged EXEC from either Global or sub-configuration mode
exit quits from the current to previous mode
interface interface-type <interface #> at the
•Ctrl-Z: Same as the
•Be aware that you need not always exit from a mode if your current and destination modes
2-14 Managing the XSR
end command
subscribe to the same parent in the mode tree.
Mode Examples
Consider the following examples to change configuration mode:
XSR>enable + Acquires Privileged EXEC mode
XSR#config terminal + Acquires Global configuration mode
+ Sets up the IP address and subnet mask for this FastEthernet port
XSR(config-if<F1>)#exit +Quits Interface mode
XSR(config)#exit +Quits Global mode
XSR#disable + Quits Privileged EXEC mode
XSR> + Returned to EXEC mode by previous command
Note: In many cases, you are not required to exit from a mode to configure a command in another
mode.
Observing Command Syntax and Conventions
Utilizing the Command Line Interface
The CLI command syntax and conventions on the XSR use the notation described below.
Table 2-4 Command Syntax and Conventions
ConventionDescription
xyzKey word or mandatory parameters (bold)
[x][ ] Square brackets indicate an optional parameter (italic)
[x | y | z][ | ] Square brackets with vertical bar indicate a choice of values
{x | y | z}{ | } Braces with vertical bar indicate a choice of a required value
[x {y | z} ][{ | } ] Combination of square brackets with braces and vertical bars indicates a
required choice of an optional parameter
(config-if<xx>)xx signifies the interface type; e.g., F1, G3, S2/1.0, D1, L0, BRI, PRI (T1/E1,
T3/E3, ATM), VPN, etc.
In the following example:
show interface [dialer | fastEthernet/gigabitethernet | loopback | serial | bri |
multilink | vpn {interface-number}]
•show and interface are keywords
•[
dialer, fastEthernet, gigabitethernet, loopback, serial, bri, multilink, vpn and
{
interface-number}] are optional parameters
Syntactically, each line begins with one or more command keywords followed by a list of
mandatory values (if any) and, lastly, a list or optional values. For example, the command below:
channel-group number timeslots range[speed {56 | 64}]
has a mandatory parameter value number, a mandatory parameter keyword and value pair
timeslots range, an optional value offered as a keyword speed and value options of 56 or 64.
XSR User’s Guide 2-15
Utilizing the Command Line Interface
CLI Command Limits
CLI commands on the XSR are bounded by the following:
• Total number of characters in a command line/help message: 299
• Total number of words in a command line: 127
• Number of command history entries recalled: 31
• Total number of characters in a prompt: 1023
• Total number of characters in system name: 31
Describing Ports and Interfaces
Technically, a port is a physical connector with some physical layer values. XSR ports are:
FastEthernet (XSR 1800 Series) or GigabitEthernet (XSR 3000 Series), Async/Sync Serial, ATM,
BRI, Loopback, T1/E1T3/E3, Console, and Null. An interface is a data and management plane
comprising the physical, link and a part of the network layer. The terms are used interchangeably
in this manual. The XSR supports multiple access types, including Fast/GigabitEthernet LAN,
Frame Relay and Serial WAN access over Asynchronous, Synchronous, T1/E1, and Serial lines
with async and sync access over permanent or dial lines. Generally, Frame Relay, PPP and
Multilink PPP (Console optional) are for WAN access and PPPoE for WAN access over a LAN.
Dial access is provided by ISDN BRI and PRI.
Supported Physical Interfaces
The XSR supports the following physical interfaces:
•FastEthernet/GigabitEthernet for LAN port consisting of Ethernet's physical, Mac (Layer-2), and
IP layer functionality.
•Serial for Sync or Async port/line consisting of a Sync port/line's physical, Layer-2 (PPP) and IP
layer functionality.
•Serial for T1/E1 (PRI) channel group consisting of its physical, Layer-2 (PPP or Frame Relay),
and IP layer functionality.
Supported Virtual Interfaces
The XSR supports the following virtual interfaces:
•Interface dialer includes physical interfaces supporting dial connectivity from the dial port/
line's physical layer functionality including dialing, Layer-2 (PPP), and IP layer functionality.
•Sub-Interface for an NBMA network. An NBMA network has multiple access over the same
line but no broadcast capability. Examples of such networks are Frame Relay, X.25, and ATM.
One physical interface comprises one or more sub-interfaces which in turn consist of one or
more circuits on the physical interface. Sub-interface examples and its circuits are: one or more
DLCIs forming a sub-interface, one or more X.25 PVC/SVCs forming a sub-interface and one
or more VCs of ATM forming a sub-interface. This interface shares its physical layer
functionality with other sub-interfaces, but each sub-interface has its own layer-2 (PPP or
Frame Relay) and IP layer functionality.
2-16 Managing the XSR
Supported Ports
The XSR supports the following port types:
• Single-channel ports: Fast- and GigabitEthernet, Sync/Async serial, ATM
• Multiple-channel type ports: BRI, T1/E1
Numbering XSR Slots, Cards, and Ports
The syntax for XSR slot, card, and port numbering on the CLI, illustrated in Figure 2-2, is:
–Sub-interface: Each sub-interface correlates with a physical interface, ranging as follows:
ATM, BRI, and Serial - 1 to 30, Fast/GigabitEthernet - 1 to 64. The sub-interface number is
Port number.sub-interface number for single channel serial, port
number.channelgroupnumber.subinterface number for multi-channel.
Configuration Examples
The following examples display minimal interface configuration:
•FastEthernet Example
interface fastethernet 1 + Begins configuring interface/port 1
no shutdown + Enables the interface
•T1 Example
controller t1 1/0 + Begins configuring controller on NIM card 1, port 0
channel-group 3 timeslots 1, 3-6, 12 + Maps timeslots 1, 3, 4, 5, 6, and 12 to channel group 3
no shutdown + Enables the interface
!
interface serial 1/0:3 + Configures channel group 3 defined above
encapsulation ppp + Sets interface encapsulation type to PPP
no shutdown + Enables the interface
•T1-PRI (ISDN) Example
controller t1 1/0/0 + Begins configuring PRI NIM card 1, port 0
pri-group + Enables ISDN, sets all timeslots to map to channel groups on NIM
controller t1 1/0/0:23 + Maps T1 NIM to D-channel sub-interface
isdn switch-type primary-ni + Selects switch type
isdn pool-member 1 priority 100 + Adds a prioritized pool member to sub-interface
•Dialer Example
interface dialer 4 + Begins configuring dialer interface 4
ip address 11.1.2.2 255.0.0.0 + Sets IP address/subnet on dialer port
dialer pool 5 + Sets dialer 4 to use pool 5. Its members are physical ports
interface serial 2/0 + Configures serial interface on NIM card 2, port 0
encapsulation ppp + Sets interface encapsulation type to PPP
dialer pool member 5 + Serial 2/0 is now a member of dialer pool 5 and will eventually be used by dialer 4
no shutdown + Enables the interface
!
interface serial 2/1
encapsulation ppp + Sets interface encapsulation type to PPP
dialer pool member 5 + Serial 2/1 is now a member of dialer pool 5 and will eventually be used by dialer 4
no shutdown + Enables the interface
+ Configures serial interface on NIM card 2, port 1
2-18 Managing the XSR
Utilizing the Command Line Interface
•BRI-Dialer (IDSN) Example
interface dialer 0 + Configures dialer interface 0
ip address 2.2.2.2 255.255.255.0 + Sets IP address/subnet on port
encapsulation + Interface/Sub-interface Behavior
XSR interfaces and sub-interfaces, channels and channel-groups are added and deleted differently
depending on the particular interface. Interface characteristics are as follows:
•T1/E1 Controller - Creating a channel group adds a serial interface. For example, when you
issue the command
controller t1 1/0, the XSR automatically creates channel group 0 with
all available timeslots assigned to it. You can verify this by checking the running configuration
where the following entry is displayed:
interface serial 1/0:0
–You can create other serial objects by creating more channel groups. For example, by
entering the following commands:
channel-group 0 timeslots 1-10 speed 64
channel-group 1 timeslots 11-20 speed 64
–the following interfaces are added:
interface serial 1/0:0
interface serial 1/0:1
–You can delete those controller interfaces only by removing the channel groups which
automatically created them by entering:
no channel-group 0 + This automatically deletes Serial port 1/0:0
no channel-group 1 + This automatically deletes Serial port 1/0:1
–To delete controller ports and all associated interfaces, you must remove the entire
controller:
no controller t1 1/0
•PRI NIM - When configuring a PRI interface, a pri group is created as follows:
controller t1 1/0
pri-group
–Creating a PRI group adds a serial interface internally, but it is not visible nor accessible to
the user:
interface serial 1/0:0 is not displayed anywhere. But, the system
resources associated with it remain in use until the pri group is deleted as follows:
no pri-group
•BRI NIM - When configuring a BRI interface, sub-interface addition/removal differs if you are
configuring a leased line or switched connection.
–Leased line: When configuring a leased line connection, serial sub-interfaces are created
and are visible to the user:
interface bri 2/1
leased-line 64 + This adds serial port 2/1:1
leased-line 64 + This adds serial port 2/1:2
–These serial interfaces are removed by deleting the entire controller. For example:
interface bri 2/2
no controller t1 2
XSR User’s Guide 2-19
Utilizing the Command Line Interface
–Switched: When configuring a switched BRI connection, three serial sub-interfaces are
automatically created when you enter:
interface bri 2/1
isdn switch-type basic-ni1
–The following sub-interfaces are added:
interface serial 2/1:0
interface serial 2/1:1
interface serial 2/1:2
–These serial sub-interfaces are removed with the no isdn switch-type command:
interface bri 2/1
no isdn switch-type + This deletes serial ports 2/1:0, 2/1:1 and 2/1:2
Entering Commands that Control Tables
A number of CLI commands configure entries in tables such as arp and access-list in the XSR.
Two types of tables are configurable:
• Single-instance table: The ARP table, for example, in which one table holds many rows and
each row is a complete entry. Entries are not displayed in the same order they are entered.
• Multiple-instance table: The Access-List table, for example, in which there are multiple
tables identified by number with each table containing many rows and each row is a
complete entry. Entries are not displayed in the same order they are entered.
With few exceptions, you must be in Global mode before issuing table commands.
Adding Table Entries
Depending on the type of table configured, the parameter list can be optional or required. For
example the ARP table has three required parameters and some optional values depending on the
context. For example, using the following command:
arp ip-address mac-address
you may type:
XSR(config)#arp 1.1.1.1 e45e.ffe5.ffee
+ where arp is the command and type of table to be filled or modified, 1.1.1.1 is the IP address corresponding to the MAC
address e45e.ffe5.ffee
Note: ARP is a table type, as well as a command, that fills or modifies entries in the ARP table.
A second example is entered as follows:
XSR(config)#access-list 1 deny any
+where access-list is the command and the type of table to be filled or modified, 1 is the ID of the table to be modified,
deny is the type of operation authorized and any is the host that should be denied.
.
2-20 Managing the XSR
Utilizing the Command Line Interface
Deleting Table Entries
There are two ways to delete an entry from a table depending on the table type. Type (e.g.):
XSR(config)#no arp 1.1.1.1 e45e.ffe5.ffee
+ removes the arp entry related to row 1.1.1.1. where no is the command that negates the previous operation and arp is
the associated table type. A second example is entered as follows:
XSR(config)#no access-list 1
+ removes access-list 1 where no is the command that clears the access-list.
Modifying Table Entries
For some tables, you must first remove the entry then add the same entry with new values. For the
ARP table the syntax is similar to the
with a new value which replaces the old value in the ARP table.
For example, typing the following:
XSR(config)#arp 1.1.1.1 e45e.ffe5.efef
XSR(config)#arp 1.1.1.1 e45e.ffe5.3434
+ first creates an arp entry of 1.1.1.1 associated with MAC address e45e.ffe5.efef. Then, this entry is modified to be
associated with the new MAC address e45e.ffe5.3434.
add command where you enter the command and entry ID
Displaying Table Entries
You can display ARP table, access-list table, gateway-type prefix table, IP routing table, and other
entries at privileged EXEC mode.
You must be in Interface mode before configuring XSR ports. To enter Interface mode, type the
following, for example:
XSR#configure terminal
XSR(config)#interface FastEthernet 1
XSR(config-if<F1>)#
XSR User’s Guide 2-21
Utilizing the Command Line Interface
Ports can be enabled or disabled, configured for default settings, associated tables, clock rate,
priority group, and encapsulation, for example. Refer to the XSR CLI Reference Guide for more
details on Interface mode commands.
Note: All interfaces are disabled by default.
Enabling an Interface
The following command enables an interface.
XSR(config-if<S2/0>)#no shutdown + Enables serial interface 2
Disabling an Interface
An interface can be administratively disabled with the shutdown command:
You can configure an interface only after invoking Interface configuration mode. Each interface
can be configured with a set of interface-specific commands. If you are unsure which commands
are available, type
commands to configure a GigabitEthernet interface:
? to list them for the particular port. Consider the following sequence of
XSR#config terminal
XSR(config)#interface gigabitethernet 2
XSR(config-if<G2>)#?
description
duplex +Manually set the duplex mode
exit + Quit interface configuration mode
help + Description of the interactive help system
ip +Interface Internet Protocol config commands
loopback +Configure interface for internal loopback
no +Negate a command or set its defaults
shutdown +Shutdown the selected interface
speed +Manually set the line speed
XSR(config-if<F1>)exit + Quit Interface mode
+ Text describing this interface
Displaying Interface Attributes
You can display the current settings of an interface when in Privileged EXEC or Global
configuration mode. For example, type:
XSR#show interface fastethernet 1
or:
XSR(config)#show interface serial 1/0
2-22 Managing the XSR
Managing Message Logs
Messages produced by the XSR, whether alarms or events, as well as link state changes for critical
ports and a management authentication log, can be routed to various destinations with the
logging command. And by issuing the no logging command, you can block messages to a site
while permitting transmission to others.
For normal operation, you should log only HIGH severity alarms which indicate critical events
and those requiring operator intervention. Be aware that the XSR may drop LOW and DEBUG
level alarms if the system is too busy to deliver them. The number of dropped messages is
displayed by the
Be aware that the DEBUG alarm level is used by maintenance personnel only.
The XSR serves the following logging destinations:
• Syslog (to remote Syslog server over the network)
• Console terminal
• Monitor (up to five CLI sessions via Telnet)
• Buffer (in XSR’s memory)
• File on CompactFlash card when persistent logging (with respect to power loss) is enabled.
This feature is used especially for the firewall (see “Configuring Security on the XSR” on
page 16-1 for more information)
show logging command.
Utilizing the Command Line Interface
• SNMP Trap (async notification by XSR to the SNMP Manager)
Logging Commands
You can log all messages into a particular destination based on the severity level of the message
(high, medium, low and debug) with the
sets that level for all destinations. Also, you can log ACL violations in particular on a per-source
per-ACL group basis with the
access-list log command and view them every five minutes.
Alternatively, you can display the log when it reaches a specified packet threshold with
list log-update-threshold
logging
clear logging commands, respectively. Be aware that the entire message history is lost when the
and show or clear messages in the memory buffer with show logging history and
. Generally, you can display your logging configuration with show
XSR is powered down.
Refer to Appendix A: “Alarms/Events, System Limits, and Standard ASCII Table” on page A-1 for a
thorough listing of XSR alarms/events and the XSR CLI Reference Guide for command details.
Performing Fault Management
When a software problem causes the XSR’s processor to fail, the system captures pertinent data,
produces a Fault Report, and restarts the router automatically. The Fault Report is useful in
diagnosing the problem because it contains the following data relevant to the failure:
•Cause of processor exception
logging command. Note that entering logging medium
access-
•Time-stamp
•Contents of processor registers
•Operating system status
•Status of tasks, current task (the crashed task)
XSR User’s Guide 2-23
Utilizing the Command Line Interface
•Contents of stacks (task stacks, interrupt stack)
•Status of one special task (packet processor by default)
•Code around the crash program counter
•Task message queues
•Memory management statistics
•Task stack traces for all tasks
The router can store one Fault Report, retaining the first Fault Report in case of multiple failures. It
is stored in a special RAM memory area which is preserved if the XSR is rebooted but lost if the
router is powered down.
A fault report is also captured in case of a catastrophic watchdog interrupt. Typically, the
watchdog timer is reset once per second. If the software fails and 2.6 seconds expire, the watchdog
hardware will induce an interrupt which initiates the capture of the fault report. After an
additional 2.6 seconds, the CPU is reset and the XSR will warm-boot.
Fault reports can be retrieved from the CLI interface and forwarded to Enterasys Support for
analysis.
When the XSR automatically reboots after a crash, the following sample message is logged:
<186>May 29 22:20:59 1.1.1.1 PLATF System warm boot from crash
Fault Report Commands
The show fault-report command displays the report. Refer to the XSR CLI Reference Guide for
more command details. The
clear fault-report command can be used to remove old fault
reports and reset the XSR to capture a new one.
Capturing Fault Report Data
Enterasys Networks recommends that you enter the following commands from privileged EXEC
mode during capture to assist in analysis and simplify the capture process. The
report
command should only be executed once you are sure that the text has been completely
captured since the data is not recoverable afterwards.
•enable
•terminal Length 0
•show fault-report
•show version
•show logging history
•clear fault-report
•terminal length 24
•disable
clear fault-
2-24 Managing the XSR
Using the Real-Time Clock
The XSR’s Real-Time Clock (RTC) is employed by other system software modules to time-stamp
events, alarms and is useful when no network clock source is accessible. It is normally
synchronized with a master clock source over the network using the Simple Network Time
Protocol (SNTP) but canalso synchronize with the battery-supported RTC chip.
For SNTP configuration, see Chapter 3: Software Configuration in the XSR Getting Started Guide.
RTC/Network Clock Options
SNTP synchronizes the RTC with a network master clock but if there is no network clock source
the RTC clock is used on its own. The RTC maintains the correct time with its battery even when
the XSR is powered down.
RTC Commands
The real-time clock can be set with the clock set command. The universal time can be viewed
with
show clock command. To set the SNTP server, use the sntp-client server command.
Refer to the XSR CLI Reference Guide for more command details.
Managing the System Configuration
Utilizing the Command Line Interface
The XSR’s system configuration consists of three discrete types which are described below. The
configuration can also be reset to the defaults, saved, and uploaded or downloaded in bulk.
•Factory Default Configuration: These system parameters are set at the factory. If you make
configuration changes and do not save them or the startup configuration file cannot be found,
the XSR reverts to factory default parameters. You can manually reset to factory defaults on
XSR 1800 Series routers by pressing the reset button at the back of the units. XSR 3000 and
4100 Series routers are not equipped with a reset button but you can restore factory defaults
via the CLI as described in the next section.
•Startup Configuration: These system settings are used as the current running configuration
when you power up or issue the
volatile (Flash) memory as the
followed by a series of CLI commands. When the XSR restarts, each CLI command in this file
is read and executed.
•Private Configuration: The
the XSR restarts, each CLI command in this file is read and executed. The file is updated or
created when the running configuration is saved to the startup configuration.
•Running Configuration: These system settings, known as
number followed by accumulated commands from
Changes made to the configuration are lost if you power cycle or reboot unless you save it to
startup-config using the copy or write command.
The XSR validates commands as they are entered and rejects with an error message those
commands which are invalid.
private-config file contains SNMP v3 related commands. When
reload command. The startup configuration is stored in non-
startup-config file. The file contains a version number
running-config, include a version
startup-config and user revisions.
XSR User’s Guide 2-25
Utilizing the Command Line Interface
Resetting the Configuration to Factory Default
In situations where the XSR has invalid software or a problem booting up, you can reset the router
and return it to its factory default settings by accessing Bootrom Monitor Mode. Take these steps:
1.Power up with a serial Com connection.
2.During the first five seconds of system initialization, press
CTRL-C to enter Bootrom mode.
3.When prompted for a password, enter any characters if you have not previously configured a
password. If you have configured a password, enter an incorrect password. In either case, the
XSR will produce an error message and prompt you to try again.
4.After trying 5 times to enter the “wrong” password, you are prompted to restore factory
defaults.
Refer to the XSR CLI Reference Guide and XSR Getting Started Guide for more details about Bootrom
Monitoring Mode.
Using the Default Button (XSR 1800/1200 Series Only)
You can also boot up from the factory default configuration by pressing the default button on the
rear panel of the XSR 1800 and 1200 Series routers. Doing so will erase the content in the startup
configuration in Flash memory. After pressing the default button, the XSR performs the following
operations:
•Processor is interrupted
•Software enforces default configuration as running configuration
•Software restarts the XSR
•XSR restarts with default configuration
•Original startup configuration in Flash is erased
•Bootrom password is set to default
•Fault report (if any) is cleared
•Security-sensitive files are erased from Flash
•Bootrom Monitor mode network parameters are set to defaults
•Master encryption key is erased from non-volatile memory
•Console connection restarts
2-26 Managing the XSR
Caution: Pressing the Default button erases all files in Flash memory.
Figure 2-3 XSR-1805 (right) and XSR-1220/35 Default Button
+12 VDC
ON / OFF
D
E
F
A
U
L
T
DEFAULT
SWITCHCORD
POWER
Default button
ELAN 1ELAN 2COM
Configuration Save Options
There are several options available regarding configuration:
•If you want to make your running configuration the new startup configuration, you can save
it to Flash memory with the
•If you want to convert your startup configuration into the running configuration, you can
issue the
•If you want to save the startup configuration to a remote site using a TFTP server, issue the
copy startup-config tftp: command. See the associated command below.
•If you want to load the configuration manually from a remote site using a TFTP server, issue
the
page 2-27 for more information about this and the previous command.
•If you want to copy your entire startup configuration including encoded files to a remote site,
issue the
and the
Refer to “Full-config Backup” on page 2-28 for more details about the command.
reload command which reboots the XSR and reloads the startup configuration.
copy tftp: startup-config command. Refer to “Bulk Configuration Management” on
copy flash: full-config tftp:<any_name> command when backing up the XSR,
copy tftp:<any_name> flash:full-config command when restoring the XSR.
Utilizing the Command Line Interface
copy running-config startup-config command.
To view the running-config, use the
config
, issue the more startup-config command.
show running-config command. To view the startup-
For more command details, refer to the XSR CLI Reference Guide.
Using File System Commands
A set of MS-DOS compatible commands are available for use in conjunction with configuration
files. The XSR has a file system residing in the XSR’s non-volatile memory.
You can copy files with the
with the
more command, verify a packed software image file with the verify command, and
copy command, remove files with the delete command, display files
change and list directory contents with the
command details, refer to the XSR CLI Reference Guide.
Bulk Configuration Management
The XSR can be configured in one action by storing CLI commands as a script in an ASCII file then
transferring the file to the router remotely using TFTP or locally from
limitation in the size of the stored file, though. If the file is larger than the limit, then the download
operation will abort producing an error message.
Downloading the Configuration
cd and dir commands, respectively. For more
cflash:. There is a
Downloading transfers a script file remotely from a server to the XSR’s startup configuration
using TFTP or locally from
cflash:. The ASCII-format script can include comments delineated by
an exclamation mark.
To perform the task correctly, the TFTP server must be running on a remote device with the
configuration file residing in the TFTP root directory of the server. You can then enter the
startup-config tftp:
the XSR. Alternately, the file must first be loaded in
cflash:startup-config flash:startup-config
command in EXEC mode to copy the configuration file from the server to
cflash: then copied to flash: with thecopy
command.
XSR User’s Guide 2-27
copy
Utilizing the Command Line Interface
Note: If you have inadvertently added errors to the CLI script file, the restoration of startupconfig will be stopped at the error line. So, any commands after that line in startup-config are
not executed.
For more command details, refer to the XSR CLI Reference Guide.
Uploading the Configuration/Crash Report
An upload copies the XSR startup-configuration file (partial) to a system in a CLI script format
using TFTP. You can later retrieve the file with TFTP.
To perform the task correctly, the TFTP server must be running on a remote device. You then enter
the
copy startup-config tftp: <tftp IP addr>/filename command in EXEC mode to copy
the file to the server. A successful upload produces the following sample output:
XSR#copy startup-config tftp:
Address of remote host [0.0.0.0]: 10.10.10.10
Destination file name [startup-config]:
Copy 'startup-config' from Flash to server
as 'startup-config'(y/n) ? y
Upload to server done
File size: 976 bytes
You can also upload the crash report via TFTP using the same procedure as the one used to
upload the configuration file.
Refer to the XSR CLI Reference Guide for more command details.
Full-config Backup
Alternately, you can backup and restore the full configuration file suite including encoded VPN
users, usernames, passwords, certificates, and SNMPv3 data files (
private-config) to a remote site with a full configuration backup. This method employs a modified
user.dat, cert.dat, and
backup/restore algorithm to copy the data encoded by the master encryption key to the
temporary
full-config file then restores the data in startup-config and other data files. Be
aware that the same master encryption key is required for both backup (on the source XSR) and
restore (on the destination XSR) operations. Information in the
ASCII text (
The
full-config backup/restore option is also available using SNMP. Refer to “Full
startup-config data) or encrypted binary text (data files).
full-config file is stored either as
Configuration Backup/Restore” on page 2-43 for details.
Creating Alternate Configuration Files
The XSR permits you to create multiple configurations, a useful option if you want to quickly
select one of two configuration files stored in
and
startup-configB. The file named startup-config is used by the autoboot process. You can
use any file name for the alternate configuration.
flash: or cflash:, for example: startup-config
To make an alternate configuration file available, rename
(for example), and startup-configB to startup-config., using the rename command. Then
issue the
2-28 Managing the XSR
startup-config to startup-configA
reload command to use the new configuration.
Managing the Software Image
The XSR can store more than one software image in Flash.
Creating Alternate Software Image Files
The XSR can create multiple software images, a useful option if you want to quickly select an
alternate image. For example, you can create two software image files:
xsr1805_b.fls.
Utilizing the Command Line Interface
XSR1805_a.fls and
Begin the process by issuing the
the name of your software file. Enter:
boot system command to create a boot-config file containing
boot system XSR1805_b.fls
The boot-config file contains the file name - XSR1805_a.fls - used by the autoboot process. By
changing the file name inside
XSR1805_b.fls:
Note: If the boot from Flash fails for any reason, the XSR will attempt to copy the specified software
file from the network based on the setting in Bootrom mode. Refer to the following section for details.
boot-config, you will boot from the alternate software file in Flash,
BootRom Upgrade Choices
Upgrading from Version 2.xx to 3.xx code on the XSR 1800 Series
Because the XSR does not recognize the 3.x format, you cannot use the Bootrom Monitor Mode
commands
using the following procedure:
1.With Bootrom version 2.x still installed, first upgrade the firmware image to Release 6.0 in the
usual manner by copying the
2.Copy Bootrom version 3.x to the
3.Enter the following command from the CLI:
the current sub-release number. The XSR will automatically reboot and be operable.
bu and bU to upgrade the Bootrom from version 2.x. You must upgrade from the CLI
xsr1800.fls file to the Flash: directory and rebooting.
Flash: directory.
bootrom update btXSR1800_3_x.fls where x is
Upgrading from Version 1.xx to 2.xx code on the XSR 1800 Series
There are two methods available to upgrade your Bootrom. If you use the Bootrom Update Utility,
you will need the
updateBootrom.fls and bootromX_xx.fls files. For details on using these files
to perform a Bootrom upgrade, refer to “Using the Bootrom Update Utility” on page 2-30.
If not using the Bootrom Update Utility, you must perform a two-step procedure to upgrade from
1.xx to 2.xx Bootrom versions due to a file format change and will need the
and
bootromX_xx1.fls files. For details, see “Local Bootrom Upgrade” on page 2-32.
bootrom_uncmp.fls
Pre-upgrade Procedures
XSR firmware upgrades are infrequent but if you do so using Bootrom mode, you must:
•Make a DB-9 null modem serial link to a terminal (HyperTerminal, Procomm, et al.) with 9600
bps, 8 bits, 1 stop bit, and no flow control.
•Make an Ethernet connection at the first network interface (located next to the power switch).
•Connect to the FTP (default) or TFTP server on a host PC running with a known user and
password. Be sure you can access the latest Bootrom binary file on the host computer, e.g.,
bootrom1_21.fls.
XSR User’s Guide 2-29
Utilizing the Command Line Interface
•Optionally, if you have CompactFlash installed, you can download the firmware file to
cflash: then perform Step 1 (see below) followed by the bu (lower-case u) command.
•If you use the Cabletron TFTP/BOOTP Services application, which does not recognize long
file names, first shorten the Bootrom file name to 8 characters or less with an extension, before
beginning the download (i.e.:
•Be aware that factory default Flash is limited to 8 Mbytes and if congested may not be able to
store a downloaded Bootrom. Delete old firmware or other files before downloading.
Using the Bootrom Update Utility
The Bootrom update utility upgrades the boot flash sectors of the on-board Flash memory. This
update tool functions similar to the
allowing Bootrom updates to be performed remotely. The utility runs as a standalone program
and can recognize both old (1.x) and new (2.01) versions of the Bootrom file format. After you
complete the Bootrom update, the XSR will reboot.
Note that screen-captured XSR text is displayed in Courier font. User-required input appears in
larger, bold Courier font.
1.From a remote Telnet session, at a CLI prompt, configure the “boot-config” file to your current
software file residing in flash: (the default is
than 1.16, the default is
XSR(config)#boot system xsr1800.fls
xsr1800.fls saved into flash:boot-config
bootnew.fls). Rename the file after the download.
bU command but also can be executed from a Telnet session,
xsr1800.fls; if your Bootrom version is earlier
xsr1805.fls). Enter:
2.Exit to EXEC mode and verify this setting by entering: more boot-config. Verify at least two
MBytes of flash file space is open by entering the
unnecessary files. The following files are required (
dir command. If file space is low, delete
xsr1800.fls may be replaced by the
current software file):
XSR-1805#dir
Listing Directory flash:/
size date time name
-------- ------ ------ --------
208OCT-31-200209:34:16 startup-config
3244017 OCT-31-200209:32:46 xsr1800.fls
12OCT-31-200209:31:32 boot-config
3,475,456 bytes free
6,727,680 bytes total
3.Using TFTP, transfer the latest Bootrom version from the network. The target name must be
6.Reconfigure boot-config to boot updateBootrom.fls:
XSR-1805(config)#boot system updateBootrom.fls
updateBootrom.fls saved into flash:boot-config
7.Display the current list of files and the contents of boot-config and restore-boot-config to
verify the transfers went smoothly:
XSR-1805#dir
Listing Directory flash:/
size date time name
208OCT-31-2002 09:34:16 startup-config
3244017OCT-31-2002 09:32:46 xsr1800.fls
820136OCT-31-2002 09:40:42 bootrom.fls
667172OCT-31-2002 09:42:06 updateBootrom.fls
18OCT-31-2002 09:44:10 boot-config
12OCT-31-2002 09:43:44 restore-boot-config
1,984,512 bytes free
6,727,680 bytes total
XSR-1805#
updateBootrom.fls
XSR-1805#
xsr1800.fls
more boot-config
more restore-boot-config
8.This is a critical step and all previous steps must be completed accurately before proceeding.
Reload and wait a couple of minutes. You will lose your Telnet session as the system reboots.
The XSR will run
updateBootrom.fls and update the Bootrom into the boot flash sectors.
Power must not be interrupted since a power failure or interruption may render the XSR
unusable. The file,
updateBootrom.fls and bootrom.fls will be removed before the router is rebooted again.
XSR-1805#reload
Proceed with reload (y/n) ?
restore-boot-config, will be renamed to boot-config and
y
9.Verify that the system is up by remotely logging in via Telnet. Enter show version and
check the new Bootrom version.
XSR User’s Guide 2-31
Utilizing the Command Line Interface
Local Bootrom Upgrade
Due to the change in the format of the Bootrom file between version 1.x and version 2.01, a
transitional step is required when updating across these versions only. This transitional step can
be avoided by using the Bootrom Update utility described above.
When you are running a 1.x version of the Bootrom and you try to upgrade to version 2.01 of the
Bootrom file, it will be rejected due to the change in format.
non-redundant Bootrom file that the existing 1_x version bU command can recognize. By
updating and rebooting with this transitional version, you can subsequently use the new
command (which recognizes the new 2.01 format) to update the Bootrom to version 2.01. Be aware
that if you boot with
“Danger! Cannot find a good copy of Bootrom”
After upgrading to version 2.01 with bootrom2_01.fls, you can reboot and all subsequent
Bootrom updates (which do not involve a change in the bootFirst module) are power-safe.
bootrom_uncmp.fls is a transitional,
bU
bootrom_uncmp.fls, you will see the following output on the screen:
In summary, when upgrading 1.x to 2.x Bootrom versions only, you must run the
twice - first with the
upgrades you must reboot using
bootrom_uncmp.fls file, then with the upgraded Bootrom. Between
bw.
bU command
To upgrade your firmware using the Local Bootrom Upgrade, perform the following steps:
1.Power on the XSR by flipping the rear switch and observe the front LEDs. When the system,
VPN, console, NIM1 and NIM2 LEDs turn off, immediately enter <Ctrl-C> on the terminal. If
you miss this time window, power off and try again. The Bootrom monitor menu should
appear as follows:
X-Pedition Security Router Bootrom
Copyright 2003 Enterasys Networks Inc.
HW Version: 9002854-02 REV0A Serial Number: 2854019876543210
CPU: IBM PowerPC 405GP Rev. D
VxWorks version: 5.4
Bootrom version: 1.20
Creation date: Aug 26 2002, 11:16:44
Cold Start: SystemReset from powerup
Password:
Entering ROM monitor Type “h” for help
Using default Bootrom password The system is not secure!!!
Use “bp” to change password
2.Type h or ?to display the command groups.
3.Type f to list the file command group.
4.Type n to list the network command group.
5.Using the np command, assign the following:
2-32 Managing the XSR
XSR1800:
–Local IP address (of the XSR).
–Remote (host computer) IP address (The host must be on the same subnet as the XSR).
Utilizing the Command Line Interface
–DOS-style full path (without the file name) of the site of the Bootrom file on the host PC.
–The username and password to use when connecting to your FTP server on the host PC.
6.Verify the network boot values using the
XSR: sn
Local IP address : 192.168.1.1
Remote IP address : 192.168.1.2
Remote file path : c:/XSR
Transfer Protocol : FTP
Ftp userid : administrator
Ftp password : anonymous
Local target name : XSR
Autoboot : enabled
Quick boot : no
Current 405 ethernet MAC address is: 00:01:f4:00:01:02
Current PCI ethernet MAC address is: 00:01:f4:01:01:03
sn command. For example:
7.Type b to list the boot command group.
8.Enter the bU command to transfer the Bootrom image file over FTP and upgrade the Bootrom
flash sectors to the latest version. Be sure to enter the command with an uppercase U and
follow the prompts.
Caution: If the Bootrom file transfer is corrupted due to a network interruption, this step may
render the router unusable. If you suspect this has happened, type n at the confirmation prompt to
abort erasing and replacing the Bootrom. Then, delete the file (type: rm bootrom1_21.fls, for
example) and re-issue the bU command to transfer the image again. Here is a sample session:
XSR1800: bU bootrom_uncmp.fls
ftp RETR 192.168.1.2:c:/XSR1850/ bootrom_uncmp.fls into
flash bootrom_uncmp.fls
........ Saved 818448 bytes to flash: bootrom_uncmp.fls
Checking bootrom_uncmp.fls...
Updating bootrom with file, “bootrom_uncmp.fls”.
Proceed with erasing current Bootrom in flash and replace with
bootrom_uncmp.fls? (y/n)
Programming 131072(0x20000) bytes at address 0xfff20000
Programming 131072(0x20000) bytes at address 0xfff40000
Programming 48299(0xbcab) bytes at address 0xfff60000
Verifying Bootrom flash sectors
Locking 3 Bootrom flash sectors
Second copy of Bootrom ...
Erasing 3 sectors at address=0xfff80000
Programming 131072(0x20000) bytes at address 0xfff80000
y
XSR User’s Guide 2-33
Utilizing the Command Line Interface
Programming 131072(0x20000) bytes at address 0xfffa0000
Programming 48299(0xbcab) bytes at address 0xfffc0000
Verifying Bootrom flash sectors
Locking 3 Bootrom flash sectors
Locking 8 Bootrom flash sectors
***** Bootrom update completed. *****
Do you want to remove the bootrom file bootrom_uncmp.fls? (y/n)
Using default Bootrom password. The system is not secure!!!
Use “bp” to change password
y
9.Reboot the XSR by entering bw.
10. Repeat Step 8 with: bU bootrom2_01.fls
11. Reboot the XSR again: bw
12. Your Bootrom in Flash memory is now updated and will be used during the next power up
sequence.
Note: For more information, consult the SSR boot Release Notes at:
http://www.enterasys.com/download/
Loading Software Images
If the XSR has a valid Bootrom but no valid firmware, the software can be loaded from Bootrom
Monitor mode using FTP. You also have the option of copying the image remotely from a TFTP
server, using the
cflash:
command. Be aware that should the transfer fail, the XSR may temporarily be without
valid software in
downloaded. Also, the CLI session which initiated the
download, with a character repeatedly shown on screen to indicate a file transfer in progress.
copy tftp: flash: command, or locally from cflash:, using the copy
flash: and should not be reloaded or powered down until a new image is
copy command is blocked during a TFTP
Using EOS Fallback to Upgrade the Image
The easy to use Enterasys Operating System (EOS) fallback feature safely upgrades your image, as
configured from either the CLI using the
not successfully install, the XSR will automatically fall back to the previous running image. The
functionality works as follows: you download a new, primary image which the XSR will reboot
from. After this image loads, the EOS fallback test will run for a period you configure. The test
checks if the XSR crashes, and optionally checks if the configuration causes a syntax error or
whether the XSR receives any SNMP messages with the primary image. If successful, the
following syslog message is sent:
<186>Jun 8 08:49:39 Toronto PLATF: EOS Fallback Test Completed, file
my_new_XSR1800.fls is OK
If the test fails, the XSR will send an error message and reboot with the secondary image - the last
image loaded before the primary image - and will disregard the primary image. Syslog failure
messages can cite no message from SNMP in 30 minutes, startup-config error, crash and watchdog expired. Respond as follows to these failure causes:
•If XSR reboots with the secondary EOS file, check the fault report generated and retry reload
2-34 Managing the XSR
reload command or via SNMP. If the new image does
Utilizing the Command Line Interface
•If the power to XSR fails, try another reload
•If a syntax error is indicated, examine your configuration for errors
•If XSR crashes, do not retry reloading. Contact Technical Support
EOS fallback is configurable from the CLI or via SNMP. Refer to the following section to configure
the feature on the CLI or “Configuring EOS Fallback via SNMP” on page 2-35 for SNMP
configuration instructions.
Configuring EOS Fallback on the CLI
1.Upgrade the bootrom. Because EOS fallback is implemented partially in bootrom and
partially in the router image, both the bootrom and image must be upgraded. Minimum
requirements are as follows on each router type: XSR 1800 Series - bootrom 3.4, XSR 1200
Series - bootrom 1.1, XSR 3000 Series - bootrom 1.7.
The following procedure configures EOS fallback through the SNMP Enterasys-image-validationmib and Enterasys-configuration-management-mib.
Caution: You must enable EOS Fallback on the CLI before specifying the primary image and
rebooting the XSR. Refer to “Configuring EOS Fallback on the CLI” in the previous section.
1.Enable EOS fallback by setting the etsysImageValidationEnable OID in the Enterasys-Image-
Validation-MIB to
2.Configure other parameters in this MIB. For example, set etsysImageValidationOperations to
0xa0 to enable the config and snmp tests during EOS fallback verification as follows:
•Enable EOS fallback:
enabled.
set 1.1.1.1 .1.3.6.1.4.1.5624.1.2.47.1.1.1.0 1
•Set test duration to 10 minutes: set 1.1.1.1 .1.3.6.1.4.1.5624.1.2.47.1.1.2.0 10
•Set test config and snmp values: set 1.1.1.1 .1.3.6.1.4.1.5624.1.2.47.1.1.3.0 a0
•Monitor SNMP requests from the PC with IP address 1.1.1.2: set 1.1.1.1
.1.3.6.1.4.1.5624.1.2.47.1.1.7.0 01010102
Note: The etsysImageValidationOperations for ping is not supported.
3.Add a row to the Configuration Management Change Table that specifies the primary image:
set 1.1.1.1 .1.3.6.1.4.1.5624.1.2.16.2.7.1.11.1 5
4.Set the primary file name which include the file (x.fls) and device name (flash: or cflash:):
set 1.1.1.1 .1.3.6.1.4.1.5624.1.2.16.2.7.1.2.1 file://cflash:/xsr3004.fls
XSR User’s Guide 2-35
Utilizing the Command Line Interface
5.Set the operation to imageSetSelected:
set 1.1.1.1 .1.3.6.1.4.1.5624.1.2.16.2.7.1.3.1 0100
6.Set the row to active:
set 1.1.1.1 .1.3.6.1.4.1.5624.1.2.16.2.7.1.11.1 1
Note: The primary image cflash:xsr3004.fls must already exist in the XSR, otherwise the
configuration will fail at this point.
7.Reboot the XSR to load the new image by configuring the following:
•Create a row:
set 1.1.1.1 .1.3.6.1.4.1.5624.1.2.16.2.7.1.11.2 5
•Set operation to resetSoftwareset: 1.1.1.1 .1.3.6.1.4.1.5624.1.2.16.2.7.1.3.2 8000
•Set the row to active: set 1.1.1.1 .1.3.6.1.4.1.5624.1.2.16.2.7.1.11.2 1
Note: The Configuration Management MIB lets you add a delay (Etsysconfigmgmtchangedelaytime)
In Steps 3-6 and Step 7. Be aware that the Step 7 delay cannot be smaller than the delay set in
Steps 3-6.
Downloading with FIPS Security
In compliance with Federal Information Processing Standard (FIPS) security, XSR 1800/3000
Series routers require a different download procedure than usual. You must specify the
FIPScompliant
HMAC SHA-1 key using either the Bootrom key command or the sw-verification key command
on the CLI. Follow the prompts as instructed.
When FIPS is enabled, all .FLS files must be signed with the signing utility:
<20hexdigits><xsr1800.fls>
. Only signed incoming FLS files will be accepted from TFTP,
SNMP and CompactFlash. After FIPS is enabled, back revisioning is not permitted. To disable
FIPS, press the Default button (on the XSR 1800 Series) to clear all configuration settings including
the FIPS and master encryption keys.
For the XSR 3000 Series only, FIPS can be disabled by entering five invalid Bootrom password
entries. You will be prompted before the XSR reverts to the default factory configuration and
clears the FIPS key.
signEtsFls.exe -k
Software Image Commands
You can view the status of the software image including such data as the current firmware image
filename, software release version, timestamp, and size by issuing the
Use the
For more command details, refer to the XSR CLI Reference Guide.
Configuration Change Hashing
Transparently, the XSR hashes persistent configuration changes and stores them in an SNMP
accessible variable to assist you in assessing remote backups or device monitoring. Hashing by the
MD5 algorithm is conducted on the following files:
•startup-config
•private-config
•user.dat
2-36 Managing the XSR
show version command.
boot system command to actively change the default file name of the software image.
When the XSR boots up, the checksum of these files is calculated and stored in volatile memory.
From then on any time the content of those files is changed the hash is recalculated and stored.
You can access the hash value in the etsysConfigMgmtPersistentStorageChSum SNMP object and
compare it with previous queries to detect configuration changes to the managed entity.
Displaying System Status and Statistics
The XSR’s numerous show commands, which are available in either privileged EXEC or Global
configuration mode, display a broad array of system data such as:
•System name, port types and their status, CPU card revision, Flash memory and DRAM size,
NIM cards and type, contact and system hardware data, image in Flash, and system location.
•XSR statistics: buffer counters, packets and NIM card status.
Memory Management
To display available show commands, issue the
Some system data such as the product type and serial number, hardware revision number of the
motherboard, and Ethernet port MAC addresses is stored in IDROM, a discrete area in Flash
memory. You can view these parameters by issuing the
Refer to the XSR CLI Reference Guide for details about these commands.
Memory Management
The XSR provides memory management via its Resource Capacity feature. Resource Capacity
marks an advance in flexibility over the hard-coded limits mechanism of earlier releases in that
you can now choose which software modules to configure based on available memory per
resource. Resource Capacity is designed to control resource creation so that the XSR does not run
out of memory and operate improperly.
The XSR defines a resource as a software element which can be created or deleted in run time.
When it is created it allocates memory by calling the memory management malloc function. When
deleted, it returns the memory to common pools by calling free functions. Currently,
approximately 45 resources including VPN tunnel, Access List entry, Route, and ARP request are
tracked by a memory governor which can be accessed with the
A resource can exist multiple times - for example, 5000 VPN tunnels - and each occurrence is
considered an Instance by Resource Capacity. The maximum number of resource instances which
can be created in a situation where practically no other resource is present constitutes that
resource’s Extreme Limit although it is highly unlikely you will ever configure that many instances.
Extreme limits are hard-coded, they can not be configured, and their size depends on the total
amount of installed memory on the XSR.
show ? command.
show version command.
show resources command.
Creating Resources
You can create a new instance of a given resource depending on the extreme limit for that resource
and the current amount of available memory. Because you can keep creating resources until you
run out of memory, you should find the right balance to satisfy your system operational needs the XSR does not arbitrarily limit any particular resource.
For example, you may want to create a “VPN-heavy” configuration with many VPN tunnels, but
only a few routes. In this case, the number of tunnels is not limited as it was in earlier releases.
Alternatively, you can set up a “route-heavy” configuration with many routes but only a few
tunnels. In either case, memory usage is balanced.
XSR User’s Guide 2-37
Network Management through SNMP
When the memory governor is asked to allow or deny a new resource, the decision is based on:
•memory low watermark
•extreme limit
You can push the extreme limit of individual resources as long as the memory low watermark is
not met. Once the low watermark is met and you wish to create more resources, you must then
free up earlier configured resources.
The memory low watermark can constrain resource creation as follows:
•Un-carved (un-allocated) memory remains in the memory “pie”. If un-carved memory is
lesser than a given number (e.g., 1 Mbyte) creation is denied but if it is larger, it is permitted.
•All memory has been carved. Each free pool (64-byte, 128-byte, and others) must have at least
the defined number of blocks to permit resource creation.
The XSR manages memory more efficiently by means of different-sized memory blocks. Memory
is carved during run time based on malloc requests received. Depending on your startup
configuration, memory will be carved in different ways. There are more than 10 fixed-size pools,
with the amount of carved buffers in each pool depending on your startup configuration. You can
examine memory buffering with the
i/o
commands.
If you intend to configure and un-configure a large number of resources, be advised to reboot the
XSR when necessary to optimize memory carving.
show buffers, show buffers malloc, and show buffers
Also remember that resource creation will be denied in the highly unlikely event of an extreme
limit being reached.
Caution: Do not enroll more certificates nor add more AAA users than permitted by the 1.5 MByte
system limit imposed on both Flash cert.dat and user.dat files, respectively. Doing so may
disable the XSR and require you to delete the files.
Network Management through SNMP
XSR system monitoring provides for the SNMP v1 agent (READ-ONLY) including gets and
limited sets and SNMP v3 gets and sets. Standard MIB II modules are supported as well as
Enterasys MIBs, as listed in the following table. Proprietary MIBs are available via download at:
http://www.enterasys.com/support/mibs For a list of supported proprietary and standard
MIB objects, refer to the table in “Chapter 1: Network Management “of the XSR User Guide.
In order to use SNMP to gather statistics or configure the device, first configure the XSR’s SNMP
agent with the
Variables you can set are: community name, traps, informs and host. SNMP v3 support includes
options to specify an engineID, security values for users and groups, and associated
commands. The
objects either via their SNMP term or numerical ID. SNMP v3 data is stored in the
config
file in Flash. Although SNMP is disabled by default, entering any SNMP configuration
command except
Refer to “XSR SNMP Proprietary and Associated Standard MIBs” on page B-1 for more
information about supported tables and table objects.
snmp-server commands.
snmp-server view command is an especially powerful tool to display SNMP
snmp-server disable will enable the server.
show
private-
2-38 Managing the XSR
SNMP Informs
SNMP Informs were first introduced in SNMPv2. An Inform is essentially nothing more than an
acknowledged trap. That is, when a remote application receives an Inform it sends back an “I got
it” message. When you send an Inform you use the remote engineID with the message and the
securityName and engineID exist as a pair in the Remote User table. The SNMP trap program
discovers the remote engineID as other applications would and creates the SNMPv3 message with
the proper user that the remote side is expecting to receive.
SNMP v3 on the XSR is supported by several CLI and SNMP agent enhancements. SNMP v1/v2c
traps can be configured with remote IP addresses to send traps with the
command. For SNMP v3, each agent has a unique identifier - the engine ID - which is used to
configure users in the User Security Model (USM). With the SNMP v3 USM, the XSR requires
configuration of remote engine IDs and remote users.
Network Management through SNMP
snmp-server host
To set up an inform recipient, first set the engine ID of the remote SNMP entity with
engineID
using
server informs
settings. The
. USM users may then be added with snmp-server user. Complete the configuration
snmp-server host to specify remote SNMP entities that will receive informs. The snmp-
command can be used to change the global retry, timeout and queue default
snmp-server enable traps command remains the same in all SNMP versions. This
command enables both traps and informs.
For a full description of SNMP commands, refer to the XSR CLI Reference Guide. Also refer to
NetSight Atlas Router Services Manager v2.0 documentation to query and change SNMP values.
Because the SNMP manager is disabled at boot-up, you must either manually enable the SNMP
manager using the CLI, or enable it in
Shaping Trap Traffic
Two controls are available to manage network traffic caused by SNMP traps. The first, set by the
snmp-server min-trap-spacing command, configures minimum spacing between successive
traps to ensure that they are spaced without causing delay and cap the number of packets
generated by traps.
The second control defines the maximum number of traps that can be sent in a given time
window. The time window is a moving sum of the number of traps sent to the network. If the
number of traps sent in the previous window-time is less than the value set by the
max-traps-per-window
Both methods work simultaneously and independently and only when both are satisfied will a
trap be sent. Otherwise, traps will be queued and sent as soon as conditions satisfy both traffic
shaping methods.
snmp-server
startup-config.
snmp-server
command, then more traps can be sent.
Statistics
The XSR supports SNMP gets for MIBs listed in “Chapter 1: Network Management “of the XSR
CLI Reference Guide. Also, refer to NetSight Atlas Router Services Manager v2.0 to query and
change SNMP values.
XSR User’s Guide 2-39
Network Management through SNMP
Alarm Management (Traps)
The following events are supported by SNMP traps: snmpTrapColdStart, snmpTrapWarmStart,
snmpTrapLinkDown, snmpTrapLinkUp, snmpTrapAuthFailure, entityTrapConfigChange,
frameRelayTrapfrDLCIStatusChange, ospfTrapIfStateChange, ospfTrapVirtIfStateChange,
ospfTrapNbrStateChange, ospfTrapVirtNbrStateChange, ospfTrapIfConfigError,
ospfTrapVirtIfConfigError, ospfTrapIfAuthFailure, ospfTrapVirtIfAuthFailure, ospfTrapIfRxBadPacket,
ospfTrapVirtIfRxBadPacket, ospfTrapTxRetransmit, ospfTrapVirtIfTxRetransmit, ospfTrapOriginateLsa,
ospfTrapMaxAgeLsa, ospfTrapLsdbOverflow, ospfTrapLsdbApproachingOverflow, bgpTrapEstablished,
and bgpTrapBackwardTransition.
SNMP alarms are listed in Appendix A: “Alarms/Events, System Limits, and Standard ASCII
Tabl e” on page A-1.
Network Monitoring via Service Level Agreement Agent
The XSR supports a Service Level Agreement (SLA) agent to monitor network performance based
on configurable latency, jitter, and packet loss metrics as well as to query the results. You can
schedule measurements between the XSR and any remote host which supports the type of
operation - ICMP echo - used to perform the measurement.
There are two management interfaces which operators can choose from to perform monitoring:
CLI or SNMP. The SLA agent supported via the CLI is based on the de facto industry standard
whereas the supported MIB provided by the SNMP interface is based on the Enterasys-Service-
Level-Reporting-MIB (SLR). This MIB in turn is based on the IP Performance Monitoring Reporting
MIB, now in RFC draft form.
The SLR MIB classifies network performance by network and aggregate measurements as follows:
•Network measure - Performs several metric measurements per packet exchange: each
measurement step produces a single result per metric.
•Aggregate measure - Summarizes the results of previous network or aggregated
measurements.
For example, metrics such as packet loss and round-trip delay are classified as network
measurements while round-trip delay average and jitter metrics, which are calculated based on
previous results, are classified as aggregate measurements. This is described further in the
following sections.
Note: The SLA agent provides statistics based on round-trip measurements only and includes XSR
processing time.
For more information on SLA-related CLI commands, refer to the XSR CLI Reference Guide. Refer
to Appendix: B “Service Level Reporting MIB Tables” on page B-1 for a list of XSR-supported
fields and tables from the Enterasys Service Level Reporting MIB.
Measuring Performance Metrics
XSR performance metrics are measured as follows:
•D(i) - the value for the ith measurement
•Ri - receive time for the ith measurement
•Si - sending time for the ith measurement
2-40 Managing the XSR
Network Management through SNMP
Latency (network delay) is measured with the formula: D(i)=(Ri-Si), which is the round-trip
interval between sending and receiving the ICMP packet triggered by the initiator and echoed
back by the target.
Jitter (network delay variation) is the value between packets i and j as figured by the formula:
D(i,j)=(Rj-Ri)-(Sj-Si). Since the XSR measures the round trip, Ri indicates the receive interval at the
source instead of the target.
Packet loss - If an ICMP echo reply packet is not received within a specified time, it is considered
lost. This does not allow the operator to identify whether the packet is lost on the way to the target
or when the response is traveled from the target back to the sender.
Configuration Examples
The following CLI and SNMP examples illustrate how to create: an owner, a measurement to ping,
schedule a measurement, and query a measurement.
Create an Owner
The XSR provides a default owner monitor residing in the first row of the owner table. If you want
to create another RTR owner, follow the instructions below.
Via CLI
The following example creates the user Clem:
XSR(config)#rtr owner Clem
Via SNMP
The example below creates a user in row 2 of the table (the instance is 2 as indicated in bold):
3.Change the row status to active (etsysSrvcLvlOwnersStatus):
1.3.6.1.4.1.5624.1.2.39.1.2.1.1.9.2 = 1 (active)
Note: The string userA is equivalent to the ASCII value 117:115:101:114:65, which will be used to
index into the aggregate measure table. If you want to use the default owner, the ASCII value of the
default owner (monitor) is 109:111:110:105:116:111:114.
Refer to “Standard ASCII Character Table” on page A-19 for more information. With NetSight
Atlas MIB Tools, retrieve the ASCII value from the Raw Value column, as shown in Figure 2-4.
The following example creates a row in the aggregate measure table with owner userA. If the
entry is created with owner monitor, replace 5.117.115.101.114.65 with
Now that you have performed the previous actions, you can query the measurement result.
Via CLI
The following command displays rtr output:
XSR#show rtr history
Via SNMP
1.Query the etsysSrvcLvlHistoryTable (1.3.6.1.4.1.5624.1.2.39.1.3.1).
Using the SLA Agent in SNMP
The XSR’s SLA agent implements the Enterasys Service Level Reporting MIB and supported
metrics as detailed in the following tables, which may cross-reference each other. For example,
etsysSrvcLvlNetMeasureIndex is used to index etsysSrvcLvlHistoryTable as well.
Note: All configurable values are limited by ranges specified in the CLI.
Refer to Appendix B: “Service Level Reporting MIB Tables” on page B-1 for supported OIDs.
Full Configuration Backup/Restore
The XSR supports a full configuration backup and restore via SNMP using the Enterasys
Configuration Management and Cabletron CTdownload MIBs. Follow the steps below.
Cabletron CTdownload MIB
1.Select the downLoadConfiguration(4) and upLoadConfiguration(5) operations in the
ctDLOnLineDownload field.
2.Specify the address of the TFTP server in ctDLNetaddress. Start the transfer with the
appropriate value in ctDLOnLineDownload. Monitor the transfer’s progress by polling the
ctDLOperStatus field. Note that by definition, the XSR will be reset after a
downloaded, unbundled, verified and committed to RAM.
3.During an upload of
be bundled and stored in a temporary file (
Enterasys Configuration Management MIB
1.Select the configurationUpload(5) and configurationDownload(6) operations in the
etsysConfigMgmtChangeOperation field. Specify the file name as full-config.
2.In order to activate the configuration, the configurationActivate(9) command is issued causing a
bundled
file name in etsysConfigMgmtChangeURL must indicate
system reset.
full-config to be unbundled and become the active (startup) configuration. The
full-config, the user.dat, cert.dat, and private-config files will
full-config is
full-config), then uploaded to the TFTP server.
full-config. This action initiates a
3.The upload and download of the
Cabletron MIB but does not bundle or unbundle other configuration components.
startup-config file follows the same steps as in the
XSR User’s Guide 2-43
Network Management through SNMP
Software Image Download using NetSight
The NetSight Remote Administrator application can download an image to the XSR using TFTP.
The software image download is initiated through NetSight using an SNMP
triggers a TFTP download session initiated from the XSR.
Note: The XSR does not support an off-line download triggered by SNMP. That is, when you use
NetSight to download an image, a dialog box will pop up with a check box titled Online download. If
the box is unchecked, the SNMP request will fail. See NetSight documentation for more information.
SNMP Download with Auto-Reboot Option
To use this option, you must first enter the following command in Global mode to allow a user to
reboot the XSR using SNMP:
XSR(config)#snmp-server system-shutdown
When you employ NetSight to download an image, a dialog box will pop up with a check box
titled Auto reboot. If the box is checked, the XSR will be rebooted remotely after the download
ends. If the
chose the auto reboot option, the request would fail.
CLI Translator
The XSR provides a CLI Translator as a stand-alone CLI configuration application or a NetSight
plug-in application to translate a CLI script configuration file, which can be downloaded to the
XSR through TFTP.
snmp-server system-shutdown command were not entered and the remote user
set command, which
Appending CLI Commands to Configuration Files via SNMP
The XSR permits appending a file containing CLI commands to your configuration by using
SNMP. This is done by the ConfigurationAppend command in the Configuration Management MIB
executing CLI commands. In detail, it is performed as follows:
•Using TFTP, the file is copied to the XSR’s
error occurs while transferring the file, an error message will be sent to the SNMP agent and
displayed in the etsConfigMgmtChangeErrorDescription field.
•Once the file has successfully transferred, the ConfigurationAppend command acquires
Global mode and begins reading the CLI commands from the file. If Global mode is locked by
another user then an error will be displayed in the etsConfigMgmtChangeErrorDescription field
and the temporary file deleted.
•When all command lines have been executed the SNMP agent is informed that the command
was successful. If an error occured in the file, you are informed through the SNMP agent.
•The running configuration is saved to the startup configuration on the CLI.
•The SNMP user is informed that the command was successful and the temporary file name is
then deleted.
Follow the steps below to perform the append:
Note: Before starting this procedure, make sure that a TFTP server program is running on your PC.
Flash: directory using a temporary file name. If an
2-44 Managing the XSR
Accessing the XSR Through the Web
1.Write a plain ASCII file containing the CLI commands you want entered. For example:
interface FastEthernet2
ip address 192.168.19.1 255.255.255.0
no shutdown
2.Save and move the file to the root directory of the TFTP server on your PC.
3.Use SNMPv3 to create a row in the Configuration Management MIB. For example,
CreateAndWait:
1.3.6.1.4.1.5624.1.2.16.2.7.1.11.1 = 5
Ifyoureadthetable,onerowshouldbeadded.
4.Set the file name to point to the file on your PC:
Theconfigurationin the newCmd file is now part of the running-config. That is,you will see the
configuration for fastethernet2 when you enter the
Note: Be aware that the ConfigurationAppend command does not check for syntax errors in the file
being downloaded from the server.
show running-config command.
For more information, refer to the Enterasys Configuration Management MIB.
Accessing the XSR Through the Web
The XSR via a browser but provide a cursory display of hardware configuration data to diagnose
the router over the Web. Because the Web server is disabled at boot-up, you must either manually
enable the Web server using the CLI, or enable it in
is 80. Access to the XSR through the Web is not password protected.
Network Management Tools
The following tools are useful to manage the XSR over the network.
NetSight Atlas Router Services Manager v2.0
XSR firewall and Access Control List (ACL) configuration can performed on the NetSight Atlas
Router Services Manager v2.0 application. For more information, refer to the following URL:
A variety of tools provided by the XSR and Enterasys’ NetSight application support:
XSR User’s Guide 2-45
Network Management Tools
Using the CLI for Downloads
TFTP can be used to transfer system firmware to the XSR remotely. A TFTP server must be
running on the remote machine and the firmware image file must reside in the TFTP root
directory of the server when using the
Using SNMP for Downloads
You can use an SNMP manager to download or upload firmware from a remote server, and copy
a configuration image file to the XSR. Only run-time/online mode downloads are supported. This
requires setting the ctDLNetAddress and ctDLFileName objects and issuing a ctDLOnLineDownLoad
defined in the CTRON-DOWNLOAD-MIB. For more details click on the following URL:
http://www.enterasys.com/support/mibs
Fault Reporting
A fault report can be uploaded through TFTP. The mechanism to upload the crash report is the
same as the one used to upload configuration file. Refer to “Performing Fault Management” on
page 2-23 for more information.
Auto-discovery
copy tftp filename command.
The NetSight Gateway Management Tool can auto-discover an XSR on the network using SNMP
with the following MIB variables:
•SysDesr
•SysObjID
•Sysuptime
NetSight also performs auto-discovery via ping using ICMP ping.
2-46 Managing the XSR
Managing LAN/WAN Interfaces
Overview of LAN Interfaces
The XSR supports two 10/100 Base-T FastEthernet ports on the XSR 1800 Series branch routers
and three 10/100/1000 Base-T GigabitEthernet ports on the XSR 3000 Series regional routers. All
ports are capable of running in half- and full-duplex modes, and are ANSI/IEEE 802.3 and ANSI/
IEEE 802.3u compliant. These ports connect to an Ethernet network for LAN connectivity.
The Fast/GigabitEthernet interfaces perform the following functions:
•Allow the XSR to connect to networks of speeds of 10 Mbps, 100 Mbps, or 1000 Mbps (using
manual settings or auto-negotiation)
•Monitor the status of the link: up or down
•Allow you to issue interface/device configuration commands through the Command Line
Interface (CLI)
•Accumulate MIB-II (RFC-1213) interface statistics regarding the transmission and reception of
bytes and packets
3
LAN Features
The XSR supports the following LAN interface features:
•Alarms/events - For a complete list, refer to “Alarms/Events, System Limits, and Standard
ASCII Table” on page A-1 in this manual.
•Duplex mode is set using the
–Half - half-duplex
–Full - full-duplex
–Auto - auto-negotiation (default)
•Packet filtering - the interface will receive:
–All broadcast packets
–All multicast packets
–Unicast packets which have the MAC addresses of the device
•Maximum Receive Unit (MRU) - all frames less than or equal to 1518 bytes are accepted
including the 4-byte FCS.
•Oversized packets greater than 1518 bytes are not accepted.
•Runt packets of 64 bytes or less are not accepted.
duplex command with the following options:
XSR User’s Guide 3-1
Configuring the LAN
•Maximum Transmission Unit (MTU) - all frames less than or equal to 1518 bytes are accepted.
MTU size is set using the
ip mtu command.
•Speed is enabled using the
–10 - 10 Mbps
–100 - 100 Mbps
–1000 - 1000 Mbps
–Auto - Auto-negotiate (default)
•Statistics - all MIB-II interface statistics are supported
•Clear commands such as
gigabitethernet
and clear interface GigabitEthernet, which reset the interface counters and facilitate
interface troubleshooting.
Configuring the LAN
Enter the following commands to configure FastEthernet interface 1 on network 192.57.99.32:
, which reset the MIB-II counters, and clear interface FastEthernet
MIB Statistics
The following table reflects MIB-II (RFC-1213) port statistics collected by a LAN interface.
Table 3-1 MIB-II Interface Statistics
Var ia bleDescription
IfDescrDescription of the interface.
IfTypeType of the interface (set once, and never changed).
IfMtuSize of the largest packet that can be sent/received on the interface, specified in bytes.
IfSpeedEstimate of the interface's current bandwidth in kilobits per second (10000 or 100000)
IfPhysAddressInterface's address at its protocol sub-layer (the MAC address).
ifAdminStatusDesired state for the interface.
ifOperStatusCurrent operational status of the interface.
ifLastChangeValue of sysUpTime when the interface entered its current operational state.
IfInOctetsSum of octets received on the interface.
ifInUcastPktsSum of subnetwork-unicast packets delivered to a higher layer protocol.
3-2 Managing LAN/WAN Interfaces
Table 3-1 MIB-II Interface Statistics (continued)
Var ia bleDescription
ifInNUcastPktsSum of non-unicast packets delivered to a higher layer protocol.
IfInDiscardsSum of inbound packets discarded.
IfInErrorsSum of inbound packets that contained errors.
IfOutOctetsSum of octets transmitted on the interface
ifOutUcastPktsSum of subnetwork-unicast packets sent to the network.
ifOutNUcastPktsSum of non-unicast packets transmitted to the network.
IfOutErrorsSum of outbound packets that could not be sent due to errors.
IfOutDiscardsSum of outbound packets discarded.
Overview of WAN Interfaces
The XSR supports as many as six serial cards (in an XSR-3250), each of which can support four
ports for a maximum of 24 serial ports. Each port is individually configurable regarding speed,
media-type, and protocol.
Overview of WAN Interfaces
The Serial WAN interface performs the following functions:
•Transmit packets given by the protocol layer onto a serial link.
•Receive packets from a serial link and pass up to the protocol layer.
•Allow CLI configuration commands to be issued.
•Accumulate all MIB-II (RFC-1213) interface statistics regarding the transmission and reception
of bytes and packets.
WAN Features
The XSR supports the following WAN interface features:
•Alarms/events - For a complete list, refer to “Alarms/Events, System Limits, and Standard
ASCII Table” on page A-1 in this manual.
•Interfaces - The following interface types can be configured using the
–RS232 (also known as V.28) (default)
–RS422 (also known as RS-530)
–RS449 (also known as V.36)
–RS530A
–V.35
media-type command:
–X.21
•Either Sync or Async mode is set by using
•Encoding - On Sync interfaces,
nrzi-encoding sets NRZI encoding (NRZ encoding is the
default).
physical-layer.
XSR User’s Guide 3-3
Configuring the WAN
•Clocking speed - For Sync interfaces, an external clock must be provided. Acceptable clock
values range from 2400 Hz to 10 MHz. For Async interfaces, the clock is internally generated
and can be set to the following values using
clock rate:
–2400 Kbps
–4800 Kbps
–7200 Kbps
–9600 Kbps (default)
–14400 Kbps
–19200 Kbps
–28800 Kbps
–38400 Kbps
–57600 Kbps
–115200 Kbps
•Statistics - all MIB-II interface statistics are supported.
•Clear commands such as
interface troubleshooting.
•Async mode commands such as
serial line.
•Maximum Receive Unit (MRU) is 1518 bytes (including CRC).
Configuring the WAN
Enter the following commands to configure either a synchronous T1 or asynchronous Serial
interface. For more detailed information on the commands used here, refer to the XSR CLI Reference Guide and other chapters in this manual.
The following example configures the synchronous T1 controller on NIM 1, port 0 named Acme T1
with the default values of ESF framing and B8ZS line encoding. It also specifies channel group 1
with mapped timeslots 1-5, 8 and 9, assigns the local IP address 192.168.1.1 to the channel group
and sets PPP encapsulation.
clear counters serial and clear interface serial facilitate
databits, stopbits, and parity provide configuration of the
3-4 Managing LAN/WAN Interfaces
Configuring the WAN
The following example configures the asynchronous serial interface on NIM 2, port 0 with the
following non-default values: PPP encapsulation, RS422 cabling, 57600 bps clock rate, MTU size of 1200 bytes, no parity, 7 databits and 2 stopbits. It also assigns the local IP address 192.168.1.1 to the
interface. Although the XSR is not designed to be an access server, you can attach an external
modem to the serial port and accept async calls as long as the modem is configured in “dumb
mode” (AT commands are disabled).
The XSR provides Frame Relay and PPP service via T1/E1 and T3/E3 functionality as well as
Drop and Insert features.
T1/E1 Functionality
The XSR provides a T1/E1 subsystem on a single NIM-based I/O card with a maximum of two
installed NIMs. Depending on the card type and series, each card can support 1, 2 or 4 T1 or E1
physical ports.
You can select either T1, at 1.544 Mbps interface rate per port, or E1, at 2.048 Mbps interface rate
per port. In both operational modes, the interface can work either in full rate T1/E1 mode (the
complete available line interface rate is assigned to one user), fractional T1/E1 mode (only one
channel group is assigned, with less than the total available number of timeslots on a T1/E1 line
configured per physical port) or in channelized mode (more than one channel group is configured
per physical port).
4
Configuring T1/E1 & T3/E3 Interfaces
In fractional/channelized mode, up to 31 DS0 channels can be assigned on E1 interfaces and up to
24 DS0 channels can be assigned on T1 interfaces. The rate (line speed) of basic channel (DS0) can
be configured at 56 or 64 Kbps.
T3/E3 Functionality
The XSR T3/E3 subsystem offers a NIM-based I/O card with a single port, full rate unchannelized
T3/E3 mode and sub-rate support for proprietary T3 and E3 DSU vendors. “Sub-rate T3/E3” and
“fractional T3” are interchangeable terms describing un-channelized T3/E3 service that delivers
less than full line bandwidth.
T3 or E3 mode is software selectable - one hardware NIM supports both modes.
Features
T1/E1 Mode
The following features are offered on the T1/E1 interfaces:
•Integrated CSU/DSU
•Full-rate, channelized and fractional
•Short and long haul symmetrical line interfaces with 100/120 ohm impedance using RJ-45/
48C or 49C connectors
XSR User’s Guide 4-1
Features
•Support for local and remote loopback
•Support for an IP interface as a loopback (refer to the CLI Reference Guide for an example)
•Clock - line (slaved to network receive clock) and internal (private clock source)
4-2 Configuring T1/E1 & T3/E3 Interfaces
•Line rate - 34.368 Mbps
•Full rate - 34.0995 Mbps (G751)
•Sub-rate - approximately 3 Mbps increments up to 33 Mbps
•Compatible DSUs supported
–Cisco or Quick Eagle (formerly Digital Link) DL3100 E3 -300-33.920 Kbps
–ADC Kentrox T3/E3 IDSU
•Scrambling - Cisco mode only
•Performance Monitoring Local Network Port Statistics - Per RFC-2496- Current 15-minute, 24-
hour (96 *15-minute intervals) and total for 24 hours
T1/E1 Subsystem Configuration
Each T1/E1 physical port is represented as a T1 or E1 controller. This is valid for both full rate T1/
E1 mode and fractional/channelized modes. Each T1/E1 physical port (line) can be configured to
run in one of the following modes:
•Full rate T1/E1 mode - full T1/E1 line bandwidth is used by one user
•Fractional T1/E1 mode - only one Channel Group is assigned to one T1/E1 physical line
•Channelized T1/E1 mode - more than one Channel Group is assigned to one T1/E1 physical
line
Features
For both fractional and channelized configurations, each configured Channel Group, which might
contain individual timeslots or ranges of timeslots, uses only one of the available logical channels.
All configured T1/E1 lines are recognized by the system software as serial interfaces. That implies
that all of the available configuration procedures for interfaces are applicable. Each of the serial
interfaces can be configured to carry data traffic with PPP encoding.
T3/E3 Subsystem Configuration
Each T3/E3 physical port is represented as a T3 or E3 controller. This is valid for both full and subrate T3/E3 modes. Un-channelized or “unformatted” service creates a point-to-point connection
between your network equipment and that of the service provider. The T3/E3 WAN transmission
line can be provisioned as follows:
•Full rate service is covered by national and international standards. Only one data stream at full
•Clear Channel service is similar to the full rate service except that the data stream rate is slightly
higher because the framing overhead bits are also used to deliver data.
–T3 - Not Available
–E3 - 34.368Mbps payload
T1 Drop & Insert One-to-One DS0 Bypassing
The XSR’s 2-port D&I NIM is designed to cross-connect unused timeslots between the two ports
and provide one T1/E1 line for both data and voice traffic, as shown in Figure 4-1. The timeslots
carrying data are terminated in the on-board HDLC controller, while voice timeslots bypass the
D&I NIM and are terminated in the downstream PBX. This NIM is configured with
insert-group
t1 s/c/x
commands.
and runs identically to the XSR’s 2-port fractional T1/E1 NIM. Show controller
is useful for debugging the line. Refer to the XSR CLI Reference Guide for associated
Figure 4-1 Drop and Insert NIM Topology
Voice timeslots
bypass the XSR
T1-PBX
drop-and-
PSTN
T1-CO
PBX
Clock
Clock
Data timeslots
terminate in the XSR
Frame
Relay
The D&I NIM does not support channelized mode nor PRI.
Note: If the XSR loses power, the two T1 lines will be cross-connected by the relays. Consequently,
the Central Office will not report the lines down.
Drop and Insert Features
The following features are supported by the D&I NIM:
•The D&I feature allows Channel Associated Signaling (CAS) voice DS0 timeslots to be taken
off the Central Office (CO) T1 or E1 interface and inserted into timeslots of the PBX T1 or E1
interface, as long as both interfaces are on the same NIM card.
•You must configure the timeslots belonging to the data channel group. All timeslots not within
the data channel group are considered idle and bypassed between the T1 or E1 ports.
•D&I timeslots need not be contiguous - all idle timeslots on both the T1 or E1 interface will be
automatically connected and transparently pass voice channels. Idle timeslots are not
configured to take part in channel groups.
•The CO T1/E1 and PBX T1/E1 ports are bypassed by relays to maintain a CO-PBX link in case
of a power outage or watchdog timeout. So, when the XSR with the D&I NIM is inserted
between the PBX and the T1 line of the CO, there is no need to reconfigure the PBX.
4-4 Configuring T1/E1 & T3/E3 Interfaces
•The D&I NIM supports different framing and line coding on the CO T1 and PBX T1 ports (ESF
versus D4, B8ZS versus AMI), but if the ports are not identically configured, the bypass relays
will not restore the voice link in the case of an XSR failure or power outage.
•The CO T1/E1 port supports one PPP or Frame Relay channel.
•The T1E1 Drop & Insert NIM includes the same data functionality as the standard two-port
Fractional T1E1 NIM.
•The PBX T1 port need not support a data channel.
Note: All of the above features are supported for the E1 interface, as well. The E1’s timeslot 16 is
reserved for CAS signaling and can not be configured for data.
Refer to “Configuring the D&I NIM” on page 4-13 for a configuration example.
Configuring Channelized T1/E1 Interfaces
Perform the following steps to set up a channelized T1/E1 port. This T1 example is similar to that
for an E1 controller and associated port.
1.Specify the slot/card/port address of the controller to be configured:
XSR(config)#controller t1 0/1/0
This command automatically adds a full-rate channel group on port 0 and acquires Controller mode.
Alternatively, you can add a different port and manually add a channel group using any of 24 timeslots.
Configuring Channelized T1/E1 Interfaces
2.Specify the clock source for the controller.
XSR(config-controller<T1-1/0>)#clock source line
The clock source command determines which one of the circuits provides the clocking signal.
3.Specify the controller's framing type:
XSR(config-controller<T1-1/0>)#framing esf
4.Specify the controller's line encoding type:
XSR(config-controller<T1-1/0>)#linecode b8zs
5.Specify a channel group and map timeslots to the group. Enter the channel-group command.
The example specifies channel group 0 and maps timeslots 1, 3 through 5, and 8 to channel group 0.
Note: Each channel group is represented as a serial interface and is set individually. Channel
groups are created as shown above but to configure them you must acquire Interface Serial mode
as shown below.
6.Enter the no shutdown command to enable the line.
XSR(config-controller<T1-1/0>)#no shutdown
7.If IP routing is enabled, assign an IP address and subnet mask to the channel group with the
8.Specify the encapsulation protocol to be used over this interface.
XSR(config-if<S1/0:0>)#encapsulation ppp
In this example PPP is used.
XSR User’s Guide 4-5
Configuring Un-channelized T3/E3 Interfaces
9.Add any additional configuration commands required to enable IP- or PPP-related protocols.
10. Use the no shutdown and exit commands to enable the interface and return to configuration
mode. Repeat the previous steps to configure more channel groups.
XSR(config-if<S1/0:0>)#no shutdown
Configuring Un-channelized T3/E3 Interfaces
Perform the following steps to set up an un-channelized T3 or E3 port. If you wish to use defaults,
enter only the first two commands. The remaining commands set up IP routing, WAN/LAN ports
and optional T3 values.
1.Specify the slot/card/port address of the controller to be configured.
XSR(config)#controller t3 0/1/0
This command adds the serial pipe, a single channel, and acquires Controller mode.
2.Enable the Controller line.
XSR(config-controller<T3-0/1>)#no shutdown
3.Optionally, if you prefer to configure internal clocking.
This section describes the techniques and procedures to troubleshoot T1/E1 or T3/E3 physical
layer problems. The troubleshooting flowchart below displays the procedures described in the
following section.
The show controller command displays current controller parameters, status and statistics data.
Most controller errors are caused by incorrectly configured lines including line coding, framing,
and clock source parameters.
When a T1/E1 or T3/E3 controller (port) is created with an associated channel or channel group, it
can exist in three states:
•Administratively down:
If you do not enter the
shutdown command for an already created controller (port), you create all associated channel-groups
no shutdown command when you create the controller (port) or enter the
on that controller (port) but they are disabled.
•Down:
If you enter the
no shutdown command for the controller in Controller mode, all associated channel
groups are enabled on the physical level but the controller senses an alarm on the line and will not pass
user data.
•Up:
Only when the associated interface is enabled using the
no shutdown command in Interface mode does
the channel-group become operational. This is because there is one-to-one mapping between channel
groups and interfaces; if an interface is administratively down so is its channel group - even if the
controller port is up!
Follow these steps to restart the controller to correct this type of error:
1.Enter Controller mode. For example:
XSR(config)#controller t1 1/0
XSR(config-controller<T1-1/0>)#
4-8 Configuring T1/E1 & T3/E3 Interfaces
2.Restart the controller:
XSR(config-controller<T1/0>)#no shutdown
If the T1/E1or T3/E3 controller and line are not up, check that either the T3/E3 NIM LOS or LOF
LEDs are shining or one of the following messages displays in the
•Receiver has loss of frame (LOF), or
•Receiver has loss of signal (LOS)
Complete the following steps if the receiver has loss of frame:
1.Ensure the framing format set on the port matches the framing format of the line. If needed,
change the framing format configuration.
2.Change the Line Build-Out (LBO) using cablelength long/short (T1) or cablelength (T3)
commands. If needed, contact your service provider for more details on LBO configuration.
Complete the following steps if the receiver has a loss of signal:
1.Ensure the cable between the interface port and the T1/E1 or T3/E3 service provider
equipment is connected correctly.
2.Check the cable integrity by looking for breaks or other physical abnormalities in the cable.
3.Check the cable connectors.
T1/E1 & T3/E3 Alarm Analysis
Troubleshooting T1/E1 & T3/E3 Links
show controller output:
Perform the following steps to troubleshoot for various alarms that can occur within the T1/E1 or
T3/E3 subsystem. The following troubleshooting flowchart displays the procedures.
1.Check the settings at the remote end to ensure that they match your port settings.
2.Contact your service provider if the problem persists.
Transmit Sending Remote Alarm (Red Alarm)
1.Ensure the framing format configured on the port matches the framing format of the line. If
not, change the framing format on the controller to match the format of the line.
2.Check the settings at the remote end and ensure that they match your port settings.
3.Contact your service/network provider if the problem persists.
Transmit Alarm Indication Signal (AIS - Blue Alarm)
1.Ensure that the framing format configured on the port matches the framing format of the line.
If not, change the framing format on the controller to match the format of the line.
2.Power cycle the XSR.
3.Connect the T1/E1or T3/E3 line to a different port. Configure the port with the same settings
as the line. If the problem persists, perform an external loopback test on that port. If the
problem persists, contact Technical Support for assistance.
This section describes various error events that can occur on controller lines and provides
troubleshooting information to fix some of these errors. The
the status and statistics specific to the hardware. This information is useful for diagnostic tasks.
All problems that can occur are captured by the underlying hardware and reported by the
controller
displaying troubleshooting actions.
output. Here are some troubleshooting steps you can perform with a flowchart
If your controller still
does not function as desired,
contact your service/network
provider
Ye s
Ye s
Ye s
Is the clock source
derived from the
network/line?
Is the framing type
Is theT1/E1 line coding
correct?
correct?
Use the following
No
No
No
commands to set
source clocking:
controller t1 x
clock source line
Use these commands
to set framing:
controller t1 x
framing
If T1, then change LBO:
cablelength {long | short}
If T3, then change LBO:
cablelength
Use the following
T1/E1 commands to set
line coding:
controller t1 x
linecode {ami | b8zs}
If T1, then change LBO:
cablelength {long | short}
Use the command
below to verify the
error counter is still:
increasing:
controller x
Use the command
below to verify the
error counter is still:
increasing:
controller x
Use the command
below to verify the
error counter is still:
increasing:
controller x
Note: Statistics displayed with the show controllers command are reset every 24 hours. That
is, once the port or line is created with the controller command, the 24-hour timer starts.
Slip Seconds Counter Increasing
If slip seconds are present on the T1/E1 or T3/E3 line, usually there is a clocking problem.
Complete the following steps to correct this problem:
1.Ensure the clock source is derived from the network (source clocking extracted from the line).
2.Set the T1/E1 or T3/E3 clock source from Controller mode if needed.
4-12 Configuring T1/E1 & T3/E3 Interfaces
Loading...
+ hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.