SmartEdge OS Product Overview


1Introduction to the SmartEdge OS


2.1Independent System Processes and Applications
2.2System Redundancy and Synchronization


SmartEdge OS System Features
3.4Ports, Channels, and Circuits


User Interface
4.1Command Modes and Prompts
4.2Command Mode Hierarchy
4.3Privilege Levels
4.4No and Default Forms of Commands
4.5Operations Commands


IP Services and Security Features
5.1IP Protocols
5.2IP Services
5.3IP Service Policies
5.4Quality of Service
5.5SmartEdge Security


RFlow Performance Management


SmartEdge Routing
7.1Static Versus Dynamic Routing
7.2IGPs Versus EGPs
7.3Basic IP Routing
7.4Dynamically Verified Static Routing
7.5Virtual Router Redundancy Protocol
7.6Routing Information Protocol
7.7Open Shortest Path First
7.8Bidirectional Forwarding Detection
7.9Border Gateway Protocol
7.10Border Gateway Protocol/Multiprotocol Label Switching Virtual Private Network
7.11Intermediate System-to-Intermediate System Routing
7.12IP Multicast
7.13Routing Policy
7.14Multiprotocol Label Switching
7.15Layer 2 Virtual Private Network
7.16Port Pseudowire Connections
7.17Label Distribution Protocol
7.18Virtual Private LAN Services
7.19Protocol Distances


What’s Next?


© Ericsson AB 2009–2011. All rights reserved. No part of this document may be reproduced in any form without the written permission of the copyright owner.


The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.

Trademark List
SmartEdge is a registered trademark of Telefonaktiebolaget LM Ericsson.
NetOp is a trademark of Telefonaktiebolaget LM Ericsson.

1   Introduction to the SmartEdge OS

The SmartEdge® router hardware and software products provide multiservice edge routers that enable the next generation of services in the new access network. In this document, all commands, modes, traffic cards, and other peripherals are supported on every router unless otherwise noted. The hardware and configuration documents in the SmartEdge library contain more information about platform compatibility.

The SmartEdge router products provide:


In this document, the following terms are used:

  • The term controller card applies to the Cross-Connect Route Processor (XCRP4) Controller card, unless otherwise noted.
  • The term chassis refers to any SmartEdge chassis.

2   Architecture

The SmartEdge OS is the advanced software system that works in conjunction with the ASIC-based SmartEdge hardware products to provide a scalable and robust multiservice platform.

The SmartEdge OS performs the route processing and other control functions and runs on the controller card. Packet forwarding is performed by Packet Processing ASICs (PPAs) on the individual traffic cards.

Figure 1 illustrates the SmartEdge OS architecture.

Figure 1   SmartEdge OS Architecture

2.1   Independent System Processes and Applications

The SmartEdge OS is based on a general-purpose operating system; each major system component runs as a separate process in the system (see Table 1 for some examples).

Table 1    SmartEdge OS Components

System Component


Authentication, authorization, and accounting (AAA)

Forces all authentication requests and accounting updates to a single set of Remote Authentication Dial-In User Service (RADIUS) servers.

NetBSD kernel

Provides a lean and stable base for the SmartEdge OS.

Process Manager (PM)

Monitors and controls the operation of the other processes in the system.

Router Configuration Manager (RCM)

Controls all system configurations using a transaction-oriented database.

Interface and Circuit State Manager (ISM)

Monitors and disseminates the state of all interfaces, ports, and circuits in the system.

Routing protocols

Run as an independent processes, maintaining independent Routing Information Bases (RIBs). The routing processes send the routing information to the central RIB.


Downloads forwarding tables to the traffic cards.

Feature modules

Run as independent processes, each in its own protected address space.

Traffic cards

Includes the PPA ASICs, which contain the Forwarding Information Base (FIB) and forwarding code.

With optimized packet-forwarding capabilities and support for high-bandwidth uplink interfaces, the SmartEdge router can also be used in the metropolitan core to aggregate traffic from other routers into the long-haul transit core.

Implementation of the major software components as independent processes provides several benefits:

The separation of the route processing and control functions (performed by the SmartEdge OS software running on the controller card) from the forwarding function (performed on the individual traffic cards) also provides several benefits:

The SmartEdge products provide:

Figure 2 shows a sample application for the SmartEdge products.

Figure 2   SmartEdge OS Application

2.2   System Redundancy and Synchronization

Among other redundancy features, the SmartEdge routers and the operating system support dual controller cards; one controller card acts as the active controller and the other acts as its hot standby.

Both controller cards contain compact-flash cards that store the operating system image, its associated files, and the configuration database. A synchronization process ensures that the standby controller is always ready to become the active controller:

To guard against system inconsistency, the synchronization process is protected. While the synchronization is in progress, switchover from the active to the standby controller is not allowed. If the active controller should fail during synchronization, the standby does not become active. If the user attempts to force a switchover during this synchronization period, the system warns the user that the standby is not ready.

The synchronization process is not affected by traffic card installation and removal. The active controller, continues to forward traffic and detect and notify the administrator of any faults that occur while the standby controller card is being synchronized (FAIL LED is blinking).

After the synchronization is complete, the standby controller is ready to become the active controller if the active controller card fails.

3   SmartEdge OS System Features

Figure 3 illustrates the SmartEdge OS software component relationships.

Figure 3   SmartEdge OS Software Component Interrelationships

3.1   Contexts

Most networking products are designed so that the entire set of ports, circuits, and protocols operate together as one global instance. The SmartEdge OS supports an advanced feature called multiple contexts. Each context is a virtual SmartEdge router instance running within a single physical device. A context operates as a separate routing and administrative domain, with separate routing protocol instances, addressing, authentication, accounting, and so on, and does not share this information with other contexts. By separating the address and name spaces in this way, service providers can use multiple contexts to provide direct access to customers, or to provide different classes of services for customers. Service providers use a single physical device to implement this, with one or more contexts being assigned to each service provider or service class. Implementing this today with equipment from other vendors requires multiple devices.

The SmartEdge router is always configured with the special local context. This context is always present on the system and cannot be deleted. In a single-context configuration, the local context is the only context present on the system.

3.2   Interfaces

The concept of an interface in the SmartEdge OS differs from that in traditional networking devices. In traditional devices, the term interface is often used synonymously with port, channel, or circuit, which are physical entities. In the SmartEdge OS, an interface is a logical construct that provides higher-layer protocol and service information, such as Layer 3 addressing. Interfaces are configured as part of a context and are independent of physical ports, channels, and circuits. The decoupling of the interface from the physical layer entities enables many of the advanced features offered by the SmartEdge OS.

For the higher-layer protocols to become active, an interface must be associated with a physical port, channel, or circuit. This association is referred to as a binding in the SmartEdge OS. For more information, see Section 3.8.

3.3   Subscribers

Subscribers are the end users of the high-speed access services. Subscriber records are configured as part of a context, either locally on the SmartEdge router or on a RADIUS server. Subscriber records contain the information necessary to bind a subscriber to the correct interface, and therefore, to the correct network context and services. Subscriber records can also contain other configuration information, such as authentication, access control, rate-limiting, and policing information. For more information, see the documents in the Subscriber Management folder: Configuring Authentication, Authorization, and Accounting, Configuring Bindings, Configuring CLIPS, Configuring PPP and PPPoE, Configuring RADIUS, and RADIUS Attributes.

