DESCRIPTION     4/221 02-CRA 119 1170/1-V1 Uen D    

Technical Product Description 

SmartEdge OS for SmartEdge Routers , Release 6.4.1

© Ericsson AB 2009-2010. 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.

Contents

1Introduction

2

New and Enhanced Software Features
2.1New and Enhanced Software Features in Release 6.4.1.1

3

New Hardware or Changes to Hardware
3.1New Hardware or Changes to Hardware in Release 6.4.1.1

4

PPA Feature Support
4.1PPA Feature Support in Release 6.4.1.1

5

Required System Components
5.1Required System Components in 6.4.1.1

6

Upgrade Alerts
6.1Preserve Link Group and Bridge Profile Behavior
6.2Remove IS-IS Graceful Restart

7

APS Traffic Card and Feature Compatibility
7.1POS APS Ports

Glossary

Reference List


1   Introduction

This document describes the new and enhanced software features in Release 6.4.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.4.1.

2.1   New and Enhanced Software Features in Release 6.4.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   IKEv2 and PKI Support for IPsec VPN Tunnel Configuration

This feature adds support for:

For more information, see IPsec VPN Configuration and Operation Using the SmartEdge OS CLI and IPsec VPN Command Reference.

2.1.1.1.1   CLI Changes to Support IKEv2

The following new commands support IKEv2:

The following commands are enhanced to support IKEv2:

2.1.1.1.2   CLI Changes to Support Manual PKI

The following new commands support manual PKI:

2.1.1.1.3   CLI Changes to Support Economical Mode

The tunnel ipsec command is enhanced to support economical mode.

2.1.1.1.4   CLI Changes to Support Traffic Selector–Based Route Addition

The new ip route traffic-selector-guided command in tunnel configuration mode supports traffic selector–based route addition.

2.1.1.2   Subscriber Aggregate Traffic Management Support

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

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

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

2.1.1.2.1   CLI Changes to Support Subscriber Aggregate Traffic Management

The following commands are enhanced to support subscriber aggregate traffic management:

2.1.1.3   Support for RADIUS Attributes in DPI Log Messages

Advanced services DPI log messages are generated when application traffic protocols are detected and to report statistics information.

In this release, the following Remote Authentication Dial-In User Service (RADIUS) attributes are propagated in DPI log messages if configured for the specified user:

If no RADIUS configuration exists, only the username is propagated.

The following example illustrates the log format output, including RADIUS attributes, for protocol statistics messages:

Example 1   Protocol Statistics Log Message Output

TZ="GMT+0:0" TS="Wed Apr 22 19:01:41 2009" Ver=2 MsgId=0x10000727
Module="DPI-TM" DevId="akari/1/2" Area="Stats:I" Level="Info"
Ctxt="m1" User="user1@m1" NAS-Port="67174400" NAS-Port-Type=5
NAS-Port-ID="4/1 vlan-id 1" NAS-Identifier="akari"
MAC-Address="00:00:64:03:01:02"
Accounting-Session-Id="0300FFFF68000002-4C07C323" Policy="NULL"
AppProto="1/bit-torrent" Src="Internet" Dest="Subscriber"
PktTx=84357 ByteTx=108510480 PktDrop=0 ByteDrop=0 Flows=1 ConnDrop=0

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

2.1.1.4   Support for Class-Level Statistics Reporting in DPI Log Messages

Previously, you could configure a SmartEdge router to propagate only protocol-level statistics reporting in DPI log messages. Now, statistics can be reported per class, per subscriber. Class-based statistics provide important information about network usage patterns for each class of traffic configured on a SmartEdge router.

The following example illustrates the log format output for per-class, per-subscriber statistics messages:

Example 2   Per-Class, Per-Subscriber Statistics Log Message Output

TZ="GMT+0:0" TS="Wed Apr 22 18:59:29 2009" Ver=2 MsgId=0x10000729 
Module="DPI-TM" DevId="akari/1/2" Area="Stats:[C,I]" Level="Notice" 
Ctxt="m1" User="user1@m1" NAS-Port="67174400" NAS-Port-Type=5
NAS-Port-ID="4/1 vlan-id 1" NAS-Identifier="akari"
MAC-Address="00:00:64:03:01:02" 
Accounting-Session-Id="0300FFFF68000002-4C07C323" Policy="tmg-pol"
Class="C1" Src="Subscriber"Dest="Internet" Pktxt=990 ByteTx=782100
PktRx=0 ByteRx=0 PktDrop=98 ByteDrop=43512 Flows=11 ConnDrop=0 

Statistics reporting is disabled by default. For more information, including a description of how to enable and configure the statistics reporting interval, see Application Traffic Management Configuration and Operation.

2.1.1.5   Dynamic Update of DPI Application Signature File

The Point-to-Point (P2P) application signature file is referenced during DPI protocol analysis to detect and identify known P2P application traffic. Each SmartEdge OS version contains a built-in signature file that is current as of the release date. As existing P2P applications evolve and new applications emerge, the built-in signature file becomes less effective. Therefore, keeping the signature file current between SmartEdge OS releases is essential for performing comprehensive application traffic management.

To deliver new signature data, Ericsson creates a new signature file and publishes it every six to eight weeks.If no new data exists, no file is created. After you download the new file to the Cross-Connect Route Processor (XCRP) controller card and issue a configuration command, the signature file data on all ASPs is dynamically updated.

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

2.1.1.5.1   New or Changed Commands

The dpi traffic-management signature-file command has been added to configure the signature file to be used. The file must be loaded into /flash on the active XCRP controller card before you can configure it. You cannot configure a signature file that does not support the applications used in DPI access-list rules, and you cannot configure rules in a DPI access-list that are not supported by the current signature file.

The show dpi traffic-management signature-file command was added to display information about the signature file in use on the XCRP card. If you add the optional sig-filename argument, which requires either the application or category keyword, the command displays a list of the applications or categories supported by the specified file.

The signature-file keyword has been added to the show dpi asp traffic-management statistics command to verify success or failure of downloads to the specified ASP. It was also added to the show dpi asp slot/asp-id traffic-management command to show information about the signature file currently in use on an ASP.

2.1.1.5.2   Verification

To determine if signature files have been downloaded successfully to an ASP, use the show dpi asp slot/asp-id traffic-management statistics signature-file command.

To verify the signature-file configuration, use the show configuration dpi command.

To list the applications supported by the current signature file used on an ASP, use the show dpi asp slot/asp-id traffic-management application command.

To list the application categories supported by the current signature file used on an ASP, use the show dpi asp slot/asp-id traffic-management category command. To list the applications in a category, add the category name.

2.1.2   BGF Features

2.1.2.1   Overload Protection

The SmartEdge Border Gateway Function (BGF) is protected against system overload, which can be caused by a spike in internal BGF CPU usage or external CPU usage from other modules and processes (also known as background load). The BGF system manages sudden increases in incoming call load and background load so that the system remains responsive and maximizes CPU utilization. To implement overload detection and control mechanisms, the BGF monitors the processing time for each H.248 transaction. If the BGF detects an overload condition, it selectively rejects new calls. If the average number of H.248 transactions per second that complete with latency is greater than:

H.248 transactions for established calls are not rejected when the BGF is overloaded.

No new commands were developed for this feature.

2.1.2.2   Network Security

In addition to the media flow gating, Network Address and Port Translation (NAPT), media source filtering, stream mode enforcement, and RTP Control Protocol (RTCP) handling, which all provide security for the core network, the SmartEdge router supports a set of native security features that extend the perimeter protection of the IMS core network. The SmartEdge router supports the following:

ACL rules can either permit or deny a packet based on the following match criteria:

Implicit checks are performed on incoming packets. Packets with an IP version other than IPV4 or IPv6, header length less than 20 bytes, incorrect header checksum, and so on, are dropped.

Packets dropped due to implicit checks, ACL violations, reassembly failures, and so on, are considered malicious traffic and optionally can be counted and logged. Counters are grouped into a number of categories for display purposes.

