Technical Product Description
SmartEdge OS for SmartEdge Routers , Release 6.5.1

Contents

1Introduction

2

New and Enhanced Software Features
2.1New and Enhanced Software Features in Release 6.5.1.1
2.1.1Advanced Services Features
2.1.2Pseudowire Redundancy Enhancements
2.1.3SVLAN Ethertypes for Single-Tagged 802.1Q PVCs
2.1.4Port Pseudowire Connections
2.1.5WAN-PHY Ports: Performance Monitoring and Payload Loopback
2.1.6Enhancements to QoS Adjustments for RMR
2.1.7CLIPS Exclusion Based on DHCP Option 77
2.1.8BGP Command Enhancements
2.1.9BGP Next Hop Delay Time and Hold Time Enhancements
2.1.10IGMP Command Enhancements
2.1.11IP Multicast Manager Enhancements
2.1.12Source-Specific Mapping
2.1.13IPv6 Support for Subscriber-facing Aggregated Links and Traffic Distribution
2.1.14IPv6 Forwarding Services and ACL
2.1.15Circuit-Level Rate Limiting for IPv6 Denial of Service Protection
2.1.16SNMP MIB Enhancements
2.1.17BGF Features
2.1.18Timestamp Added to Filename of Core Dump
2.1.19Enhancements to the "show tech-support" Command
2.1.20CLI Commands Exclusively Associated to PPA1 Line Cards Not Supported
2.1.21New Documentation

3

New Hardware or Changes to Hardware
3.1New Hardware or Changes to Hardware in Release 6.5.1.1
3.1.1PPA1 Line Cards Not Supported in Release 6.5.1.1

4

PPA Feature Support
4.1PPA Feature Support in Release 6.5.1.1

5

Required System Components
5.1Required System Components in 6.5.1.1
5.1.1Required Boot ROM Versions
5.1.2Required Minikernel Versions

6

Upgrade Alerts
6.1Preserve Link Group and Bridge Profile Behavior
6.2Remove IS-IS Graceful Restart
6.3Ensure that the MGC Group Name Is Valid
6.4Ensure that the Realm Name Is Valid

Glossary

Reference List
Copyright

© Ericsson AB 2011. 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
SmartEdge is a registered trademark of Telefonaktiebolaget LM Ericsson.
NetOp is a trademark of Telefonaktiebolaget LM Ericsson.

1   Introduction

This document describes the new and enhanced software features in Release 6.5.1 of the SmartEdge® OS for SmartEdge routers. It also describes the new hardware available with this product release.

Note:  
This document does not describe all features; it describes only those that are new or enhanced in the current release.

For software installation and upgrade instructions, see Reference [7]. For information on the changes to default system behavior that are introduced in this release, see Reference [9].

2   New and Enhanced Software Features

This section describes new and enhanced software features introduced in Release 6.5.1.

2.1   New and Enhanced Software Features in Release 6.5.1.1

The following software features are new or enhanced in this release.

2.1.1   Advanced Services Features

This section describes the Layer 4-to-Layer 7 features in this release.

2.1.1.1   Enhanced Traffic Management Support

In previous releases, when configuring a Deep Packet Inspection (DPI) traffic management policy, you could apply a set of DPI quality of service (QoS) actions only for application traffic mapping to a particular class for a specified subscriber or for all traffic associated with a subscriber. In this release, you can also apply DPI control actions for application traffic mapping to a particular class for a group of subscribers or for all subscribers configured on a SmartEdge router.

DPI QoS actions configured for a traffic management policy are applied first to classes within the subscriber traffic, then to all traffic for a subscriber, and finally to all traffic associated with a subscriber group. All enforcement, including rate limiting and marking, is controlled by the DPI engine on the Advanced Services Engine (ASE) card.

For more information, see Application Traffic Management Configuration and Operation and Application Traffic Management Command Reference.

2.1.1.1.1   CLI Changes to Support Enhanced Traffic Management

The following new commands support per-class, per-subscriber group and per-class, per-router DPI traffic management:

The following commands are enhanced to support per-class, per-subscriber-group and per-class, per-router DPI traffic management:

2.1.1.2   Application Traffic Diagnostics and Monitoring Improvements

This release introduces various application traffic diagnostic and monitoring enhancements, including:

For more information, see Application Traffic Management Configuration and Operation and Application Traffic Management Command Reference.

2.1.1.3   Support for Subscriber Group Class Accounting Messages

Previously, you could configure a SmartEdge router to propagate only protocol or per-class, per-subscriber-level statistics reporting in DPI accounting messages. Now, accounting can be reported per class, per subscriber group.

Note:  
Remote Authentication Dial-In User Service (RADIUS) attributes are not included in subscriber group class accounting messages.

The following example illustrates the log format output for subscriber group class accounting messages:

Example 1   Per Class Per Subscriber Group Class Statistics Log

TZ="GMT+0:0" TS="Mon May 03 00:21:36 2010" Ver=2 MsgId= 0x1000072a
Module="DPI-TM" DevId="/6/2" Area="Stats:[C,I]" Level="Info"  Group="group1"
Policy="tmg-pol" Class=”C1” Src="Subscriber" Dest="Internet"
PktTx=990 ByteTx=782100 PktRx=0 ByteRx=0 PktDrop=98 ByteDrop=43512