The number of active subscribers is a function of configuration, memory, processing power, and desired per-subscriber bandwidth. Each software and hardware variant has a maximum active subscriber figure, which may or may not be achieved under deployment scenarios.

The SmartEdge OS system supports the following subscriber management services:

3.4   Ports, Channels, and Circuits

Ports, channels, and circuits in the SmartEdge OS represent the physical connectors and paths on the SmartEdge traffic and controller cards. Physical port, channel, and circuit configurations include both hardware and software parameters that allow the behavior of the port, channel, or circuit to be specified for a specific router.

Before any higher-layer user data can flow through a physical port, channel, or circuit, that port, channel, or circuit must be associated with an interface within a context. This association is referred to as a binding in the SmartEdge OS. The configuration for each port, channel, and circuit includes binding information. For more detailed information on ports, channels, and circuits, in the SmartEdge OS, see Configuring ATM, Ethernet, and POS Ports, Configuring Cards, and Configuring Circuits.

3.5   Cross-Connections

The SmartEdge OS supports various types of cross-connections that allow you to cross-connect circuits of different types or of the same type. For more information, see Configuring Cross-Connections.

3.6   Bridges

The SmartEdge OS supports transparent, self-learning bridges (as described in IEEE 802.1D) that support restricted (very secure) circuits. Bridging on the SmartEdge router is context-specific and a context can support multiple bridges. Circuits that can be bridged include Ethernet ports with 802.1D or 802.1Q encapsulation, 802.1Q permanent virtual circuits (PVCs), and Asynchronous Transfer Mode (ATM) PVCs with RFC 1483 bridged encapsulation. IP- and Point-to-Point Protocol (PPP)-encapsulated circuits cannot be bridged; however, bridging of IP over Ethernet (IPoE)-encapsulated circuits and PPP over Ethernet (PPPoE)-encapsulated circuits is supported at the medium access control (MAC) layer. The SmartEdge router implements the Rapid Spanning Tree Protocol (RSTP) and MAC moves monitoring to provide path redundancy and to prevent bridging loops. Additional information on RSTP is found in IEEE 802.1d and IEEE 802.1w (RSTP is not supported over ATM.) For more information, see Configuring Bridging.

3.7   Tunnels

The SmartEdge OS supports the following tunnel types.

For more information, see Configuring GRE Tunnels, Configuring L2TP, and Configuring Single Circuit Tunnels.

3.7.1   IP-in-IP Tunnels

IP-in-IP tunneling transports IP payload packets encapsulated inside an outer IP header. This tunneling mode allows the Multicast backbone to set up tunnels between sites to exchange IP Multicast traffic over the Internet.

Mobile IP services also use IP-in-IP tunnels to transport packets from a mobile node (MN), when it is forwarded from the foreign agent (FA) to the home agent (HA), and optionally in the reverse direction. For more information about configuring mobile IP services, see Configuring Mobile IP for a Foreign Agent, Configuring Mobile IP for a Home Agent, Configuring Hotlining for a Foreign Agent, and Configuring Hotlining for a Home Agent.

3.7.2   Overlay Tunnels

An overlay tunnel is used within a site or between sites; it is equivalent to a permanent link between two IPv6 domains over an IPv4 backbone. The primary use is for stable connections that require regular secure communication between two edge routers or between an end system and an edge router, or for connection to remote IPv6 networks. You can configure overlay tunnels between border routers or between a border router and a host. The host or router at each end of a tunnel must support both the IPv4 and IPv6 protocol stacks.

The SmartEdge OS implementation of overlay tunnels is based on the RFC 2893, Transition Mechanisms for IPv6 Hosts and Routers. IPv6 is fully described in RFC 2460, Internet Protocol Version 6 (IPv6) Specification.

The changes from IPv4 to IPv6 include:

For a description of IPv6 addressing and the types of IPv6 addresses, see RFC 3513, Internet Protocol Version 6 (IPv6) Addressing Architecture.

3.7.3   GRE Tunnels and VPNs

Generic Routing Encapsulation (GRE) is a simple, stateless protocol that allows for the tunneling of IP in IP. GRE allows you to connect remote sites using private IP addresses over a public network that uses publicly routable IP addresses. GRE supports both IPv4 and IPv6 traffic. IP packets traveling through the tunnel are encapsulated with an IP header from the public address space as shown in Figure 4 and Figure 5.

Figure 4   GRE Tunnel Packet Encapsulation for IPv4 Packets

Figure 5   GRE Tunnel Packet Encapsulation for IPv6 Packets

One of the more common applications of GRE tunneling is the creation of VPNs to connect to remote sites. Multiple SmartEdge OS contexts and GRE tunnel circuits, one for each VPN, demultiplex traffic for each VPN into its own IP address space. Thus each context acts as a dedicated virtual router for a VPN, where the IP address space (for example, private addresses as described in RFC 1918, Address Allocation for Private Internets) and routing databases are maintained separately from other contexts.

For more information, see Configuring GRE Tunnels.

3.7.4   L2TP Tunnels

L2TP tunnels are User Datagram Protocol (UDP)/IP-encapsulated circuits that carry subscriber Point-to-Point Protocol (PPP) sessions to another router.

The router is designated as an LNS or a LAC, depending on its relationship with the SmartEdge router:

In each context configured on the system, the SmartEdge router can function as a LAC to one or more LNSs, as an LNS to one or more LACs, or as both a LAC and an LNS.

Figure 6 shows a SmartEdge router acting as a LAC: terminating subscriber PPP sessions and tunneling these sessions to a number of L2TP peers that are acting as LNSs.

Figure 6   L2TP Tunnels over UDP/IP

3.8   Bindings

Bindings form the association in the SmartEdge OS between the ports, channels, or circuits and the higher-layer routing protocols configured for a given context. No user data can flow on a port, channel, or circuit until some higher-layer service is configured and associated with it. After a port, channel, or circuit is bound to an interface, traffic flows through the context as it would through any IP router. For more information, see Configuring Bindings.

Bindings are either statically mapped during configuration or dynamically created based on subscriber characteristics as defined in the local database, or on a RADIUS server as described in the following sections.

3.8.1   Static Bindings

With static bindings, a port, channel, or circuit is bound directly to an interface. In this case, the port, channel, or circuit is hard-wired to the higher-layer protocols defined for the interface. Multiple ports, channels, or circuits can be bound to a single interface.

A circuit can also be statically bound to a particular subscriber in a given context. In this case, the binding between the circuit and the higher-layer protocols is determined indirectly, through the subscriber record. In Figure 7, subscriber joe is configured with an IP address that maps to interface if1 in the context local. When the virtual circuit on ATM port 6/1 is bound to subscriber joe, the SmartEdge OS determines the interface that the circuit will be bound to by examining the subscriber information for joe.

3.8.2   Dynamic Bindings

Dynamic binding occurs when a circuit is bound to the higher-layer protocols based on session information. For example, a PPP-encapsulated session can be bound to a particular context and interface by examining the authenticated structured subscriber name in the form sub-name@ctx-name.

The separator character between the sub-name and the ctx-name arguments is configurable and can be any of %, -, @, _, \\, #, and /. The default character is @. For information about configuring the separator character, see Configuring Authentication, Authorization, and Accounting.

Dynamic binding is the key to enabling advanced features, such as dynamic service and provider selection. Dynamic binding also enables simultaneous access to multiple services on a single circuit.