The malicious counters are aggregated to trigger a context-wide malicious traffic alarm when the counter reaches a high watermark. The alarm is cleared when the aggregated malicious traffic counter drops to or below a low watermark. Malicious traffic can be logged to syslog servers or local files.

2.1.2.2.1   Enhanced Match Criteria for ACLs

The ACL match criteria has been extended to permit or deny a packet based on:

Although you can permit or deny each new match criterion, it is recommended you deny it to prevent malicious traffic from entering your network.

The invalid-tcp-flags, fragmentsand ip-options match parameters are supported for IPv4 filter ACLs applied on the interface and IPv4 administrative ACLs. They are also supported on debug ACL rules. The setupoption is supported in all IPv4 ACL rules.

Table 1 describes the new keywords for the permit and deny commands.

Table 1    New ACL Match Criteria

fragments

Optional. Allows packet to be permitted or denied based on whether the packet is fragmented. This keyword matches packets where the More-Fragments field is equal to 1 or the IP-Offset field is not equal to 0.

ip-options

Optional. Specifies that IPv4 packets with the IP Header Length field greater than 20 bytes are a match.

setup

Optional. Specifies that TCP packets with SYN set and ACK not set in the Flags field are a match.


This keyword is only available if you specify tcp for the protocol argument.

invalid-tcp-flags

Optional. Specifies that TCP packets with flag combinations other than the following are a match:


  • SYN

  • SYN+ACK

  • ACK

  • PSH+ACK

  • URG+ACK

  • URG+PSH+ACK

  • FIN

  • FIN+ACK

  • RST

  • RST+ACK


Only the lower-order 6 bits (for example, FIN, SYN, RST, PSH, ACK, and URG) in the TCP Flags field are considered for validation. The higher order 6-bits (ECN bits defined by RFC 3168, The Addition of Explicit Congestion Notification (ECN) to IP, and the reserved bits) are ignored.


This keyword is only available if you specify tcp for the protocol argument.

For more information, see permit and deny.

The following restrictions apply to ACL match criteria:

The show ip access-list command, which is used to display the status of configured ACLs, has been enhanced to include the established keyword and the keywords described in Table 1. The established keyword allows you to specify that only established connections are to be matched and is only available if you specified tcp for the protocol argument.

2.1.2.2.2   Malicious Traffic Detection and Monitoring Commands

Table 2 describes the new commands that support malicious traffic detection and monitoring in the SmartEdge router:

Table 2    New Commands for Malicious Traffic Detection and Monitoring

Command

Description

Command Mode

alarms

In malicious-traffic configuration mode, configures alarm parameters for malicious traffic and enters malicious-traffic alarms configuration mode. In malicious-traffic context configuration mode, enables an alarm to be generated when the counters for malicious traffic reach a certain threshold.

malicious-traffic configuration


malicious-traffic context configuration

clear malicious-traffic log

Clear malicious traffic data.

 

counters

Enables the generation of malicious-traffic counters.

malicious-traffic context configuration

interval

Configures the time interval between reports of malicious-traffic counters to the SmartEdge OSSM Family OS.

malicious-traffic alarms configuration mode

logging malicious-traffic category

Enables logging of a specified category of malicious traffic.

context configuration mode

logging malicious-traffic file

Enables logging of malicious traffic messages to a file.

context configuration mode

logging malicious-traffic syslog

Enables logging of malicious traffic messages to a remote syslog server.

context configuration mode

logging rate-limit

Specifies the rate and burst limits for malicious traffic log events.

malicious-traffic configuration mode

malicious-traffic

In global configuration mode, configures malicious traffic parameters and enters malicious-traffic configuration mode. In context configuration mode, configures malicious traffic parameters and enters malicious-traffic context configuration mode.

global configuration context configuration

threshold

Specifies the high and low threshold values for malicious traffic alarms.

malicious-traffic alarms configuration

show malicious-traffic

Displays malicious traffic information.

all modes

For information about detecting and monitoring malicious traffic, see Configuring Malicious Traffic Detection and Monitoring.

2.1.2.2.3   RBN-SYS-SECURITY-MIB

To support system and network level security issues, RBN-SYS-SECURITY-MIB was added. Objects defined in this MIB are only accessible within the context identified in the SNMP protocol (the community string in SNMPv1 or SNMPv2, or the contextName in SNMPv3).

The SmartEdge router samples data at the start and end of the interval configured using the interval command in malicious-traffic configuration mode. The difference between the start and end of the interval is called the delta value.

You configure the high and low thresholds using the threshold command in malicious-traffic configuration mode.

RBN-SYS-SECURITY-MIB contains the following notifications:

The following objects support the notifications:

For more information, see Enterprise MIBs and SNMP MIB Notifications.

2.1.2.3   Support for IPv4 and IPv6 Payload Traffic

The SmartEdgeBGF now supports IPv4 and IPv6 payload traffic and IPv4-IPv6 protocol translation. To configure a SmartEdge BGF to support this feature:

  1. Use the ipv6 address command to configure an IPv6 interface with a /128 IPv6-address.
  2. Use the media-local-address command to configure the SmartEdge BGF router to use the configured /128 IPv6 address as the media address.

The show media-gateway [instance] statistic command is enhanced to include information about IPv6 traffic.

2.1.2.4   Detection of Hanging Terminations

The hangterm package is implemented according to the H248.36 standard. When the hangterm/thb is enabled on a termination, a timer is started when the Service Policy Decision Function (SPDF) sends a hangterm/thb event in the event descriptor of that termination. When the timer expires, an event notification is sent to the SPDF. If the termination is considered unused or unknown to the SPDF, it is deleted. The timer value can be provided by the SPDF in the hangterm/thb event; if it is missing, a configured value is used. The range for the configured default timer value is 0 to 86,400 seconds, with a default value of 3600. The value 0 disables hangterm detection for that specific termination. The timer is restarted for every Modify command on the termination and after every expiration event notification sent to the SPDF. The granularity of the timer is 300 seconds.

The following command has been enhanced for this feature:

timers—The hanging-terminationkeyword was added to specify the default timer value for detecting hanging termination in seconds.

2.1.2.5   Media Flow Gating

To protect the IP Multimedia Subsystem (IMS) core network from media fraud, the SPDF specifies to the BGF which streams are allowed to pass through the dynamic pinhole firewall and which pinhole criteria are valid per stream. The BGF allocates the IP address and port number to be used. The SPDF specifies the transport protocol, direction of media, and source filtering parameters to be used. To prevent media from an already terminated call to flow through new calls, the used ports are quarantined for a certain amount of time before they are used in new calls. To increase capacity when call volume is high, quarantined ports are used if all free ports are in use. The BGF only accepts Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) as transport protocols for media.

2.1.2.6   Configurable Value of Alarm Timer for Association Down

In previous releases, the link down alarm is implemented when the association goes down for 30 seconds. This timer is now configurable.

Use the new alarms h248-link-status BGF command to configure the timer used to raise the H248-Link-Status alarm.

2.1.2.7   Autonomous Pinhole Closing in BGF

BGF provides autonomous pinhole closing to optionally terminate all calls in the system when it cannot reestablish the H.248 association within the configured time limit. Once the BGF Association link with the Media Gateway Controller (MGC) is operationally down, the BGF starts a timer (configurable in the CLI). If the timer expires and BGF has not reestablished connection, it terminates all calls on the virtual Media Gateway (MG) and uses the initial start procedure to connect to MGC again. All call data is lost. The next ServiceChange message sent has Restart as the method and Cold Boot as the reason. This timer is started independently of the link-down alarm timer. By default, autonomous pinhole closing is disabled.

The call-cleanup keyword has been added to the existing timers command. Use this keyword to configure the value of the timer for closing pinholes or calls on a Virtual Media Gateway (VMG) when it cannot reconnect to the MGC.