For more information about DPI log message formats, see Application Traffic Management Overview.

Accounting messages are disabled by default. For a description of how to enable and configure the reporting interval, see Application Traffic Management Configuration and Operation.

2.1.1.4   Supported Number of IPsec Tunnel Sessions

This release supports up to 8,000 Internet Protocol Security (IPsec) tunnel sessions using IKEv1 and IKEv2 signalling on each ASE card, up to a total of 32,000 sessions for the SmartEdge router.

2.1.1.5   Support for IPsec Tunnels over BGP/MPLS VPNs

In this release, you can now configure an Internet Protocol Security (IPsec) tunnel on a SmartEdge router acting as a Provider Edge (PE) router in a Border Gateway Protocol (BGP)/Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN). For a SmartEdge router to terminate an IPsec tunnel, the router must be equipped with an Advanced Services Engine (ASE) card. First, the BGP/MPLS VPN must be configured at both ends of the IPsec tunnel, and then each end of the IPsec tunnel must be configured. Both economical (circuitless) and circuit-based IPsec tunnel modes are supported. For an overview, see IPsec Tunnels Over MPLS VPNs.

Intercontext static routing must be enabled on all nonlocal contexts in which IKE or IPsec packets terminate. For details, see Enabling Inter-Context Routing for IPsec Tunnels Over MPLS VPN.

For an example of how to configure a PE router to support IPsec tunnels over a BGP/MPLS VPN, see IPsec Tunnels Over MPLS VPN. For information on configuring an IPsec tunnel, see IPsec VPN Configuration and Operation Using the SmartEdge OS CLI.

2.1.2   Pseudowire Redundancy Enhancements

Layer 2 Virtual Private Network (L2VPN) cross-connect (XC) and Virtual Private LAN Services (VPLS) Pseudowire (PW) redundancy is enhanced as follows:

2.1.3   SVLAN Ethertypes for Single-Tagged 802.1Q PVCs

In previous releases, it was not possible to bind an IP interface to a single-tagged 802.1Q PVC and use a custom SVLAN Ethertype, such as 0x88a8, for this circuit's traffic, even if the dot1q tunnel ethertype xxx option was configured. In this release, SVLAN Ethertype traffic is supported for IP interfaces bound to a single 802.1Q PVC when "encap 1qtunnel" is configured on the PVC.

2.1.4   Port Pseudowire Connections

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

If you are migrating to MPLS-based aggregation, you can scale your network by directly terminating the services on port PWs instead of a physical port or VLAN. Port PWs also simplify the aggregation network by enabling all provisioning services (such as MPLS PWs, IP over Ethernet (IPoE) circuits, and VPN instances) to be integrated into the same node.

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

In a typical deployment, port PW connections are used to transport IP over Ethernet traffic from the ingress L2 PE device (PE2 in figure 1) to the egress L3 PE router (PE1). PE1 is configured with a port PW port.

Figure 1   Typical PW Port Deployment

In this deployment, CPE1 and CPE2 are devices in the broadband access or other network topologies behind the L2 PE node. Traffic from CPE1 and CPE2 is forwarded by PE2 to PE1, where it is routed and forwarded into the L3 IP/MPLS network on the Internet. It is also transported in the other direction from PE2 to PE1 and forwarded towards the CPEs. The port PW is configured on PE1, leading to its PW peer, PE2, through the access MPLS cloud. The port PW interface and routing connect CPE devices behind the L2 PE to the Internet backbone or another L3 network. PE2 is configured with an L2VPN Ethernet PW to PE1, which simply forwards L2 packets from the attachment circuit into the L2VPN PW, and back.

The following commands have either been enhanced or are new for this feature:

For more information, see Configuring Port Pseudowire Connections.

2.1.5   WAN-PHY Ports: Performance Monitoring and Payload Loopback

Prior to this release, neither performance monitoring nor payload loopback was supported on WAN-PHY ports. With this release, the following commands can now be applied to WAN-PHY ports:

Note:  
WAN-PHY is supported only on the 1-port 10 Gigabit Ethernet card (10ge-1-port) and 1-port 10 Gigabit Ethernet/OC-192c DDR card (10ge-oc192-1-port).

2.1.6   Enhancements to QoS Adjustments for RMR

The quality of service (QoS) adjustments for remote multicast replication (RMR) feature has been enhanced in this release. In prior releases, when the qos-adjust keyword of the igmp group-bandwidth command was configured, the no-oif keyword was set as the default value and added to the configuration. With the no-oif keyword as the default, an output interface (OIF) state creation on the SmartEdge router in response to an Internet Group Management Protocol (IGMP) join was not created for the multicast route. In this release, the no-oif keyword is now configurable. If the no-oif keyword is omitted, the outgoing interface (OIF) is created for IGMP joins to the relevant group, even if QoS adjustments for RMR are also applied in response to the join. This combination of functionality is not typically effective, so it is recommended that the no-oif keyword always be specified.

The igmp group-bandwidth command has been enhanced for this feature.

Syntax: [no] igmp group-bandwidth rate group-list acl-name [qos-adjust [average-packet-size bytes] [no-oif]]

For more information, see igmp group-bandwidth.

Other enhancements applied to QoS adjustments for RMR include the following:

Note:  
You cannot use QoS adjustments for RMR when the SmartEdge router functions as the Multicast Controller as described in Remote Multicast Replication. The QoS adjustments for RMR feature is designed to be used in conjunction with an external Multicast Controller that is configured for RMR. Configure the network and multicast application such that IGMP Joins and Leaves for applicable multicast streams are forwarded to the SmartEdge router on the session or virtual LAN (VLAN) to which each corresponding QoS adjustment should be applied.

For more information, see QoS Adjustments for RMR.

2.1.7   CLIPS Exclusion Based on DHCP Option 77

In previous releases, the SmartEdge router supported excluding a host from CLIPS service on a port or PVC based on matching the vendor class ID specified in Dynamic Host Configuration Protocol (DHCP) option 60. Starting with this release, the SmartEdge router can also exclude a host from CLIPS service based on the user class specified in DHCP option 77. If the user class ID specified in received DHCP Discover/Request packets matches any of the user class IDs configured for the port or PVC, the SmartEdge router bypasses CLIPS authentication and forwards the Discover and Request packets to the DHCP server. Configure user-class-ID–based CLIPS exclusion using the following command:

[no] service clips-exclude user-class-id id [offset position]

This command is available in the following configuration modes:

If CLIPS exclusion is not configured, the SmartEdge router ignores option 77 in the DHCP packet. If the SmartEdge router is configured for CLIPS exclusion based on both DHCP option 60 and option 77, and if either option matches, the host is excluded from CLIPS service. If neither option matches, a CLIPS session is set up for the host. CLIPS-excluded hosts are connected through a DHCP relay.

To display the statistics for CLIPS excluded hosts, a new option, the clips-excluded keyword, has been added to the show dhcp relay stats command. This option displays counters for packets for which no response is expected from the external DHCP server. When the show dhcp relay stats command is used without this option, it continues to display packet statistics for both CLIPS sessions and CLIPS-excluded sessions.

The following example configures CLIPS exclusion in dot1q PVC configuration mode.

2.1.8   BGP Command Enhancements

The new {no | default} timers active-open interval command specifies the interval that the router waits for a BGP peer to come up after a graceful restart before starting the best-path computation.

The show bgp neighbor command is enhanced to display Outbound Route Filter (ORF) prefix filters configured on a BGP neighbor:

The {no | default} timers active-open interval command is available in BGP neighbor and BGP peer group configuration mode.

2.1.9   BGP Next Hop Delay Time and Hold Time Enhancements

With this release, you can now set the BGP minimum interval between two consecutive next-hop triggered best path calculations (nexthop triggered holdtime command) and the delay before starting a best path calculation after a next-hop change (nexthop triggered delay command) in milliseconds. Previously, you could only specify these intervals in seconds. The syntax for these enhanced commands follows:

nexthop triggered holdtime {milliseconds msec | seconds} [backoff milliseconds msec | seconds]

nexthop triggered delay {millisecond msec | seconds}

The minimum hold time is 0 and the minimum delay is 0; that is, no hold time, no delay, respectively.

The implementation of the nexthop triggered holdtime has also changed:

The show bgp route summary now includes the optional detail keyword. When this keyword is included in the commend, the output shows the current settings for the next-hop delay time, hold time, and backoff time. In addition, the current Time since last triggered NEXT_HOP scan: is displayed.

2.1.10   IGMP Command Enhancements

The new {no | default} igmp verify source subnet command enables Internet Group Management Protocol (IGMP) source subnet verification on an interface; the interface accepts only those packets with a matching source IP subnet. Packets with a nonmatching source IP subnet are dropped.

Note:  
We recommend enabling IGMP source subnet verification on nonloopback IGMP interfaces. Nonloopback IGMP interfaces should accept only those packets with a source IP subnet that matches the IGMP interface IP subnet. Loopback IGMP interfaces can accept packets from any source.

The show igmp group command is enhanced to include the optional subscriber {agent-circuit-id agent-circuit-id | agent-remote-id remote-circuit-id | username subscriber-user name [detail]} construct:

2.1.11   IP Multicast Manager Enhancements

The following new commands are added to enhance IP multicast manager support:

2.1.12   Source-Specific Mapping

The source-specific multicast (SSM) feature is an extension of multicast routing where traffic is forwarded to receivers from only those multicast sources to which the receivers have explicitly joined. For multicast groups configured to use SSM, only source-specific multicast distribution trees are created; shared trees are not.

In this release, you can enable the router to determine one or more multicast source addresses for group G, an P Multicast destination address. The mapping translates IGMPv1 or IGMPv2 membership reports to an IGMPv3 report, enabling the router to continue as if it had initially received an IGMPv3 report.

The new ssm-map command (in igmp service profile configuration and igmp snooping profile configuration modes) supports SSM. For information about this command, see the Configuring IP Multicast and CLI documents.

The following commands are enhanced to support SSM:

2.1.13   IPv6 Support for Subscriber-facing Aggregated Links and Traffic Distribution

