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

Technical Product Description 

SmartEdge OS for SmartEdge Routers, Release 6.2.1

© Copyright Ericsson AB 2009. All rights reserved.

Disclaimer

No part of this document may be reproduced in any form without the written permission of the copyright owner. The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.

Trademark List

SmartEdge is a registered trademark of Telefonaktiebolaget L M Ericsson.
NetOp is a trademark of Telefonaktiebolaget L M Ericsson.

Contents

1Introduction

2

New and Enhanced Software Features in Release 6.2.1.1
2.1ASE Support for ATM APS
2.2Support for BFD Liveliness Detection and IP Network Prefix Tracking
2.3BGF Software Features
2.4Ethernet CFM Phase 2 Feature
2.5RSVP Graceful Restart Helper Mode
2.6IS-IS Fast Convergence Enhancements
2.7Support for IPV6 over an IPV4 MPLS Core
2.8IGMP Enhancement
2.9Mobile IP Features
2.10RFlow Enhancements
2.11Network Management Features
2.12On-Demand IPsec Tunnel Configuration
2.13Use AAA to Configure Preshared Key
2.14Enhanced Support for Troubleshooting
2.15SSE Card Support
2.16L2VPN Enhancement
2.17New Log Messages Guide

3

New Hardware in Release 6.2.1.1
3.1SmartEdge 600 Router
3.2New and Modified Traffic Cards

4

PPA Feature Support in Release 6.2.1.1

5

APS Traffic Card and Feature Compatibility
5.1POS APS Ports

Glossary

Reference List


1   Introduction

This document describes the new and enhanced software features that are introduced in Release 6.2.1.1 of the SmartEdge® OS. It also describes the new hardware that is available with this product release.

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

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

2   New and Enhanced Software Features in Release 6.2.1.1

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

2.1   ASE Support for ATM APS

This release provides ASE card support for ATM APS.

Prior to this release, when the working and protection ports were on different slots, and egress traffic did not need to traverse an ASE card, the egress was replicated on both the APS working and protection network-facing ports. However, when traffic had to traverse an ASE card, this replication did not occur.

In this release, information about the slots corresponding to the working and protection network-facing APS ATM ports is sent to the ASE card, and an ASP on the ASE card replicates egress traffic when necessary.

2.1.1   Restrictions and Requirements

2.1.2   Application Traffic Management CLI Changes

There are no changes to the CLI configuration commands.

The show security asp command is enhanced. The syntax for this command is:

show security asp slot/asp-id statistics {packet linecard | system}

2.2   Support for BFD Liveliness Detection and IP Network Prefix Tracking

The SmartEdge router now supports BFD tracking and IP network prefix tracking on backup VRRP routers.

Note:  
BFD liveliness detection and IP network prefix tracking are supported on backup VRRP routers only and do not function when configured on a VRRP owner router.

2.2.1   BFD Liveliness Detection

If BFD is enabled on a backup VRRP router, that router uses BFD to monitor the state of the master VRRP router. During master VRRP router failure, the BFD session on the backup VRRP router triggers an early VRRP switchover. In such instances, the backup VRRP router takes over as the master router without waiting for three advertisement intervals to pass, as is typical. Use the bfd-monitoring neighbor command in VRRP configuration mode to enable BFD liveliness detection on a backup VRRP router.

During an XCRP switchover, a VRRP switchover can occur and traffic may be lost for up to three VRRP advertisement intervals because the standby XCRP does not support VRRP in hot standby mode. BFD liveliness detection does not occur during an XCRP switchover. If the VRRP advertisement interval has been configured in milliseconds (with the advertise interval command), the interval reverts to the default value where VRRP advertisements are sent every second.

Use the new bfd-monitoring neighbor ip-addr command in VRRP configuration mode to enable the backup VRRP router to track a specified network through the IP network prefix of that network. Replace ip-addr with the P address of the BFD neighbor you want to track.

2.2.2   IP Network Prefix Tracking

A backup VRRP router can be configured to track a network through the IP network prefix of that network. VRRP IP network prefix tracking prevents traffic loss by detecting connectivity failures; a backup VRRP router can track up to ten IP network prefixes. When a change occurs in an IP network prefix that is tracked (for example, when a backup VRRP router loses connectivity to a neighbor network), the RIB on the backup router updates VRRP and the priority of the backup VRRP router is decremented by the amount configured with the track network command. The backup VRRP router learns about network connectivity failures through regular routing updates to the router.

When a network regains reachability, the VRRP router reverts to its original priority. A change in router priority can cause a master VRRP router to become a backup VRRP router, and a backup to become a master.