2.1.2.8   QoS Address Handling

SmartEdge BGF allows configuration of up to two media address groups based on a specified Differentiated Services Code Point (DSCP) range value. Each media local interface configured under the realm can be attached to these newly configured groups. For more information, see QoS Address Handling in Reference [10].

The following new commands have been added for this feature:

The following command was enhanced for this feature:

media-local-address—The media-address-group keyword was added to specify the media address group to be attached to the interface.

2.1.2.9   KeepActive Flag

The BGF assumes that all events have the KeepActive flag; BGF does not cause any signal to stop. An events audit does not report a KeepActive flag. The KeepActive flag functionality is supported for latch signal. The Session Gateway Controller (SGC) starts the relatching process by including the signal latch. If later, the SGC modifies the termination signals descriptor, the SGC keeps the signal latch (to avoid the signal being stopped if it had not completed) and adds the KeepActive flag to prevent the signal latch from reactivating.

If the SGC adds a second stream and the latch state on the first stream is not known, then the SGC sends the signal descriptor with latch (without KeepActive) on second stream and latch (with KeepActive) on first stream.

The KeepActive flag, if applied, is reported in the Audit descriptor for the latch signal.

2.1.2.10   MSRP Support

In this release, the SmartEdge BGF supports Message Session Relay Protocol (MSRP). Clients that implement chat and media transfer using this protocol and are compliant with MSRP Alternate Connection Model (ACM) Ref 15 and MSRP session match Ref 16 can interoperate with this implementation. The BGF adds the MSRP URI in the a=path Session Description Protocol (SDP) attribute in the Local Descriptor and returns this information to the SGC. The path header contains the IP address from the c line and the port number from the m line of the SDP. For the TCP, TCP/MSRP media types the BGF latches to first TCP packet received. Once a TCP connection is established, the MSRP traffic flows through the BGF. The To/From-Path headers in MSRP packets are not modified. The BGF does not act as an MSRP Back-toBack User Agent (B2BUA) and so packets are not validated at the MSRP level.

2.1.2.11   Error Handling

The SmartEdge BGF tests for routing failures at call setup. If the endpoints are not routable at call setup, the call is rejected with an error response (error code 531). A route lookup is also performed during latching. A routing failure during latching generates a g/cause with generalcause as FP (Fault Permanent) and failurecause as No Route Found to MGC. During an active session, only media inactivity is detected.

2.1.2.12   Alarms

The following alarms and events are supported in this release:

rbnH248LinkStatusAlarm—This alarm is raised when the H.248 link for a vMG is detected to be down for more than the configured alarm interval because the MGC is not reachable, the MGC is administratively down, or there is no MGC configuration. The alarm has the vMG name “mgc-group-name/mgd-instance-id” as the identifier. This alarm and associated notification is always enabled for an active vMG.

The alarm is cleared in the following conditions:

2.1.2.13   New MIBs

This section describes the new Management Information Bases (MIBs) developed in this release.

2.1.2.13.1   RBN-ALARM-EXT-MIB

To support association-down alarms, RBN-ALARM-EXT-MIB has been added to define extensions to the standard ALARM-MIB, RFC 3877, Alarm Management Information Base (MIB).

The following tables are included in RBN-ALARM-EXT-MIB:

For more information, see Enterprise MIBs.

2.1.2.13.2   RBN-MEDIA-GATEWAY-MIB

To monitor link status, RBN-MEDIA-GATEWAY-MIB was added.

The RBN-MEDIA-GATEWAY-MIB contains the rbnH248LinkStatusAlarm notification, which indicates that the H.248 link for an MGC group was down for more than the configured timeout, with major severity. You configure the timeout value with the alarms h248-link-status command in global configuration mode; the default value is 30 seconds.

The following objects support the in rbnH248LinkStatusAlarm notification:

For more information, see Enterprise MIBs and SNMP MIB Notifications.

2.1.3   Forced PPPoE MRU

By default, the SmartEdge router uses an Maximum Received Unit (MRU) of 492 bytes for Point-to-Point Protocol over Ethernet (PPPoE) peers that do not negotiate MRU; this behavior complies with RFC 2516, A Method for Transmitting PPP Over Ethernet (PPPoE). In this release, the SmartEdge router supports connecting with non-negotiating PPPoE clients at MRUs other than 1492. This feature prevents unnecessary packet fragmentation when the downstream device does not negotiate MRU but can support larger packet sizes.

This feature is supported on any 802.1Q circuit that supports Point-to-Point Protocol (PPP) subscriber termination, including link aggregation groups, CCoDs, 802.1Q PVCs and 802.1Q tunnels; however, it is supported only for clients that do not negotiate MRU.

Table 3 describes the new command that supports this feature:

Table 3    New Commands for Forced PPPoE MRU

Command

Description

Command Mode

[no] ppp mru mru

Specifies the MRU to be used for PPPoE clients that do not negotiate MRU. The range is 256 to 12800. The default is 1492.


If a PPPoE session is using a 802.1Q profile with a configured PPP MRU, the value configured in the profile takes precedence over any other configured values for that PPPoE session

dot1q profile configuration

2.1.4   CFM MEPs and MIPs on Transport-Enabled VLAN-Based Circuits

You can configure Ethernet Connectivity Fault Management (CFM) Maintenance Association End Points (MEPs) and Maintenance Association Intermediate-Points (MIPs) on transport-enabled Virtual LAN (VLAN)-based circuits.

2.1.4.1   New or Changed Commands

The newtransport argument in the ethernet-cfm linktrace and ethernet-cfm loopback commands consists of the transport keyword followed by the VLAN identifiers of the linktrace or loopback initiator or the any keyword. Specifically, the syntax for the transport argument is:

The new rmep argument allows you to specify the remote MEP ID instead of the remote MEP Medium Access Control (MAC) address when sending loopbacks or link traces. Use the following syntax:

The mep-local and mip configuration commands are changed to allow binding to transport-enabled circuits. The new transport argument has the same syntax as in the loopback and linktrace commands:

The show ethernet-cfm errors command has been added to display any CFM error conditions detected in the specified Maintenance Association (MA), including CFM configuration errors.

2.1.4.2   SNMP Changes

The dot1agCfmFaultAlarm now reports if a remote MEP caused the defect; the IDs of both the remote MEP and its peer local MEP are reported in the dot1agCfmMep Identifier object.

2.1.4.3   Verification

After verifying the configuration, use the show ethernet-cfm database command to monitor the transport-enabled circuits to which MEPs and MIPs are bound.

2.1.5   Support for BVI with RSTP

With this release, you can use Bridged Virtual Interfaces (BVIs) with Rapid Spanning Tree Protocol (RSTP) in your network. You can alternatively bind the bridge interface to an Link Aggregation Group (LAG); RSTP with BVI works over the LAG.

The release also supports Virtual Router Redundancy Protocol (VRRP) for BVI IP addresses with RSTP on a bridged network.

For more information, see Configuring Bridging.

Use the show spanning-tree bridge-name circuit detail command to verify the status of Spanning Tree Protocol (STP) and the circuits with which it interfaces.

2.1.6   L2TPv3 Lite Tunnels over VPLS PWs

You can now configure Layer 2 Tunneling Protocol Version 3 (L2TPv3) lite tunnels over Virtual Private LAN Services (VPLS) Pseudowires (PWs). L2TPv3 lite tunnel service enables you to provide Layer 2 tunneling service over a non-Multiprotocol Label Switching (MPLS)-based IP backhaul network. In this configuration, the VPLS PWs function like L2TPv3 tunnels that terminate in a VPLS instance.

When configuring the SmartEdge router for L2TPv3 lite tunnels encapsulated in VPLS PWs, you use the new static encapsulation l2tpv3 command to specify a static L2TPv3 encapsulation consisting of a 32-bit session ID and 32-bit cookie.