Support for bundling access-facing circuits carrying IPv6 traffic into link aggregation groups (LAGs) is implemented in this release. Specifically, Open Shortest Path First version 3 (OSPFv3), Routing Information Protocol next generation (RIPng), BGP, and Dynamic Host Configuration Protocol for IPv6-Prefix Delegation (DHCPv6-PD) are now supported for IPv6 traffic on access LAGs; however, neither IS-IS nor class-based forwarding are supported for IPv6 traffic on access LAGs. This new functionality adds to the support for IPv6 over network-facing trunk LAGs implemented in previous releases. This support for access LAGs includes economical and noneconomical (hitfull and hitless) LAG, route redistribution, and stateless address autoconfiguration (SLAAC). With IPv6 support for access LAGs you can, for example, configure access LAGs on two customer edge (CE) routers to secure the gateways for the Layer 2 Virtual Private Network (L2VPN) between them.

The following commands have been updated or added:

Procedures in the documentation for configuring access LAGs, routing protocols, BGP, forwarding, and L2 and L3 tunnels have been updated to support configuration of access LAGs carrying IPv6 traffic.

2.1.14   IPv6 Forwarding Services and ACL

This release includes IPv6 support for policy Access Control List (ACLs) and forward policies. All SmartEdge OS supported IPv4 ACL applications are supported for IPv6 ACL subscribers.

An IPv6 policy ACL can be referenced in Quality of Service (QoS) and forward policies in the same configuration contexts that IPv4 ACLs are referenced. Both IPv4 and IPv6 traffic can be classified into the same class, with per-class rate limits enforced on the aggregate of both kinds of traffic. QoS or forward policies with IPv6 policy ACLs can be applied to both static and subscriber circuits. Forward policies support redirect to local (HTTP redirect) and drop modes for IPv6 traffic.

IPv6 ACL VSA or IETF attributes are supported in the same way as IPv4 ACL attributes. IPv6 ACL Vendor Specific Attribute (VSA) or Internet Engineering Task Force (IETF) attributes can be configured in addition to configured IPv4 ACL attributes and can be simultaneously applied to dual-stack subscriber sessions.

You can use Dynamic QoS Parameter (DQP, VSA attribute 196) ipv6-fwd-ip-access-group provides a mechanism to combine multiple IPv6 policy access-lists into an access-group to be applied to a subscriber session’s inbound RADIUS-guided forward policy.

With this release, RSE service accounting now supports both IPV4 and IPv6 service accounting; CLI commands are not changed. If you configure service accounting, it is applied to both stacks for dual stack subscribers.

The following documents have been updated

The following commands have been added:

The following commands have been modified:

2.1.15   Circuit-Level Rate Limiting for IPv6 Denial of Service Protection

Circuit-level rate-limiting to protect the SmartEdge router against Denial of Service (DoS) attacks originating from DHCPv6 or Neighbor Discovery (ND) clients is implemented in this release.

The following commands have been added:

For configuration procedures, see Configure Router to Prevent DoS Attacks from DHCPv6 Clients and Configure Router to Limit the Effect of ND Packet DoS Attacks.

2.1.16   SNMP MIB Enhancements

The following Standard Simple Network Management Protocol (SNMP) management information bases (MIBs) are supported:

Standard SNMP MIBs

The following Ericsson Enterprise MIBs are supported:

Enterprise MIBs

SNMP notifications in the following MIBs are supported:

SNMP MIB Notifications

The following CLI commands have been added to support new MIB objects:

The following CLI commands have been modified to support new MIB objects:

2.1.16.1   Ping MIB Enhancements

To support ping tests using SNMP, PING-MIB supports the pingProbeHistoryTable MIB object.

PING-MIB supports the following ping functionality:

The show snmp ping command has been modified, allowing you to view the status and results of any ping tests using the CLI.

An Enterprise MIB, RBN-PING-MIB, has been added to support the following MIB objects:

2.1.16.2   IPv4 Traceroute MIB Support

In this release, the TRACEROUTE-MIB has been added to provide the following functionality:

The new show snmp traceroute command allows you to view the status and results of traceroute tests.

2.1.16.3   MPLS VPN MIB Enhancements

The following Standard MIB objects are supported:

The following CLI command is enhanced to support the MIB objects:

{ ip | ipv6 } maximum-routes [ multicast ] [ vpn ] route-limit [ log-only | threshold value ] [ mid-threshold value ] ]

Use the new mid-threshold value construct to set an optional threshold value for the mid-level limit that triggers a warning. The range of values is 1 to 100.

2.1.16.4   MPLS L2VPN MIB Enhancements

The following MIB objects are supported:

2.1.16.5   IS-IS MIB Support

In this release, the standard IS-IS MIB is supported. This MIB supports the functionality described in Request for Comments (RFC) 4444, Management Information Base for Intermediate System to Intermediate System (IS-IS).

Note:  
The isisRATableGroup, isiNotificationGroup, and isisNotificationObjectsGroup objects are not supported in this release. You can enable IS-IS MIB debugging with the debug snmp mib ospf CLI command.

2.1.17   BGF Features

2.1.17.1   Optimized BGF Selection

Multiple Border Gateway Functions (BGFs) can now be connected to one Session Gateway Controller (SGC) in most operator deployment scenarios. The SGC selects a BGF for a call based on supported realms; if more than one BGF supports the realms required for a call, the SGC uses a round-robin algorithm to select the BGF. The selection can be further optimized by selecting the closest BGF or selecting the BGF that was previously used for anchoring the same call. The new selection criteria require BGF to have a location-based identifier, which can be configured by the operator. BGF siteID, a new property in the “eri_seco” package introduced to support this feature, is a root-level property that can be audited by the SGC.