Figure 7 also shows a dynamic binding between the virtual circuit on ATM port 6/2 and interface if5 in context ispgold. When the subscriber initiates a PPP session using the structured subscriber name, mary@ispgold, the SmartEdge OS determines the context (ispgold) for the connection, and selects an interface (if5) to which to bind the circuit. Successful dynamic binding depends on subscriber information for subscriber mary configured in context ispgold, and successful PPP authentication during PPP session establishment. The binding between this circuit and the ispgold context will be removed when the PPP session is terminated. Because the binding on the circuit is dynamic, this same circuit could be used by a different subscriber to select a different service.

Figure 7   Static and Dynamic Bindings

4   User Interface

The primary user interface to the SmartEdge OS is the CLI; for more information about using CLI commands, see Using the CLI and for information about specific commands, see the Command List.

4.1   Command Modes and Prompts

The two major modes are exec and global configuration. When a session is initiated, the CLI is set to the exec mode by default. The exec mode allows you to examine the state of the system and perform most monitoring, troubleshooting, and administration tasks using a subset of the available CLI commands.

Exec mode prompts can be one of the following forms, depending on the user privilege level (see Section 4.3).



In this example, local is the context in which commands are applied and hostname is the currently configured hostname of the router. When you exit exec mode using the exit command, this also ends the CLI session.

Global configuration mode is the top-level configuration mode; all other configuration modes are accessed from this mode. These modes allow you to interactively configure the system through the CLI, or to create and modify a configuration file offline by entering configuration commands using any text editor. After you have saved the file, you can then load it to the operating system at a later time.

To access global configuration mode, enter the configure command (in exec mode).

Configuration mode prompts are of the following form:


In the previous example, local is the context in which commands are applied, hostname is the currently configured hostname of the router, and mode-name is a string indicating the name of the current configuration mode.

The prompt (in global configuration mode), assuming the factory default hostname of Redback and the local context, is as follows:


Each feature supported through the SmartEdge OS can have one or more configuration modes, some of which you access using a command (in global configuration mode). Table 2 lists the configuration modes for the commands described in this document and the commands that you enter to access them.

4.2   Command Mode Hierarchy

Command modes exist in a hierarchy. You must access the higher-level command mode before you can access a lower-level command mode in the same chain. As an example, Figure 8 shows the hierarchy of the command modes used to configure some basic system features.

For the modes required for specific commands, see the command in Command List.

Figure 8   Command Mode Hierarchy for Basic System Commands

Table 2 lists a sample of the command modes (in alphabetical order) for the SmartEdge basic system features. This is not a comprehensive list and is provided only as a sample. For more information about the command modes, see Command List.

Table 2    Basic System Features: Command Modes and System Prompts

Mode Name

Commands Used to Access

Command-Line Prompt


(user logon)

# or >


administrator command from context configuration mode



port atm command from global configuration mode


ATM profile

atm profile command from global configuration mode



bulkstats policy command from context configuration mode



context command from global configuration mode


dot1q profile

dot1q profile command from global configuration mode


Frame Relay profile

frame-relay profile from global configuration mode



configure command from exec mode



interface command from context configuration mode



macro command from global configuration mode



netop command from global configuration mode



port channelized oc-12, port ethernet, and port pos commands from global configuration mode


snmp server

snmp server command from global configuration mode


software license

software license command from global configuration mode



stats-collection command from global configuration mode



port channelized-stm1 command from global configuration mode



subscriber command from context configuration mode


4.3   Privilege Levels