When a packet is sent from the router over the VPLS PW, it adds the L2TPv3 header to the inner MPLS packet. The L2TPv3 header is followed by a 32-bit MPLS label stack. When a non-MPLS remote peer receives a packet on the tunnel, it treats the packet as an L2TPv3 packet sent with a 64-bit cookie.

When an L2TPv3 packet with 64-bit cookie is received by the SmartEdge router, it treats the packet as an L2TPv3 packet with a 32-bit cookie arriving over MPLS. The SmartEdge router strips off the session ID and 32-bit cookie and extracts the 32-bit MPLS label stack embedded in the lower 32 bits of the cookie. The embedded MPLS label stack then identifies the VPLS PW corresponding to the tunnel, and the packet is injected into the corresponding VPLS instance.

Note:  
When QoS propagation is enabled for static L2TPv3 encapsulation, the MPLS EXP values are updated. This can cause remote peers that validate the cookie to drop the packet. To prevent this, configure class maps to set the EXP bits to 0.

For more information, see Configuring VPLS.

2.1.6.1   New or Changed Commands

The following new command has been added for this feature:

static encapsulation l2tpv3

2.1.6.2   Verification

Use the show vpls peer detail command to verify L2TPv3 encapsulation and the cookie and session-ID parameters.

To verify L2TPv3 tunnel information, use the show ip route next-hop command.

2.1.7   Enable Link Dampening after System Restart

To enable subscribers to maintain a steady state during a restart, you can enable dampening of link-state detection.

For more information, see Configuring ATM, Ethernet, and POS Ports.

2.1.7.1   New or Changed Commands

To enable this feature, use the restart restart-delay construct in thelink-dampening command (in port configuration mode) with the following syntax:

link-dampening [up up-delay down down-delay restart restart-delay]

This optional construct specifies the delay before declaring a port up after a system restart. The range of values is 0 to 65,535 seconds. Without this construct, the default value is 0.

2.1.7.2   Verification

Use the show port command with the detail keyword (in any mode) to display the state of link dampening for this port.

2.1.8   Traffic Management Support

TM available in the SmartEdge router provides robust queuing and hierarchical scheduling capabilities along with the necessary packet buffering capabilities for the management of access networks. TM is used to manage oversubscription and service level agreement (SLA) enforcement, and provide differentiated levels of service for different types and classes of traffic on both layer 3 (for example, IP routed) and layer 2 (for example, cross-connected and bridged) networks. This release of the SmartEdge router :

2.1.8.1   TM Support on a 10 GE (4-port) Card

In addition to supporting traditional TM on TM-capable GE cards and other TM-capable interfaces with a line speed equal to or less than 1 Gbps, the SmartEdge router now supports virtual-port TM. Virtual-port TM is only supported on a the 10 GE (4-port) card. In virtual port TM, high-speed port traffic is partitioned into multiple lower-bandwidth scheduling domains using VPCGs. Each physical port or access link group is divided into virtual ports with a maximum of 10 virtual ports per port. Each virtual port forms the top of a TM scheduling tree as a virtual-port scheduling node and can schedule up to 1Gbps of traffic, for a total of 10 Gbps of TM-scheduled line-rate traffic. Traffic within each virtual port is scheduled independently.

Hierarchical scheduling in virtual-port TM is a hybrid of MDRR and PWFQ scheduling. Multiple virtual-port scheduling nodes are attached to the port (L4 node). Logically, the virtual port is a level of aggregation below the port. You assign L3 and L2 nodes to virtual ports instead of a physical port. Since children follow their parent, the top-most node determines the virtual-port assignment of all the nodes below it. A topmost node may be an L3 or L2 node. PWFQ is used to schedule the traffic within each virtual port.

The default port queues for 10 GE ports only support MDRR. This ensures that a 10-GE wire speed is achievable using the default port queues. On each physical port, the output from the virtual ports is combined and scheduled by the MDRR scheduler before egressing the port.

You can assign a circuit to a virtual port by making the circuit a member of the Virtual Port Circuit Group (VPCG). The SmartEdge router supports the following methods of VPCG assignment for virtual ports:

The following applies to VPCGs:

The following applies to a child of a VPCG:

On affected ports and link groups, a circuit must be associated with a VPCG either directly or through inheritance before the circuit can accept any of the following PWFQ configuration commands:

A VPCG supports all of the functionality of a homed circuit group, including:

Restrictions

The following configuration restrictions apply to VPCGs:

CLI Changes

The following are the new and modified commands to support virtual-port TM:

VSA 210, Circuit_Group_Member has been added to support virtual port TM. This VSA is used to specify that the subscriber is a member of the specified circuit group.

See Virtual Port Circuit Groups and SmartEdge OS Traffic Management for more information about this feature.

2.1.8.2   TM-capable Cards Support MDRR and PWFQ Coexistence

All TM-capable cards now support the coexistence of configured MDRR and PWFQ policies on circuits within a port. Each circuit can only exist in one schedule cone (either MDRR or PWFQ) at a time.

MDRR and PWFQ policy coexistence allows you to selectively divide the traffic across hardware-based (MDRR) queues and software-based (PWFQ) queues. It also allows individual circuits to be scheduled at rates greater than the maximum allowed by PWFQ (1 Gbps). For example, a Permanent Virtual Circuit (PVC) used for carrying high bandwidth traffic, such as multicast video. Currently, the only virtual-port TM card supported is the 10 GE (4-port) card.

Table 4 lists the guidelines for MDRR and PWFQ policy coexistence along with any exceptions.

Table 4    MDRR and PWFQ Policy Coexistence Guidelines

Guideline

Exceptions

MDRR bindings must always act as leaf nodes in the scheduling hierarchy. A leaf node refers to the last (or lowest) queuing and scheduling node in the context of the hierarchy as shown in the following examples of valid configurations:


  • Valid Configuration

    port ethernet 1/1
    	 encapsulation dot1q
    	  dot1q pvc 1 encapsulation 1qtunnel
     	   qos rate maximum 1024
    	   qos policy queuing pwfq1
    	   dot1q pvc 1:1 encapsulation pppoe
     	    qos policy queuing mdrr1     <==== leaf node
    

  • Valid Configuration

    port ethernet 1/1
    	 encapsulation dot1q
     	 qos policy queuing pwfq1
    	  dot1q pvc 1 encapsulation 1qtunnel
     	   qos rate maximum 1024
    	   qos policy queuing mdrr1        <====  leaf node
    	   dot1q pvc 1:1 encapsulation pppoe
    


The following example shows an invalid configuration of a leaf node:


Invalid Configuration

  port ethernet 1/1
	 encapsulation dot1q
	  dot1q pvc 1 encapsulation 1qtunnel
 	   qos rate maximum 1024
	   qos policy queuing mdrr1
	   dot1q pvc 1:1 encapsulation pppoe
 	    qos policy queuing pwfq1    <====  invalid leaf node


Non leaf-node MDRR bindings are allowed on ports and top-level link group circuits.

PWFQ bindings may not be applied to a circuit that is subordinate in the circuit hierarchy to a circuit with an MDRR binding.

The parent port or link group may have an MDRR policy binding; this will not prevent the application and enforcement of PWFQ policy bindings on subordinate circuits like 802.1q PVCs and subscribers, but the MDRR policy parameters will not apply to the traffic of such subordinate circuits with a PWFQ binding.

A TM-capable port may have either an MDRR or PWFQ policy configured on it. The exception is that PWFQ policies cannot be applied on port or link group circuits within virtual-port TM cards.


None

See MDRR and PWFQ Coexistence for more information.

2.1.9   rate circuit Command Supported for MDRR Bindings

In this release, the rate circuit command now applies to MDRR policy bindings on both physical and access link-group circuits. Prior to this release, the rate circuit out command only modified the PWFQ and metering bindings.

Now, the rate circuit out command also allows you to modify both the rate and the burst of an MDRR binding. Use the new optional queuing-burst bytes construct to configure the queuing burst tolerance of an MDRR binding. The range of values is 1 to 8,000,000. This construct only applies to MDRR policy bindings.