Configure the site ID using the following new command:

For more information, see the site command.

2.1.17.2   Globally Unique MID

In this release, the format of the H.248 message ID (MID) has changed. This ID is used to uniquely identify a virtual Media Gateway (vMG). Multiple vMGs can be supported by a single SmartEdge BGF. SmartEdge BGF supports the device-name format for the MID, as follows:

MGC-group name/MGD instance id@system MAC

where:

The output of the show media-gateway [instance] mgc-group command is enhanced for this feature. Available in all modes, this command displays information for the vMG corresponding to the MGC group for all MG instances or a specified MG instance. The output of this command has been modified so that the H.248 message ID of the vMG is identified in the H.248 Message ID (MID) field. To see the enhanced output display of this command, see the Examples section of the show media-gateway [instance] mgc-group command.

2.1.17.3   3.2 IPv6 Security Support

Support for IPv6 ACL Rules

Both IPv4 and IPv6 Access Control List (ACL) rules can either permit or deny a packet based on the following match criteria:

Prior to this release, only IPv4 ACL rules were supported.

Note:  
The following IPv4 ACL parameters (within the permit and deny commands for IPv4) are not supported in IPv6 ACLs:
  • ip-options
  • fragments
  • invalid-tcp-flags

RPF Check Support for IPv6 Packets

You can now prevent IP spoofing attacks by configuring Reverse Path Forwarding (RPF) checks for both IPv4 and IPv6 packets. Prior to this release, RPF checks were supported only for IPv4 packets.

Note:  
RPF checks for IPv6 traffic are limited to subscriber circuits.

Implicit Security Checks Now Support IPv6 Packets

The SmartEdge router performs implicit security checks to detect and drop malicious traffic applicable to IPv4, IPv6, or both. New security checks performed by the Packet Processing ASIC (PPA) drop packets for the following reasons:

For more information about the new IPv6 security support, see Configuring Malicious Traffic Detection and Monitoring.

2.1.18   Timestamp Added to Filename of Core Dump

The filenames of core dump files now contain a timestamp to facilitate debugging.

The timestamp appears as a filename prefix in the format YYYYMMDD_hhmmss_, reflecting the approximate year, month, day, hour, minute, and second of the crash that triggered the core dump file. By looking at the filename, you can easily determine which log files and other information to investigate while debugging the crash.

Previously, it was sometimes impossible to determine when a core dump file was created. The last modified date of the core dump file was unreliable because XCRP switchovers update the modified date of core dump files. The modified date of a core dump file could be days or months after the crash that triggered its creation.

The timestamp in the filename is not the precise time of the crash. After the crash occurs, a few minutes pass while the file is created and an internal process moves the file and adds a timestamp to the filename.

2.1.19   Enhancements to the "show tech-support" Command

For improved debugging capability, the show tech-support command has been reorganized to include a basic macro to collect general troubleshooting information and new optional keywords to collect information about many SmartEdge modules. The basic command collects information in the areas listed in Table 1.

Table 1    Areas Covered by Basic show tech-support Command

Startup and software revision

System hardware details

Configuration

Core system statistics

Process and memory status and crashes

Core system processes

IP routes

Subscriber details (basic)

Shared memory routing

DHCPv6

Table 2 lists the keywords that have been added for collecting focussed troubleshooting data.

The command still includes the ase keyword to collect information about ASE cards.

Table 2    New show tech-support Command Keywords

Keyword

Output Data Includes

aaa

Authentication, Authorization, and Accounting configuration and events

atm

Asynchronous Transfer Mode (ATM) information

bfd

Bidirectional Forwarding Detection (BFD) information

bgp

Border Gateway Protocol (BGP) information

dhcp

Dynamic Host Configuration Protocol (DHCP) server and relay information

dot1q

802.1Q permanent virtual circuit (PVC) information

flowd

Flow process information for Flow Admission Control

gre

Generic Routing Encapsulation (GRE) tunnels and tunnel circuit information

igmp

Internet Group Management Protocol (IGMP) information

ipv6

IPv6 subscriber services information, concentrating on IPv6 and ND; the basic command collects data about DHCPv6

isis

Intermediate System-to-Intermediate System (IS-IS) routing information

l2tp

Layer 2 Tunneling Protocol (L2TP) peer and group information

ldp

Label Distribution Protocol (LDP) signalling information

mobile-ip

Mobile IP information

ospf

Open Shortest Path First (OSPF) information

ospf3

Open Shortest Path First version 3 (OSPFv3) information

pim

Protocol Independent Multicast (PIM) information

ppp

Point-to-Point Protocol (PPP) information

pppoe

PPP over Ethernet (PPPoE) information

qos

Quality of service (QoS) information

rdb

SmartEdge database information

snmp

Simple Network Management Protocol (SNMP) information

For more information about using the show tech-support command to collect troubleshooting data, see Data Collection Guideline for the SmartEdge Router.

2.1.20   CLI Commands Exclusively Associated to PPA1 Line Cards Not Supported

The following PPA1-related CLI commands have been removed from the SmartEdge OS documents.

For more information about PPA1 line cards, see Section 3.1.1.

2.1.21   New Documentation

2.1.21.1   New Software Documentation