The SmartEdge OS supports 16 different privilege levels for administrators and for commands. By default, administrators are assigned an initial privilege level of 6; administrators can only issue commands that are assigned at the same level as their own privilege level or lower than their privilege level. Each command in the CLI is assigned a default privilege level. At a privilege level of 6 or higher, the prompt in the CLI displays a number sign (#) instead of an angle bracket (>).

There are three types of administrators:

An administrator authenticated to the local context, given appropriate administrator privileges, can configure all functions on the SmartEdge router, including functions for each context and global entities, such as ports, port profiles, SNMP, and so on. Non-local administrators have no configuration mode privileges and have restricted exec mode privileges.

To configure administrator privilege levels, see Configuring Contexts and Interfaces.

Each command has a default privilege level that determines, given the privilege assigned to the administrator, who can enter the command. The majority of commands (in exec mode) have a default privilege level of 3, while commands in any configuration mode have a default privilege level of 10. Exceptions are noted in parentheses ( ) in the Command Mode section in any command description; for example, “exec (15)”.

Command privilege levels are configurable; to change the default privilege level for a command, see Restricting Access to the CLI.

4.4   No and Default Forms of Commands

Many configuration commands support the no keyword. Entering the no keyword in front of a command disables the function or removes the command from the configuration. For example, to create a message that displays after a user logs on to the system, enter the banner exec command (in global configuration mode). To subsequently disable the command from the configuration, enter the no banner exec command (in global configuration mode).

Many configuration commands support the default keyword. Entering the default keyword in front of a command returns a parameter or feature to the default state.

4.5   Operations Commands

Operations commands are characterized as follows:

For more information about specific commands, see the Command List.

Operations commands are described in the following sections.

4.5.1   Monitoring Commands

Monitoring commands allow you to view the state of one or more feature elements. Table 3 lists the types of monitoring commands and examples of each type.

Table 3    Types of Monitoring Commands

Type of Command



Device monitoring

show chassis

show hardware

Displays status of cards installed in the chassis.

Displays detailed card hardware information.

show port perf-monitor

Display configuration and performance statistics for one or more ports.


Feature monitoring

show circuit counters

Displays statistics for one or more circuits.

monitor process

Monitor the status of a process and provide continuous updates. Enter this command in exec mode.


File monitoring



Displays a list of files in the specified directory. Enter this command in exec mode.

Displays the current working directory. Enter this command in exec mode.

Process monitoring

show process

Displays current status of a process. Enter this command in all modes.

Release monitoring

show release

show version

Displays release and installation information. Enter this command in all modes.

Displays the version of the currently running OS. Enter this command in all modes.

Session (administrator) monitoring

show privilege

show public-key

Displays the current privilege level for the current session. Enter this command in all modes.

Displays the public keys for an administrator. Enter this command in all modes.

System monitoring

show clock-source

Displays clock source information. Enter this command in all modes.


show configuration

Displays the configuration commands for a feature. Enter this command in all modes.


show memory

Displays memory statistics. Enter this command in all modes.


show redundancy

Displays state of the standby controller card. Enter this command in all modes.


show system alarm

Displays system alarms at one or more levels. Enter this command in all modes.

4.5.2   Administration Commands

Administration commands allow you to perform routine maintenance. Table 4 lists the types of administration commands that you enter in exec mode and examples of each type.

Table 4    Types of Administration Commands

Type of Command



Device management

mount /md


Mounts a mass-storage device.

Disables a port (stop operations on it).

Feature management

clear circuit counters

Clears circuit counters for one or more circuits. Enter this command in exec mode.

File management



Deletes a file. Enter this command in exec mode.

Create a directory. Enter this command in exec mode.

Process management

process start

process stop

Starts a process. Enter this command in exec mode.

Stop a process. Enter this command in exec mode.

Release management

release upgrade

Installs another release. Enter this command in exec mode.


release erase

Removes a release. Enter this command in exec mode.

Session (administrator) management



Modifies the privilege level for the current session. Enter this command in exec mode.

Establishes an SSH session from the SmartEdge router to a host. Enter this command in exec mode.

System management

bulkstats force transfer

clock set

Immediately transfers the bulkstats data file to the configured receiver. Enter this command in exec mode.

Sets the system time. Enter this command in exec mode.

4.5.3   Troubleshooting, Performance Management, and Problem Recovery Commands

Troubleshooting commands allow you to view information or determine the low-level state of a feature element. Table 5 lists the types of troubleshooting and problem recovery commands, which are run in various modes, and examples of each type.

For more information about troubleshooting and data collection, see the General Troubleshooting Guide, BRAS Troubleshooting Guide, Debugging, and Data Collection Guideline for the SmartEdge Router.

Table 5    Types of Troubleshooting and Problem Recovery Commands

Type of Command



Feature troubleshooting

debug snmp

Initiates internal monitoring of a feature and the generation of messages, which can be stored in the system log buffer or displayed in real time.

Enter this command in exec mode.

System-wide data collection

show tech-support

Collects system-wide information (this macro has a basic form for general troubleshooting which is required to be saved and sent to customer support when logging a customer support request (CSR). It also has optional keywords for collecting data about more focussed problems such as ASE cards and many SmartEdge OS processes.

Enter this command in exec mode.

System troubleshooting or problem recovery


save seos-core

Reloads the operating system. Enter this command in exec mode.

Saves a core dump of the operating system to a pair of files on the mass-storage device /md partition. Enter this command in exec mode.



Tests IP connectivity to a host. Enter this command in exec mode.


format microdrive(1)

Reformats the mass-storage device.


diag on-demand

Initiates on-demand diagnostics for a traffic card.

Enter format microdrive and the diag on-demand commands in exec mode.

Process troubleshooting or problem recovery

process set

Sets process management parameters for a specified process. Enter this command in exec mode.


process coredump

Initiates a core dump of a process, and saves it in a crash file. Enter this command in exec mode.


process restart

Restarts a process that has stopped. Enter this command in exec mode.

(1)  This command is supported only on the SmartEdge 400, 600, 800, 1200, and 1200H routers. Use the format media-device command (in exec mode) on the SmartEdge 100 router.

For more information about these commands, see Command List.   Using Debugging Commands

Use debugging commands to enable the generation of messages that will help in troubleshooting problems.

To store or display debug messages, configure your system as follows:

  1. To store messages in the system log buffer, use the logging debug command (in global configuration mode).
  2. To display the messages, use the show log command (in exec mode).
  3. To display messages in real time when connected through the console port, enter the logging console command (in context configuration mode).
  4. To display them when connected through a Telnet or Secure Shell (SSH) session, use the terminal monitor command (in exec mode).
For more information about logging commands and the terminal monitor command, see Command List.

Risk of performance loss. Enabling the generation of debug messages can severely affect system performance. To reduce the risk, exercise caution when enabling the generation of any debug messages on a production system.

5   IP Services and Security Features

This section describes the SmartEdge OS IP protocols, IP service policies, Quality of Service, and Security.

5.1   IP Protocols

The SmartEdge OS supports the following IP protocols; see Configuring ANCP, Configuring ARPConfiguring DHCP, Configuring ND, and Configuring NTP.

5.1.1   Address Resolution Protocol

The SmartEdge OS implementation of the Address Resolution Protocol (ARP) is consistent with RFC 826, An Ethernet Address Resolution Protocol, also called Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware. In addition, the SmartEdge OS provides a configurable ARP entry-age timer and the option to automatically delete expired dynamic ARP entries.

5.1.2   Neighbor Discovery Protocol

SmartEdge routers use the Neighbor Discovery (ND) protocol for IP Version 6 (IPv6) to determine the link-layer addresses for neighbors known to reside on attached links and to quickly purge cached values that become invalid. The IPv6 ND protocol corresponds to a combination of the IPv4 ARP and Internet Control Message Protocol (ICMP) Router Discovery. The ND protocol is described in RFC 2461, Neighbor Discovery for IP Version 6 (IPv6).

IPv6 is a new version of the Internet Protocol, designed as the successor to IP Version 4 (IPv4). IPv6 is fully described in RFC 2460, Internet Protocol, Version 6 (IPv6) Specification. The changes from IPv4 to IPv6 include:

For a description of IPv6 addressing and the types of IPv6 addresses, see RFC 3513, Internet Protocol Version 6 (IPv6) Addressing Architecture.

When IPv6 addresses are not referenced or explicitly specified, the term, IP address, can refer generally to IPv4 addresses, IPv6 addresses, or IP addressing. In instances where IPv6 addresses are referenced or explicitly specified, the term, IP address, refers only to IPv4 addresses.

5.1.3   Network Time Protocol

The SmartEdge OS supports versions 1, 2, and 3 of the Network Time Protocol (NTP). On the SmartEdge router, NTP operates in client mode only, meaning that the router can be synchronized by a remote NTP server, but the remote server cannot be synchronized by the router.

Before using NTP, the SmartEdge router must first be configured with the IP address of one or multiple NTP servers.

5.1.4   Dynamic Host Configuration Protocol

The SmartEdge router provides three types of Dynamic Host Configuration Protocol (DHCP) support:

5.1.5   ANCP

The Access Node Control Protocol (ANCP) is a communications control protocol that allows the SmartEdge router to communicate with an access node and gather information about the parameters for the individual access lines on the access node.

The ANCP is an out-of-band control protocol that does not interfere with the subscriber sessions that are carried on the access lines. Beneath the ANCP the SmartEdge router uses the General Switch Management Protocol (GSMP) version 3 (GSMPv3) to communicate with the ANCP neighbor peers; GSMPv3 messages are encapsulated using the Transmission Control Protocol (TCP).

5.2   IP Services

The SmartEdge OS provides the IP services described in the following sections.

5.2.1   Domain Name System

The Domain Name System (DNS) enables subscribers to access devices using hostnames, instead of IP addresses. When a command refers to a hostname, the SmartEdge OS consults the local host table for mappings. If the information is not in the table, the router generates a DNS query to resolve the hostname. DNS is enabled on a per-context basis, with one domain name allowed per context.

5.2.2   HTTP Redirect

HTTP redirect enables service providers to interrupt subscriber HTTP sessions and to redirect them to a preconfigured URL. Applications include the ability to require customer registration, to direct customers to web sites for downloading virus protection software, and to advertise new services or software updates. An HTTP redirect profile containing a redirect URL is attached to subscriber records, and a forward policy redirects HTTP traffic to the lightweight HTTP server on the controller card attached to the subscriber circuit. The forward policy that performs the redirection is removed through a subscriber reauthorization mechanism.

5.2.3   Hotlining

Hotlining allows WiMAX operators to redirect subscribers to a portal controlled by a service provider. This portal can be used for service registration, updates, and service advertisements, and to address issues that require immediate attention, such as virus attacks and missed payments. When hotlining is complete, the subscriber is released from the hotlined state (released from the portal) and directed to the original destination.

5.2.4   Mobile IP (Wireless)

Mobile IP services allow the SmartEdge router to act as one or more foreign agents (FAs). Each communicates with its associated home-agent (HA) peers that support the mobile subscribers, which are referred to as mobile nodes (MNs). Each FA has a care-of address (CoA) that the system uses as the termination address for the tunnel to an HA peer.

The MNs connect to the FA through one or more base transceiver stations (BTSs) using Ethernet circuits. MNs can move to different BTSs, depending on their locations.

MNs communicate with the SmartEdge router (the FA) over Ethernet-based circuits, using a context that you configure for the FA. The system routes the MN traffic to each external HA peer using a Generic Routing Encapsulation (GRE) tunnel circuit or an IP-in-IP tunnel. Each HA peer uses a different tunnel. Traffic from an HA peer is routed back to the MNs associated with that HA peer using the same tunnel circuit.

5.2.5   Access Control Lists

The SmartEdge OS supports IP access control lists (ACLs) and policy ACLs as described in the following sections.   IP ACLs

IP ACLs are lists of packet filters. Based on the criteria specified in the IP ACLs associated with the packet, the SmartEdge OS decides whether the packet should be forwarded or dropped. IP ACLs filter packets through the use of deny and permit, or seq deny and seq permit statements. IP ACLs are applied interfaces and contexts and affect packets on all circuits bound to the interface or all administrative packets on a context.   Policy ACLs

Policy ACLs are lists of packet filters, packet classifications, or both. Based on criteria specified in the policy ACLs associated with the packet, the SmartEdge OS decides whether the packet should be forwarded, dropped, or assigned a class name. Policy ACLs filter packets, classify packets, or perform both actions, through the use of permit and seq permit statements. Policy ACLs can be applied to forward policies, to NAT policies, and to quality of service (QoS) metering and policing policies.   Conditional ACLs

You can configure both IP ACLs and policy ACLs with time-based conditions that filter or classify packets for a specified time period. In addition, you can modify time-based conditions in real time, without modifying the configuration file for the SmartEdge OS.   Dynamic ACLs

Dynamic ACLs allow the SmartEdge OS to apply an IP or policy ACL sent from a RADIUS server using vendor-specific attributes (VSAs) 242 and 164 to a circuit or policy.

5.3   IP Service Policies

The SmartEdge OS provides the IP service policies described in the following sections.

5.3.1   Forward Policies

Forward policies support IP traffic mirroring, redirect, and drop. IP traffic mirroring copies packets traveling across a circuit and forwards the duplicated packets to a designated outgoing port. IP traffic redirect forwards IP packets to IP addresses that are different than their original destination. IP traffic drop determines which particular packets should be dropped, rather than forwarded.

5.3.2   Network Address Translation Policies

Through Network Address Translation (NAT) policies, hosts using unregistered IP addresses on private networks can connect to hosts on the Internet and vice versa. NAT translates the private (not globally unique) addresses in the internal network into legal addresses before packets are forwarded onto another network.

5.3.3   Service Policies

Service policies determine the context, or contexts that Point-to-Point Protocol (PPP)- and PPP over Ethernet (PPPoE) subscribers can access by verifying the domain or context name associated with subscriber records.

A service policy can be attached to any PPP- or PPPoE-encapsulated subscriber circuit, including PPP-encapsulated Layer 2 Tunneling Protocol (L2TP) tunnels.

5.4   Quality of Service

The SmartEdge OS provides the following QoS features:

5.4.1   Classification, Marking, and Rate-Limiting

The SmartEdge OS classifies, marks, and rate-limits incoming packets as described in the following sections.   Priority Groups

A priority group number assignment enables you to classify all traffic, including non-IP traffic, on an ingress circuit. A priority group is an internal value used by the SmartEdge router to determine into which egress queue the inbound packet should be placed. The type of service (ToS) value, Differentiated Services Code Point (DSCP) value, and Multiprotocol Label Switching (MPLS) experimental (EXP) bits are not changed by this command. The actual queue depends upon the number of queues configured on the circuit.   Policy ACLs

A classification filter is configured through a policy ACL. Each policy ACL supports up to eight unique classes. Packets can be classified according to IP precedence value, protocol number, IP source and destination address, ICMP attributes, Internet Group Management Protocol (IGMP) attributes, Transmission Control Protocol (TCP) attributes, and User Datagram Protocol (UDP) attributes.

A policy ACL can be applied to incoming or outgoing packets on a port, circuit, or for a subscriber profile. A policy ACL is applied to incoming packets through a QoS policing policy and to outgoing packets through a QoS metering policy.   QoS Policing and Metering Policies

A QoS policing policy marks, rate-limits, or performs both actions on incoming packets, while a QoS metering policy does the same for outgoing packets. Both types of policies can be applied at one of two levels or at both levels simultaneously. One level of application applies to all packets on a particular circuit. Another level of application applies to only a particular class of packets traveling across the circuit. The class is configured through a policy ACL.

5.4.2   Scheduling

After classification, marking, and rate-limiting occurs on an incoming packet, the packet is placed into an output queue for servicing by an egress traffic card’s scheduler. The SmartEdge OS supports up to eight queues per circuit. Queues are serviced according to a queue map scheme, a QoS scheduling policy, or both, as described in the following sections.   Queue Maps

The SmartEdge OS assigns factory preset, or default, mapping of a priority group to a particular egress queue, according to the number of queues configured on a circuit. You can configure queue maps to override the default mapping of packets into egress queues. You can apply queue maps along with any of the four QoS scheduling policies.   Priority Queuing

With a priority queuing (PQ) scheduling policy, the output queues on a circuit are serviced in strict priority order; that is, packets waiting in the highest-priority queue (queue 0) are serviced until that queue is empty, then packets waiting in the second-highest priority queue are serviced (queue 1), and so on. Under congestion, PQ allows the highest priority traffic to get through, at the expense of lower-priority traffic.   Enhanced Deficit Round Robin

The enhanced deficit round-robin (EDRR) scheduling policy can operate in one of three modes: normal, strict, or alternate. In normal mode, queue 0 is treated like all other queues on a circuit. Each queue receives its share of the circuit’s bandwidth according to the weight assigned to the queue. In strict mode, queue 0 always has priority over all other queues configured on a circuit. In alternate mode, in every other round, either queue 0 or one of the other queues on the circuit is served, in alternating fashion.   Modified Deficit Round Robin

Like the EDRR scheduling policy, the modified deficit round-robin (MDRR) scheduling policy can operate in one of three modes: EDRR normal and strict modes and PQ strict priority queuing mode. For the EDRR modes, MDRR supports circuit rate limits; for the PQ strict priority queuing mode, MDRR supports two, four, or eight queues on a circuit.   Asynchronous Transfer Mode Weighted Fair Queuing

The Asynchronous Transfer Mode weighted fair queuing (ATMWFQ) scheduling policy can operate in one of two modes: alternate or strict. In either mode, an MDRR algorithm is used to implement class-based WFQ.

In alternate mode, the servicing of queues alternates between queue 0 and the remaining queues. Queue 0 is served, then the next queue is served. Queue 0 is served again, and the next queue in turn is served, and so on. For example, if there are four queues configured, the order of servicing will be q0, q1, q0, q2, q0, q3, q0, q1, and so on. In strict mode, high-priority queue 0 is serviced immediately and then the other queues are serviced in a round-robin fashion.   Priority Weighted Fair Queuing

Priority weighted fair queuing (PWFQ) policies use a priority- and a weight-based algorithm to implement hierarchical QoS-aware scheduling. Each queue in the policy includes both a priority and a relative weight, which control how each queue is serviced. Inside the PWFQ policy, priority takes precedence, and for queues placed at the same priority, the individual configured weight defines how the queue is used in the scheduling decision.

With PWFQ policies, you can configure different congestion behaviors that depend on the DSCP values of the packets in a queue; this feature is referred to as multidrop precedence. Multidrop precedence supports up to three profiles for each queue, and each profile defines a different congestion behavior for one or more DSCP values.

PWFQ policies are supported only for traffic-managed ports and circuits.   Hierarchical Scheduling

Hierarchical scheduling provides the means to perform QoS scheduling at the port, 802.1Q tunnel, and 802.1Q permanent virtual circuits (PVC) levels, using PWFQ policies. Hierarchical scheduling operates on PWFQ queues in either of two modes: strict or weighted round-robin (WRR). In strict mode, each queue is serviced according to the priority you assigned to the queue. In WRR mode, each queue is serviced in round-robin order according to its priority and its traffic share, as determined by the relative weight.   Hierarchical Nodes and Node Groups

A hierarchical node functions as an individual circuit, such as an 802.1Q PVC; you can assign a traffic rate and attach a PWFQ policy to it. In addition, you can specify the scheduling mode for the queues defined by the PWFQ policy, either strict or WRR.

Each node is a member of a node group. You can assign a traffic rate and a scheduling mode (which might not be the same traffic rate or scheduling mode assigned to any of the nodes within the group) to a node group. When a subscriber record is assigned to a hierarchical node, all sessions for that subscriber are governed by the QoS shaping configured for the node and for the node group.

Hierarchical nodes and node groups are supported only on traffic-managed ports and circuits.   Congestion Management and Avoidance

The SmartEdge OS employs the following congestion avoidance features with scheduling policies:

5.4.3   Flow Admission Control

A flow is a unidirectional object that identifies related data packets and enables you to apply a set of services to a portion of a circuit. Without flows, you could only apply services to entire groups of subscribers mapped to a specified circuit. All attributes on a flow inherit from the services applied to the circuit to which the flow applies.

All attributes applied using flow features reside in a flow admission control (FAC) profile, which is the basic unit of flow configuration. First you create a FAC profile, and then you apply it to an existing circuit from circuit configuration mode.

5.5   SmartEdge Security

The SmartEdge OS provides the following security features.

5.5.1   Authentication, Authorization, and Accounting

The SmartEdge OS uses authentication, authorization, and accounting (AAA) to authenticate subscribers through database records kept in one of these locations:

The first location is the local database, which is a set of subscriber configuration mode commands entered through the SmartEdge OS CLI. The local database provides what is known as local authentication. The second location is the RADIUS server’s database, which contains the subscriber records. The SmartEdge OS, configured with the IP address or hostname of the RADIUS server, relies on the database records of the server to authenticate subscribers.

Each SmartEdge OS context can use the IP address or hostname of a RADIUS configured within its context for authentication—this is known as context-specific RADIUS authentication. Alternatively, a context can be configured to use the IP address or hostname of the RADIUS server in the local context—this is known as global authentication. With global authentication, the RADIUS server is expected to return the Context-Name vendor-specific attribute (VSA) that indicates the particular context to which the subscriber is to be bound. You can also configure the SmartEdge router to try authentication through the RADIUS server configured in the current context first, with a fallback to the global RADIUS server or to the local database, in case the RADIUS server in the current context becomes unreachable.

The SmartEdge OS supports subscriber session reauthorization, so that a subscriber’s attributes can be updated dynamically, without requiring renegotiation for a current subscriber session and without dropping the session. The updates to the subscriber record are made immediately without interruption.

Subscriber accounting tracks RADIUS-based messages for subscriber sessions. The data can be sent to a set of RADIUS servers in the local context, a set of RADIUS servers in another context, or both. This last case is called two-stage accounting, where, for example, a wholesaler can send a copy of accounting data to his own RADIUS server and to an upstream service provider’s RADIUS server, allowing end-of-period accounting data to be reconciled and validated by both parties.

5.5.2   RADIUS

RADIUS is based on a client/server architecture. The SmartEdge OS can be configured to act as a RADIUS client. The use of RADIUS replaces the need for local configuration of user records, although we recommend a local configuration in case the remote server is unreachable.

RADIUS servers are context-specific, with a limit of five servers for each context.

If your network topology requires separate RADIUS accounting servers for billing or load-balancing purposes, you can also configure one or more RADIUS accounting servers, which then take over the accounting functions from the RADIUS servers. The SmartEdge OS can send RADIUS accounting data to a global set of RADIUS servers, a context-specific set of RADIUS servers, or both. This last case is referred to as two-stage accounting.

5.5.3   TACACS+

The Terminal Access Controller Access Control System Plus (TACACS+) protocol secures remote access to networks and network services and is based on a client/server architecture. The SmartEdge router can be configured to act as a TACACS+ client. The use of TACACS+ replaces the need for local configuration of user records, although we recommend a local configuration in case the remote server is unreachable. The SmartEdge OS supports the TACACS+ features of OPIE, S/Key, and secureID.

Before using TACACS+, the SmartEdge router must first be configured with the IP address or hostname of one or multiple TACACS+ servers. TACACS+ servers are configured on a per-context basis, with a limit of six servers per context.

5.5.4   Key Chains

Key chains allow you to control authentication keys used by various routing protocols in the system. Currently, the SmartEdge OS supports the use of key chains with the Open Shortest Path First (OSPF), Intermediate System-to-Intermediate System (IS-IS), and Virtual Router Redundancy Protocol (VRRP) routing protocols. In the configuration process, you establish a name for each key chain, and an identification for each key within the key chain.

6   RFlow Performance Management

The SmartEdge OS provides the RFlow protocol for performance management. You can use this to collect a variety of IP traffic statistics, which are compiled in a record that can help you to understand data traffic in your network and optimize the following:

7   SmartEdge Routing

Network routing moves information across an internetwork from a source to a destination, typically passing through one or more intermediate nodes along the way. The primary difference between routing and bridging is that the two access different levels of information to determine how to transport packets from source to destination—routing occurs at layer 3 (the network layer), while bridging occurs at layer 2 (the link layer) of the Open Systems Interconnection (OSI) reference model.

In addition to transporting packets through an internetwork, routing involves determining optimal paths to a destination. Routing algorithms use metrics, or standards of measurement, to establish these optimal paths, initializing and maintaining routing tables that contain all route information.

The SmartEdge OS routing table stores routes to directly attached devices, static IP routes, and routes learned dynamically from Routing Information Protocol (RIP), Constrained Shortest Path First (CSPF), the Open Shortest Path First (OSPF) protocol, Border Gateway Protocol (BGP), and the Intermediate System-to-Intermediate System (IS-IS) routing protocol. In the routing table, next-hop associations specify that a destination can be reached by sending packets to a next-hop router located on an optimal path to the destination. Routing algorithms must converge rapidly; that is, all routers must agree on optimal routes.

When a network event causes routes either to go down or become unavailable, routers distribute routing update messages that are propagated across networks, causing a universally agreed recalculation of optimal routes. Routing algorithms that converge slowly can cause routing loops or network outages. Many algorithms can quickly select next-best paths and adapt to changes in network topology.

Methods for implementing IP routing, and the supported routing protocols, are described in the following sections.

7.1   Static Versus Dynamic Routing

Static routing involves packet forwarding on the basis of static routes configured by the system administrator. Static routes work well in environments where network traffic is relatively predictable and network topology is relatively simple.

In contrast, dynamic routing algorithms adjust to changing network circumstances by analyzing incoming routing update messages. RIP, OSPF, BGP, and IS-IS all use dynamic routing algorithms. A dynamic routing algorithm can also be supplemented with static routes where appropriate. For example, a router of last resort (to which all unroutable packets are sent) can store information on such packets for troubleshooting purposes.

Some routing algorithms operate in a flat, hierarchy-free space, while others use routing hierarchies. In a flat routing system such as RIP, all routers are peers of all other routers. As networks increase in size, flat routing systems encounter scaling limitations. To address this, some routing protocols allow the administrator to partition the network into hierarchical levels, which facilitates the summary of topology information for anyone located outside the immediate level or area. An example is the OSPF protocol, which supports a two-level hierarchy where area 0 is the backbone area that interconnects all other areas.

7.2   IGPs Versus EGPs

Another group of protocols that works to optimize network performance are the Interior Gateway Protocols (IGPs). These optimize the route between points within a network. Examples of commonly used IGPs are RIP, OSPF, and IS-IS.

Exterior Gateway Protocols (EGPs) support route information exchange between different networks. An example of a commonly used EGP is BGP-4. The choice of an optimal path is made based on the cost of the path measured by metrics associated with each link in the network.

IGPs and EGPs have slightly differing administrative designs. An IGP typically runs in an area under a single administrative control; this area is referred to as an autonomous system (AS) or a routing domain. In contrast, an EGP allows two different autonomous systems to exchange routing information and send data across the AS border. Policy decisions in EGPs can be shaped to decide which routing information crosses the border between the two autonomous systems.

7.3   Basic IP Routing

Basic IP routing includes static IP routing and other basic routing features not covered by any routing protocol, including router IDs, static routes for multicast reverse path forwarding (RPF) lookup, IP Martian addresses, unicast RPF checks, maximum IP routes, and intercontext static routing among non-local contexts. For more information, see Configuring Basic IP Routing.

7.4   Dynamically Verified Static Routing

Dynamically verified static routing (DVSR) is a semidynamic and semistatic routing protocol used mainly for making edge routing decisions.

SmartEdge routers support DVSR as a unique edge routing feature in addition to static routing and regular IGPs, such as IS-IS, OSPF, and RIP. DVSR is similar to normal static routing. The main difference is that the DVSR’s next hop, or some other relevant host IP address, is dynamically verified by this protocol before the prefix can be injected into the local routing table. In many ISP networks, using static routing without proper next-hop checks results in blackholing of network traffic. For more information, see Configuring DVSR.

7.5   Virtual Router Redundancy Protocol

Virtual Router Redundancy Protocol (VRRP) eliminates the single point of failure that is common in the static default routed environment and provides a higher availability default path without requiring the configuration of dynamic routing or router discovery protocols on every end host.

VRRP works by dynamically assigning responsibility for a virtual router to one of the VRRP routers on a LAN. A virtual router is defined by its virtual router ID (VRID) and a set of IP addresses. There are two types of VRRP routers—owner and backup. The VRRP router controlling the IP addresses associated with a virtual router is called the owner, and it forwards packets sent to the IP addresses. Configuring VRRP.

7.6   Routing Information Protocol

RIP is a distance-vector protocol that uses a hop count as its metric. Relatively old, RIP is still commonly used, especially in small homogeneous networks. Our implementation supports RIP Version 2 and provides for multiple RIP instances. Each instance maintains its own routing table and set of interfaces. Each interface can only be assigned to at most one RIP instance. For more information, see Configuring RIP.

7.7   Open Shortest Path First

OSPF is an IGP that uses link-state advertisements (LSAs) to inform other routers of the state of the sender’s links. In a link-state routing protocol, each router distributes information about its interfaces and neighbor relationships. The collection of the link states of individual routers forms a database that describes the AS topology. As OSPF routers accumulate link-state information, they use the Shortest Path First (SPF) algorithm to calculate the shortest path to each node, which forms the basis for developing routing information for that autonomous system. For more information, see Configuring OSPF.

7.8   Bidirectional Forwarding Detection

Bidirectional Forwarding Detection (BFD) is a simple Hello protocol that in many respects is similar to the detection components of some routing protocols. A pair of routers periodically transmit BFD packets over each path between the two routers, and if a system stops receiving BFD packets after a predefined time interval, some component in that particular bidirectional path to the neighboring router is assumed to have failed.

A path is only declared to be operational when two-way communication has been established between systems.

BFD provides low overhead, short-duration detection of failures in the path between adjacent forwarding engines, including the interfaces, data links, and to the extent possible, the forwarding engines themselves.

The legacy Hello mechanism run by routing protocols do not offer detections of less than one second, and for some applications, more than one second is too long and represents a great deal of lost data at gigabit rates. BFD provides the ability to detect communication failures in less than one second.

For more information, see Configuring BFD.

7.9   Border Gateway Protocol

Border Gateway Protocol (BGP) is an EGP based on distance-vector algorithms, and uses the Transmission Control Protocol (TCP) as its transport protocol. BGP is a protocol between exactly two BGP nodes, or BGP speakers. First, the TCP connection is established and then the two BGP speakers exchange dynamic routing information over the connection. The exchange of messages is a BGP session between BGP peers. For more information, see Configuring BGP.

7.10   Border Gateway Protocol/Multiprotocol Label Switching Virtual Private Network

In its most general definition, a Virtual Private Network (VPN) is a network in which customer connectivity among multiple remote sites is deployed across a shared central infrastructure, yet still provides the same access or security as a private network.

More specifically, a Border Gateway Protocol/Multiprotocol Label Switching Virtual Private Network (BGP/MPLS VPN) is a collection of policies, and these policies control connectivity among a set of sites. A customer site is connected to the service provider network, often called a backbone, by one or more ports, where the service provider associates each port with a VPN context.

BGP/MPLS VPN allows you to implement a wide range of policies; for example, within a given VPN, you can allow every site to have a direct route to every other site (full mesh), or you can restrict certain pairs of sites from having direct routes to each other (partial mesh). For more information, see Configuring BGP/MPLS VPN.

7.11   Intermediate System-to-Intermediate System Routing

IS-IS routing is an IGP that uses link-state information to make routing decisions.

IS-IS is defined in ISO 10589, Intermediate System to Intermediate System Intra-Domain Routing Exchange Protocol for Use in Conjunction with the Protocol for Providing the Connectionlessmode Network Service (ISO 8473), ISO DP 10589, February 1990, and RFC 1195, Use of OSI IS-IS for Routing in TCP/IP and Dual Environments. For more information, see Configuring IS-IS.

7.12   IP Multicast

IP multicast communication enables a source host to send IP packets to any number of hosts, anywhere within an IP network; it is one-to-any communication. That is, multicast communication is not limited to sending packets to a single destination host, or sending packets to every host on the network. Instead, multicast enables a source host to send IP packets to as many destination hosts as necessary, but no more than that. The advantages of multicast communication, unlike broadcast communication, which floods the network with unnecessary traffic, is that a source host can communicate with more than one destination host without sending traffic to every host on the network. This results in an economic use of bandwidth.

Configuration of Multicast protocols is described in Configuring IP Multicast .

The main challenge for multicast communication is developing a method for determining which hosts will receive multicast traffic, and which hosts will not receive the traffic. Several different multicast protocols have been developed, each with its own unique approach to addressing the multicast challenge. The SmartEdge OS supports the following multicast protocols:

7.13   Routing Policy

Routing policies allow network administrators to enforce various routing policy decisions onto incoming, outgoing, and redistributed routes. The tools used to configure routing policies include BGP AS path lists, BGP community lists, IP prefix lists, and route maps with match and set conditions. For more information, see Configuring Routing Policies.

7.14   Multiprotocol Label Switching

MPLS is a method for efficiently forwarding packets through a network. MPLS operates across an interface in an MPLS-enabled context.

In a conventional IP network, routers forward packets through the network, from one router to the next, with each router making an independent forwarding decision by analyzing the packet header. This conventional approach to forwarding packets has become insufficient to support current networking demands.

With MPLS, the complete analysis of the packet header is performed only once, when it enters an MPLS-enabled network. At each incoming (ingress) point of the network, packets are assigned a label by an edge LSR. Packets are forwarded along a LSP where each LSR makes forwarding decisions based on the label information. At each hop, the LSR swaps the existing label for a new label that tells the next hop how to forward the packet. At the outgoing (egress) point, an edge LSR removes the label, and forwards the packet to its destination. MPLS uses the Resource Reservation Protocol (RSVP), or the LDP, to communicate labels and their meaning among LSRs. For more information, see Configuring MPLS.

7.15   Layer 2 Virtual Private Network

Layer 2 Virtual Private Networks (L2VPNs) customer edge (CE) routers send L2 traffic to provider edge (PE) routers over L2 circuits configured between the PE and the CE routers. An L2 circuit can be either an Ethernet port, an 802.1Q virtual LAN (VLAN), a Frame Relay permanent virtual circuit (PVC), or an Asynchronous Transfer Mode (ATM) PVC.

An L2VPN is configured on PE routers and is used to cross-connect a local L2 circuit with a corresponding remote L2 circuit through an LSP tunnel that crosses the network backbone. For more information, see Configuring L2VPN.

7.16   Port Pseudowire Connections

MPLS port pseudowires (PWs) provide point-to-point (P2P) connections between pairs of provider edge (PE) routers, enabling you to connect, route, and forward layer 2 (L2) networks to layer 3 (L3) networks. Like physical Ethernet ports in the SmartEdge router, port PWs (containing untagged Ethernet circuits) can be bound to IP interfaces in the local context or a VPN context (one port PW to an interface). You can view and configure SmartEdge OS port PWs in much the same way as physical ports.

Port PW connections are only supported on PPA2 and PPA3 line cards.

In a typical deployment, port PW connections are used to transport fixed IP traffic from the ingress L2PE device to the egress L3PE router. In this deployment, traffic from CPE devices in the broadband access or other network topologies behind the L2PE node is forwarded by the L2PE device (which can be a SmartEdge router) through the port PW to the SmartEdge router (where the port PW is configured), where it is routed and forwarded into the L3 IP/MPLS network and the Internet. For more information, see Configuring Port Pseudowire Connections.

7.17   Label Distribution Protocol

LDP enables dynamic label allocation and distribution in an MPLS network. An LSR enabled with LDP can establish LSPs to other LSRs in the network. LDP creates label bindings by assigning labels to connected routers and by advertising the bindings to neighbors. LDP also assigns labels to label bindings learned from neighbors, and readvertises the binding to other neighbors. When an LSR advertises a label binding for a route, the LSR is advertising the availability of an LSP to the destination of that route. LDP can learn several LSPs from different neighbors for the same route. In this case, LDP activates only the path selected by the underlying IGP. For this reason, LDP must work together with an IGP, such as the IS-IS or OSPF protocol. For more information, see Configuring LDP.

7.18   Virtual Private LAN Services

VPLS enables networks at separate geographical locations to communicate with each other across a wide area network (WAN) as if they were directly attached to each other in a LAN. The WAN becomes transparent, which is achieved by creating VPLS pseudowires.

A pseudowire is a mechanism that emulates the attributes and function of Ethernet connectivity over a WAN. Any required switching functionality or service translation is outside the scope of the pseudowire and of the transport network. Pseudowires are carried over MPLS tunnels on the network. For more information, see Configuring VPLS.

MPLS signaling protocols are used to automatically provision a service on a pseudowire end-to-end, so you can provision a pseudowire by pointing to its two endpoints, and MPLS automatically negotiates the path.

7.19   Protocol Distances

When determining a single optimal route among multiple routes within a single routing protocol, the SmartEdge OS selects the route that has the shortest distance. When deciding a best path among routes originating from multiple protocols, the system uses a more complex methodology. The SmartEdge routing table stores direct, static, external BGP (eBGP), OSPF, IS-IS, RIP, and internal BGP (iBGP) routes.

Table 6 lists the protocols and their default values for routes learned through various protocols.

Table 6    Protocol Distance Defaults


Distance Value

Directly connected


Static IP












8   What’s Next?

You can interactively configure the SmartEdge router through the CLI. You can also configure the SmartEdge router using a text editor to create a configuration file and then loading that file on to the router.

The SmartEdge OS configuration process is transaction-based and supports atomic transactions, including commits and aborts, against the configuration database. Sequences of commands can be entered and validated before being applied, and automated provisioning systems can be interfaced to the SmartEdge for flow-through provisioning and scheduled command execution.

You can also use the NetOp™ Element Management System to configure the SmartEdge router and NetOp Policy Manager to dynamically manage subscriber profiles.


authentication, authorization, and accounting
access control list
Access Node Control Protocol
Automatic Protection Switching
Address Resolution Protocol
autonomous system
Asynchronous Transfer Mode
Asynchronous Transfer Mode weighted fair queuing
Bidirectional Forwarding Detection
Border Gateway Protocol
base transceiver session
customer edge
care-of address
Constrained Shortest Path First
Dynamic Host Configuration Protocol
Domain Name System
Differentiated Services Code Point
dynamically verified static routing
external BGP
enhanced deficit round-robin
Exterior Gateway Protocols
foreign agent
flow admission control
Forwarding Information Base
Generic Routing Encapsulation
General Switch Management Protocol
(GSMP) version 3
home agent
internal BGP
Internet Control Message Protocol
Internet Group Management Protocol
Interior Gateway Protocols
Internet Protocol
IP over Ethernet
IP, Version 4
IP, Version 6
Intermediate System-to-Intermediate System
Interface and Circuit State Manager
Label Distribution Protocol
Layer 2 Tunneling Protocol
Layer 2 Virtual Private Networks
link-state advertisements
modified deficit round-robin
mobile node
Multiprotocol Label Switching
maximum transmission unit
Network Address Translation
Neighbor Discovery
Network Time Protocol
Open Systems Interconnection
Open Shortest Path First
provider edge
Process Manager
Packet Processing ASICs
Point-to-Point Protocol
PPP over Ethernet
priority queuing
permanent virtual circuits
priority weighted fair queuing
quality of service
Remote Authentication Dial-In User Service
Router Configuration Manager
random early detection
Routing Information Bases
Routing Information Protocol
reverse path forwarding
Rapid Spanning Tree Protocol
Reservation Protocol
Shortest Path First
Secure Shell
Terminal Access Controller Access Control System Plus
Transmission Control Protocol
type of service
User Datagram Protocol
Virtual Private Network
virtual router ID
Virtual Router Redundancy Protocol
vendor-specific attribute
wide area network
weighted round-robin