Use the track network ip-addr [decrement priority] command to enable the backup VRRP router to track a specified network through the IP network prefix of that network. Replace ip-addr with the IP address of the network to be tracked by the VRRP instance. Use the optional decrement priority construct to specify the amount by which the priority of the VRRP router is decremented if there is a failure in the IP network (for example, when the backup VRRP router loses connectivity to a neighbor network. The default priority value is 10.

2.3   BGF Software Features

In the 6.2.1 release of SmartEdge OS, the BGF can now interoperate with Ericsson SBG 3.1.

2.3.1   New BGF Features

The following features are supported in this release of the SmartEdge BGF:

For more information about these features, see Reference [2].

Note:  
The SmartEdge BGF is not supported on the SmartEdge 100 router.

Figure 1 shows the logical position of the SmartEdge BGF in an IMS or other multimedia network. The distributed SBC consists of an SGC and a SmartEdge BGF. For more information about the SmartEdge BGF, see Reference [2].

Figure 1   Logical Position of D-SBC and SmartEdge BGF in IMS or other Multimedia Network

2.3.2   Targeted Locations of BGF in the Network

This section provides examples of multimedia networks showing locations of where a BGF can reside within the network, along with the function the router plays within a distributed SBC.

Figure 2 shows the SmartEdge BGF as a C-BGF in a distributed SBC collocated with BRAS or ECR. In this deployment, both the SmartEdge and BGF functionality are used in a single solution. In this deployment, most media traffic in the domain of an operator does not need to go to the core network, eliminating media tromboning.

Figure 2   Example Multimedia Network with SmartEdge Router Deployed as both C-BGF and BRAS or C-BGF and ECR

Figure 3 shows the SmartEdge BGF as a C-BGF in a distributed SBC collocated with a general router. In this deployment, both the routing and BGF functionality of the SmartEdge router are used.

Figure 3   Example Multimedia network with SmartEdge router deployed as both C-BGF and general router or I-BGF and general router

Figure 4 shows the SmartEdge BGF as a dedicated C-BGF or I-BGF in a distributed SBC. In this deployment, the BGF is the main application running on the SmartEdge router.

Figure 4   Example multimedia network with SmartEdge router deployed as a dedicated C-BGF or I-BGF

Figure 5 shows the SmartEdge BGF as a I-BGF deployed at the edge of a network acting as an IP-to-IP media gateway between different service provider networks. In this deployment, both the routing and BGF functionality of the SmartEdge router are used.

Figure 5   Example of multimedia network with SmartEdge router deployed as I-BGF and general router

2.3.3   New and Enhanced BGF Commands

The following new commands support the SmartEdge BGF feature:

The following BGF commands were enhanced for this release:

Command

Previous Command Mode (if applicable)

Current Command Mode (if applicable)

Other Enhancements (if any)

profile

MG configuration (global)

MGC group (global) configuration

Default profile changed from Ericsson version 4 to version 2.

maximum

not applicable

not applicable

This gates keyword is renamed as calls.

media-gateway

SBC configuration (global)

global configuration

 

media-gateway-controller

SBC configuration (global)

MGC group configuration

 

media-local-address

SBC configuration (context-specific)

realm configuration (context-specific)

 

realm

SBC configuration (context-specific)

MG configuration (context-specific)

Function of this command changed, so is listed a new command.

shutdown

SBC configuration (global)

MGC configuration (global)

MG configuration (global)

MGC group configuration (global)

 

signaling-endpoint

MGC configuration (global)

MGC configuration (global)

The construct context context-name added to this command.

segmentation

MG configuration (global)

MGC group (global) configuration

 

timers

MG configuration (global)

MGC group (global) configuration

 

The following SBC commands were either replaced with their BGF command equivalents or removed from the BGF:

For more information about the new and enhanced BGF commands, see Reference [1].

2.3.4   BGF Configuration Example

This section provides an example of a BGF configuration:

!

! service multiple-contexts

!

!

software license

!  media-gateway multimedia password XXXXXXXXXXXXXXXXXXX

!  media-gateway calls 2000 password XXXXXXXXXXXXXXXXXXX

!

! Configure BGF services on the router

media-gateway

 no shutdown

! Configure MGC group

 mgc-group mgc-grp1

profile ericsson-bgf version 2

no shutdown

! Add an MGC to the list of MGCs that can control the vMG on the router and define the characteristics of that MGC.

media-gateway-controller 1

 transport sctp

!

context abc

signaling-endpoint local 10.10.1.2

signaling-endpoint remote 155.53.12.212 2944

no shutdown

!

!

context abc

!

! Define loopback IP addresses

!

 interface med1 loopback

ip address 10.20.1.2/32

interface signalling loopback

ip address 10.10.1.2/32

interface med2 loopback

ip address 10.20.1.3/32 !

!

context local

!

! Define management interface

interface mgmt

ip address 10.13.49.235/24

!

! Configure BGF services in the context

 media-gateway

! Specify the name of a realm to configure for the BGF

realm realm1

! Specify an MGC group that can use this realm for calls

mgc-group mgc-grp1

! Specify the interfaces to use for media traffic in the realm you are configuring

media-local-address interface med1

media-local-address interface med2

!

! ** End Context **

!

end

2.4   Ethernet CFM Phase 2 Feature

The SmartEdge OS 6.2.1.1 includes following second phase enhancements to the SmartEdge router’s implementation of Ethernet CFM:

2.4.1   Restrictions and Requirements

Hardware restrictions and requirements follow:

General restrictions and requirements follow:

2.4.2   CLI Changes

2.4.2.1   ethernet-cfm linktrace and ethernet-cfm loopback Commands

ethernet-cfm linktrace from {mep-cct | domain md-id ma ma-id mep mep-id} to dest-mac level level

The following list defines the parameters that appear in the preceding commands:

ethernet-cfm loopback from {mep-cct | domain md-id ma ma-id mep mep-id} to dest-mac level level [data data] [size data-size]

2.4.2.2   no loopback and no linktrace Commands

The disable-linktrace command is replaced by the no linktrace command. There is no functional difference between no linktrace and disable-linktrace.

The new no loopback command is introduced in this release.

By default, CFM instances respond to linktrace and loopback tests. The no form of these commands disable responding to linktrace and loopback.

2.4.2.3   show ethernet-cfm circuit Command

The new show ethernet-cfm circuit command displays CFM information for a specific circuit. The syntax for this command follows:

show ethernet-cfm circuit cct [level]

2.4.2.4   clear ethernet-cfm counters Command

The new clear ethernet-cfm counters clears loopback and link-trace counters for each MEP, but does not clear Continuity-Check Message (CCM) counters. The syntax for this new command follows:

clear ethernet-cfm counters [instance-name] [domain domain-name]

2.5   RSVP Graceful Restart Helper Mode

RSVP graceful restart is enhanced to support helper mode. When RSVP graceful restart is enabled with the graceful-restart command, helper mode is also enabled by default. When RSVP graceful restart helper mode is enabled, the SmartEdge router assists the restarting neighbor by maintaining the LSPs between the SmartEdge router and the RSVP neighbors.

Keep the following rules and restrictions in mind before enabling and configuring RSVP graceful restart on your system:

The graceful restart command is updated in RSVP router configuration mode to include the helper, maximum_helper_recovery-time, and maximum_helper_restart-time keywords. The new command syntax is:

[no] graceful-restart [helper | restart-time interval | recovery-time interval | maximum_helper_recovery-time interval | maximum_helper_restart-time interval

Use the optional new helper keyword to enable RSVP helper mode.

Use the optional new maximum_helper_recovery-time interval construct to specify the maximum time interval (in seconds) that the RSVP instance retains information about the state of an LSP after a graceful restart. When the maximum helper recovery time expires, the status information for the neighbor expires and is no longer retained. The range of values for the interval argument is 20 to 3600.

Use the optional new maximum_helper_restart-time interval construct to specify the maximum time interval (in seconds) that the RSVP instance waits for a neighbor to come up after a graceful restart before considering the neighbor to be down. When the maximum helper restart time expires, the LSPs between the SmartEdge router and the restarting neighbor are no longer retained. The range of values for the interval argument is 10 to 1800.

Note:  
The helper, maximum_helper_recovery-time, and maximum_helper_restart-time keywords are available in RSVP router configuration mode only.

Use the no graceful-restart helper command to disable RSVP graceful restart helper mode on a system. When graceful restart helper mode is disabled, the SmartEdge router does not help the restarting neighbor.

2.6   IS-IS Fast Convergence Enhancements

The following enhancements have been made to Intermediate System-to-Intermediate System (IS-IS) fast convergence:

When IS-IS fast convergence is disabled, the holddown time is in seconds instead of milliseconds, and there is a delay between successive SPF calculations.

Note:  
The SPF delay configured with the fast convergence command overrides the SPF delay interval set with the spf interval command.

Using the fast-convergence command to configure a maximum SPF count greater than zero enables additional SPF calculations in the SPF holddown interval. Configuring the maximum SPF count to zero prevents additional SPF calculations in the SPF holddown interval. Any SPF triggering events received after the completion of the first SPF calculation result in the scheduling of an SPF calculation at the beginning of the next SPF holddown interval.

Note:  
We recommend that you do not configure the SPF to run continuously. For example, in large networks where a single SPF calculation can take 200 milliseconds or more, do not set the SPF delay value to 50 milliseconds, the max-spf-count to 3 calculations, and the SPF holddown (using the spf holddown command) to 1 second. This configuration can result in excessive CPU utilization when other applications try to run between SPF calculations.

2.7   Support for IPV6 over an IPV4 MPLS Core

In configurations where two IPV6 systems must communicate across an IPv4 MPLS network, the SmartEdge router now supports the tunneling of IPv6 VPN routes over an IPV4 MPLS core or soft-GRE tunnel.

Consider the following before enabling IPv6 VPN routes over an IPv4 MPLS core:

The following types of BGP routes are supported:

The following new commands support the tunneling of IPv6 VPN routes over an IPv4 MPLS core or soft-GRE tunnel:

The show bgp neighbor command is updated to include information about the configuration of IPv6 VPNs over an IPV4 MPLS core.

The following example enables the transport of labeled IPv6 VPN routes over an IPv4 network on an internal neighbor. First, the transport of IPv6 routes over the MPLS IPv4 network is enabled:

[local]PE1(config)#context local

[local]PE1(config-ctx)#router bgp 100

[local]PE1(config-bgp)#address-family ipv6 vpn

[local]PE1(config-bgp)#end

Next, the IPv6 VPN address-family is globally enabled for BGP:

[local]PE1(config)#context local

[local]PE1(config-ctx)#router bgp 100

[local]PE1(config-bgp)#neighbor 10.10.10.2 internal

[local]PE1(config-bgp-neighbor)#address-family ipv6 vpn

[local]PE1(config-bgp-neighbor)#end

2.8   IGMP Enhancement

The show igmp group detail command output has been enhanced to display the sources that are included and excluded in IGMPv3 reports.

The following example shows that the hosts running IGMPv3 (11.3.1.2 and 100.3.5.2) receive traffic for group 225.1.1.1 from the source 192.18.1.1. In this example, source 192.18.1.1 is included in IGMPv3 reports, and source 193.18.1.2 is excluded in the IGMPv3 reports.

[local]Redback>show igmp group detail


Group             : 225.1.1.1

  Interface       : ----

  Circuit         : 255/22:1:26/1/2/4

  Uptime          : 00:00:53

  Expires         : 00:03:57

  Last reporter   : 100.3.5.2

  Running version : v3

  Host Count      : 0

  Filter mode     : Exclude

  Source list      :

    Source Address  Uptime     Expires    Forwarding  Reporter

 

   Sources in INCLUDE list:

   192.18.1.1      00:00:03   00:04:17   Yes          11.3.1.2

 

   Sources in EXCLUDE list:

    193.18.1.2      00:00:53   stopped    No           100.3.5.2

2.9   Mobile IP Features

This section describes the Mobile IP features in this release.

2.9.1   MAC VSE support on Foreign Agent

Previously, in a Mobile IP configuration where access points are connected to the SmartEdge router through a Foundry switch, the Foundry switch may be delayed in learning the MAC address when the mobile node moves across the access points. As a result, the registration reply from the FA is delivered to the incorrect access point. When the FA receives a registration request, it uses the source MAC address as the destination in the reply.

Now, the request can include a VSE that encodes the MAC address of the access point in the registration request. If the FA encounters errors while parsing a MAC VSE, the request is ignored. If the MAC VSE is present and valid, the FA processes it, and the reply will be sent to the MAC address contained in the VSE. The FA processes all requests without a MAC VSE as previously.

Use the show mobile-ip detail and show mobile-ip interface detail commands to display the number of RRQs with valid and invalid MAC VSEs. Use the show mobile-ip visitor pending detail to show the access point MAC address if the MAC VSE if the pending RRQ contained the MAC-VSE.

2.9.2   New Security for MN-FA Authentication

Previously, FA implementation ignored the MN-FA authentication extension in the registration request sent by the MN. Now, the MN-FA authentication extension is supported and processed in the following way:

  1. The FA requests the MN-FA key set during initial subscriber authentication if the RRQ includes the MN-FA authentication extension.
  2. The FA requests the MN-FA key set during subscriber reauthentication if the RRQ includes the MN-FA authentication extension and if the MN-FA authentication extension in the request refers to an SPI for which a matching key set has expired or does not exist.
  3. The FA requests the MN-FA key set during initial subscriber authentication if the RRQ includes the MN-FA authentication extension and the CoA in the RRQ is different from the existing visitor entry for the MN.
  4. The FA requests the MN-FA key set during subscriber reauthentication if the RRQ includes the MN-FA authentication extension and the CoA in the RRQ is different from the existing visitor entry for the MN.
  5. If the re-registration request is received through an interface different from the initial RRQ, then the following reauthentication request contains the new FA-IP-MIP4. Changing the interface itself does not trigger reauthentication.

The authentication (home agent instance) command was changed to authentication (foreign agent peer instance). The authentication (foreign agent instance) command was changed to authentication (home agent peer instance. You can use new keywords with the authentication (home agent peer instance) and the authentication (foreign agent peer instance) commands to set how the SmartEdge processes RRQ with MN-FA authentication extensions:

You can use the show subscriber log command to display RRQ and RRP messages between the MIPd and AAd and the number of MN-FA keys the MN retrieved. You can use the show mobile-ip detail command to display the number of invalid MN-FA key sets received and the number of authentication and reauthentication failures.

The authentication (home agent peer instance) command and authentication (foreign agent peer instance) command were changed. Now, the authentication (home agent peer instance) command is entered only in HA peer configuration mode and the authentication (foreign agent peer instance) command is entered only in FA peer configuration mode. Some additional keywords have been modified for both. For more information, see the authentication (home agent peer instance) and the authentication (foreign agent peer instance) commands.

The following are the error codes that might be returned on the MN for this feature:

Table 1    Error Codes for MN-FA Authentication Extension

Code

Reason

66

Authentication server was unreachable because it either stopped working or it is subject to throttling.

67

Authentication failed because the authentication extension is missing or invalid.

The following new Motorola VSAs were added or modified:

Table 2    New Motorola VSAs for Mobile IP Supported by the SmartEdge Router

#

Attribute Name

Sent in Access-Request

Sent in Acct-Request

Received in Access-Response

Notes

71

MN-FA-Key

No

No

Yes

Encrypted string. The MN-FA key used for MN-FA authentication.

72

MN-FA-Lifetime

No

No

Yes

Integer. The amount of time in seconds that the MN-FA key may be used after the FA obtains it.

73

MN-FA-SPI

Yes

No

Yes

Integer. The SPI associated with the MN-FA key.

74

FA-IP-MIP4

Yes

No

No

IP address. The IP address of the FA the received the MP request and used to generate the MN-FA key for authentication.

2.9.3   Support for Dynamic Assignment of Home Agent IP Address

Previously, the Home Agent field in the RRQ packet was populated with a known HA IP address that identified the destination HA. Now, the SmartEdge router supports dynamic assignment of the HA IP address when the MN does not have the HA IP address. This feature adds functionality outlined in RFC 4433, Mobile IPv4 Dynamic Home Agent (HA) Assignment, where the MN sets the HA IP address in the RRQ to 255.255.255.255 or 0.0.0.0. Optionally, the RRQ can include a dynamic home agent extension with a requested HA IP address. This feature does not support HA redirection as specified in this RFC.

To dynamically assign the HA IP address, the MN must send an RRQ with an HA address of 255.255.255.255 or 0.0.0.0 to the FA. Optionally, the MN can include a dynamic home agent extension requesting a specific HA IP address. The FA sends the request to the CAPC to get the HA IP address. The Access-response CAPC server includes the HA IP address, in addition to other attributes. If the RRQ from the MN includes a requested HA IP address in the dynamic home agent extension, the FA validates the requested HA IP address against the HA IP address sent by the CAPC. If they do not match, the RRQ is rejected. If the IP address matches, the request is forwarded to the HA.

When the HA receives the RRQ with Home Agent field as 0.0.0.0 or 255.255.255.255, the HA sends an Access-Request to the AAA server with both the RRQ-HA-IP address and its own IP address, which is a valid unicast address. The AAA server then sends two keys back: one to authenticate the RRQ (RRQ-MN-HA-KEY), the other to add the authentication extension to the reply packet (MN-HA-CMIP4). The HA stores values of RRQ-MN-HA-KEY and MN-HA-Key for re-registration and deregistration.

A deregistration request sent to the HA from the MN must include a valid HA IP address to end the session on the HA. A deregistration message received with an HA IP address of ones or zeros will be dropped.

This feature handles re-registration in the following ways:

The HA authenticates the re-registration message using the cached key for the HA IP address of 0.0.0.0 or 255.255.255.2555 if one exists. If it does not exist, an Access-Request is sent to the AAA server to fetch keys as described above.

The following attributes are sent in different circumstances:

This feature is enabled by default. Use the radius server and aaa authentication subscriber radius commands on the foreign agent and home agent contexts to obtain the HA IP address and the relevant keys.

The following new Motorola VSAs were added or modified:

Table 3   

#

Attribute Name

Sent in Access-Request

Received in Access-Request

Received in Access-Response

Notes

67

FA-hHA-Key

No

No

Yes

Encrypted string. FA-hHA-Key is used by the FA to create an FA-HA authentication extension. This field is protected with an encryption algorithm defined in RFC 2868, RADIUS Attributes for Tunnel Protocol Support, for Tunnel-Password

68

FA-hHA-Lifetime

No

No

Yes

Integer. The amount of time in seconds that this FA-hHA-key can be used after it is fetched.

69

FA-hHA-SPI

Yes (optional)

No

Yes

Integer. The SPI for FA-hHA-Key. FA-hHA-SPI may be sent in the Access Request to the AAA server if the FA does not have a matching key corresponding to the key used by the HA in a registration revocation message.

The following new WIMAX forum RADIUS VSAs for Mobile IP were added or modified:

Table 4    WiMax Forum RADIUS VSAs for Mobile IP Supported by the SmartEdge Router

#

Attribute Name

Sent in Access- Request

Sent in Acct- Request

Received in Access- Response

Notes

4

WIMAX-Session-ID

Yes(1)

No

Yes

Binary string. Unique identifier in the home network for the session set in the home network AAA server. Received in Access-Response is also received in the CoA.

6

hHA-IP-MIP4

Yes

No

No

IP address. IP address of the home agent (HA).

18

RRQ-HA-IP

Yes

No

No

IP address. The IP address identified in the HA IP address file in the RRQ.

19

RRQ-MN-HA-Key

No

No

Yes (optional)

Encrypted string. MN-HA key bound to the HA IP address.

64

vHA-IP-MIP4

No

Yes

Yes

IP address. IP address of the visited HA from the AAA server.

(1)  Yes, if the Access-Request is sent for reauthentication.

The Redback VSA, Session_error_message, was extended to support this feature. If the HA receives multiple instances of the RADIUS attribute, class, only the first instance is stored on the HA.

The following are the error codes that might be returned on the MN for this feature:

Table 5    Error Codes for MN-FA Authentication Extension

Code

Reason

90

Authentication failed because the HA IP address contained only zeros.

136

Unknown HA IP address. Used by the HA and by the FA when the IP address in the dynamic HA extension does not match the HA IP address received from CAPC.

2.10   RFlow Enhancements

This release provides additional support for RFlow. You can perform the following tasks:

The following CLI commands have been added for RFlow support:

2.11   Network Management Features

2.11.1   Support for ALARM-MIB

Support was added for ALARM-MIB based on RFC 3877, Alarm Management Information Base (MIB).

ALARM-MIB enables you to set up alarm models to specify specific types of alarms and alarm states to be raised for existing notifications. To configure an alarm model, perform the following steps:

  1. Use the new snmp alarm command to enter the new SNMP alarm model command mode.
  2. Use one of the following new commands to set up the SNMP alarm model with additional parameters:
  3. Use the following new show commands to display information about SNMP alarm models:
  4. Enable debugging for SNMP alarm models by using the existing debug snmp mib command with the new alarm keyword.

2.11.2   Support for ENTITY MIB v3

Support is added for ENTITY-MIB v3 based on RFC 4133 Entity MIB (Version 3). For every physical port entity in entAliasMappingTable in ENTITY-MIB v3, a corresponding entry is created in this table, mapping entPhysicalIndex to ifIndex. For example, a MIB walk produces the value 1.3.6.1.2.1.2.2.1.1.123456 for a physical port entity. In the example, 123456 is the ifIndex value, and 1.3.6.1.2.1.2.2.1.1 is the ifIndex object ID.

This feature only supports the following objects in entPhysicalTable in compliance with RFC 4133. No other tables or objects referenced in RFC 4133 are supported.

2.11.3   ATM VPL Counters in MIB and CLI

This feature adds support for ATM2-MIB. It also adds the proprietary MIB RBN-ATM2-MIB to offer extended support in compliance with RFC 3606, Definitions of Supplemental Managed Objects for ATM Interface. This feature also provides support for ATM Virtual Path Link (VPL) and Virtual Channel Link (VCL) statistic counters in these MIBs.

This feature adds additional counters to the show atm counters command based on these objects in ATM2-MIB: .

The new optional keyword, vp, was added to the show atm counters command. If you specify the vp vpi keywords together, the output displays VP statistics counters. The VP statistics counter is the sum of PVC statistics counters in the same VP tunnel. If a PVC counter is reset, the vp vpi keywords return the PVC counters since the last counter reset and the counters for all other PVCs in the same VP tunnel. If a PVC is deleted from a VP tunnel, the vp vpi keywords return only the counters of remaining PVCs on the VP tunnel. For more information, see the show atm counters command.

2.11.4   Bulkstats Support for Link Groups and ML-PPP Circuits

Bulkstats now supports data collection for link groups. The bulkstats schema profile command now includes a link-group profile. The link-group command now includes the bulkstats keyword to associate the link group with the bulkstats schema profile. For more information, see the bulkstats schema profile command and the link-group command.

2.12   On-Demand IPsec Tunnel Configuration

During IPsec tunnel configuration, the IP address of the remote peer may not be known. For example, remote CPE devices may not have a static IP address, but may obtain it dynamically at bootup. In this situation, you can configure an on-demand auto key IPsec tunnel.

2.12.1   CLI Changes

The following new commands support on-demand IPsec tunnel configuration:

The following commands are enhanced to support on-demand IPsec tunnel configuration:

2.13   Use AAA to Configure Preshared Key

You can use AAA to obtain the preshared key for a specific remote peer from an external RADIUS server by configuring pre-shared-key use-aaa during IKE policy configuration. The preshared key can only be obtained using AAA for on-demand IPsec tunnels.

2.14   Enhanced Support for Troubleshooting

The show tech-support command is enhanced to include the keyword.

2.14.1   CLI Changes

show tech-support

Use the ase option to display information for each ASP in the system.

2.15   SSE Card Support

The SmartEdge Storage Engine (SSE) provides Network File System (NFS) services to store large amounts of data for clients and applications internal to the SmartEdge router, including the Cross-Connect Route Processor Controller card (XCRP4).

The SSE card stores call data records (CDRs) from the SmartEdge router. The SSE can store a large number of data records for a number of hours without requiring file extraction. The SSE can also store logs and bulk statistics, as well as event-based performance statistics. Data can be extracted through FTP or SFTP.

See Quick Installation Guide for the SmartEdge Storage Engine 4/153 30-CRA 119 1028/1 and SSE Configuration and Operation 84/1543-CRA 119 1170/1 for more information.

2.15.1   Restrictions and Requirements

The SSE can be installed in any I/O slot in the SmartEdge 1200 or SmartEdge 600 chassis. It includes two field-replaceable Hard Disk Drives (HDDs) mounted in an HDD carrier that can be inserted and ejected from the SSE card without ejecting the SSE card. The SSE card can operate with one or two HDDs inserted; each HDD can be replaced separately without interrupting read/write activity.

Currently, the Network Equipment Building Standards (NEBS) compliance with a short term temperature requirement of 55 degrees C can only be met on the SmartEdge 1200 or SmartEdge 600 router in a single SSE HDD configuration.

2.15.2   CLI Changes

The following new commands support the SSE card:

The following commands are enhanced to support the SSE card:

2.16   L2VPN Enhancement

Beginning with this release, LDP-based L2VPN pseudowires (except ATM and AAL2 PW) are compliant with RFC 4447 for MTU matching, by default. The MTUs across the PW endpoints are compared and must be same for the PW state to be operationally up. Use the pseudowire ignore-mtu command to override this default behavior. When the command is enabled, the SmartEdge system runs in non-RFC 4447 compliance mode for MTU matching. When the command is disabled, the system adheres to RFC 4447 compliance for MTU matching.

2.17   New Log Messages Guide

With this release, a new Log Messages Guide has been added to the SmartEdge library, with entries for the ATM and CSM log messages. For each message, the guide describes the severity, a description of the condition that triggered the message, and recommended actions to resolve the issue. Entries for messages from other SmartEdge OS modules will be added to the guide in future releases.

3   New Hardware in Release 6.2.1.1

The following hardware is new in this release.

Note:  
This release of the SmartEdge OS includes support for the SM 480 product line; see Reference [24] for more information.

3.1   SmartEdge 600 Router

The SmartEdge 600 Multi-Service Edge Router (MSER) operates at the edge of the IP backbone and delivers traffic-intensive applications, such as video (HDTV) and broadband mobility. It can be used as an edge aggregation router and simultaneously as a broadband remote access server (BRAS) to directly connect customers to the network. The SmartEdge 600 router enables the service providers to offer full-service broadband applications, such as routing protocols, quality of service (QoS), and inbound and outbound access control lists (ACLs).

3.2   New and Modified Traffic Cards

This release introduces the following traffic cards.

3.2.1   PPA2-Based 4-Port POS OC-48c/STM-16c Card

Release 6.2.1.1 of the SmartEdge OS supports a new PPA2-based 4-port POS OC-48c/STM-16c traffic card. This 4-port POS traffic card can be installed in a SmartEdge 400, SmartEdge 800, or SmartEdge 1200 router and is fully compatible with all cards supported on these SmartEdge systems, including other traffic cards and controller cards. The card is considered a separate and distinguishable I/O card for the SmartEdge system.

The product order number for this 4-port POS OC-48c/STM-16c traffic card is OIM-SE8-4OC48 or ROA1283251/1.

The 4-port POS OC-48c/STM-16c card functions as a network uplink module in edge routing and BRAS applications. This card has a minimum memory capacity of 1 GB.

Automatic Protection Switching (APS) is not supported on this 4-port POS OC-48c/STM-16c traffic card.

The card provides four GE ports and requires separate small form-factor pluggable (SFP) transceiver for each port. These SFPs support Short Reach, Intermediate Reach, and Long Reach, with different wavelength ranges.

Table 3 lists slot allocations for this card in each router.

Table 6    Slot Allocations for the 4-Port POS OC-48c/STM-16c Traffic Card

Chassis

Slots

SmartEdge 400

1 to 4

SmartEdge 800

1 to 6, 9 to 14

SmartEdge 1200

1 to 6, 9 to 14

For information about installing an POS OC-48c/STM-16c traffic card, see Quick Installation Guide for SmartEdge Packet over SONET/SDH Traffic Cards. The following enhanced commands support this card:

Available in global configuration mode.

Specifies a traffic card for a slot, or selects one for modification, and enters traffic card configuration mode, where card-type is oc48e-4-port, specifying a 4-port POS OC-48c/STM-16c traffic card. Use this command to configure a traffic card and its associated ports, channels, and circuits before the traffic card is actually installed in the chassis of a SmartEdge router.

Available in all modes. Displays general port and slot information for a POS OC-48c/STM-16c traffic card.

Available in all modes. Displays information about system hardware.

3.2.2   Supporting HSVC-FAIR SAR Image on the PPA2-Based 8-Port ATM OC-3c/STM-1c Traffic Card

In Release 6.2.1.1, the PPA2-Based 8-port ATM OC-3c/STM-1c traffic card uses both vc-fair and hsvc-fair SAR images. The vc-fair SAR image provides functionality consistent with PPA1-based ATM cards, but at a higher scale and without VC sparseness issues. The hsvc-fair image supports hierarchical and non-hierarchical shaping, port rate limiting, and VC fairness under congestion. Both vc-fair and hsvc-fair SAR images support statistics. The SAR devices support two, four, or eight distinct CoS queues for each ATM PVC, allowing a mix of priority- and class-based queuing for each ATM PVC. When configuring the EPD threshold in hsvc-fair mode, the value used should not exceed 500.

Note:  
The number used after threshold (in this case, 5000) has an acceptable range of 1 to 10000; however, in the case of hsvc-fair mode, it should not be configured greater than 500. If it is configured above 500, poor performance can result.

The following enhanced commands support this 8-port ATM card:

3.2.3   Supporting 48K Circuits per PPA3-Based Traffic Card

In Release 6.2.1.1, the PPA3-Based 20-port GE and 4-port 10GE traffic cards are enhanced to support up to 48K circuits per card.

4   PPA Feature Support in Release 6.2.1.1

Table 7 describes the feature support on PPA versions 1, 2, and 3 in Release 6.2.1.1 of the SmartEdge OS. This matrix applies to the SmartEdge router only.

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

Table 7    PPA Feature Support for Release 6.2.1.1

Feature

PPA1

PPA2

PPA3

Notes

MAC VSE support on Foreign Agent

No

Yes

Yes

 

New Security for MN-FA Authentication

No

Yes

Yes

 

BGF Features

No

Yes

Yes

 

Support for Dynamic Assignment of Home Agent IP address

No

Yes

Yes

 

Support for ALARM-MIB

Yes

Yes

Yes

 

Support for ENTITY MIB v3

Yes

Yes

Yes

 

ATM VPL Counters in MIB and CLI

Yes

Yes

Yes

 

Bulkstats support for Link Groups and ML-PPP circuits

Yes

Yes

Yes

 

PPA2-Based 4-Port POS OC-48c/STM-16c Card

No

Yes

No

 

Supporting HSVC-FAIR SAR Image on the PPA2-Based 8-Port ATM OC-3c/STM-1c Traffic Card

No

Yes

No

 

Supporting 48K Circuits per PPA3-Based Traffic Card

No

No

Yes

 

RSVP Graceful Restart Helper Mode

Yes

Yes

Yes

 

IS-IS Fast Convergence Enhancements

Yes

Yes

Yes

 

Support for IPV6 over an IPV4 MPLS Core

Yes

Yes

Yes

 

IGMP Enhancement

Yes

Yes

Yes

 

Ethernet CFM Phase 2

Yes

Yes

Yes

 

Support for BFD Liveliness Detection and IP Network Prefix Tracking

No

Yes

Yes

 

pseudowire ignore-mtu Command

Yes

Yes

No

 

5   APS Traffic Card and Feature Compatibility

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

5.1   POS APS Ports

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

Table 8    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 9 summarizes encapsulation and feature compatibility for POS APS ports.

Table 9    POS APS Feature Compatibility

Feature

Supported

Notes

Encapsulation

   

Cisco 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

APS
Automatic Protection Switching
 
ASE
Advanced Services Engine
 
ASP
Application Services Processor
 
BGF
Border Gateway Function
 
BRAS
Broadband remote access server
 
CAC
Connection admission control
 
C-BGF
Core BGF
 
DPI
Deep Packet Inspection
 
D-SBC
Distributed SBC
 
DSCP
Differentiated Services Code Point
 
ECR
Edge collector router
 
I-BGF
Interconnect BGF
 
MBS
Maximum burst size
 
IMS
IP multimedia subsystem
 
PDR
Peak data rate
 
RTCP
RTP Control Protocol
 
SBG
Session Border Gateway
 
SDR
Sustained data rate
 
SGC
Session Gateway Controller
 
SPDF
Service policy decision function
 
VPN
Virtual Private Network

Reference List

All referenced documents are located in the Ericsson CPI Store under “IP Networking."

[1] BGF Command Reference, 27/190 82-CRA 119 1170/1.
[2] SmartEdge Border Gateway Function, 155 13-CRA 119 1170/1 Uen.
[3] Advanced Services Configuration and Operation Using the NetOp EMS Software, 1553-CRA 119 1170/1.
[4] Advanced Services Fault Management Guide, 3/1543-CRA 119 1170/1.
[5] Application Traffic Management Command Reference, 190 80-CRA 119 1170/1-V1.
[6] Application Traffic Management Configuration and Operation, 1543-CRA 119 1170/1-V1.
[7] Application Traffic Management Overview, 221 02-CRA 119 1170/1.
[8] Changes to Default System Behavior, SmartEdge OS, Release 6.2.1.1, 198 23-CRA 119 1170/1.
[9] Commands: through al, 1/190 82-CRA 119 1170/1-V1.
[10] Commands: g through io, 9/190 82-CRA 119 1170/1-V1.
[11] Commands: ip through li, 10/190 82-CRA 119 1170/1-V1.
[12] Commands: o through po, 13/190 82-CRA 119 1170/1-V1.
[13] Commands: r, 15/190 82-CRA 119 1170/1.
[14] Commands: show p through show q, 23/190 82-CRA 119 1170/1-V1.
[15] Configuring Circuits for QoS, 53/1543-CRA 119 1170/1-V1.
[16] Installing Release 6.1.5.1, 1/190 47-CRA 119 1170/1.
[17] IPsec VPN Command Reference, 2/190 80-CRA 119 1170/1-V1.
[18] IPsec VPN Configuration and Operation Using the SmartEdge OS CLI, 1/1543-CRA 119 1170/1.
[19] IPsec VPN Overview , 2/221 02-CRA 119 1170/1-V1.
[20] Performing Basic Configuration Tasks, 6/1543-CRA 119 1170/1.
[21] Quick Installation Guide for SmartEdge ATM Optical Traffic Cards, 4/153 30-CRA 119 1025/1.
[22] Quick Installation Guide for SmartEdge Fast Ethernet and Gigabit Ethernet Traffic Cards, 6/153 30-CRA 119 1025/1.
[23] RADIUS Attributes, 66/1543-CRA 119 1170/1.
[24] Technical Product Description, SmartEdge OS for the SM 480 Product Line, Release 6.2.1, 4/221 02-CRA 119 1170/1-V2.