With this release, the Configuring Port Pseudowire Connections document has been added to the SmartEdge Library. To view this document, navigate to the Operations and Maintenance > Configuration Management > MPLS Routing directory.

2.1.21.2   New Troubleshooting Documentation

With this release, the following troubleshooting documents have been added to the SmartEdge Library:

To view troubleshooting documents, navigate to the Operation and Maintenance -> Fault Management -> Troubleshooting directory.

3   New Hardware or Changes to Hardware

This section describes new hardware or changes to hardware introduced in Release 6.5.1.

3.1   New Hardware or Changes to Hardware in Release 6.5.1.1

The following hardware is introduced or changed in this release.

3.1.1   PPA1 Line Cards Not Supported in Release 6.5.1.1

You cannot provision PPA1-based line cards in SmartEdge OS release 6.5.1.1. If installed, the line cards listed in Table 3 are not recognized.

Table 3    Disabled Line Cards

Description

CLI Card Type

12x1 Fast Ethernet

ether-12-port

4x1 Gigabit Ethernet – [Gigabit Ethernet card (4-port)]

ge-4-port

8x1 OC-3c/STM-1c POS – [OC-3c/STM-1c card (8-port)]

oc3-8-port

4x1 OC-12c/STM-4c POS – [OC-12c/STM-4c card (4-port)]

oc12-4-port

1x OC-48c/STM-16c POS – [OC-48c/STM-16c card (1-port)]

oc48-1-port

1x Ch OC-12 to DS-3/DS-1

ch-oc12ds1-1-port

1x Ch OC-12 to DS-3

ch-oc12ds3-1-port

3x1 Ch STM1 to E1

ch-stm1ds0-3-port

12x1 DS3 ATM – [ATM DS-3 card (12-port)]

atm-ds3-12-port

4x1 OC-3c/STM-1c ATM – [ATM OC-3c/STM-1c card (4-port)]

atm-oc3-4-port

1x OC-12c/STM-4c ATM Enhanced – [Enhanced ATM OC-12c/STM-4c card (1-port)]

atm-oc12e-1-port

12x1 Clear Channel DS-3 – [Clear-channel DS-3 card (12-port)]

ds3-12-port

12x1 Ch DS-3 to DS-1 – [Channelized DS-3 card (12-port)]

ch-ds3-12-port

3x1 Ch DS-3 to DS-1 – [Channelized DS-3 card (3-port)]

ch-ds3-3-port

24x1 Ch Copper E1 – [Channelized E1 card (24-port)]

ch-e1ds0-24-port

6x1 Clear Channel E3 – [Clear-channel E3 card (6-port)]

e3-6-port

4   PPA Feature Support

This section describes PPA support for features introduced in Release 6.5.1.

Note:  
For information about which traffic cards support each PPA version, see the device hardware guides.

4.1   PPA Feature Support in Release 6.5.1.1

Table 4 describes the feature support for PPA versions in this release.

Table 4    PPA Feature Support for Release 6.5.1.1

Feature

PPA2

PPA3

Notes

Advanced Services Features

Yes

Yes

ASEs are not PPA-based, so, in general, PPA support does not apply.


At the same time, an ASE card is required to negotiate the secure connections between tunnel endpoints and to encrypt and decrypt traffic passing through the tunnel. PPA2/3 linecards must support an 8 byte Octeon Instruction header for all DPI and IPsec data traffic in both tunneling and detunneling directions. The header reflects the CoS queue that must be used by the ASP on the ASE card. The CoS queue is based on the PD bits in the packet’s own header.

Support for IPsec Tunnels over BGP/MPLS VPNs

Yes

Yes

 

Pseudowire Redundancy Enhancements

Yes

Yes

 

SVLAN Ethertypes for Single-Tagged 802.1Q PVCs

Yes

Yes

 

Port Pseudowire Connections

Yes

Yes

 

WAN-PHY Ports

Yes

No

 

Enhancements to QoS Adjustments to RMR

Yes

Yes

Supported on PPA2 and PPA3 only for PWFQ. Suppported on line card versions for metering binding.

CLIPS Exclusion Based on DHCP Option 77

Yes

Yes

 

BGP Command Enhancements

Yes

Yes

 

BGP Next Hop Delay Time and Hold Time Enhancements

Yes

Yes

 

IGMP Command Enhancements

Yes

Yes

 

IP Multicast Manager Enhancements

Yes

Yes

 

Source-Specific Mapping

Yes

Yes

 

IPv6 Support for Subscriber-facing Aggregated Links and Traffic Distribution

Yes

Yes

 

IPv6 Forwarding Services and ACL

Yes

Yes

 

Circuit-Level Rate Limiting for IPv6 Denial of Service Protection

Yes

Yes

 

BGF Features

Yes

Yes

 

Timestamp Added to Filename of Core Dump

Yes

Yes

 

Enhancements to the "show tech-support" Command

Yes

Yes

 

5   Required System Components

This section describes the system components required in Release 6.5.1.

5.1   Required System Components in 6.5.1.1

The following system components are required in this release.

5.1.1   Required Boot ROM Versions

Release 6.5.1.1 requires the boot ROM versions listed in in the following table:.

Table 5    Required Boot ROM Versions

Card Type

Version

Filename

XCRP4

2.0.2.45