Note:  
The existing burst bytes parameter modifies the burst tolerance of a metering binding (PWFQ does not support burst tolerance). The queuing-burst bytesparameter was introduced so that a circuit's metering and MDRR burst tolerance values can be modified independently where applicable.

Following is the updated syntax for the rate circuit command:

rate circuit {in | out} kbps burst bytes [excess-burst bytes] [queuing-burst bytes]

Note:  
Currently, no support exists for using RADIUS, AAA, TR-101, or Access Node Control Protocol (ANCP) to customize the MDRR circuit level rate.


2.1.10   RMR QoS Rate Adjustment

This release introduces RMR QoS rate adjustment. When functioning as a Broadband Remote Access Server (BRAS), the SmartEdge router can perform traffic management on a VLAN or a subscriber session that represents the flow of traffic destined for an access line. When a subscriber joins a multicast channel, the subscriber’s bandwidth needs to be adjusted downwards so as to prevent downstream congestion at access node (AN) or DSLAM. RMR QoS rate adjustment helps avoid downstream congestion.

As an example, the SmartEdge router may enforce a downstream rate of 10 Mbps for a DSL subscriber that is matched to the physical downstream sync speed of the subscriber's access line. If the SmartEdge router allows up to 10 Mbps of traffic for the subscriber, but an additional 2 Mbps of multicast traffic is inserted downstream for the subscriber (by the RMR Multicast Replicator for an Internet Protocol Television (IPTV) channel that the subscriber is viewing), the forwarding capacity of the access line is exceeded and may lead to some loss of traffic. When RMR QoS rate adjustment is enabled and the SmartEdge router receives a subscriber's Internet Group Management Protocol (IGMP) join, it reduces the rate of traffic admitted toward the subscriber to 8 Mbps, reserving 2 Mbps to account for additional traffic that is added downstream by the multicast replicator. This adjustment ensures that the capacity of the access line is never exceeded.

In this release, the SmartEdge router only supports adjusting either the rate of PWFQ queuing or metering binding or adjusting the rate for both queuing or metering when applied to a given circuit.

2.1.10.1   Updated Configuration Commands

The following existing IGMP commands have been updated to accommodate the capabilities of this feature:

2.1.10.2   Revised Show Commands

When the RMR QoS rate adjustment is enabled, the following show commands display additional information:

2.1.11   BGP Graceful Restart Support for Labeled Address Families

In previous releases, BGP graceful restart negotiation was not supported for labeled address families. In Release 6.4.1.1, BGP graceful restart negotiation is supported on all IPv4 and IPv6 address families, including:

Note:  
You must use the send label command to enable negotiation of IPv4 and IPv6 labeled address families.

The show bgp neighbor command output is enhanced to include information pertaining to IPv4 and IPv6 labeled address families.

See Configuring BGP for more information about this feature.

2.1.12   BGP Minimum Route Advertisement Interval

The SmartEdge router now supports an Minimum Route Advertisement Interval (MRAI) of 0, so that BGP routing updates are immediately sent to the specified neighbor.

The MRAI starts when an UPDATE message is sent to a BGP neighbor or peer group. After sending an UPDATE message to the specified BGP peers, the router waits for the specified MRAI before sending the next UPDATE message. If a route change occurs and the MRAI has passed since the last UPDATE message was sent, the router immediately sends an UPDATE message to the peer. If a route change occurs and the MRAI has not passed since the last UPDATE message was sent to the peer, the router waits the specified MRAI before sending a new UPDATE message.

Use the advertisement-interval 0 command to set the BGP MRAI to 0.

See Configuring BGP for more information about the BGP MRAI.

2.1.13   BGP Fast-Reset Interval Enhancement

To improve BGP convergence and response time to adjacency changes with BGP neighbors, the SmartEdge OS now allows the BGP fast-reset interval to be set to 0, which triggers an immediate fast reset of a BGP peer session when the links used to reach a neighbor go down.

Use the fast-reset 0 command in one of the following modes to trigger an immediate fast reset:

