SSR System Description
DESCRIPTION
1/221 02-CRA 119 1364/1-V2 Uen D Copyright
© Ericsson AB 2011–2013. All rights reserved. No part of this document may be reproduced in any form without the written permission of the copyright owner.
Disclaimer
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
NetOp NetOp is a trademark of Telefonaktiebolaget LM Ericsson.
1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 Contents
Contents
1 Overview 1 1.1 Scope 1 1.2 Audience 2
2 Introduction 2
3 SSR Use Cases 3 3.1 Layer 2 Solutions 3 3.2 Layer 3 Solutions 4 3.3 BNG Solutions 7 3.4 SSR in Other Ericsson Solutions 8 3.5 Multi-Service Edge Routing Solution 10
4 System Architecture 11 4.1 Hardware Architecture 11 4.2 Software Architecture 16 4.3 Forwarding 28
5 Features 30 5.1 Synchronous Ethernet 30 5.2 Layer 2 Features 31 5.3 Tunnels 32 5.4 Routing 33 5.5 BNG Features 38 5.6 IP Protocol Support 39 5.7 IP Services 41 5.8 SSC Services 42 5.9 Quality of Service 43 5.10 Connectivity Fault Management (CFM) 45 5.11 System Redundancy and Synchronization (High Availability) 46
6 User Interface 48 6.1 Using the SSR CLI 48
7 Administration 51
1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 SSR System Description
7.1 Managing Security 51 7.2 Managing Performance 54 7.3 Monitoring and Reporting Tools 55
Glossary 59
Reference List 63
1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 Overview
1 Overview
This document describes the Ericsson SSR 8000 family and its usage, services, and architecture.
1.1 Scope
This description covers the logical and functional aspects of the product, and it includes a brief overview of the hardware architecture. For more information, see the following documents:
SSR 8000 Routers
• Hardware Overview for the SSR 8010
• Hardware Overview for the SSR 8020
Interface Cards
• 10-Port 10 Gigabit Ethernet Card (10 X 10 Gigabit Ethernet (GE) line card)
• 40-Port Gigabit Ethernet Card (4 X 1GE line card)
• 1-Port 100 Gigabit Ethernet or 2-Port 40 Gigabit Ethernet Card (1 X 100GE or 2 X 40GE line card)
• 4-Port 10 Gigabit Ethernet, or 20-Port Gigabit Ethernet and 2-Port 10 Gigabit Ethernet Card (2 X 10GE or 4 X 10GE and 20 X 1GE card for Broadband Network Gateway (BNG) and Multi-service Edge Routing (MSER) services
Controller Cards
• RPSW (Controller) Card
• ALSW (Alarm) Card
• SW (Switch) Card
Service Cards
• Smart Services Card (SSC)
Other Components
• SSR 8000 Power Entry Modules
• SSR 8000 Fan Trays
1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 1 SSR System Description
1.2 Audience
This document provides an introduction to the SSR platform, including its architecture and SSR concepts, to anyone who is unfamiliar with the product.
2 Introduction
The SSR combines multiple functions into a single platform that provides Layer 3 (IP) routing, Layer 2 (Ethernet) network aggregation, and BNG services, as well as advanced services for applications. The SSR provides carrier-class reliability, scalability, performance, and an optimal power footprint. It also provides a flexible and high-performance platform for Ericsson applications, such as Evolved Packet Gateway (EPG).
The SSR platform supports the following functions:
• Comprehensive range of interior and exterior gateway routing protocols and multicast routing.
• Peering, edge aggregation, and core route reflection.
• End-to-end Ethernet transport services with direct connection to the access layer of the network.
• Advanced traffic management with Hierarchical Quality of Service (H-QoS) and comprehensive traffic shaping.
• Direct connection to the access layer of the network, which eliminates unnecessary network layers and reduces complexity.
• Support for up to 748,000 subscribers per physical device and all methods of subscriber encapsulation for Dynamic Host Configuration Protocol (DHCP) or IP access clients, including Point-to-Point Protocol (PPP) over Ethernet (PPPoE).
The SSR in combination with other Ericsson products provides a complete end-to-end solution for the following:
• BNG—Layer 2 and Layer 3
• EPG—Layer 3
• IP Radio Access Network (IP RAN)—Layer 3
• Mobile Backhaul (MBH)—Layer 2 and Layer 3
2 1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 SSR Use Cases
• Mobile Packet Backbone Network (MPBN)—Layer 2 and Layer 3
For a description of these solutions, including diagrams and the configuration requirements, see Layer 2 Solutions, Layer 3 Solutions, BNG Solutions, and SSR Router in Other Ericsson Solutions.
Figure 1 illustrates the possible combinations and shows how other Ericsson solutions fit with the SSR platform.
Figure 1 Possible Service Combinations
3 SSR Use Cases
3.1 Layer 2 Solutions
You can use the SSR platform to provide services for Ethernet traffic. For example:
• Layer 2 Virtual Private Networks (L2VPNs) based on Virtual Private Wire Service (VPWS)—Provides end-to-end Layer 2 cross-connected circuits over IP/Multiprotocol Label Switching (MPLS) core networks
• Ethernet to Ethernet Layer 2 cross-connects (XCs)
1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 3 SSR System Description
• XC VPWS-based transport, including tagged and untagged frames as part of the VPWS (does not support medium access control (MAC) learning)
• Link aggregation groups (LAGs) provide increased bandwidth and availability. The SSR supports up to 800 802.1AX link groups, with 8 ports per link group.
• Multichassis LAGs (MC-LAGs) provide node-level redundancy on top of the link-level redundancy provided by a regular link group. In an MC-LAG configuration, identical link groups are configured on separate nodes. The Ericsson SSR platform supports two nodes, and therefore two link groups, in an MC-LAG cluster.
• Mirror policies allow an operator to create a copy of all the traffic entering or leaving a specified physical port to troubleshoot network problems.
Figure 2 illustrates the SSR 8000 in a Layer 2 network.
Figure 2 SSR in a Layer 2 Network
Table 1 lists the features that you can configure for Layer 2 solutions.
Table 1 Layer 2 Solution Features
Business Application Layer 2 Transport Routing and Label Distribution Services Method Options L2VPN (Business VPN) L2VPN VPWS LDP or RSVP VPN pseudowire VPWS IS-IS or OSPF QoS Propagation L2VPN (Business VPN) Layer 2 XC Ethernet-to-Ethernet Local XC QoS Propagation XC
3.2 Layer 3 Solutions
The SSR can provide Layer 3 Virtual Private Network (L3VPN) services and IPv4 and IPv6 routing and transport services.
4 1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 SSR Use Cases
3.2.1 L3VPNs
The router can provide the following Layer 3 services:
• End-to-end Layer 3 connection over an IP/MPLS core network
• Business VPNs, such as Border Gateway Protocol (BGP)/MPLS Layer 3 VPNs, IP Security (IPsec) VPNs, or Generic Routing Encapsulation (GRE) VPNs
• Multicast routing supporting broadcast TV and video-on-demand solutions
• Core routing solutions, such as P router and route reflector, in an IP/MPLS core network
• BNG with Layer 3 VPN services, such as remote business VPNs and wholesale service offerings (requires at least one 4-port 10GE or 20-port Gigabit Ethernet and 2-port 10GE card)
Figure 3 illustrates the router in a Layer 3 network with VPNs.
Figure 3 L3VPNs
Table 2 lists the features that you can configure for Layer 3 solutions.
1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 5 SSR System Description
Table 2 Configurable Features for Layer 3 Solutions
Business Circuit Options Routing Options Services Application Integrated PTA One of the following combinations: QoS BNG/L3VPN L2TP BGP, MPLS, LDP, ISIS Filter and Policy ACLs CLIPS BGP, MPLS, LDP, OSPF CE-PE Routing Options DHCP BGP, MPLS, RSVP, ISIS Route Filters Static Circuits BGP, MPLS, RSVP, OSPF BGP, MPLS, LDP over 1-hop RSVP, ISIS BGP, MPLS, LDP over 1-hop RSVP, OSPF L3VPN CLIPS Static routes or an IGP or eBPG for CE QoS to PE connectivity DHCP Filter and Policy ACLs Combinations of the following: Static circuits CE-PE Routing options BGP Route filters MPLS LDP or RSVP IS-IS or OSPF Mobile applications, Static circuits Combinations of the following: QoS such as MPBN BGP Filter and Policy ACLs MPLS LDP or RSVP IS-IS or OSPF Layer 3 PE Router Static circuits CE-PE routing options: QoS Static Filter and Policy ACLs OSPF or IS-IS Route Filters eBGP IPSec RIP GRE Core routing options: LAG or ECMP BGP Multicast MPLS LDP or RSVP IS-IS or OSPF Layer 3 P Router Not applicable Core routing options: Route Reflector BGP LAG or ECMP MPLS LDP or RSVP IS-IS or OSPF
6 1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 SSR Use Cases
3.3 BNG Solutions
The router can provide the following BNG services:
• Broadband Remote Access Server
PTA: PPP Terminated Access
PPP (over Ethernet)
• Layer 2 Tunneling Protocol (L2TP) terminated access
L2TP L2TP Access Concentrator (LAC)
L2tp Network Server (LNS)
L2TP Tunnel Switch (LTS)
• DHCP PTA
DHCP
Clientless IP Service Selection (CLIPS)
• Triple-Play service model
Broadcast TV, video-on-demand, Voice Over IP (VoIP), high speed Internet
• Dedicated Virtual LAN (VLAN) per subscriber – Service-based VLANs
Figure 4 illustrates a router in a network providing BNG services.
Figure 4 Router in a Network Providing BNG Services
Table 3 lists the features that can be configured for BNG solutions.
1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 7 SSR System Description
Table 3 Features Configured for BNG Solutions
Business Access Technology Transport Options Services Application PTA PPPoE Single and double VLANs, ACL CCOD, link groups QoS HTTP Redirect LI VoIP Multicast applications NAT Flow services L2TP LAC Single and double VLANs, ACL CCOD, link groups, ATM PVC, ATM APS QoS LTS Routed IP, ECMP IP, link groups, HTTP Redirect MPLS LI LNS Routed IP, ECMP IP, link groups, MPLS VoIP Multicast applications NAT Flow services CLIPS Static CLIPS Single and double VLANs, link ACL groups, ATM PVC, ATM APS QoS Dynamic CLIPS Single and double VLANs, CCOD, link groups, ATM PVC, HTTP Redirect ATM APS, LI VoIP Multicast applications NAT Flow services DHCP DHCP server Single and double VLANs, ACL CCOD, link groups, ATM PVC, ATM APS QoS DHCP relay Single and double VLANs, HTTP Redirect CCOD, link groups, ATM PVC, ATM APS LI DHCP proxy Single and double VLANs, VoIP CCOD, link groups, ATM PVC, Multicast applications ATM APS NAT Flow services Static IPoE Single and double VLANs
3.4 SSR in Other Ericsson Solutions
You can also use the SSR platform in other Ericsson solutions, such as EPG, IP RAN, MBH, or MPBN.
8 1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 SSR Use Cases
Figure 5 illustrates the router in a topology using other solutions.
Figure 5 SSR with Other Solutions
Table 4 lists the features that you can configure to use with other solutions.
Table 4 Configurable Features for Use with Other Ericsson Solutions
Business Application Access or Transport Routing Options Service Options or Features Technologies SSR as EPG Access types: Static QoS Direct Ethernet IS-IS or OSPF Filter and Policy ACLs Ethernet 802.1Q BGP BFD VRRP LAG, MC-LAG, or ECMP IPsec SSR in IP RAN Solution Access types: Static QoS Direct Ethernet IS-IS or OSPF Filter and Policy ACLs Ethernet 802.1Q BGP BFD MPLS VRRP LDP or RSVP LAG, MC-LAG, or ECMP IPsec MPLS Fast Reroute
1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 9 SSR System Description
Table 4 Configurable Features for Use with Other Ericsson Solutions
Business Application Access or Transport Routing Options Service Options or Features Technologies SSR in MBH Solution Access types: Static QoS Direct Ethernet IS-IS or OSPF Filter and Policy ACLs Ethernet 802.1Q BGP BFD Transport Technology: MPLS CFM VPWS LDP or RSVP VRRP XC VPWS LAG, MC-LAG, or ECMP MPLS Fast Reroute SSR in MPBN Solution Access types: Static L3VPN (CE-PE) Direct Ethernet IS-IS or OSPF Inter-AS VPN Ethernet 802.1Q BGP QoS Transport Technology: MPLS Filter and Policy ACLs VPWS LDP or RSVP BFD XC VPWS CFM VRRP LAG, MC-LAG, or ECMP MPLS Fast Reroute
3.5 Multi-Service Edge Routing Solution
An MSER solution (see Figure 5) eliminates unnecessary network layers and reduces complexity of the network. As an MSER, the SSR can provide Layer 2 Ethernet transport services, Layer 3 unicast routing and multicast routing, as well as broadcast TV, video-on-demand, and VoIP services simultaneously within the same platform.
With the configured services listed in Table 5, the high-capacity SSR supports mobile and fixed backhaul traffic, with a full range of services. It also supports enterprise VPN connections and end-to-end Layer 3 connection over an IP/MPLS core network.
10 1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 System Architecture
Table 5 Configurable Features for Use with Other Ericsson Solutions
Business Application Access or Transport Routing Options Service Options or Features Technologies Converged Backhaul Access types: Static L3VPN (CE-PE) Direct Ethernet IS-IS or OSPF Inter-AS VPN Ethernet 802.1Q BGP QoS Transport Technology: MPLS Filter and Policy ACLs VPWS LDP or RSVP BFD XC VPWS CFM VRRP LAG, MC-LAG, or ECMP MPLS Fast Reroute Multicast
4 System Architecture
4.1 Hardware Architecture
The Ericsson SSR 8000 platform includes the 8010 and 8020 chassis, a family of carrier-class routers that support packetized traffic. You can use them as edge aggregation routers to directly connect customers to the network. The optimized packet-forwarding capabilities and support of high-bandwidth uplink interfaces, also makes the SSR platform suitable for use in the metropolitan core to aggregate traffic from other routers into the long-haul transit core.
1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 11 SSR System Description
4.1.1 SSR 8010 Chassis
Figure 6 SSR 8010 Chassis Features
The Ericsson SSR 8010 chassis includes the following:
• Chassis 21 rack unit (RU) (31.9 inch) high with ETSI 600 mm (23.6 inch) cabinet compliance.
• Four switch fabric cards, including two route processor controller cards (RPSW) (which package a route processor complex with the switch fabric) and two alarm switch (ALSW) cards (which package an internal switch (for control traffic) with alarm hardware).
The switch fabric is load-shared redundant.
• The chassis has a potential throughput of 4 Tbps (full duplex).
• Ten line card slots for I/O or service cards.
• Two fan trays with six fans per tray.
• Six power modules with rear external cabling, a DC-only power source, and a maximum-rated power of 10.5 kW (5 plus 1 redundancy).
• Space for cable management above and below the card cage.
12 1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 System Architecture
4.1.2 SSR 8020 Chassis
Figure 7 SSR 8020 Chassis Features
The Ericsson SSR 8020 chassis includes the following:
• Chassis 38 RU (57.75 inch) high with ETSI 600 (23.6 inch) mm cabinet compliance.
• Eight switch fabric cards, including two RPSW cards that package a route processor complex with the switch fabric and two ALSW cards that package an internal switch (for control traffic) and alarm hardware. Each ALSW card has 2 external Building Integrated Timing Supply / Standalone Synchronization Equipment (BITS/SASE) ports (BITS A and BITS B) for support of synchronous Ethernet. Two Y-cables (Part Order No. TSR899263/3000), one each for BITS A and BITS B, are required for BITS input and output redundancy.
The switch fabric is load-shared redundant.
• The chassis has a potential throughput of up to 8 Tbps (full duplex).
• Twenty line card slots for I/O or service cards.
• Two fan trays with six fans per tray.
• Eight power modules with rear external cabling, a DC-only power source, and a maximum-rated power of 14.7 kW (7 + 1 redundancy).
• Space for cable management above and below the card cage.
4.1.3 SSR 8000 Line and Service Cards
The SSR platform supports:
1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 13 SSR System Description
• A 40-port GE line card, which allows up to 40 basic Small Form-Factor Pluggable (SFPs) plug-ins.
• A 10-port 10GE line card, which allows up to 10 10-Gbps Form-Factor Pluggable XFP plug-ins.
• A 4-port 10GE or 20-port GE and 2-port 10GE line card, which allows up to 4 10GE XFP plug-ins or 20 SFPs and 2 10GE XFP plug-ins.
• A 1-port 100 GE or 2-port 40GE card, which allows up to one 100GE or two 40GE C-Form Factor Pluggable (CFP) plug-ins.
• A Smart Services Card (SSC), which provides advanced services that are beyond the scope of the terminating and forwarding capabilities provided by the line cards. The SSC is targeted on both control- and user-plane applications.
Unlike a line card, an SSC does not have I/O interfaces that are used for traffic processing. It receives all its traffic from other line cards via the switch fabric. The SSC supports a single application per card and offers complete installation flexibility. It occupies a single slot in the chassis and can be plugged into any usable card.
4.1.4 SSR System Communication
Communications between the redundant RPSW controller cards and line cards are managed through dedicated 10GE control plane switching and the switch fabric.
Figure 8 SSR General System Communication
14 1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 System Architecture
All line cards communicate with all fabric switch cards.
Figure 9 illustrates the switch fabric architecture for the SSR 8010.
Figure 9 SSR 8010 Switch Fabric Architecture
Figure 10 illustrates the switch fabric architecture for the SSR 8020.
1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 15 SSR System Description
Figure 10 SSR 8020 Switch Fabric Architecture
4.2 Software Architecture
4.2.1 Software Components
Figure 11 illustrates the Ericsson IP Operating System major software component relationships.
16 1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 System Architecture
Figure 11 SSR Software Component Interrelationships
4.2.1.1 Contexts
Most networking products are designed so that the entire set of ports, circuits, and protocols operate together as one global router. However, the SSR supports multiple contexts, which act as virtual routers 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. A context does not share its information with other contexts.
Separating the contexts allows you to separate servicesand provide direct access and different classes of services for customers. You use a single physical device, with one or more contexts assigned to each service provider or service class. Implementing this type of topology with equipment from other vendors would require multiple devices.
4.2.1.2 Interfaces
The concept of an interface on the SSR differs from earlier networking devices. In earlier devices, the term interface is often used synonymously with port, channel, or circuit, which are physical entities. In the SSR, 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 and circuits. The decoupling of the interface from the physical layer entities enables many of the advanced features offered by the router.
For the higher layer protocols to become active, an interface must be associated—or bound—to a physical port or circuit. For more information about bindings, see Section 4.2.1.4 on page 18.
4.2.1.3 Ports and Circuits
Ports and circuits in the router represent the physical connectors and paths on the SSR line cards and controller cards. In general telecommunications use, a circuit is a communications path between two or more points. In an SSR, the term circuit refers to the endpoint of a segment of a communications path that terminates on the router.
1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 17 SSR System Description
You configure hardware and software parameters to specify the behavior of the port or circuit for a particular router.
The SSR supports two types of circuits:
• Non-transport Ethernet circuits, which can include 802.1Q permanent virtual circuits (PVCs) (VLANs), static 802.1Q PVCs, and 802.1Q tunnels.
• Layer 2 service instances (SIs), which are subinterfaces of a LAN that accepts one or more Layer 2 (802.1Q) services for transport across local physical ports or a provider backbone network. You can create and configure one or a range of Layer 2 service instances on any Ethernet port, except on the management port on the controller card.
For more information, see Ethernet Ports, Cards, Ethernet Circuits, and Layer 2 Service Instances.
4.2.1.4 Bindings
Bindings associate particular ports or circuits with the higher layer routing protocols configured for a context. No user data can flow on a port or circuit until a higher layer service is configured and associated with it. After a port or circuit is bound to an interface, traffic flows through the context as it would through any IP router.
Bindings are statically mapped. You can bind multiple ports and circuits to a single interface.
For more information, see 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.
4.2.2 Software Processes
Figure 12 illustrates the Ericsson IP Operating System architecture.
This section provides definitions of the SSR processes illustrated.
18 1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 System Architecture
Figure 12 SSR Software Architecture
4.2.2.1 Independent System Processes
Because the major software components act as independent processes, a process can be stopped, restarted, and upgraded without reloading the entire system or individual traffic cards. In addition, if a single component fails or is disrupted, the system continues to operate.
Separating the route processing and control functions from the forwarding function also provides the following benefits.
• Dedicated route processing functions are not affected by heavy traffic.
• Dedicated packet forwarding is not affected by routing instability in the network.
1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 19 SSR System Description
• The architecture enables line-rate forwarding on all traffic cards.
• You can add new features to the control software on the controller without affecting forwarding performance.
• The architecture provides nonstop forwarding during system upgrades or reloads. The traffic cards continue to forward packets.
4.2.2.1.1 Platform Management Processes
SSR major system components run as separate processes. Table 6 lists some examples.
Table 6 Ericsson IP Operating System Processes Module Descriptions Card/Port State Module Processes events for cards and ports, and relays events to other (CSM) processes, such as RCM, ISM, PM, and the kernel. Fabric Manager (fabricd) Configures the switch fabric that connects all line cards and carries all forwarded traffic. Along with the configuration, fabricd continuously monitors the fabric for errors and other abnormal operational conditions and performs fabric reconfiguration when certain errors occur. Flow daemon (Flowd) Provides an infrastructure for enabling and controlling the classification of packets into flows. Interface and Circuit Monitors and disseminates the state of all interfaces, ports, and State Manager (ISM) circuits in the system. Logger Manages logging Platform Administration Monitors and configures platform entities, such as ports and cards. Daemon (PAd) It interacts with components that run on the line cards to ensure that cards are configured properly and brought up and down following configurations, and that ports are activated and monitored for correct operation. Port Encapsulation IP Operating System process that controls port-specific packet Module (PEM) encapsulation used in the forwarding plane. Ping Performs Ping operations on the SSR. Process Manager (PM) Monitors and controls the operation of the other processes in the system. Router Configuration Controls all system configurations using a transaction-oriented Module (RCM) database. Simple Network Performs monitoring and management of network devices. Management Protocol Communicates trap and Inform-Request and manages requests (SNMP) according to the Management Information Bases (MIBs).
20 1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 System Architecture
Table 6 Ericsson IP Operating System Processes Module Descriptions Statistics Manager Maintains counters from line cards and the forwarding plane, (statd) aggregates and processes counters, and allows various applications in the system, including the command-line interface (CLI), to access the counters. System Monitor Manages system event messages. (Sysmon) Traffic Slice Manager Directs traffic from the line cards to SSC cards according to the (TSM) processing required, and egress forwarding path for packets.
4.2.2.2 Layer 2 Processes
4.2.2.2.1 ARP Process
The Address Resolution Protocol (ARP) process manages IP-to-MAC address resolution, as described by RFC 826. IP ARP and XC ARP are supported. ARP entries are stored in a database residing on the control plane. XC ARP is used for cross-connects to manage MAC information for the Layer 2 portions of the bypass connection.
4.2.2.2.2 DOT1Q Process
The dot1q (802.1Q) process manages circuits with 802.1Q single and double-tagged encapsulation. These include explicitly configured circuits and circuit ranges, as well as circuits created on demand. For double-tagged packets, a circuit might correspond to both tags or to just the outer tag (a tunnel).
4.2.2.2.3 LG Process
Link Group daemon (LGd) is responsible for link aggregation and running the Link Aggregation Control Protocol (LACP).
4.2.2.2.4 Tunnel Process
The Tunnel Manager (Tunnel) process implements soft tunnels on the SSR, adding only an encapsulation without a tunnel entry endpoint in the forwarding plane. It handles tunnels according to the next-hop types in the Forwarding Information Base (FIB), including:
For IPv4
• GRE tunnels
• IP-in-IP tunnels
• IPsec or site-to-site tunnels (used with the SSC)
1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 21 SSR System Description
For IPv6
• 6PE tunnels (IPv6 tunnels on the Provider Edge (PE), which allow IPv6 to be tunneled over an MPLS/IPv4-enabled core network)
• 6VPE tunnels (IPv6 VPN tunnels on the PE, which allow IPv6 VPNs to be tunneled over an MPLS/IPv4-enabled core network)
Unlike these tunnels, L2TP tunnel functionality is managed by the L2TP process.
4.2.2.2.5 XC Process
The XC process manages cross-connections. It communicates statically configured cross-connects to the forwarding plane. The packet received on an 802.1Q PVC on ingress is switched to a particular egress circuit. The Layer 2 cross-connect feature enables Layer 2 switching between service instances, which carry the following types of attachment circuits:
• Single tagged 802.1Q PVC
• Double-tagged 802.1Q PVC
4.2.2.3 User Access Processes
User access functions are managed by modules such as:
4.2.2.3.1 AAA Process
The AAA process performs Authentication, Authorization, And Accounting (AAA) of administrators, subscribers, tunnels, and circuits, and performs the following tasks:
• In collaboration with other processes, provisions, manages, and retains subscriber sessions.
• Implements AAA configuration and command processing.
• Handles RADIUS and communicates with RADIUS servers.
4.2.2.3.2 DHCP Process
DHCP passes configuration information to hosts on a Transmission Control Protocol/Internet Protocol (TCP/IP) network. DHCP is based on the Bootstrap Protocol (BOOTP), adding the capability of automatic collection of reusable network addresses and additional configuration options.
The SSR router provides three types of DHCP support:
• External DHCP relay server
22 1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 System Architecture
In relay mode, the router acts as an intermediary between the DHCP server and the subscriber. The router forwards requests from the subscriber’s system to the DHCP server and relays the server’s responses back to the subscriber system.
• External DHCP proxy server
In proxy mode, the router provides responses directly to the subscriber requests. Each subscriber sees the router as the DHCP server and sends all DHCP negotiations, including IP address release and renewal to the router, which then relays the information to the DHCP server.
The proxy feature enables the router to track IP address lease times and other DHCP information more closely. With RADIUS authentication, an accounting record is sent from the router to RADIUS every time an IP address is assigned or released.
• Internal DHCP server
The router provides the functions of the DHCP server; no communications are sent to an external DHCP server.
Note: Before using an external DHCP server, the SSR must first be configured with the IP address or hostname of one or multiple external DHCP servers. DHCP servers are configured on a per-context basis, with a limit of one server per context.
The internal DHCP server is also used for CLIPS, interacting with the CLIPS daemon to appropriately configure the forwarding plane.
4.2.2.3.3 HTTP Redirect Process
The HR process manages HTTP Redirect configuration and enforcement, and tracking of redirected subscriber session details.
4.2.2.3.4 L2TP Process
L2TP process facilitates the tunneling of PPP packets across an intervening network.
4.2.2.3.5 PPP Process
The PPP process manages PPP subscriber sessions, including packet forwarding and handling PPP-related configuration and show commands.
4.2.2.3.6 PPPoE Process
PPPoE transmits PPP traffic over Ethernet connections and learns the Ethernet address of the remote peer, and establishes a unique session identifier for all packets.
1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 23 SSR System Description
4.2.2.3.7 RADIUS Process
The RADIUS process manages configuration of RADIUS attributes, and SSR interactions with RADIUS servers.
4.2.2.4 Feature Processes
4.2.2.4.1 QoS Process
The QoS process provides different priorities to different applications, users, or data flows and enforces forwarding throughput limits in individual data flows and aggregations of flows. It also implements related Resource Reservation Protocol (RSVP) mechanisms and configures forwarding that implements QoS.
4.2.2.4.2 CLS Process
The Classifier (CLS) module manages access control lists (ACLs), including processing ACL-related configurations and generating the information necessary to program the specialized hardware that implements the ACLs in the forwarding plane.
4.2.2.5 Routing Processes
On the SSR, route information is collected from the different routing protocols in the Routing Information Base (RIB) on the RPSW controller card, which calculates the best routes and downloads them to the FIB on the line cards.
Figure 13 Routing Information Flow
24 1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 System Architecture
4.2.2.5.1 RIP and RIPng Processes
The Routing Information Protocol (RIP) process implements RIP Version 2 (RFC 1388) and RIPng (RFC 2080). It also implements RIPv2 over a multibind interface, which is an SSR proprietary feature.
4.2.2.5.2 BGP Process
The BGP process is responsible for installing routes in the RIB, installing Multicast Domain Tree (MDT) routes into Protocol Independent Multicast (PIM), and communicating MPLS labels allocated by BGP to the Label Manager (LM).
4.2.2.5.3 IS-IS Process
The Intermediate System-to-Intermediate System (IS-IS) process performs the IS-IS routing protocol functions, including providing routes to the RIB and handling IS-IS configuration, show, and debug commands. It also responds to events on interfaces where it is running.
4.2.2.5.4 NAT Process
Manages Network Address Translation (NAT) functionality on the SSR.
4.2.2.5.5 OSPF Process
The Open Shortest Path First (OSPF) and OSPFv3 processes perform the OSPF routing protocol functions, including providing routes to the RIB and handling OSPF configuration, show, and debug commands. It also responds to events on interfaces where it is running.
4.2.2.5.6 RIB Process
The RIB process runs on the active controller card. It is a fundamental router process that directly impacts how packets flow in and out of the box. It configures the routing tables in the forwarding plane and connectivity to the management interface. The RIB process collects routes from its clients, selects the best path, and downloads the routes to the FIB of each line card. See Figure 13 for a diagram of RIB-related information flow and some of the modules that it interacts with.
4.2.2.5.7 Staticd Process
The Static daemon (Staticd) supports both interface (connected) and gateway (non-connected) IP and IPv6 static routes that can be configured either through CLI or the NetOp™ Element Management System (EMS). Additionally, configured gateway routes may be verified using the proprietary Dynamically Verified Static Route (DVSR) protocol that periodically pings the specified gateway.
1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 25 SSR System Description
4.2.2.5.8 Multicast Process
The multicast process (Multicast Manager) collects multicast groups and forwarding data from the PIM, Internet Group Management Protocol (IGMP), and Multicast Source Discovery Protocol (MSDP) processes and passes it to the Multicast FIB (MFIB) in the line cards. It also logs multicast events.
Figure 14 Multicast Information Flow
The IGMP process manages IGMPv3, as described in RFC 3376, and IGMPv2, as described in RFC 2236. On SSR interfaces, the process determines which IP multicast groups and, for IGMPv3, which sources have listeners on the network attached to the interface. Collected information is provided to PIM to be advertised to other multicast routers.
The MSDP process manages MSDP as described in RFC 3618, advertising (S,G) entries for groups that use a particular source address from one PIM-SM domain to another.
The PIM process maintains multicast information per group and per interface, which is downloaded to the Multicast Manager for installation on the line cards.
4.2.2.5.9 MPLS Process
The MPLS process enables MPLS forwarding by downloading the Label-Switched Path (LSP) configuration to the Label FIB (LFIB) in the line cards.
26 1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 System Architecture
Figure 15 MPLS Label Information Flow
4.2.2.5.10 LM Process
The Label Manager (LM) process manages label requests and reservations from various MPLS protocols, such as Label Distribution Protocol (LDP) and RSVP, and configures LSPs and PWs in the system. It installs LSPs and Layer 2 routes in the RIB and provisions MPLS-related data structures in the forwarding plane. It also handles MPLS-related configurations and functionality, such as MPLS ping and traceroute. L2VPN functionality is handled in the LM process, including configuration and pseudowire setup.
4.2.2.5.11 LDP Process
The LDP process creates MPLS labels based on OSPF and IS-IS routes. It installs LSPs in the LM and registers labels, routes, and prefixes in the RIB. The Update process sends LDP updates to neighbors.
4.2.2.5.12 RSVP Process
The RSVP process implements RSVP (as described in RFC 3031, RFC 3032, RFC 3209, and RFC 4090), providing LSPs to the LM process. It queries the RIB for outgoing interfaces and next-hop information and registers Bidirectional Forwarding Detection (BFD) sessions in the RIB.
4.2.2.5.13 MPLS-Static Process
The MPLS-Static process manages the static LSP configuration on the router, when serving as an Ingress Label Edge Router (iLER), a Label-Switching Router (LSR), or egress LER (eLER), and communicates the details to the LM process.
1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 27 SSR System Description
4.3 Forwarding
The SSR 8000 line cards have a common forwarding abstraction layer (FABL) that scales the function across different line cards. The FABL is network processor unit (NPU)–independent. It communicates with the control plane processes on the controller card and with an adaptation layer daemon (ALD) on the line-card Local Processor (LP) that contains and isolates network processor–dependent functions. The combination of the FABL and ALD maintain the data structures used by the NPUs to control forwarding. The NPU (also known as the packet forwarding engine (PFE) is responsible for forwarding packets to other line cards, receiving control packets sent to the SSR, sending control packets originated by the SSR, and forwarding data packets out of the SSR.
The line cards and SSC support the following forwarding types:
• Unicast flow—The forwarding process on each line card performs packet processing functions, such as FIB lookup for the longest prefix match with the destination IP address, and QoS classification for fast data traffic and slower control traffic, such as Internet Control Message Protocol (ICMP), Virtual Router Redundancy Protocol (VRRP), or BFD messages.
• Multicast flow—An application multicast group associates each multicast packet with a set of outgoing circuits. Depending on the distribution of the outgoing circuits, the multicast packets are replicated either in the fabric element (FE), egress PFE, or both.
Figure 16 illustrates the common SSR forwarding adaptation layer architecture. This adaptation is uniform across all I/O line cards (40x1GE and 10x10GE, 2x40GE, 1x100GE, 4x10GE, and 2x10GE plus 20x1GE) and SSCs.
28 1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 System Architecture
Figure 16 SSR Forwarding Architecture
The SSR line cards and SSC support the following control information flow types:
• Punt flow—management and control path packets destined to the control processors are punted from the forwarding path to the LP. Punt packets are punted from the PFE to LP memory using the Direct Memory Access (DMA) engine in the PFE over a Peripheral Component Interconnect Express (PCI-E) interface. The packets are received by the platform ALD and passed to processes in the FABL. These processes may in turn send the packets to the controller card using the internal GE network.
• Host-sourced flow—packets sourced from either the LP or the controller card (via the LP) can enter the forwarding plane in the ingress or egress path. Packets transmitted to the PFE follow a similar but reversed path. FABL processes originate or relay packets to the ALD, which directs the packets toward the PFE over the PCI-E interface using DMA.
• Packet slice flow—SSC traffic slice management configures entries in Traffic Slice Forwarding Tables (TSFT) on the line cards to steer packets to SSCs. The line cards forward specific application traffic to SSCs, based on the rules configured by TSFT. The SSC can forward its traffic to either another SSC using hosted next hop or to an egress line card using FIB.
1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 29 SSR System Description
Figure 17 illustrates the punted and host-sourced packet flow from the ingress path to the LP.
Figure 17 SSR Control Packet Path
5 Features
5.1 Synchronous Ethernet
Synchronous Ethernet on the SSR is supported by both hardware and software and is implemented in accordance with ITU-T Recommendation G.781: Synchronization layer functions and several other ITU-T recommendations listed in Synchronous Ethernet. The equipment clock is a Stratum-3E module on the ALSW card; it can be configured as Stratum-3 or Stratum-3E.
The Timing Control Module daemon (TCMd) runs on the active controller card in cold standby mode, which means that the standby process is halted. The control process has no configuration and cannot access the ALSW hardware.
30 1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 Features
In the event of an RPSW switchover from active to standby, the TCMd process on the newly active RPSW is configured and updated with the current state of the input sources. Based on this information, the control process selects the best synchronization input source and begins normal synchronization operation.
5.2 Layer 2 Features
5.2.1 Link Aggregation Groups
The SSR supports Link Aggregation Groups (LAGs) based on the IEEE standard Link Aggregation Group (LAG) 802.1AX. LAG 802.1AX (2008) is the current version of LAG 802.3ad (2000).
A link group can consist of a mix of circuits configured for packet-based hashing, where load balancing is done per flow based on a hash algorithm, or for circuit-based hashing, where load balancing is done at the circuit level. Link groups also support fast failover, as well as the QoS policing, metering, and queueing features. Whereas the QoS configuration for link groups is done at the link-group level (link group configuration mode), policing, metering, and queueing are performed internally per constituent port. The system supports up to 800 802.1AX link groups, with eight ports per link group. Link groups provide increased bandwidth and availability. Load balancing and load distribution over the ports in the link group result in increased bandwidth. In addition, when ports are bundled in a link group, the failure or replacement of one link in the group does not cause the link group to be brought down. Instead, other links accept the traffic of the link that is out of service, with the following process:
• Single-port link group—Migrating services from one slot to another without impacting services by first adding the new constituent port to the link group and removing the old port from the link group.
• Link redundancy—Using a link group with two ports on the same line card to provide link redundancy.
• Additional link capacity—Using a link group with N ports to carry traffic. Ports can be on the same line card or spread across cards.
• Line card redundancy—Spreading a link group with N ports among at least two different line cards to guard against traffic delays resulting from line card failure or link failures.
• Node redundancy—Spreading a link group with N ports across two different chassis to guard against traffic delays resulting from the failure of a node. This configuration is known as a multichassis LAG (MC-LAG).
• Virtual Leased Line (VLL) service instances are supported for link groups on the Layer 2 service side and Layer 2 access circuit side.
• Single-session BFD over IPv4 link groups.
1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 31 SSR System Description
For more information on LAG, see Link Aggregation Groups. For more information on MC-LAG, see Multichassis LAG.
5.2.2 Cross-Connections
Local cross-connections allow you to connect two Layer 2 SIs or range of SIs to each other. You can configure how Layer 2 traffic is forwarded from the SIs on one port of the Ericsson SSR 8000 router to the SIs on another port of the router. For more information, see Local Cross-Connections.
5.2.3 Port Mirroring
The SSR supports port mirroring policies, which allow an operator to create a copy of all ingress or egress traffic for a specified physical port to troubleshoot network problems. Because the ability to mirror traffic to another location represents a potential security risk, port mirroring can only be configured using the highest CLI security privilege level (level 15). A stream of mirrored traffic can only be forwarded to one mirror destination. However, a single mirror destination can receive multiple streams of mirrored traffic. Traffic can be mirrored to a local or a remote destination. For more information, see Mirror Policies.
5.3 Tunnels
The SSR supports the following tunnel types:
• 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. For more information, see IP-in-IP Tunnels.
• GRE Tunnels and VPNs
GRE is a simple, stateless protocol that allows tunneling of IP in GRE. GRE allows you to connect remote sites using private IP addresses over a public network that uses publicly routable IP addresses.
Using GRE tunneling, you can create VPNs to connect to remote sites. Multiple contexts and GRE tunnel circuits, one for each VPN, demultiplex traffic for each VPN into its own IP address space. Each context acts as a dedicated virtual router for a VPN in which the IP address space and routing databases are maintained separately from other contexts.
For more information, see GRE Tunnels.
• L2TP Tunnels
32 1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 Features
L2TP tunnels are User Datagram Protocol (UDP) IP-encapsulated circuits that carry subscriber PPP sessions to another router.
For more information, see L2TP.
The router is designated as an LNS or a LAC, depending on its tunnel function:
As an LNS, the router accepts IP packets from LACs in the network and terminates them.
As a LAC, the router terminates subscriber PPP sessions and tunnels these sessions to a number of LNSs.
In each context configured on the system, the 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.
• IPsec Tunnels
You can implement IPsec VPNs between two gateways. If you are using the IPsec support provided by the SSC-based Security Service, both gateways can select mutually acceptable security protocols and determine the method of implementing the service. An IPsec VPN session sets up the IPsec tunnel and secures the traffic for the duration of the session.
5.4 Routing
The SSR supports standard IP routing that forwards packets to their final destination using intermediate nodes. Each node looks up the destination IP address and forwards the packet toward the destination through routes collected in a routing table.
On the SSR, route information is collected from the different routing protocols in the RIB on the RPSW controller card, which calculates the best routes and downloads them to the FIB stored on the line cards. The RIB process collects routes to directly attached devices, configured static IP routes, and routes learned dynamically from RIP, OSPF, BGP, and IS-IS.
When a network event causes routes to go down or become unavailable, routers distribute routing update messages that are propagated across networks, causing a 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 the network topology. Because the SSR control and forwarding planes are separated, the SSR continues to forward traffic during this process.
5.4.1 Routing Protocol Support
The SSR supports the following routing protocols:
1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 33 SSR System Description
• Basic IP Routing
Basic IP routing on the SSR includes static IP routing, static routes for multicast Reverse Path Forwarding (RPF) lookup, IP Martian addresses, unicast RPF checks, maximum IP routes, and intercontext static routing among nonlocal contexts. For more information, see IP Routing.
• RIP and RIPng
RIP is a distance-vector protocol that uses hop count as its metric. It can be used in small, homogeneous networks. The router supports RIPv2 and provides for multiple RIP instances. Each instance maintains its own routing table and set of interfaces. Each interface can be assigned to only one RIP instance.
RIP Next Generation (RIPng) is an enhanced version of RIP that supports IPv6-based network routing.
For more information, see RIP.
• OSPF and OSPFv3
OSPF is an Interior Gateway Protocol (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 forms a database that describes the autonomous system (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 AS.
The router supports nonstop routing (NSR), which maintains OSPF neighbor relationships and operations in steady state if the active controller card fails and switches over to the standby controller card. Other OSPF routers in the network do not detect the failure of the active controller card, and the OSPF routing domain continues to operate in steady state. All other routing domains are disrupted by the failure. Only non-pseudocircuits and LAGs are supported. IPsec multibind interfaces and other pseudocircuits are not supported.
Note: NSR is not supported on PPA3LP line cards such as the 4-port 10GE, or 20-port GE and 2-port 10GE card.
OSPF Version 3 (OSPFv3) is the version of OSPF that supports IPv6. The fundamental mechanisms of OSPF remain unchanged in OSPFv3; however, because of changes in protocol semantics between IPv4 and IPv6, several changes have been made in OSPFv3.
OSPF Version 3 (OSPFv3) is the version of OSPF that supports IPv6. The fundamental mechanisms of OSPF remain unchanged in OSPFv3; however, because of changes in protocol semantics between IPv4 and IPv6 several changes have been made in OSPFv3.
34 1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 Features
For more information, see OSPF.
• BFD
The router supports RFC 5880, BFD. BFD is a simple Hello protocol that is similar to the detection components of some routing protocols. A pair of routers periodically transmits BFD packets over each path between the two routers. If a system stops receiving BFD packets after a predefined time interval, a component in the bidirectional path to the neighboring router is assumed to have failed. A path is declared to be operational only when two-way communication has been established between the systems. To establish BFD sessions, you must configure one or more BFD clients on the same interface as BFD. BFD clients are Ericsson IP Operating System applications or routing protocols, which use BFD events to detect link failures; for example, BFD clients can be BGP, OSPF, IS-IS, RSVP, PIM, VRRP, and other applications.
For configuration information, see BFD.
• BGP
BGP, an EGP based on distance-vector algorithms, uses Transmission Control Protocol (TCP) as its transport protocol. BGP operates between two BGP nodes, called BGP speakers. After a TCP connection is established, the two BGP speakers exchange dynamic routing information over the connection. The exchange of messages is a BGP session between BGP peers.
The router supports BGP advertisement of the best external route, as speci fied in IETF Internet draft, draft-ietf-idr-best-external-03.txt. When this feature is enabled, the system computes two best paths: the overall best path and the best external path. If the best path is an internal path (received from an internal peer), the speaker is allowed to advertise the best external path to internal peers.
The best external path feature is supported for IPv4 and IPv6 unicast and for IPv4 multicast address families (and configured in VPN contexts using BGP). It is supported for BGP speakers in any role, except confederation AS Border Router (ASBR). The feature is supported on route reflectors only if client-to-client reflection is not in effect—that is, when all clients are fully meshed.
You can also configure the BGP diverse path feature on the router, enabling a BGP speaker to announce the second best path—the diverse path—instead of the best path. Announcing the diverse path as well as the best path enables the client to select the better route. The diverse path feature can also improve network convergence if the best path becomes unreachable. If a router has an alternative path available, it can install the path immediately, without waiting for a BGP speaker to announce the new best path.
1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 35 SSR System Description
In scenarios where the router acts as a pure BGP route reflector to reduce routing table size and CPU load, you can filter which routes get downloaded from BGP to RIB and FIB before being readvertised to peer BGP routers. With this feature enabled, the route reflector does not download routes before readvertising to peer routers, resulting in smaller routing tables in the RIB and FIB and requiring less memory and CPU.
You can also filter route download to RIB for an entire address family or for part of an address family by specifying a prefix list. When a BGP route reflector receives a route advertisement from a peer and the network ID matches the specified address family or prefix list, the network's best path is not downloaded to the RIB before the route reflector readvertises the routes to its peers.
For more information, see BGP.
• IS-IS
IS-IS is an IGP that makes routing decisions based on link-state information. 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. IS-IS supports both IPv4 and IPv6. For more information, see IS-IS.
• Routing Policies
SSR routing policies allow network administrators to enforce various routing policy decisions on 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 Routing Policies.
• 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: Multicast communication is not limited to sending packets to a single destination host or 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. For more information, see IP Multicast .
The main challenge for multicast communication is developing a method for determining which hosts can receive multicast traffic and which cannot. The router supports the following multicast protocols:
IGMP
PIM Sparse Mode (PIM-SM)
MSDP
36 1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 Features
5.4.2 MPLS Networking
The router supports MPLS to efficiently forward packets through a network. On the SSR, 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. Packet processing often causes considerable forwarding delay. With MPLS, the complete analysis of the packet header is performed only once when it enters an MPLS-enabled network. For more information, see MPLS.
5.4.2.1 Label Distribution
To communicate labels and their meanings among LSRs, MPLS uses RSVP or LDP, which enable dynamic label allocation and distribution in an MPLS network.
• With RSVP, you can specify the ingress LSR and the egress LSR, but the next hops are either configured or determined according to labels derived from existing routing protocols. For more information, see MPLS.
• An LSR enabled with LDP can establish LSPs to other LSRs in the network. LDP creates label bindings by assigning labels to connected routes and 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. LDP must be configured with an IGP, such as IS-IS or OSPF. LDP assigns a label only to routes selected by the underlying IGP. For more information, see LDP.
5.4.2.2 MPLS OAM Tools
For MPLS-enabled networks, you can use the LSP ping and traceroute Operations, Administration, And Maintenance (OAM) tools for troubleshooting MPLS LSPs. You can also use LSP traceroute to specify a range of addresses and verify the LDP equal-cost multipath (ECMP) paths at the LER. Over link groups, you can use these tools to verify a single constituent port in a link group at an ingress LSR or transit LSR.
For non-LAG support, MPLS OAM tools include virtual circuit connectivity verification (VCCV) ping support.
5.4.3 MPLS-Based Solutions
The router supports solutions using MPLS networks in which customer connectivity among multiple remote sites is deployed across a shared central infrastructure and still provides the same access or security as a private
1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 37 SSR System Description
network. For example, it supports L2VPNs, Virtual Private Wire Service (VPWS), and L3VPNs in MPLS network topologies.
• VPWS
A VPWS cross-connects the local SI between the local CE and your router to a pseudowire that crosses the MPLS backbone network to the remote PE router. A VPWS is based on L2VPN in which CE routers send Layer 2 traffic to PE routers over Layer 2 circuits, that are configured between the PE and the CE routers.
The router serves as a PE router and supports these Layer 2 circuits: Ethernet port and 802.1Q VLAN.
You can configure the L2VPN on PE routers and use it to cross-connect a local Layer 2 circuit with a corresponding remote Layer 2 circuit through an LSP tunnel that crosses the network backbone. For more information, see VPWS (L2VPN).
• BGP/MPLS VPNs
Layer 3 BGP/MPLS VPNs are a collection of policies that 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. The service provider associates each port with a VPN context.
A BGP/MPLS VPN allows you to implement a wide range of policies. For example, within a 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 BGP/MPLS VPN.
5.5 BNG Features
In the SSR, subscribers are the end-users of BNG services, which include DHCP, CLIPS, L2TP, PPP, and PPPoE models.
Subscriber records are configured as part of a context, either locally on the router or on a RADIUS server. Subscriber records contain the information necessary to bind a subscriber to the correct interface, and 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 Subscribers and the documents in the Subscriber Management folder: Authentication, Authorization, and Accounting, Bindings, CLIPS, PPP and PPPoE, L2TP, RADIUS, and RADIUS Attributes.
The number of active subscribers depends on licensing, 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 in different deployment scenarios.
38 1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 Features
The system supports the following subscriber management services:
• Dynamic service selection dynamically binding the subscriber sessions to services
• Access functions that traditional routers are not designed to provide, such as subscriber management, provisioning, authentication, and accounting
• Routing of subscriber traffic based on Layer 3 addressing
• Translations necessary to convert subscriber traffic to IP, relieving the service provider backbone routers of frame translations that can cause congestion on high-volume routers
• Grooming of individual subscriber data streams into simplified IP flows for routers connecting to the Internet backbone
5.6 IP Protocol Support
The SSR supports the following IP service protocols.
• ARP
The ARP implementation 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 router provides a configurable ARP entry-age timer and the option to automatically delete expired dynamic ARP entries.
For more information, see ARP.
• ND
SSR routers use the Neighbor Discover (ND) protocol for 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 ICMP Router Discovery. The ND protocol is described in RFC 2461, Neighbor Discovery for IP Version 6 (IPv6). IPv4 and IPv6 ND can coexist.
The changes from IPv4 to IPv6 include:
Increase in address size from 32 bits to 128 bits
Simplified header
Extensible header with optional extension headers
Multicast instead of broadcast addresses
For more information about ND on the router, see ND.
1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 39 SSR System Description
• NTP
The router supports versions 1, 2, and 3 of the Network Time Protocol (NTP). On the router, NTP operates only in client mode. A remote NTP server can synchronize the router, but the router cannot synchronize the remote server.
Note: Before using NTP, the router must be configured with the IP address of one or multiple NTP servers.
For more information, see NTP.
• DHCP
The DHCPv4 server dynamically leases IP address information to IPv4 host clients. For IPv4 support, the router provides the following DHCPv4 support.
DHCPv4 relay server
The router acts as an intermediary between an external DHCPv4 server and the client. The router forwards requests from the client to the DHCPv4 server and relays the responses from the server back to the client.
DHCPv4 proxy server
The router provides responses directly to client requests. Each client sees the router as the DHCPv4 server, and as such, sends all DHCPv4 negotiations, including IP address release and renewal, to the router, which then relays the information to the external DHCPv4 server. The proxy feature enables the router to maintain IP address lease timers.
DHCPv4 internal server The router provides the functions of the DHCPv4 server; no communication is sent to an external DHCPv4 server.
For more information, see DHCP.
• VRRP
You can use VRRP to enhance a redundancy solution to eliminate the single point of failure that is common in the default static routed environment. VRRP provides a higher availability default path without requiring dynamic routing or router discovery protocols on every end host.
VRRP provides a default gateway to a LAN. There are two types of VRRP routers—master 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.
VRRP supports hot standby by preserving VRRP instance states during switchovers and process restarts. By preserving the master state, the
40 1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 Features
master VRRP router reduces VRRP service disruptions. Hot standby is not supported on Unified LAG configurations.
For more information, see VRRP.
• ANCP
Access Node Control Protocol (ANCP) is a communications control protocol that allows the 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 router uses the General Switch Management Protocol Version 3 (GSMPv3) to communicate with the ANCP neighbor peers; GSMPv3 messages are encapsulated using TCP.
5.7 IP Services
The SSR supports IP filtering ACLs and policy ACLs (for both IPv4 and IPv6 traffic) that work in collaboration with QoS to manage traffic flow.
ACLs
• IP Filtering ACLs
An IP ACLs is a list of packet filtering rules. Based on the criteria specified in the IP ACL associated with the packet, the router decides whether the packet is forwarded or dropped. IP ACLs filter packets by using deny and permit statements. You can apply IP ACLs to interfaces and contexts to affect packets on all circuits bound to the interface or all administrative packets for a context.
• Policy ACLs
A policy ACL is a list of packet filters or packet classifications, or both. Based on criteria specified in the policy ACLs associated with the packet, the router decides whether the packet is forwarded, dropped, or assigned a class name. Policy ACLs filter packets, classify packets, or both by using permit statements. You can apply a policy ACL to forward, NAT, and QoS metering and policing policies.
Note: The SSR only supports IPv4 administrative ACLs.
For more information about ACLs, see ACLs.
• DNS
Domain Name System (DNS) enables the system to translate IP addresses to host names. When a command refers to a host name, the router consults
1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 41 SSR System Description
the local host table for mappings. If the information is not in the table, the router generates a DNS query to resolve the host name. DNS is enabled on a per-context basis, with one domain name allowed per context.
For more information about DNS on the router, see DNS.
• HTTP Redirect
The HR module enables service providers to interrupt subscriber HTTP sessions and redirect them to a preconfigured URL. Applications can require customer registration, direct customers to web sites to download virus protection software, and 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 redirects is removed through a subscriber reauthorization mechanism.
For more information about HTTP redirect policies, see HTTP Redirect.
5.7.1 IP Forward Policies
The SSR provides policy-based forwarding for IPv4 traffic in the ingress direction. Both circuit-based and class-based forwarding is supported. When you apply a forward policy to a circuit, packets can be dropped, redirected to a next-hop IP address, or redirected to a GRE tunnel. For more information, see Forward Policies.
5.8 SSC Services
The SSC contains Advanced Service Processors (ASPs) that provide additional processing power on an Ericsson SSR 8000 router for services such as the EPG and SSC-based security, which run on these ASPs. The SSC-based security service supports IPsec VPN, which provides support for secure tunnels. You can use the CLI to add an SSC and configure the ASPs, ASP pools, and ASP groups, which distribute the processing capabilities of the ASPs on the SSCs installed in the router, provide load balancing when multiple ASPs are installed, and support resiliency when excess ASPs are available.
When the SSC is deployed, traffic over line cards can also be secured using IPsec VPN applications provided by the security service on the SSC. IPsec secures site-to-site tunnels between two gateways, referred to as peers. You can create IPsec tunnels between two Ericsson SSR 8000 routers or between one managed Ericsson SSR 8000 router and an unmanaged device (referred to as an extranet device), such as customer premises equipment (CPE) or a remote special-purpose server.
For more information, see IPsec VPNs, and Configuring SSC Services.
42 1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 Features
5.9 Quality of Service
The Internet provides only best-effort service, offering no guaranteed packet delivery. The SSR router offers QoS differentiation based on traffic type and application, and supports both IPv4 and IPv6.
5.9.1 Configuring QoS on Circuits
You can attach both metering (ingress) and policing (egress) policies to ports, SIs, link groups, and 802.1Q PVCs (single tag and dual tag circuits). For more information, see Circuits for QoS.
5.9.1.1 QoS Support on Service Instances
The router supports binding QoS services to SIs that are configured under Ethernet ports or link groups. For a link group, and for any Layer 2 service instances under that link group, QoS bindings are applied per constituent.
The following QoS services are supported for service instances on SSR on 40-port GE and 10-port GE cards:
• Policing, inherited policing, and hierarchical policing (hierarchical child) QoS policy bindings on ingress
• Metering, inherited metering, and hierarchical metering (as hierarchical child) QoS policy bindings on egress
• Priority Weighted Fair Queuing (PWFQ) queuing and inherited queuing on egress
• Overhead profile and its inheritance on egress
• QoS priority on ingress
• Propagating priority marking to and from Ethernet using a dot1q profile on ingress or egress
5.9.2 Rate Limiting and Class Limiting
The SSR classifies, marks, and rate-limits incoming packets.
• Policy ACLs
A policy ACL is a list of rules. Each rule refers to a class that is defined in the policy. A policy ACL, unlike an IP ACL, does not define the action for each rule. Instead, the action for each class is determined by the policy to which the policy ACL is applied. All policy ACLs are defined within a context.
A classification filter is configured through a policy ACL. Each policy ACL can support up to eight unique classes. You can classify packets according
1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 43 SSR System Description
to IP precedence value, protocol number, IP source and destination addresses, ICMP attributes, IGMP attributes, TCP and UDP attributes.
You can apply a policy ACL to class-based QoS policies to assign a class to the packets that meet each rule in the policy ACL. The 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 or rate-limits, or performs both actions on incoming packets. A QoS metering policy does the same for outgoing packets. You can apply both types of policies at one of two levels or at both levels simultaneously. One level applies to all packets on a particular circuit. The other level applies to only a particular class of packets traveling across the circuit. You configure the class through a policy ACL.
For more information, see Rate-Limiting and Class-Limiting.
5.9.3 Queueing and Scheduling
After classification, marking, and rate limiting occurs on an incoming packet, the packet enters an output queue for servicing by an egress traffic card’s scheduler.
The SSR supports up to eight queues per circuit. Queues are serviced according to a queue map scheme or QoS scheduling policy, or both.
The SSR uses PWFQ policies for H-QoS scheduling. PWFQ policies support the following features.
• Attachable to Layer 2 and Layer 3 circuits
• One, two, four, or eight queues
• QoS priority marking and queue maps to determine the egress queue
The policy can reference a customized queue map.
• Up to 256 congestion avoidance maps to specify Random Early Detection (RED) parameters
• Scheduling algorithm that is both priority- and weight-based
Each queue in the policy includes both a priority and a relative weight. Together, the priorities and the weights control how the traffic in the queue is handled. Within a PWFQ policy, priority takes precedence. For queues with the same priority, the queues are scheduled proportionally according to their weights. For more information about the PWFQ scheduling algorithm, see Queuing and Scheduling.
• Shaping Using Priority Groups
44 1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 Features
For a group of queues that have the same priority, you can configure an overall rate of traffic that applies to the group as a whole. You can then specify a relative weight (percentage of bandwidth) for each queue within that priority group. For example, if queues 2, 3, and 4 are all set to priority 1, you can limit the total bandwidth for priority 1 traffic to an absolute value (in kbps) or a relative value (percentage of line rate). You can then assign relative weights to the three queues within this priority. For example, you can specify that queue 2 gets 20% of the group’s bandwidth, queue 3 gets 30%, and queue 4 gets 50%.
• Policy Weight
Each policy as a whole has a configurable weight. The policy weights manage how circuits on the same port that use different PWFQ policies share the port bandwidth.
• Policy Dual-Rate Shaping
Each PWFQ policy can use a maximum and minimum rate for traffic shaping. The maximum rate is the highest rate that the policy allows for all queues. The minimum rate is the lowest rate serviced by the policy for all queues. Among policies, higher priority takes precedence over minimum rate.
• Individual Queue Shaping
You can specify a minimum and maximum rate for each individual queue.
For more information, see Queuing and Scheduling.
5.9.4 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 an entire group of subscriber traffic mapped to a separate 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. Create a FAC profile and apply it to an existing circuit in circuit configuration mode.
For more information about flow admission control, see Configuring Flow Admission Control.
5.10 Connectivity Fault Management (CFM)
To enable providers and users to monitor Ethernet connectivity faults and quickly determine their location, the Ericsson SSR 8000 supports IEEE standard 802.1ag-2007 (Amendment to IEEE Standard 802.1Q-2005) IEEE
1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 45 SSR System Description
Standard for Local and metropolitan area networks - Virtual Bridged Local Area Networks Amendment 5: Connectivity Fault Management. Connectivity Fault Management (CFM) is the type of Ethernet OAM implemented by the router.
The CFM implementation provides service management of the Ethernet and Ethernet emulating interfaces of the router, allowing service providers and end users to individually manage their Ethernet service instances. The mechanisms that the router uses to monitor customer instances for Ethernet faults are based on IEEE P802.1ag protocol data unit (PDU) messages.
For more information, see Ethernet CFM.
5.11 System Redundancy and Synchronization (High Availability)
The router supports dual controller cards. One controller card serves as the active controller, and the other is its hot standby. Controller cards are not involved in ingress-to-egress traffic forwarding, and each line card maintains its own FIB to make routing decisions. For these reasons, when a controller card is temporarily unavailable, such as during switchover, traffic continues to be forwarded.
5.11.1 Synchronization
Both controller cards contain internal file systems that store the operating system image, its associated files, and the configuration database. A synchronization process ensures that the standby controller card is always ready to become the active controller card. The configuration databases of the active and standby controller cards are always synchronized.
When the software release or firmware on the active controller card is upgraded, the standby controller card automatically synchronizes its software or firmware version with the active controller. If a user modifies the contents of the compact-flash card (for example, by saving a configuration to a file, copying a file, or deleting a file), the change is propagated to the compact-flash card of the standby controller.
To guard against system inconsistency, the synchronization process is protected during system load and controller card reload. While the synchronization is in progress, a switchover from the active to the standby controller card is not allowed. If the active card fails during synchronization, the standby controller card does not become active. If you try to force a switchover during this synchronization period, the system warns that the standby is not ready. However, during a normal running state, a switchover can occur at any time, and the standby controller card has the data required to take the active role.
The synchronization process is not affected by traffic card installation and removal. The active controller card continues to forward control traffic and
46 1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 Features
detect and notify the administrator of any faults that occur while the standby controller card is being synchronized (the FAIL LED is blinking).
After the synchronization is complete, the standby controller is ready to become the active controller card if the active card fails.
For more information, see Managing Files.
5.11.2 Redundancy
The router also provides the following hardware redundancy features:
• N plus 1 power modules
• Redundant ALSW cards
Stratum 3/3E Module Redundancy
BITS Redundancy
• Redundant switch fabric to which all line cards connect
• Redundant fan trays
• Redundant SSCs
The router supports the following software redundancy features:
• Link resiliency in Layer 2 topologies using LAG, MC-LAG, or VPWS pseudowire redundancy. For more information, see Link Aggregation Groups, Configuring Multichassis LAG LAG, and VPWS (L2VPN).
• MPLS route redundancy using LDP. See MPLS.
• Multipaths in networks using BGP route advertisement.
• Inter-Chassis Redundancy (ICR) using VRRP. See Inter-Chassis Redundancy
• Inter-chassis redundancy for PPPoE, CLIPS, and DHCP subsessions (with PPA23LP-based line cards)
The router also supports the following service monitoring and fast-failover functions:
• VRRP
• Single-Session BFD
• Ethernet CFM
1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 47 SSR System Description
6 User Interface
The router provides the following interfaces to access, manage, and configure the system, as well as access node state information.
• CLI, referred to as the SSR exec CLI
• The NetOp EMS interface (see Communications with the NetOp EMS)
• SNMP (see RMON and SNMP)
6.1 Using the SSR CLI
You can access the SSR CLI in the following ways.
• Ethernet management port connection to a local management workstation
Requires a PC-type workstation running DOS, Windows, or Linux using a Telnet or Secure Shell (SSH) session. Requires a shielded Ethernet crossover cable for a local workstation.
• Ethernet management port connection to a remote management workstation
Requires a PC-type workstation running DOS, Windows, or Linux using a Telnet or SSH session. Requires a shielded Ethernet straight cable (shipped with the system) or a router or bridge.
• Console port connection to a remote console terminal
Requires either an ASCII or VT100 console terminal or equivalent that runs at 9600 baud, 8 data bits, no parity, 1 stop bit, or a PC-type workstation running DOS, Windows, or Linux with a terminal emulator in the same configuration as the ASCII or VT100 terminal.
It is advisable to have two access methods available, such as a remote workstation connected to the Ethernet management port and a console port connection with connection to a terminal server. (A console cable is shipped with the system.) Many administrative tasks are performed with the CLI through a terminal server, because some processes, such as reloading or upgrading the software, interrupt an Ethernet management port connection.
6.1.1 Command Modes and Prompts
In the SSR CLI, the two primary modes are exec and global configuration. When a session is initiated, the CLI is set to exec mode. Exec mode allows
48 1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 User Interface
you to examine the state of the system and perform most monitoring, troubleshooting, and administrative tasks.
The exec mode prompt can be one of the following, depending on the user privilege level (see Section 6.1.3 on page 50).
[local]hostname#
[local]hostname>
In this example, local is the context in which commands are applied, and hostname is the configured host name of the router. When you exit exec mode using the exit command, the entire CLI session ends.
Global configuration mode is the top-level configuration mode. All other configuration modes are accessed from this mode. The configuration modes allow you to interactively configure the system through the CLI or create and modify a configuration file offline by entering configuration commands using a text editor. After you have saved the file, you can then load it to the operating system.
To access global configuration mode, enter the configure command in exec mode.
Configuration mode prompts are of the following form:
[local]hostname(mode-name)#
In the example, local is the context in which commands are applied, hostname is the configured host name 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 host name of Ericsson and the local context, is:
[local]Ericsson(config)#
Each feature supported in the CLI can have one or more configuration modes. You access some of the modes using a command from global configuration mode. Table 7 lists some of the configuration modes for basic system features and the command used to access the mode.
6.1.2 Command Mode Hierarchy
Command modes have a hierarchy. You must access the higher level mode before you can access a lower level mode in the hierarchy.
Table 7 lists a sample of the command modes for some basic system features. For the modes required for specific commands, see the command in the Command List.
1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 49 SSR System Description
Table 7 Basic System Features: Command Modes and System Prompts Mode Name Commands Used to Access Command-Line Prompt exec user logon #or> administrator administrator command (config-administrator)# from context configuration mode bulkstats bulkstats policy command (config-bulkstats)# from context configuration mode context context command from global (config-ctx)# configuration mode dot1q profile dot1q profile command (config-dot1q-profile)# from global configuration mode global configure command from (config)# exec mode interface interface command from (config-if)# context configuration mode port port ethernet command (config-port)# from global configuration mode port synchronous synchronous-mode command (config-port-sync)# from port configuration mode synchronization synchronization command (config-synchronization)# from global configuration mode BITS input bits input bits-a or bits (config-bits-input)# input bits-b command from synchronization configuration mode BITS output bits output bits-a or (config-bits-output)# bits output bits-b command from synchronization configuration mode equipment clock equipment-clock command (config-equip-clock)# from synchronization configuration mode input source input-source command from (config-input-src)# equipment clock configuration mode
For more information about using CLI commands, see Using the CLI.
6.1.3 Privilege Levels for Commands and Administrators
The SSR supports 16 privilege levels for administrators and commands. Each command in the CLI is assigned a default privilege level. Administrators are
50 1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 Administration
assigned an initial privilege level of 6. Administrators can issue commands that have the same level or below their own privilege level. If the privilege level is 6 or higher, the CLI prompt is # instead of >.
There are two types of administrators:
• Local—An administrator authenticated to the local context. The local administrator has a structured administrator name in the form admin-name@local. A local administrator with appropriate administrator privileges can configure all functions on the router, including those for each context and global entities, such as ports, port profiles, and SNMP.
• Nonlocal—An administrator authenticated to any context other than the local context. An example of a nonlocal administrator that has a administrator name in the form admin-name@ctx-name is joe@vpn1, where vpn1 is the name of the context. Nonlocal administrators have no configuration mode privileges and have restricted exec mode privileges.
The administrator assigns privilege levels to users. If no level is assigned, the default is 6. Users can access any command at or below their assigned privilege level.
Each command has a default privilege level that determines who can enter the command. The majority of commands in exec mode have a default privilege level of 3. Commands in any configuration mode have a default privilege level of 10. Commands that are performed only by administrators who can do anything have a privilege level of 15. Privilege exceptions are noted in parentheses in the Command Mode section of a 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.
7 Administration
The router has many features for managing security and performance, monitoring and reporting on status, and troubleshooting the system.
7.1 Managing Security
The SSR provides forwarding and advanced Layer 2 to Layer 7 services to carriers around the world. With the rapid expansion of the Internet—connected devices, bandwidth, and multimedia (data, voice, and video)—security has become an important aspect of handling Internet traffic. An SSR router deployed at the edge of the network is directly exposed to various types of
1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 51 SSR System Description
security attacks. The comprehensive security features of the Ericsson IP Operating System help protect the SSR router and other nodes in the core network.
For more information, see Key Chains, TACACS+, Restricting Access to the CLI, and IPsec VPNs.
7.1.1 User Access and Operations
You can access the CLI through a directly connected console port or via Telnet or SSH sessions to the management port. The SSR supports login authentication (using a local user database on the SSR) as well as centralized authentication using a RADIUS or Terminal Access Controller Access-Control System Plus (TACACS+) server.
You can manage local user accounts through the CLI. All user accounts must have a password. Passwords are stored encrypted in the configuration file. After you log in the first time, you can change your password using CLI commands. By default, idle sessions are disconnected after 10 minutes. You can configure the idle time-out interval.
In the Ericsson IP Operating System, user privilege levels determine which commands accessible to a particular user. Users with the default privilege level (level 6) cannot configure the system, but they can modify some ACL rule conditions. Access to higher privilege levels is password-protected.
To protect the system, you can physically and logically separate OAM traffic from other traffic by using separate network interfaces. To provide secure access, the SSR platform supports secure protocols such as SSH, secure copy protocol (SCP), and Secure File Transfer Protocol (SFTP). Both SSH version 1 (SSHv1) and SSH version 2 (SSHv2) are supported, with SSHv2 providing the better protection. If the SSC is deployed, you can also secure line card traffic using IPsec.
Unsecured access includes access through Telnet, FTP, and Trivial File Transfer Protocol (TFTP). You can disable unsecured access to the operating system.
Event logs and alarms raised by different modules on the SSR platform are managed by a centralized logging infrastructure. The security audit trail is visible to the logging infrastructure, which includes successful and failed login attempts and logouts. You can filter Logs based on the log level and directed to multiple destinations—for example, the system console, local storage, or a remote syslog server. If the SSC is deployed, you can use an IPsec tunnel to securely transmit logs to syslog servers.
The Ericsson IP Operating System supports SNMPv1, SNMPv2, and SNMPv3. SNMPv3 affords the greatest degree of security and is the recommended version.
52 1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 Administration
7.1.2 Layer 2 Security
The SSR platform includes various features that provide Layer 2 security and protect against various Layer 2 attacks.
All ports on the SSR router are disabled by default. To be functional, you must explicitly enable a port and then bind it to an interface.
By default, routing protocols are not enabled on any interfaces. VLANs are also not configured. You must explicitly configure a VLAN by setting the port encapsulation to 802.1Q and creating at least one PVC. If the PVC is not explicitly configured, the VLAN is not created.
7.1.3 Layer 3 Security
The SSR platform supports various features that provide protection from Layer 3 attacks. Malicious traffic is detected using a combination of implicit and configured checks. The Ericsson IP OS IP stacks are, by default, hardened against a number of threats. The forwarding plan implicitly performs Layer 3 security checks.
You can filter packets for malicious traffic by configuring IP ACLs. When you apply an ACL to an interface, packets received and sent over the interface are subject to the rules specified in the ACL. ACLs applied at the context level are called administrative ACLs. Only packets sent to the kernel are subject to those ACLs. You can configure administrative ACLs used in any context to protect the control plane from unwanted traffic.
If the SSC is deployed, the SSR can use deep content inspection to detect malicious traffic, count and log events. It can also be configured to raise alarms when malicious traffic exceeds a specified threshold.
Ericsson recommends that you use the software loopback interface for all routing protocols. However, the CLI does not enforce this practice. By default, routing protocols are not enabled on any interface.
Authentication is implemented for all unicast IPv4 and IPv6 protocols. Manually distributed keys are used for authentication. The keys are stored encrypted in the configuration files. You can configure prefix lists to control how messages are routed.
7.1.4 Security Protocols
You can secure traffic exchanged over line cards using IPsec if SSCs are deployed on the system. Only line card and SSC traffic can be secured by IPsec. The kernel does not support IPsec. However, Ericsson IP Operating System control traffic can be secured by IPsec if the traffic travels over line card ports.
1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 53 SSR System Description
Advanced Encryption Standard (AES) and Triple Data Encryption Standard (3DES) algorithms are supported in IPsec tunnels. Detection of anomalies and attacks is not supported.
The SSR IPsec implementation is fully compliant with RFCs 2403 and 2405 and partially compliant with RFCs 4301 through 4309.
7.2 Managing Performance
To manage performance, you can use RFlow, load balancing and SNMP.
7.2.1 RFlow
The SSR provides RFlow for performance management. You can use RFlow to collect a variety of IP traffic statistics, which are compiled in a record that can help you understand data traffic in your network and optimize the following:
• Network planning and analysis
• Network monitoring
• Troubleshooting
• Accounting and billing
For details, see RFlow
7.2.2 Load Balancing
For performance management, the router provides load balancing in the following topologies:
• MPLS networks with LER and LSP transit node (P router) configurations
• Networks using BGP route advertisement
• LAG configurations
Traffic in these topologies is balanced on up to 16 equal-cost links.
For more information, see Load Balancing.
7.2.3 SNMP
You can enable SNMP on the router to monitor one or more network devices from a central location. An SNMP management system includes one or more SNMP agents, an SNMP Manager, and the protocols to communicate information between the SNMP agent and manager entities, such as trap
54 1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 Administration
notifications. You can also configure a target for collecting SNMP data. For more information, see RMON and SNMP.
7.3 Monitoring and Reporting Tools
7.3.1 Logging
The SSR contains two log buffers: main and debug. Log files must be sent to Customer Support when submitting a support request. In large installations, it is recommended to enable the logging of system events to a remote Syslog server that is reachable by the current context.
By default, log messages for the local context are displayed in real time on the console. Nonlocal contexts are not displayed in real time on the console. To change this behavior and display log messages in real time, use the logging console command in context configuration mode in the context of interest. You can display log messages in real time from any Telnet session using the terminal monitor command in exec mode.
The router also supports In-service Performance (ISP) logging, stored in the flash memory of the router. It collects information about predefined system events that can have a potential impact on applications. It enables support representatives to perform root-cause analysis and troubleshooting. It also logs events for third-party applications, such as EPG.
For more information, see Logging.
7.3.2 Event Tracking
The SSR event tracking infrastructure (ETI) provides a low-latency delivery of urgent event notifications for software components, reported in the system logs. When the ETI is enabled, if the state of an object that is tracked by the ETI changes, a corresponding event is immediately published. Applications subscribing to these events react by taking the appropriate action depending on the state received in the event.
For more information, see Event Tracking.
7.3.3 Statistics
To monitor router status, you can configure bulkstats to gather large amounts of data and periodically send updates to a management station. The bulkstats feature frees both the router and the management station from SNMP polling processes and minimizes the amount of memory used for statistics collection. Data collection is governed by a named bulkstats policy. A bulkstats policy defines the collection information, such as the transfer interval, the server to
1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 55 SSR System Description
which the data files are sent, and the sampling interval. A bulkstats policy is context-specific. A context can have multiple bulkstats policies.
For more information, see Bulkstats.
7.3.4 Reporting
The SSR provides show commands to display system features and functions. For example, you can use the monitoring commands in Table 8. For information about specific commands, see theCommand List. For information about using show commands, see Using the CLI.
Table 8 Types of Monitoring Commands Type of Command Commands Notes Monitor a system show chassis Displays status of cards installed in the component chassis. show hardware Displays detailed hardware information. show card Displays detailed card information. show circuit Displays statistics for one or more circuits. counters Monitor the status monitor process Monitors the current status of a specified of a process and category of processes, and provides provide continuous continuous updates to the status. Enter updates this command in exec mode. Monitor files in directory Displays a list of files in the specified memory directory. pwd Displays the current working directory. Enter these commands in exec mode. Monitor a process show process Displays current status of a process. Enter this command in any mode. Display a software show release Displays release and installation release or version information. show version Displays the version of the currently running OS. Enter these commands in any mode. Monitor an show privilege Displays the current privilege level for the administrator current session. session show public-key Displays the public keys for an administrator. Enter these commands in any mode.
56 1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 Administration
Table 8 Types of Monitoring Commands Type of Command Commands Notes Monitor the system show configuration Displays the configuration commands for a feature. Enter this command in any mode. show memory Displays memory statistics. Enter this command in any mode. show redundancy Displays the state of the standby controller card. Enter this command in any mode. show system alarm Displays system alarms at one or more levels. Enter this command in any mode. show port synchrono Displays synchronization information for us-mode one or all synchronous mode ports. show synchronizatio Displays information about BITS/SASE n bits inputs or outputs. show synchronizatio Displays equipment-clock status and n equipment-clock configuration. show synchronizatio Displays information about the n input-source synchronization input sources.
7.3.5 Data Collection
If you have a problem with a router, before attempting to troubleshoot, collect data to record the state of the router at the time the problem occurred and send it to your Technical Support representative for troubleshooting.
1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 57 SSR System Description
58 1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 Glossary
Glossary
3DES CLIPS Triple Data Encryption Standard Clientless IP Service Selection
AAA CLS Authentication, Authorization, And Accounting Classifier
AES CM Advanced Encryption Standard Configuration Management
ANCP COM Access Node Control Protocol Common Operations and Management
ARP CPE Address Resolution Protocol Customer Premises Equipment
ASBR CSM AS Border Router Card/Port State Module
ASPs DHCP Advanced Service Processors Dynamic Host Configuration Protocol
ATM DMA Asynchronous Transfer Mode Direct Memory Access
BFD DNS Bidirectional Forwarding Detection Domain Name System
BGP DSCP Border Gateway Protocol Differentiated Services Code Point
BITS/SASE DVSR Building Integrated Timing Supply / Dynamically Verified Static Route Standalone Synchronization Equipment eLER BNG egress LER Broadband Network Gateway EMS BOOTP Element Management System Bootstrap Protocol EPG CFM Evolved Packet Gateway Connectivity Fault Management FAC CFP Flow Admission Control C-Form Factor Pluggable FIB Forwarding Information Base
1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 59 SSR System Description
FM L3VPN Fault Management Layer 3 Virtual Private Network
GE LAC Gigabit Ethernet L2TP access concentrator
GRE LACP Generic Routing Encapsulation Link Aggregation Control Protocol
GSMPv3 LAG General Switch Management Protocol Version Link Aggregation Group 3 LDP H-QoS Label Distribution Protocol Hierarchical Quality of Service LFIB ICMP Label FIB Internet Control Message Protocol LGd Link Group daemon ICR Interchassis Redundancy LM Label Manager IGMP Internet Group Management Protocol LNS L2TP Network Server IGP Interior Gateway Protocol LP Local Processor IPoE IP over Ethernet LSP Label-Switched Path IPsec IP Security LSR Label-Switched Router IPv6 IP Version 6 LTS L2TP Tunnel Switch IS-IS Intermediate System-to-Intermediate System MBH Mobile Backhaul ISM Interface and Circuit State Manager MC-LAGs Multichassis LAGs ISP In-service Performance MDT Multicast Domain Tree L2TP Layer 2 Tunneling Protocol MFIB Multicast FIB L2VPN Layer 2 Virtual Private Network MIB Management Information Base
60 1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 Glossary
MO PIM Managed Object Protocol Independent Multicast
MPBN PIM-SM Mobile Packet Backbone Network PIM Sparse Mode
MPLS PM Multiprotocol Label Switching Process Manager
MSDP PPP Multicast Source Discovery Protocol Point-to-Point Protocol
MSER PPPoE Multi-service Edge Routing PPP over Ethernet
NAT PWFQ Network Address Translation Priority Weighted Fair Queuing
NBI RCM Northbound Interface Router Configuration Module
ND RED Neighbor Discovery Random Early Detection
NE RIB Network Element Routing Information Base
NTP RIP Network Time Protocol Routing Information Protocol
OAM RIPng Operations, Administration, And Maintenance RIP Next Generation
OSPF RPF Open Shortest Path First Reverse Path Forwarding
OSPFv3 RSVP OSPF Version 3 Reservation Protocol
PAd SCP Platform Administration Daemon SSH, secure copy protocol
PCI-E SFTP Peripheral Component Interconnect Express Secure File Transfer Protocol
PE SNMP Provider Edge Simple Network Management Protocol
PEM SPF Port Encapsulation Module Shortest Path First
PFE SSC Packet Forwarding Engine Smart Services Card
1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 61 SSR System Description
SSH VRRP Secure Shell Virtual Router Redundancy Protocol
SSHv1 SSH version 1
SSHv2 SSH version 2
TACACS+ Terminal Access Controller Access-Control System Plus
TCMd Timing Control Module daemon
TCP Transmission Control Protocol
TCP/IP Transmission Control Protocol/Internet Protocol
TFTP Trivial File Transfer Protocol
ToS Type Of Service
TSFT Traffic Slice Forwarding Tables
TSM Traffic Slice Manager
UDP User Datagram Protocol
VLAN Virtual LAN
VLL Virtual Leased Line
VoIP Voice over IP
VPLS Virtual Private LAN Service
VPWS Virtual Private Wire Service
62 1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 Reference List
Reference List
[1] Ericsson IP Operating System Hardening Guide—006 51-2143 Uen K
1/221 02-CRA 119 1364/1-V2 Uen D | 2013-03-25 63