OFW-XC4-2.0.2.45.fallback.md5

SmartEdge 100 controller

2.0.1.4

OFW-se100-2.0.1.4.primary.bin

ASE

2.0.2.45

OFW-ASE-2.0.2.45.fallback.md5

FSSB

2.0.2.56

OFW-FSSB-2.0.2.56.ofwbin.md5

5.1.2   Required Minikernel Versions

Release 6.5.1.1 requires the minikernel versions listed in the following table:

Table 6    Required Minikernel Versions

Card Type

Version

Filename

XCRP4

11.7

MINIKERN_RBN64-xc4.p11.v7

SmartEdge 100 controller

2.7

se100-minikernel.p2.v7.bin

ASE

13.5

MINIKERN_ASE64-ase.p13.v5

FSSB

N/A

N/A

6   Upgrade Alerts

This section identifies situations that require additional steps or may affect your system before you upgrade to this release.

In addition, before you upgrade, check for any relevant security notifications on the Ericsson E-business portal at https://ebusiness.ericsson.net.


 Stop! 
The Advanced Services Engine (ASE) card must be running the correct version of the boot ROM and so must the SmartEdge OS system. To avoid a serious equipment outage in the field, if you are running SmartEdge OS Release 6.2.1.5 or later on either the ASE or the SmartEdge OS system, DO NOT DOWNGRADE to 6.2.1.4 or earlier. If you must downgrade, contact your support representative for an equipment-safe procedure. Downgrading from these releases can cause permanent damage to the ASE.

6.1   Preserve Link Group and Bridge Profile Behavior

In Release 6.1.4.1 and subsequent, a port or circuit can be associated with either a bridge profile or a link group, but not both. If you are upgrading from an earlier release in which you have one or more ports or circuits associated with both a bridge profile and a link group and you want to preserve existing behavior after the upgrade, perform the following steps:

  1. If you have bridge profiles configured directly under any of the physical ports belonging to a link group, remove them. Change bridge profile configuration so that the bridge profile is configured for the link group—not the port or circuit.
  2. Use the show configuration command to display the link-group configuration.
  3. Copy the link-group configuration to a text file.
  4. Upgrade the SmartEdge router to this release.
  5. Use the text file you created with link group configuration information to reconfigure the bridge profiles under the dot1q pvc mode under the link group. This must be done manually.
  6. Verify that the link group configuration and bridge profile configuration is correct.

6.2   Remove IS-IS Graceful Restart

If you are upgrading from a release earlier than Release 6.1.4.3, you must perform extra steps to handle changes to IS-IS graceful restart.

The implementation of IS-IS graceful restart in Release 6.1.4.3 and subsequent releases does not interoperate with the previous implementations of the feature. As a result, for IS-IS graceful restart, systems running earlier releases of the SmartEdge OS do not interoperate with those running Release 6.1.4.3 and later. All SmartEdge IS-IS systems in your network must be running the same version of graceful restart; different versions do not interoperate.

In addition, in Release 6.1.4.3, the command [no] graceful-restart replaced the [no] restart graceful-time command.

To upgrade from a release earlier than Release 6.1.4.3:

  1. Disable IS-IS graceful restart by using the no restart graceful-time command (pre-Release 6.1.4.3 version of the command).
  2. Upgrade all adjacent IS-IS routers.
  3. Re-enable IS-IS graceful restart by using the graceful-restart command (Release 6.1.4.3 and later version of the command).

If you need to downgrade to a release earlier than 6.1.4.3:

  1. Disable IS-IS graceful restart by using the no graceful-restart command (Release 6.1.4.3 and later version of the command) on all adjacent routers.
  2. For each adjacent IS-IS router:
    1. Downgrade the SmartEdge OS.
    2. Use the no restart graceful-time command (pre-Release 6.1.4.3 version of the command) to disable IS-IS graceful on that router until all other IS-IS routers have been downgraded.
  3. Re-enable IS-IS graceful restart by using the restart graceful-time command (pre-Release 6.1.4.3 version of the command) on all adjacent routers.

6.3   Ensure that the MGC Group Name Is Valid

Prior to upgrading to Release 6.5.1, ensure that the MGC group name in the configuration has a valid value. Use the mgc-group command (in global MG configuration mode) to specify an MGC group name.

In releases prior to Release 6.5.1, the character set of the MGC group name was unrestricted. In Release 6.5.1 and later, the valid value for the MGC group name is an alphanumeric string of up to 30 characters, and the first character must be a letter. If the configured MGC group name does not conform to the new syntax, the upgrade to the new release will fail. Before upgrading to Release 6.5.1 or subsequent, change the MGC group name to conform to the new syntax.

6.4   Ensure that the Realm Name Is Valid

Prior to upgrading to Release 6.5.1, ensure the realm name in the configuration has a valid value. Use the realm command (in MG context configuration mode) to specify a realm name.

In previous releases, the character set of the realm name did not fully conform to fully qualified domain name (FQDN) format. Starting with Release 6.5.1, it conforms. The valid value of a realm name is a string of up to 63 characters and is case-insensitive. The string must start and end with an alphanumeric character; can contain only letters, digits, hyphens (-), and periods (.); and must consist of at least two characters. If the configured realm name does not conform to the new syntax, the upgrade to the new release will fail. Before upgrading to Release 6.5.1, change the realm name to conform to the new syntax.