Note:  
The ` fast-reset configuration for a particular neighbor takes precedence over the BGP fast-reset configuration for a peer group.

See Configuring BGP for more information about BGP fast reset.

2.1.14   Verification of the First AS Number in a Received AS Path from an eBGP Peer

You can now optionally disable the verification of the first Autonomous System (AS) number in a received AS path from an eBGP peer.

Use the new [no] enforce first-as command in BGP router configuration mode to disable (or reenable, if disabled) the verification of the first AS number in a received AS path from an eBGP peer.

By default, a BGP router compares the remote AS number of an eBGP peer with the first AS number in the paths received from that peer. If those AS numbers do not match, the BGP router:

See Configuring BGP for more information about this feature.

2.1.15   Packet Replication for High-Bandwidth Multicast Traffic

You can enable Packet Mesh ASIC (PMA)-based traffic replication to efficiently manage high-bandwidth multicast applications such as IPTV.

A maximum of two line cards per router can be enabled for optimizing replication. For example, you can configure two uplink (or trunk) ports to carry IPTV traffic for distribution among downlink ports. On the packet mesh, the QoS priority of optimized multicast traffic is fixed at a level between the DSCP value of unicast EF class (CS5) and AF4 class (CS4). Enabling or disabling this feature causes a momentary traffic interruption of less than one second.

The following card configuration mode command has been added to enable this feature:

optimize replication

2.1.16   BFD Support on PIM Interfaces

Bidirectional Forwarding Detection (BFD) is now supported on Protocol Independent Multicast (PIM) interfaces. By default, BFD is enabled on PIM interfaces and for each neighbor on the interface; however, you can disable BFD for the interface by using the new no pim bfd command.

Note:  
Use the pim bfd command to reenable BFD on a PIM interface that has BFD disabled.

The show pim interface and show pim neighbor commands are enhanced to include information about whether BFD is enabled (Up) or disabled (Down) on a PIM interface.

The new debug pim bfd command enables generation of PIM BFD debug messages.

2.1.17   SNMP Trap Support for ASP State Change

The SmartEdge router supports ASP down alarms for Simple Network Management Protocol (SNMP). If ASP fails, an SNMP card alarm trap is generated. When the ASP is functional after being down, an SNMP card alarm trap is generated to indicate that the alarm is cleared.

Note:  
You cannot set or reset this alarm, it can only be cleared.

The RBN-CARDMON-MIB and RBN-NOTIFY-ENHANCE-MIB rbnCardAlarm notifications have two rbnCardAlarmId values to support ASP failure:

The new ASP alarm ID and MIB object values assigned for the ASP alarms are summarized in Table 3.

Table 5    ASP Alarm ID and MIB Object Values

Alarm ID

Severity

Description

Alarm Type

Probably Cause

Service Affecting

aseAsp1Down(82)

Critical(2)

ASP 1 down

equipmentAlarm(5)

processorProblem(59)

Yes(1)

aseAsp2Down(83)

Critical(2)

ASP 2 down

equipmentAlarm(5)

processorProblem(59)

Yes(1)

2.1.18   AAA Route Download

The SmartEdge router allows you to configure and advertise IPv4 access routes before the routes have been assigned to subscribers. More than one RADIUS server can be designated as a route download server.

When this feature is enabled, the SmartEdge router periodically sends a RADIUS Access-Request message to the RADIUS server acting as a route download server, requesting to download routes. To respond, the RADIUS server sends an Access-Accept message containing a set of routes within the RFC-specified RADIUS packet length.

2.1.18.1   New Configuration Commands

The following new AAA Route Download commands have been added to accommodate the capabilities of this feature:

2.1.18.2   Updated Configuration Commands

The following AAA Route-Download commands have been updated to accommodate the capabilities of this feature:

2.1.18.3   New Show Commands

When AAA Route-Download is enabled, the following new show commands display important information:

2.1.18.4   Updated Show Commands

When the AAA Route-Download feature is enabled, the following show commands display additional information:

2.1.19   New RADIUS VSA for Monitoring ICR Failover Events

The Cluster-Partition-ID RADIUS VSA is sent in subscriber Access-Request and Accounting-Request messages that indicate the VRRP partition ID used to bring up the session. This new VSA is used to identify Inter-Chassis Redundancy (ICR) failover events.

2.1.19.1   New RADIUS Attributes

VSA 209 209

String (up to 243 characters) sent in Access-Request and Accounting-Request messages to provide the VRRP partition ID.

After a VRRP state transition, this VSA contains a new value for the VRRP partition ID (in the Access-Request and Accounting-Request messages). The subscriber sessions initiated before the VRRP transition are cleaned up.

The SmartEdge OS populates this attribute with the description string configured under the VRRP monitoring circuit with the VRRP state this subscriber circuit is tracking.

For more information, see RADIUS Attributes.

2.1.20   36 RADIUS CoA Servers Now Supported Per Context

With this release, you can configure up to 36 RADIUS CoA servers per context, using the existing radius coa server command.

The feature is supported on the SmartEdge 100, 400, 800, and 1200 platforms with XCRP3 and XCRP4 controller cards.

RADIUS CoA servers support the following subscriber types: PPPoE, Point-to-Point Protocol over Asynchronous Transfer Mode (PPPoA), L2TP (LAC and LNS), and IP over Ethernet (IPoE) using Dynamic Host Configuration Protocool (DHCP) or Clientless IP Service Selection (CLIPS).

2.1.21   LAC Support for Dual-Stack Subscribers

When configured as an L2TP Access Concentrator (LAC), the SmartEdge router now supports IPv6 and dual-stack subscribers.

For information on configuring the SmartEdge router as an LAC, see Configuring L2TP.

For information on configuring the SmartEdge router to provide subscriber services to IPv6 and dual-stack subscribers, see Configuring IPV6 Subscriber Services.

There are no new or enhanced commands associated with this feature.

2.1.22   Support for IPv6 Prefix Error Detection

The SmartEdge OS detects any duplicate IPv4 addresses and IPv6 prefixes during session authentication.

With dual-stack subscribers, the IPv4 and IPv6 sessions function independently of one another. By default, if a duplicate IPv4 address or IPv6 prefix is detected during the authentication phase for a dual-stack subscriber:

The session-action dual-stack-failure command is enhanced to include the dual-stack-failure keyword. Use the session-action dual-stack-failure command in subscriber configuration mode to modify the default behavior so that the entire dual-stack session fails if the router detects duplicate IPv4 addresses or IPv6 prefixes during session authentication.

For more information about duplicate IPv6 prefix and IPv4 address conflicts, see Configuring IPV6 Subscriber Services.

2.1.23   Support for IPv6 Path MTU Negotiation

The SmartEdge OS now supports IPv6 Path Maximum Transmission Unit (PMTU) negotiation.

Use the new ipv6 path-mtu-discovery discovery-interval command in global configuration mode to globally enable IPv6 PMTU negotiation on the router and configure the timeout value used for aging PMTUs.

When IPv6 PMTU discovery is enabled, the source router fragments into multiple smaller packets any IPv6 packet that exceeds the Maximum Transmittion Unit (MTU) of the receiving node. In addition, the source router reduces the MTU for that particular hop (the path between the source and the receiving routers) to match the MTU of the receiving router. This process is repeated for all hops in a path. If all nodes support MTU discovery, the MTU of the entire path is eventually discovered, ensuring that all packets sent on that path reach their destination.

See Configuring Basic IP Routing for more information about PMTU negotiation.

2.1.24   Support for IPv6 Packets on Network-Facing IEEE 802.3ad Link Groups

With this release, the SmartEdge OS supports IPv6 packets on network-facing IEEE 802.3ad link groups; that is, on both the Ethernet and 802.1Q link group types. 802.3ad link groups are also known as link aggregation groups (LAGs).

Network-facing LAGs support all IGPs supported by the SmartEdge router: OSPF3, Routing Information Protocol Next Generation (RIPNG), and Intermediate System-to-Intermediate System version 6 (ISISv6).

Use IPv6 ping and link-trace to verify packet forwarding.

2.1.25   IPv6 Subscriber Licensing

The SmartEdge router now requires you to enable an IPv6 subscriber license before you configure IPv6 subscriber services.

In software license configuration mode, use the subscriber command as follows to enable an IPv6 subscriber license on the SmartEdge router:

subscriber active ipv6 sub-num password password

Replace the sub-num argument with the number of active subscriber sessions licensed, using one of the following keywords:

Replace the password argument with the unencrypted paid license password required to enable the IPv6 subscriber function.

Note:  
For IPv6 subscriber sessions, the SmartEdge router supports only unencrypted passwords.

Consider the following when enabling an IPv6 license on the SmartEdge router:

The new show subscribers summary command displays information about the subscriber sessions on the system. You can display information about IPv4, IPv6, and dual-stack subscriber sessions.

The new show subscribers license summary command displays information about the subscriber licenses currently used by the system.

2.1.26   Support for IPv6 Pools and Statically Mapped DHCPv6 PD Prefixes

In prior releases, the SmartEdge OS IPv6 subscriber services supported only administratively configured Dynamic Host Configuration Protocol Version 6 (DHCPv6) PD and Neighbor Discovery (ND) IPv6 prefixes. In Release 6.4.1.1, DHCPv6 obtains IPv6 prefixes from:

ND obtains IPv6 prefixes from:

For detailed information about configuring DHPCv6 PD and ND for IPv6 subscriber services, see Configuring IPV6 Subscriber Services.

The following new commands support configuration of DHCPv6 PD and shared IP pools:

The show subscribers command is enhanced to include information related to IPv6 pools.

2.1.26.1   Changes to RBN-IPPool-MIB

In this release, to support the addition of IPv6 pools to IPv6 subscriber services, the following changes have been made to RBN-IPPOOL-MIB:

For more information, see Enterprise MIBs and SNMP MIB Notifications.

2.1.26.2   Changes to RBN-SUBSCRIBER-ACTIVE-MIB

In this release, to support the addition of IPv6 pools to IPv6 subscriber services, the following new objects have been added to rbnSubsCntxtCountTable in RBN-SUBSCRIBER-ACTIVE-MIB:

For more information, see Enterprise MIBs.

Also, to support IPv6 subscriber services, support for the following standard SNMP MIBs has been updated:

2.1.27   DHCPv6 and ND DoS Protection

New commands have been added to limit the effect of DHCPv6 and ND packet DoS attacks.

The following commands have been added:

rate-limit dhcpv6

rate-limit nd

2.1.27.1   Verification

Although the configuration of these commands can be verified, you cannot verify the operation of these commands without laboratory simulation of a DoS attack.

2.1.28   New Documentation

2.1.28.1   New Software Documentation

With this release, the Configuring Malicious Traffic Detection and Monitoring document has been added to the SmartEdge Library. To view this document, navigate to the Operational and Maintenance -> Security Management -> Configuring Malicious Traffic Detection and Monitoring directory.

2.1.28.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 Operational 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.4.1.

3.1   New Hardware or Changes to Hardware in Release 6.4.1.1

The following hardware is introduced or changed in this release.

3.1.1   New and Modified Transceivers

Table 6    Transceiver Order Numbers

Redback P/N

ABC P/N

INE P/N

CLEI Code

Transceiver Description

Supported Line Card

SFP-OC48-LR2

RDH90172/1

N/A

SOOTAK1TAA

SFP optical transceiver, OC-48 Long-Reach, SMF using LC connector

POS OC-48c/STM-16c (4-port)

N/A

RDH90191/1

N/A

IPUIBH72AA

SFP optical transceiver, OC-12, MMF using LC connector

ATM OC-12c/STM-1c (2-port)

N/A

RDH90183/1

N/A

SOOTAK5TAA

SFP 1000BASE-BX10 Bidirectional optical transceiver. 1490nm TX, 1310nm RX, SMF using LC connector

Gigabit Ethernet 3 (4-port)


Gigabit Ethernet 1020 (10-port)


Gigabit Ethernet 1020 (20-port)


Gigabit Ethernet (5-port)


Gigabit Ethernet (20-port)


Gigabit Ethernet DDR (10-port)

N/A

RDH90184/1

N/A

SOOTAK6TAA

SFP 1000BASE-BX10 Bidirectional optical transceiver. 1310nm TX, 1490nm RX, SMF using LC connector

N/A

RDH90190/35

N/A

IPUIBH82AA

OTN XFP optical transceiver, 10GE DWDM, ITU Channel 35, SMF using LC connector

10 Gigabit Ethernet (4-port)


10 Gigabit Ethernet/OC-192c DDR (1-port)(1)

N/A

RDH90190/36

N/A

IPUIBH92AA

OTN XFP optical transceiver, 10GE DWDM, ITU Channel 36, SMF using LC connector

N/A

RDH90190/37

N/A

IPUIBJA2AA

OTN XFP optical transceiver, 10GE DWDM, ITU Channel 37, SMF using LC connector

N/A

RDH90190/53

N/A

IPUIBJB2AA

OTN XFP optical transceiver, 10GE DWDM, ITU Channel 53, SMF using LC connector

N/A

RDH90190/55

N/A

IPUIBJC2AA

OTN XFP optical transceiver, 10GE DWDM, ITU Channel 55, SMF using LC connector

(1)  This line card is supported on the SmartEdge 400, 600, 800, 1200, and 1200H routers.


3.1.2   New Cards

3.1.2.1   2-Port ATM OC12c/STM-4c Card

The 2-port ATM OC-12c/STM-4c card (atm-oc12e-2-port) is designed as a subscriber-facing module and a network uplink module.

This PPA2-based, third-generation ATM OC-12c/STM-4c card has an increased minimum memory capacity of 1 GB. It also has increased circuit density of 24K with eight Class of Service (CoS) queues, or 32K with two or four CoS queues. The 2-port card provides improved performance and supports more Asynchronous Transfer Mode (ATM) VPs and PVCs than the 1-port card.

This card supports OC-12c/STM-4c SR-0, SR-1, and IR-1 SFP transceivers.

3.1.2.2   10-Port Gigabit Ethernet DDR Card

The 10-port Gigabit Ethernet DDR-based (ge2-10-port) card is designed for traffic management using second-generation PPAs. This card has an increased minimum memory capacity of 1 GB and can process data internally to match the speed of the ports. It also has increased circuit density of 32K with a minimum of 24K with eight CoS queues.

This card supports 1000Base- SX, LX, ZX, TX, BX-D-20, BX-U-20, CWDM, and DWDM SFP transceivers.

3.1.2.3   1-Port 10 Gigabit Ethernet/OC-192c DDR Card

The 1-port 10GE/OC-192c DDR-based (10ge-oc192-1-port) card designed for traffic management using second-generation PPAs. This multimode DDR card supports the 10GE LAN-PHY, 10GE WAN-PHY, 10GE-DWDM, POS OC-192c, OC-192c DWDM, or OTN-DWDM modes for the SmartEdge routers.

This card supports a minimum of 1 GB of memory capacity and can process data internally to match the speed of the port — 10.3125 Gbps in 10GE LAN-PHY or 10GE-DWDM mode; 9.953 Gbps in 10GE WAN-PHY, POS OC-192c, or OC-192c DWDM mode; and 11.0957 Gbps in OTN-DWDM mode.

For 10GE LAN-PHY, 10GE WAN-PHY, 10GE-DWDM, or OTN-DWDM mode, the maximum MTU is 9,198 bytes; for POS OC–192c or OC–192c DWDM mode, 12,800 bytes.

This card supports 10GE- SR/SW, LR/LW, ER/EW, ZR/ZW, DWDM, OTN-DWDM; and OC-192c/STM-64c SR-1, IR-2, LR-2 XFP transceivers.

3.1.3   End-of-Life Cards

The following cards are not supported in release 6.4.1.1 and future releases.

4   PPA Feature Support

This section describes PPA support for features introduced in Release 6.4.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.4.1.1

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

Table 7    PPA Feature Support for Release 6.4.1.1

Feature

PPA1

PPA2

PPA3

Notes

Advanced Services Features

No

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 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.

BGF Features

No

Yes

Yes

 

Forced PPPoE MRU

No

Yes

Yes

 

CFM MEPs and MIPs on Transport-Enabled VLAN-based Circuits

Yes

Yes

Yes

 

Support for BVI with RSTP

No

Yes

Yes

 

L2TPv3 Lite Tunnels over VPLS PWs

No

Yes

Yes

 

Enable Link Dampening After System Restart

Yes

Yes

Yes

This feature can be enabled for all ATM, Ethernet (including Gigabit Ethernet), and POS line cards that support link-dampening on the SmartEdge 100, 400, 600, 800, 1200 and 1200H platforms.

TM support on a 10 GE (4-port) Card

No

No

Yes

 

TM-capable cards support MDRR and PWFQ coexistence

No

Yes

Yes

 

rate circuit command supported on MDRR policies

No

Yes

Yes

 

RMR QoS Rate Adjustment

Partial

Yes

Yes

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

BGP graceful restart support for labeled address families

Yes

Yes

Yes

 

BGP minimum route advertisement interval

Yes

Yes

Yes

 

BGP fast-reset interval Enhancement

Yes

Yes

Yes

 

Verification of the first AS number in a received AS path from an eBGP peer

Yes

Yes

Yes

 

Packet Replication for High-Bandwidth Multicast Traffic

No

No

Yes

This feature is only supported on the following PPA3-based line cards:


  • Gigibit Ethernet 20 port (ge4-20-port)

  • 10 Gigabit Ethernet 4 port (10ge-4-port)

BFD support on PIM interfaces

No

Yes

Yes

 

AAA Route Download

No

Yes

Yes

 

New RADIUS VSA for Monitoring ICR Failover Events

No

Yes

Yes

This feature is supported on all PPA2 and PPA3-based Ethernet cards.

36 RADIUS CoA servers now supported per context

No

Yes

Yes

 

Network security

No

Yes

Yes

 

LAC support for dual-stack subscribers

No

Yes

Yes

 

Support for IPv6 Prefix Error Detection

No

Yes

Yes

 

Support for IPv6 Path MTU Negotiation

No

Yes

Yes

 

Support for IPv6 Packets on Network-Facing IEEE 802.3ad Link Groups

No

Yes

Yes

This feature is supported on all PPA2 and PPA3-based Ethernet cards.

IPv6 subscriber licensing

No

Yes

Yes

Supported on the following PPA2-based traffic cards only:


  • PPA2-based 10-port Gigabit Ethernet

  • 2-port 60 Fast Ethernet–Gigabit Ethernet

  • 1-port 10 Gigabit Ethernet


Supported on the following PPA3-based traffic cards only:


  • PPA3-based 10-port Gigabit Ethernet

  • PPA3-based 20-port Gigabit Ethernet

Support for IPv6 pools and statically mapped DHCPv6 PD

No

Yes

Yes

 

DHCPv6 and ND DoS Protection

No

Yes

Yes

This feature is supported on all PPA2 and PPA3-based Ethernet cards.

5   Required System Components

This section describes the system components required in Release 6.4.1.

5.1   Required System Components in 6.4.1.1

The following system components are required in this release.

5.1.1   Required Boot ROM Versions

Release 6.4.1.1 requires the boot ROM versions listed in Table 8.

Table 8    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

5.1.2   Required Minikernel Versions

Release 6.4.1.1 requires the minikernel versions listed in Table 9.

Table 9    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

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.

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 Release 6.4.
  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.

7   APS Traffic Card and Feature Compatibility

This section describes the traffic cards and features supported by Automatic Protection Switching (APS) port for SmartEdge routers.

7.1   POS APS Ports

Table 10 lists the traffic cards that support POS APS ports.

Table 10    Traffic Cards That Support POS APS

Traffic Cards Supported

Notes

OC-3c/STM-1c


OC-12c/STM-4c


OC-48c/STM-16c

Working and protection ports must be on the same type of card.


Working and protection ports must have identical configuration.

Note:  
POS APS is not supported on the 4-port POS OC-48c/STM-16c card.

Table 11 summarizes encapsulation and feature compatibility for POS APS ports.

Table 11    POS APS Feature Compatibility

Feature

Supported

Notes

Encapsulation

   

Cisco High-level Data Link Control (HDLC)

Yes

Required

PPP

Yes

 

Static CLIPS

No

 

Dynamic CLIPS

No

 

Routing RIP

Yes

 

OSPF

Yes

 

ISIS

Yes

 

PIM

Yes

 

BGP

Yes

 

IP Services

Yes

 

IP Service Policies

   

NAT

Yes

 

Forward policy

Yes

 

Service policy

Yes

 

IP Security

   

AAA

Yes

 

RADIUS

Yes

 

TACACS+

Yes

 

Circuit Types

   

On-demand

No

 

On-demand via AAA

No

 

Explicit ranges

No

 

Tunnels GRE

Yes

 

L2TP LNS

Yes

 

L2TP LAC

Yes

 

QoS Policing/metering

Yes

 

PWFQ (queuing)

No

 

Flow Admission Control

No

PPA2 cards only

Management

   

NetOp EMS

Yes

Configuration and monitoring of Frame Relay circuits is supported

SNMP

Yes

 

APS

   

RDI-P

Yes

Required

REI-P

Yes

Required

1+1

Yes

 

1:1

No

 

1:N

No

 

Bidirectional switching

Yes

 

Unidirectional switching

No

 

Revertive switching

Yes

 

Nonrevertive switching

Yes

Default

Use of protection line for extra traffic

Yes

Can be enabled or disabled

MPLS Services

   

Cross-connect

No

 

Bridging (VPLS)

No

 

L2VPNs

Yes

Frame Relay DLCI; no Ethernet resiliency

MPLS

Yes

 

Scalability

   

Maximum PVCs per group

16,000

 

Maximum protected PVCs per system

48,000

 

Maximum APS groups per system

8

 

Switchover time

<2.5 seconds

 

Glossary

AAA
Authentication, Authorization, and Accounting
 
ACM
Alternate connection model
 
ANCP
Access Node Control Protocol
 
APS
Automatic Protection Switching
 
AS
Autonomous System
 
ASE
Advanced Services Engine
 
ASP
Advanced Services Processor
 
ATM
Asynchronous Transfer Mode
 
B2BUA
Back-to-Back User Agent
 
BFD
Bidirectional Forwarding Detection
 
BGF
Border Gateway Function
 
BGP
Border Gateway Protocol
 
BRAS
Broadband Remote Access Server
 
BVI
Bridged Virtual Interface
 
CAC
Connection Admission Control
 
CCOD
circuit creation on demand
 
CFM
Connectivity Fault Management
 
CLI
command-line interface
 
CLIPS
Clientless IP Service Selection
 
CoA
Change of Authorization
 
CoS
Class of Service
 
DHCP
Dynamic Host Configuration Protocol
 
DHCPv6
Dynamic Host Configuration Protocol Version 6
 
DoS
Denial of Service
 
DPI
Deep Packet Inspection
 
DSCP
Differentiated Services Code Point
 
DUID
DHCPv6 Unique Identifier
 
eBGP
external BGP
 
ECN
Explicit Congestion Notification
 
ECR
Edge Collector Router
 
ERDI-P
Path Enhanced Remote Defect Indication
 
FR
Frame Relay
 
HDD
Hard Disk Drive
 
HDLC
High-level Data Link Control
 
IAID
Identity Association Identifier
 
ICMP
Internet Control Message Protocol
 
ICR
Inter-Chassis Redundancy
 
IGMP
Internet Group Management Protocol
 
IGP
Inter Gateway Protocol
 
IKEv1
Internet Key Exchange Version 1
 
IKEv2
Internet Key Exchange Version 2
 
IMS
IP multimedia subsystem
 
IP
Internet Protocol
 
IPoE
IP over Ethernet
 
IPsec
Internet Protocol Security
 
IPTV
Internet Protocol Television
 
IPv4
Internet Protocol Version 4
 
IPv6
Internet Protocol Version 6
 
ISISv6
Intermediate System-to-Intermediate System version 6
 
L2TP
Layer 2 Tunneling Protocol
 
L2TPv3
Layer 2 Tunneling Protocol version 3
 
LAC
L2TP Access Concentrator
 
LAG
Link Aggregation Group
 
LCD-P
Path Loss of Code-Group Delineation
 
LNS
L2TP Network Server
 
MA
Maintenance Association
 
MAC
Medium Access Control
 
MDRR
Modified Deficit Round Robin
 
MEPs
Maintenance Association End-Points
 
MIB
Management Information Base
 
MIPs
Maintenance Association Intermediate-Points
 
MBS
Maximum Burst Size
 
MG
Media Gateway
 
MGC
Media Gateway Controller
 
MGD
Media Gateway Daemon
 
MPLS
Multiprotocol Label Switching
 
MRAI
Minimum Route Advertisement Interval
 
MRU
Maximum Receive Unit
 
MSRP
Message Session Relay Protocol
 
MTU
Maximum Transmission Unit
 
NAPT
Network Address and Port Translation
 
ND
Neighbor Discovery
 
nRT
non Real Time
 
OSPF
Open Shortest Path First
 
P2P
Point-to-Point
 
PD
Packet Descriptor
 
PD
Priority Descriptor
 
PDR
Peak Data Rate
 
PIM
Protocol Independent Multicast
 
PKI
Public Key Infrastructure
 
PLM-P
Path Payload Label Mismatch
 
PMA
Packet Mesh ASIC
 
PMTU
Path Maximum Transmission Unit
 
POS
Packet over Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH)
 
PPA
Packet Processing ASIC
 
PPP
Point-to-Point Protocol
 
PPPoA
Point-to-Point Protocol over Asynchronous Transfer Mode
 
PPPoE
Point-to-Point Protocol over Ethernet
 
PQ
Priority Queuing
 
PVC
Permanent Virtual Circuit
 
PW
Pseudowire
 
PWFQ
Priority Weighted Fair Queuing
 
QoS
Quality of Service
 
RADIUS
Remote Authentication Dial-In User Service
 
RIB
Routing Information Base
 
RIPNG
Routing Information Protocol Next Generation
 
RDI-P
Path Remote Defect Indication
 
RMR
Remote Multicast Replication
 
RSTP
Rapid Spanning Tree Protocol
 
RT
Real Time
 
RTCP
RTP Control Protocol
 
SA
Security Association
 
SBG
Session Border Gateway
 
SDP
Session Description Protocol
 
SDR
Sustained Data Rate
 
SGC
Session Gateway Controller
 
SNMP
Simple Network Management Protocol
 
SPDF
Service Policy Decision Function
 
SSE
SmartEdge Storage Engine
 
STP
Spanning Tree Protocol
 
TCAM
Ternary Content Addressable Memory
 
TCP
Transmission Control Protocol
 
ToS
Type of Service
 
TM
Traffic Management
 
TR-101
Technical Report 101
 
UDP
User Datagram Protocol
 
URI
Uniform Resource Identifier
 
VLAN
Virtual LAN
 
VMG
Virtual Media Gateway
 
VPCG
Virtual Port Circuit Group
 
VPLS
Virtual Private LAN Services
 
VPN
Virtual Private Network
 
VRRP
Virtual Router Redundancy Protocol
 
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 Release 6.4.1 (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.