Glossary

ASE
Advanced Services Engine
 
AAA
Authentication, Authorization, and Accounting
 
ACL
Access Control List
 
ANCP
Access Node Control Protocol
 
ASE
Advanced Services Engine
 
ASP
Advanced Services Processor
 
ATM
Asynchronous Transfer Mode
 
BFD
Bidirectional Forwarding Detection
 
BGF
Border Gateway Function
 
BGP
Border Gateway Protocol
 
CLI
command-line interface
 
CLIPS
Clientless IP Service Selection
 
CoS
Class of Service
 
CSR
Customer Service Request
 
DHCP
Dynamic Host Configuration Protocol
 
DHCPv6
Dynamic Host Configuration Protocol Version 6
 
DHCPv6-PD
Dynamic Host Configuration Protocol for IPv6-Prefix Delegation
 
DoS
Denial of Service
 
DPI
Deep Packet Inspection
 
DSCP
Differentiated Services Code Point
 
FSSB
File System Server Blade
 
GRE
Generic Routing Encapsulation
 
ICMP
Internet Control Message Protocol
 
IETF
Internet Engineering Task Force
 
IGMP
Internet Group Management Protocol
 
IGP
Inter Gateway Protocol
 
IKEv1
Internet Key Exchange Version 1
 
IKEv2
Internet Key Exchange Version 2
 
IP
Internet Protocol
 
IPoE
IP over Ethernet
 
IPsec
Internet Protocol Security
 
IPv4
Internet Protocol Version 4
 
IPv6
Internet Protocol Version 6
 
IS-IS
Intermediate System-to-Intermediate System
 
L2
Layer 2
 
L2TP
Layer 2 Tunneling Protocol
 
L2TPv3
Layer 2 Tunneling Protocol version 3
 
L2VPN
Layer 2 Virtual Private Network
 
L3
Layer 3
 
LAG
Link Aggregation Group
 
LDP
Label Distribution Protocol
 
MAC
Medium Access Control
 
MG
Media Gateway
 
MGC
Media Gateway Controller
 
MGD
Media Gateway Daemon
 
MIB
Management Information Base
 
MID
Message ID
 
MPLS
(BGP)/Multiprotocol Label Switching
 
MPLS
Multiprotocol Label Switching
 
ND
Neighbor Discovery
 
ORF
Outbound Route Filter
 
OSPF
Open Shortest Path First
 
OSPFv3
Open Shortest Path First version 3
 
P2P
Point-to-Point
 
PE
Provider Edge
 
PE1
PE router
 
PFE
Packet Forwarding Engine
 
PIM
Protocol Independent Multicast
 
POS
Packet over Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH)
 
PPA
Packet Processing ASIC
 
PPPoA
Point-to-Point Protocol over Asynchronous Transfer Mode
 
PPPoE
Point-to-Point Protocol over Ethernet
 
PVC
Permanent Virtual Circuit
 
PW
Pseudowire
 
PWFQ
Priority Weighted Fair Queuing
 
PWs
MPLS port pseudowires
 
QoS
quality of service
 
RADIUS
Remote Authentication Dial-In User Service
 
RFC
Request for Comments
 
RIPng
Routing Information Protocol next generation
 
RMR
Remote Multicast Replication
 
RPF
Reverse Path Forwarding
 
SGC
Session Gateway Controller
 
SNMP
Simple Network Management Protocol
 
TCP
Transmission Control Protocol
 
TM
Traffic Management
 
ToS
Type of Service
 
TR-101
Technical Report 101
 
UDP
User Datagram Protocol
 
VCCV
Virtual Circuit Connectivity Verification
 
VLAN
Virtual LAN
 
VMG
Virtual Media Gateway
 
VPLS
Virtual Private LAN Services
 
VPN
Virtual Private Network
 
VSA
Vendor Specific Attribute
 
XCRP
Cross-Connect Route Processor

Reference List

SmartEdge OS (EN/LZN 783 0011/1)
[1] Configuring Bridging (7/1543-CRA 119 1170/1-V1)
[2] Configuring CLIPS (63/1543-CRA 119 1170/1-V1)
[3] Configuring Ethernet CFM (52/1543-CRA 119 1170/1-V1)
[4] Configuring ATM, Ethernet, and POS Ports (9/1543-CRA 119 1170/1-V1)
[5] Configuring IPv6 Subscriber Services (85/1543-CRA 119 1170/1-V1)
[6] Configuring Rate-Limiting and Class-Limiting (55/1543-CRA 119 1170/1-V1)
[7] Installing the SmartEdge OS (1/190 47-CRA 119 1170/1-V1)
[8] Configuring NTP (34/1543-CRA 119 1170/1-V1)
[9] Changes to Default System Behavior (198 23-CRA 119 1170/1)
Other CPI
[10] SmartEdge Border Gateway Function, 155 13-CRA 119 1170/1.
Standards and Recommendations
[11] WAN Interface Sublayer, IEEE 802.3ae.
[12] Link Aggregation, IEEE 802.3ad.
[13] ETHERLIKE-MIB, RFC 2665.
[14] ETHER-WIS-MIB, RFC 3637.
[15] IF-INVERTED-STACK-MIB, RFC 2864.