930430sddsd02v5.0.r2 - v1 - 7210-Sas M Os 5.0r2 Software Release Notes

7210-SAS M OS 5.
0R2 JANUARY 7, 2013
7210-SAS M OS 5.0R2 SOFTWARE RELEASE NOTES
These release notes are for Release 5.0R2 of the 7210 SAS-M OS software for 7210 SAS M devices.
RELEASE NOTE ORGANIZATION

The following are the major topics covered in these Release Notes: Standard Software Upgrade Procedure on page 2 Resolved Issues on page 7 New Features on page 24 Enhancements on page 53 Known Limitations on page 68 Known Issues on page 73
Alcatel-Lucent
*93-0430-02
V5.0.R2*
Page 1
93-0430-02 V5.0.R2
7210 SAS-M OS 5.0R2 Software Release Notes
SOFTWARE UPGRADE PROCEDURES

The following sections contain information for upgrading to the 5.0R2 software version. In particular, there are sections that describe the following: Standard Software Upgrade Procedure Procedure for performing a standard, service-affecting upgrade. Note that when upgrading from Release 1.1, ensure that the 7210 SAS M is not power cycled until the following upgrade procedure is completed. STANDARD SOFTWARE UPGRADE PROCEDURE This section describes the standard software upgrade procedure which is service-affecting: Each software release includes a boot loader (boot.tim) and the software image (both.tim). The boot loader initiates the loading of the 7210 SAS OS image based on the boot options file (bof.cfg) settings.
The following steps describe the software upgrade process: Step 1. Backup existing images and configuration files New software loads may make modifications to the configuration file which are not compatible with older versions of the software. Note: Alcatel-Lucent recommends making backup copies of the BOOT loader (boot.tim), software image and configuration files, should reverting to the old version of the software be required.
Step 2. Copy 7210 SAS M images to cf1: The 7210 SAS M image files must be copied to the cf1: device on the 7210 SAS M node. It is good practice to place all the image files for a given release in an appropriately named subdirectory off the root, for example, cf1:\5.0R2. Copying the boot.tim and other files in a given release to a separate subdirectory ensures that all files for the release are available should downgrading the software version be necessary. Step 3. Copy boot.tim to the root directory on cf1: The BOOT Loader file is named boot.tim. This file must be copied to the root directory of the cf1: device. Note: If it is not possible to overwrite cf1:\boot.tim file, Change the cf1:\boot.tim attributes using file attrib -r cf1:\boot.tim command.
Step 4. Modify the boot options file to boot the new Image
Page 2
Alcatel-Lucent
The Boot Options File (bof.cfg) is read by the BOOT Loader and indicates primary, secondary and tertiary locations for the image file. The bof.cfg should be modified as appropriate to point to the image file for the release to be loaded. Use the bof save command to save the Boot Options File modifications. Step 5. When upgrading to 5.0R2, execute the admin reboot upgrade command. Note that, executing 'admin reboot upgrade' command system will upgrade the bootrom and CPLD firmware if required. Note: The 10G Port hang issue and false fan alarms fixes requires CPLD firmware version 28. Upgrading 7210 SAS-M to using "admin reboot upgrade" CLI updates CPLD firmware version to 28.. Allow the boot sequence to complete and verify that the card comes up. Step 6. Upgrade the Golden BOOT Loader (only if all of the above steps were successful). After successfully booting of the new version of 7210 SAS M image, upgrade the golden boot loader by executing the admin update-golden-bootstrap cf1:/boot.tim command. Note: After upgrade to 4.0 or later software images, during next boot, if the user forgets the BOF password and fails to provide a correct password, after three attempts, the system prompts the user to reset the BOF password to factory default. If user accepts BOF password recovery, as a security measure, the system also resets the flash to factory defaults (that is, it removes all the files from the flash except the boot image file (cf1:\boot.tim) and Timos image file (cf1:\both.tim)) and reboots the node with the factory default settings. Refer 7210 User Guide and "BOF PASSWORD RECOVERY" in Enhancements section of this document for more details.
Alcatel-Lucent
Page 3
UPGRADE FROM PRIOR RELEASES

UPGRADE TO 5.0R1 FROM
PRIOR RELEASES ACCOUNTING
RECORD NUMBERS
In 5.0R1 release following accounting numbers are modified, new numbers are shown in ( ) netInfIngressOct(52), netInfIngressPkt(53), combinedNetInfIngress(54), accessEgressPkt(55), accessEgressOct(56), combinedAccessEgress(57), combinedNetEgress(58), combinedSvcEgress(59), combinedSvcInEgPkt(60), combinedNetInEgPkt(61) In previous releases 7210 SAS was allowing to configure non supported feature CLI's. In 5.0R1 some of the non supported CLI's are removed. In previous releases if user had configured non supported feature CLI, configuration will error out during upgrade to 5.0R1 release. It is recommended to check for non supported CLI by loading config file with 5.0R1 and remove non supported CLIs from config file before final upgrade.
NON SUPPORTED CLI
TACACS+
From 5.0R1 tacacs+ "single-connection" option is deprecated. During upgrade following warning message displayed WARNING: CLI Line:xx "single-connection" This command has been deprecated.
SPLIT HORIZON
GROUP NAME
During upgrade to 5.0R1, if "split-horizon-group <group-name>" CLI, where <group-name> configured with name having spaces, config file execution will error out during upgrade. Workaround is to edit the config file before upgrading to ensure split horizon group names are with double quotes or no space(s) in the group name.
LOGGING
In 5.0, as part of log-id config (configure>log>log-id <num>) needs to have from change. This is necessary for the box to generate config change logger/trap messages, modify configuration file accordingly.
UPGRADE TO 4.0R4 OR
HIGHER FROM PRIOR RELEASES SAP INGRESS QOS During upgrade to 4.0R4 or higher release, the following warning message displayed can be ignored: MAJOR: CLI #1010 Saps in the system will be re-configured without Sap Indexs because Sap index file could not be located.
Page 4
Alcatel-Lucent
After upgrade to 4.0R4 or higher, it is recommended to save the configuration. When the configuration is saved with 4.0R4 or higher build, sap index file with extension .sdx is automatically generated and saved at a location where the configuration file is stored. For more information, see, "Efficent Allocation of SAP Ingress QoS Resource" feature in "New Features"of this document. Y.1731 MA NAME From 4.0R1, Y1731 MA name should be unique across the system. During upgrade to 4.0R1 or higher if system finds duplicate names in the configuration file then upgrade to new configuration fails. Before upgrade, it is recommended to modify the configuration file. For example CLI "association 1 format icc-based name "abcdabcdabcd1", name "abcdabcdabcd1" should be unique across system for successful upgrade to 4.0R1 or higher. NETWORK QOS
POLICY
During boot up with 4.0R1 image, for each "network" qos policy of "ip-interface" type in the configuration file system generates "mpls-lsp-exp-profile-map" policy and attached to network qos policy. mpls-lsp-exp-profile-map policy id is equal to network qos policy id. "mpls-lsp-exp-profile-map" policy is populated with "lsp-exp lsp-exp-value profile {in|out}" information. lsp-exp and profile values are copied from corresponding network qos policy of the configuration file. It is recommended to save the configuration file after upgrade to 4.0R1 release. Refer to Enhancements section for more details.
R1.1R7
In 1.1R7, a default SAP and a dot1q SAP cannot be configured along with enabled egress filters when the SAPs are configured on the same port. If such a configuration exists in the startup-config, it is recommended that the following procedure is used before performing an upgrade: Step 1. Create a config file on the cf1 flash which contains the CLI commands to provide basic in-band connectivity and management functions. Step 2. Step 2. Add the following command in the startup configuration file. Note that the config-file parameter is the file mentioned in step #1. config>system>boot-bad-exec cf1:/<config-file> Step 3. Follow the Standard Software Upgrade Procedure on page 2.
R1.1R6
In 1.1R6, number of egress ACLs is restricted to 256 for combined IP and MAC criteria. If the 7210 SAS M is booted with a configuration file containing more than 256 egress ACLs, the configuration will error out. It is recommended that, in such cases, the following procedure is used before performing an upgrade. Step 1. Create a config file on the cf1 flash which contains the CLI commands to provide basic in-band connectivity and management functions. Step 2. Add the following command in the startup configuration file. Note that the config-file parameter is the file mentioned in step #1.
Alcatel-Lucent
Page 5
config>system>boot-bad-exec cf1:/<config-file> Step 3. Follow the Standard Software Upgrade Procedure on page 2.
Page 6
Alcatel-Lucent
RESOLVED ISSUES
RESOLVED IN R5.0R2
The following are specific technical issues that have been resolved in Release 5.0R2 of 7210 SAS-M OS. From release 5.0R2 7210 SAS-M supports VRRP Standby forwarding. [150203] In previous release, Down MEPs configured over spoke-SDP goes into defect state "DefRDICCM" when SDP using LDP LSP as tunnel label and LSP is switched to another IP Interface due to shutdown of original IP interface. This issue is resolved from 5.0R1. [138325] XCON was not raised as expected in a VPLS Service if there are 2 UP MEP-s at 2 different levels on 2 different endpoints in the service. Issue is resolved in 5.0R2 release. [146908] From release 5.0R1, Dot1ag 2dm and 1DM packets are sent with default priority of 7, in earlier releases default priority was 0. [143576] In release 5.0R1, multiple remote MEPs under one association with ccm-interval 100ms configuration fails, issue is resolved in 5.0R2. [149509] MCS peer ship (MC-LAG control session) was not formed when control packets received with MPLS labels. Issue is resolved in 5.0R2. [146619] Node lost management and console access when node receives malformed Tacacs authresponse. Issue is resolved in 5.0R2. [148054] In release 5.0R1, 1588 was not supported with 10 gig ports, this issue is resolved in 5.0R2. [142398] In release 5.0R1, 1588 PTP follow up packets were not getting mirrored. Issue is resolved in 5.0R2 In previous release, If ipv4 and ipv6 servers configured for radius, in case ipv4 server is not responding, then 7210 was not communicating with ipv6 radius server. Issue is resolved in 5.0R2. Workaround was, not to configure ipv4 source address for radius application or not configuring ipv4 or ipv6 source address for radius application. This issue is also not seen if only ipv6 source address is configured for radius application. [146182] Packets were not looped back if loopback with mac-swap is applied on Q1.Q2 sap for 7210 SAS M in network mode only. Issue is resolved in 5.0R2. [147013] SAS-M access-Uplink mode, egress sap stats were not incrementing for the multicast data traffic in the MVR user VPLS service, issue is resolved in 5.0R2. [136684] If "split-horizon-group <group-name>" CLI, where <group-name> configured with name having a space at the beginning (or) end (or) more than one contiguous space in port split horizon group name, config file execution will error out during upgrade. Cases of split horizon group name containing single space (can appear multiple times separated by a character) is resolved in release 5.0R2. In case of previous release, workaround is to edit the config file before upgrading to ensure split horizon group names are with double quotes or no space(s) in the group name. [142324] 7210 SAS-M in network mode with 4.0R6 release, if "config>system>res-prof>ingressinternal-tcam no acl-sap-ingress" is configured, saving this config file stores extra "exit" in config file. Re-execution of saved config will error out. 5.0R2 release resolves issue of upgrading from 4.0R6, node can be upgraded to 5.0R2 with config file saved with 4.0R6.
Alcatel-Lucent
Page 7
Note that, the above issue is not observed if default value of "acl-sap-ingress" is not changed. Log events for changes to "configure system resource-profile" CLI context were not generated, issue is resolved in 5.0R2. [146911] In previous releases, 7210 SASM allowed creation of more than 64 saps in a vpls service with a combination of 10G mda & 1G ports. In 5.0R2 such combination is also restricted to max of 64 saps per service. [145558] In earlier releases, SAP ingress qos policy with IP criteria applied on SAP, ingress non IP traffic classified to dscp value "be" and corresponding fc. From release 5.0R1, non IP payload is classified to "default-fc". [151005] Prior to 5.0R1 release, two time ACL resources were consumed when ACL is applied to access lag having one port from fixed 10G port and other port from 10G MDA. This issue is resolved from 5.0R1. [136676] When an egress filter (ip or mac) is applied to the qinq SAP, the SAP statistics show double the number of packets actually egressing SAP. This issue is resolved in 5.0R2. [150205] In release 5.0R1, VRRP (owner mode) configured on network IP, deconfiguring VRRP results in stale entry in ARP table. Due to this network protocols (RSVP, BFD, and other network protocols) went down. This issue is resolved in 5.0R2. [149258]
RESOLVED IN R5.0R1
The following are specific technical issues that have been resolved in Release 5.0R1 of 7210 SAS-M OS. In previous releases SyncE active ref flaps if standby ref port flaps. This issue is resolved in 5.0R1. [143748] In previous releases "debug sync-if-timing force-reference ref" was not selecting the intended port internally. This issue is resolved in 5.0R1. [144146] With snmp trap configured, VPLS PW switch over timings are optimized in 5.0R1 release of 7210 SAS-M. [131510] From Release 5.0R1 "show card detail" displays "Last bootup reason". If 7210 SAS is power cycled "Last bootup reason" displayed as "power cycle", for any other reason, "Last bootup reason" displayed as "hard boot". [101378] From release 5.0R1 config load fails if there is mimatch in config and index file, following message displayed on console: MINOR: SVCMGR #2093 Mismatch in Index file and Config File In such case, deleting index file and re-loading will load config file. [142700] In scaled MSTP configuration, on lag flap some times loop was observed in data service. This issue is resolved in 5.0R1. [145347] In release 5.0R1, IPv6 ACL 64-bit mode supports only source and destination IPv6 address match, other match options which are not supported were blocked in CLI and snmp. [144609] In previous release, when MD5 is enabled on RSVP, LSP went down during MBB global revert if the optimized mbb path is along the bypass path. This issue is resolved in 5.0R1 release. [147143]
Page 8
Alcatel-Lucent
RESOLVED IN R4.0R7
The following are specific technical issues that have been resolved in Release 4.0_R7 of 7210SAS M OS. In the earlier releases of 7210 SAS-M 24F 2XFP, when all of the 4 x 10G ports (that is, when 2 x 10G MDA and the 2 x10G fixed ports) were in use, in a small scenarios, some of the 10G ports stopped transmitting. This issue of 10G port hang is fixed in 7210 SAS release 4.0R7. [136922] Note: The fix requires newer version of CPLD firmware on 7210 SAS-M, It is mandatory to upgrade to 7210 SAS release 4.0R7 image using "admin reboot upgrade" CLI. The workaround for this issue is available from 4.0R1 release, refer "RESOLVED IN R4.0R1 section". When device is in power on state, insertion and removal of 10G MDA is supported from 7210 SAS 4.0R7. NOTE: The fix requires newer version of CPLD firmware on 7210 SAS-M, It is mandatory to upgrade to 7210 SAS 4.0R7 image using "admin reboot upgrade" CLI. In a few cases, 7210 SAS-M reported false fan fail alarm. This issue is resolved in 7210 4.0R7. [133331] Note: The fix requires newer version of CPLD firmware on 7210 SAS-M, It is mandatory to upgrade to 7210 SAS 4.0R7 image using "admin reboot upgrade" CLI. In release 7210 SAS 4.0R7, FRR fail over timings are improved for the scenarios, where: The primary path does not use PHP and the backup path uses PHP. The port going down either due to link fail or port shut. [135505]
In earlier releases, the console message was displayed when EFM "remote loopback" or "local loopback" on L2 Uplink port is initiated, this issue is resolved in 7210 SAS 4.0R7. [136466] In the earlier release, rebooting 7210 SAS-M without sap index file and with scaled configuration of vprn saps using sap-ingress qos, the device might fail to load the whole configuration with the below message: "MINOR: SVCMGR #1622 Insufficient ingress resources to create the SAP" This issue is resolved in 7210 SAS 4.0R7. [141678] In the previous 4.0 releases, when power supply was taken out after switch off, "critical" LED was glowing. In release 4.0R7, when power supply is taken out after switch off, "critical" LED goes off and "Major" LED goes on. [139218] In previous releases, CES SAP Packet counts displayed for "#monitor service id xx sap 1/2/x.x rate CLI commands were absolute values instead of the rate. From 4.0R7 correct rates are displayed. [137903]
RESOLVED IN R4.0R6
The following are specific technical issues that have been resolved in Release 4.0_R6 of 7210SAS M OS. In previous releases, packets that ingress a network interface and egress out of VPRN SAP and dot1p values were getting re-marked as the default re-mark policy even when remarking is disabled on access egress port. This issue is resolved in 7210 SAS 4.0R6. [121822]
Alcatel-Lucent
Page 9
In previous releases, when re-marking was disabled on access port, in case of packets that ingress on VPRN SAP and egress out of VPRN SAP and dot1p value of egress packet was same as ingress dot1p value. This issue is resolved in 7210 SAS 4.0R6. [121540] In 7210 SAS-M Access-uplink mode, when default and dot1q SAPs exist on same port, egress SAP stats of default (*) SAP increments when traffic sent out of dot1q SAP. This issue is resolved in 7210 4.0R6. [126890] In 7210 SAS 4.0R6, a fix is provided to prevent the high CPU issue, if the inserted Copper SFP is faulty (PHY read fail). An error message is displayed, if SFP read fails. [130324] In case of 7210 SAS-M as LSR, when MPLS packet ingresses with two labels and egress with single VC label (penultimate hop with php enabled on LER), egress packets always take "be" queue, even when ingress packets were classified to different FC's. This issue is seen from 7210 SAS 4.0R1 release and is resolved in 7210 SAS 4.0R6. [136733] In previous releases, when the ingress statistics mode of a SAP is set to forward-dropcount, in the output of the command monitor service id <> sap <> rate" the values shown against "For. InProf" and "For. OutProf". In 7210 SAS 4.0R6, this issue is resolved and the values are shown against "Total Forwarded" and "Total Dropped". [134878] The system reboots automatically after 500 days of uptime due to wrapping of internal counter which was resolved in 7210 SAS 4.0R1. [135164]
RESOLVED IN R4.0R5
The following are specific technical issues that have been resolved in Release 4.0_R5 of 7210SAS M OS. In the previous release, if LAG flaps on account of member ports being removed and added back, VPRN SAP stats were not incrementing. The alternative was to shut or no-shut VPRN service. The issue is resolved in this release. [127081] In the previous release, when Hello padding was enabled on remote node, ISIS would not ascend with that node. The alternative was to disable padding on the remote node. The issue is resolved in this release. [131058] In 7210 SAS-M Access-uplink mode, if CFM was enabled on multiple SAPs belonging to the same service, removing one of the SAP from the service was resulting in "defRemoteCCM" state on other SAPs. The issue is resolved in this release. [119056] Prolonged flap of network IP interface resulted in traffic disruption in VPRN, VPLS or Epipe service. The issue is resolved in this release. [125449] IPv4 Multicast data traffic continues to flow on the standby subgroup of LAG after switchover to primary subgroup. However, at the other end traffic on standby subgroup dropped as expected. The issue is resolved in this release. [130889] In 7210 SAS-M Access-uplink mode, static mrouter configured on SAP was not working after igmp-snooping shut or no-shut in a service. The issue is resolved in this release. [130663] From 7210 SAS 4.0R5,for record type SAA, acct-policy "collection-interval" minimum value starts from 1 minute, now ranges 1-120 minutes. [132523] There existed MIB compilation issues using some of the third party tools, in this release MIB's can be compiled using some of the third party tools. [118513]
Page 10
Alcatel-Lucent
RESOLVED IN R4.0R4
The following are specific technical issues that have been resolved in Release 4.0_R4 of 7210SAS M OS. In previous releases, when LDP was shutdown, IP packet arriving on a router interface containing 0x286 value at IP header offset 22 was dropped instead of L3 forwarding. Workaround was to enable LDP on the system using CLI: config>router>ldp>no shutdown. This issue is resolved in 4.0R4.[128896] In previous releases, sap accounting records does not get reset when sap statistics ingress counter-mode was changed. This issue is resolved in 4.0R4.[124643] In SAS-M access-uplink mode, when snooping enabled on an access-uplink port, learned multicast traffic was impacting the unicast meter instead of multicast meter in previous releases. This issue is resolved now.[127139] In previous release of SAS-M acceess-uplink mode, G.8032 took around 100-200 ms to recover after the links were restored. In 4.0R4 this issue is resolved and revertive times are sub 50 ms.[130977] In previous 4.0 releases, on execution of CLI "config system security mgmt-access-filter ip-filter entry 1 router <router-instance>", console hanged and management access to the system was blocked. This issue is resolved in 4.0R4.[130545] From release 4.0R4 "proxy-arp-policy" configuration for vprn interface is supported.[130032] In previous releases, with ISIS configured on IP interface, if the IP interface prefix is changed from higher value (example - 20.0.0.1/31) to lower value (example - 20.0.0.1/ 24) and again set to higher value (example - 20.0.0.1/31), then IP forwarding was failing, LSP were brought down and ping failed. This issue is resolved in 4.0R4.[126237]
RESOLVED IN R4.0R3
The following are specific technical issues that have been resolved in Release 4.0_R3 of 7210SAS M OS. In previous release, lsp pings/trace was failing over the facility backup tunnel. This issue has been fixed in 4.0R3. [119954] From 4.0R3, PBB B-SAP on LAG configuration is supported.[122880] In previous release, if PBB "backbone-dest-mac" entries (configured in pbb-epipe service or learnt dynamically in case of pbb-vpls) exceeds max backbone-dest-mac entries then following error message displayed on console. 1:iomMsg-1:IOM:add_update_backbone_mim_port Sap index allocator failed for mac 1:iomMsg-1:IOM:add_update_backbone_mim_port Sap index allocator failed for mac. In 4.0R3, when "backbone-dest-mac" (pbb tunnel termination) entries are exhausted, CLI displays error while attaching ivpls/epipe service to bVPLS service or new sap addition to existing bvpls service. [125357] In previous releases, TACACS authenticated CLI users experienced slow response in some cases. This issue has been resolved.[122799] When 7210 SAS-M configured in access-uplink mode, IGMP enabled services having saps on same port if igmp snooping is shutdown in one service, and igmp data forwarding stopped on other service. This issue has been resolved in 4.0R3.[123370]
Alcatel-Lucent
Page 11
In previous release, if multiple saps exist on loopbacked port, it was recommended to shutdown saps, which are not configured for loopback during loopback test, otherwise cpu utilization increased if other saps were forwarding traffic. This issue has been resolved in 4.0R3. [125259] Issue of dropping LLC frames, which are received on sap with control field 0x8e88, is resolved in 4.0R3.[126469] SCP file transfer rate is improved in release 4.0R3.[127449] For SAS-M in acces-uplink mode, in prior releases, when IGMP join was received from IP addresses in the range of 225.0.0.1-239.255.255.255.255 that share the MAC addresses with those in the link-local range 224.0.0.1-224.0.0.255, entry in MFIB was not created and traffic was flooded in service. Now this issue has been fixed. The system creates a entry in the MFIB table and replicates traffic only to the members.[127572] Note that for SAS-M in network mode, traffic is flooded in service.
RESOLVED IN R4.0R2
The following are specific technical issues that have been resolved in Release 4.0_R2 of 7210SAS M OS. Using 4.0R1 release, file download using SCP took more time compared to previous releases. In 4.0R2, this issue has been resolved, and file download time is similar to pre4.0r1 releases. [126557] svcVRouterID mib object is enabled in 4.0R2 release.[126903] In previous releases, "show eth-cfm mep" for remote mep, Rx CC showed "True" but HighestDefect showed "defRemoteCCM" when the remote MEP was deleted or remote port/sap was shut down. This issue has been resolved. [124981] In previous releases, SAS-M in network mode, single tagged igmp control packets on Q.* sap were not learned in mfib, and data was not following mfib. This issue has been resolved.[108801] Packet dropped in the primary LSP when the re-calculated detour tunnel flaps. This has been resolved in 4.0R2.[122661] In previous release, 7210 SAS-M access-uplink mode, when port loopback without MAC swap configured, traffic egressing out of *.* epipe sap was not looped back. This issue has been resolved in 4.0R2. [124521] In release 4.0R1, Mac filters attached to sap were not working when default action on filter was toggled from drop-forward-drop. This issue has been resolved. [124726] In 4.0R1, dynamic update of mpls-lsp-exp-profile-map policy was not taking effect for ILDP labels in some cases. This issue has been resolved in 4.0R2.[125872] 7210 SAS-M 24F 2XFP: if bof's "no-service-ports" as "loopback_no_svc_port", port loopback with mac swap stopped working if null encap configured on loopbacked port changed to dot1q/qinq encap. This issue has been resolved in 4.0R2. [125956] In 4.0R1, if no ports were assigned for "uplinkA-port", "uplinkB-port", and "eth-mgmtdisabled" in bof, image load from flash "cf1:\" failed, and box did not boot. This issue has been resolved in 4.0R2.[126409]
Page 12
Alcatel-Lucent
With 4.0R1, if 7210 SAS-M booted with config file having configuration ql-selection enabled under sync-if-timing, after boot, box crashed. This issue is resolved in 4.0R2.[127164]
RESOLVED IN R4.0R1
The following are specific technical issues that have been resolved in Release 4.0_R1 of 7210SAS M OS. Tagged BPDUs on a null SAP were forwarded by the software if SAS-M is configured in access-uplink mode. From 4.0R1 release, tagged BPDUs is forwarded by the hardware. [109624] In previous releases, SAS-M in access uplink mode, single tagged igmp control packets on Q.* sap were not learned in mfib, and data was not following mfib. This issue has been resolved. [108516] In prior release of 7210 SAS-M 24F 2XFP, when all of the 4 x 10G ports (that is, when 2 x 10G MDA and the 2 x10G fixed ports) are in use, in a small amount of scenarios some of the 10G ports stop transmitting. In this release, as a workaround, if software detects such a condition it recovers the port by re-initializing the fixed 10G ports (1/1/25 and 1/1/26). If 2port LAG with 10G interfaces is needed, it is recommended to use, one port from fixed 10G and another port from the 2x10G MDA, as in this case re-initializing the ports may not result in protocol flap. [121819] When LSP was added to SDP, in certain scenario error message "siaSdpInfoEntrySet: sdpAddLspId failed:" displayed on console and LSP addition failed. This issue is resolved in 4.0R1.[122970] Detour LSP setup was failing after router-id of one of the nodes in the path is modified, this issue is resolved in 4.0R1.[122288] In previous releases removal and addition of LAG member ports resulted in BFD protocol flap for some cases. This issue is resolved in 4.0R1.[109046]
RESOLVED IN R3.0R6
The following are specific technical issues that have been resolved in Release 3.0_R6 of 7210SAS M OS. In previous releases, when the internal loopback was configured, T1 port on the CES MDA operational was "down" until signal was present or a physical loopback was plugged onto the port. In this release, the port comes operationally "Up" when the internal loopback is configured even though no physical loop/signal is present on that port, and loopback works without physical loop/signal. [121052] Removing and inserting back the Copper/Dual Rate SFP was resetting the port mtu to default value, this issue has been resolved. [121404] In FRR facility mode, if implicit-null-label was enabled on LSR, 7210 LER incorrectly populates the label when LSP was active on bypass tunnel. This resulted in dropping of STP, Dot1ag, SDP Keepalive, sdp-ping PDU's. In this release, this issue has been resolved.[119515] [119536] In a default LSP configuration that used fast reroute facility protection, a bypass tunnel would not be signaled if the RESV message contained the router ID as the first entry in the
Alcatel-Lucent
Page 13
record route object, and the router ID was not advertised in the OSPF area. This issue only occurred when interoperating with other vendors devices. The workaround is to either advertise the router ID in the area or to disable node-protect. This issue has been resolved.[111700]
RESOLVED IN R3.0R5
CLI/SNMP
The following are specific technical issues that have been resolved in Release 3.0_R5 of 7210SAS M OS.
The clear router mpls lsp command of an LSP in operationally down state now clears the down time.[11697] A CLI session might have remained logged in beyond its idle-timeout period if the user improperly terminated the CLI session by closing the session window while a multi-output CLI command (that is, the "monitor" command) was in progress. This issue has been resolved.[111704] When a user enables/disables standby-signalling-master, the node did not send the modify Trap. This issue has been resolved. [116509] Creating a user with all the SNMP OIDs are sent in one PDU and executing CLI "admin display-config" and "admin tech-support", or "configure system security / info", hangs CLI session. This issue has been resolved. This issue does not occur in SAS-M 1.1 releases of SAS-M. [117416] For SAS-M in acces-uplink mode, CLI errored out while doing 'no fc af' on networkpolicy. This issue has been resolved.[118866] In previous releases, CLI was allowing SAP configuration when associated with an endpoint having "standby-signaling-master", now this configuration is not allowed from CLI.[118393] During boot up, if "debug mirror-sorce" CLI executed as a part of boot good-exec, error message was displayed. This issue has been resolved.[113353] For VPLS service, config of sdpBindControlWordBit and sdpBindOperControlWord object for SDP using snmp is disabled from release 3.0R5 because the control word configuration for vpls service was not supported in 3.0 releases.[118315] In previous releases, when more than one type-7 LSAs were in the ospf database of the ABR router for the same prefix destination, the ABR did not translate to type 5 LSA properly. This issue has been resoled.[111672] In previous releases, for ISIS, when exporting routes from OSPF into IS-IS, IS-IS may continue to advertise some OSPF imported prefixes even after they have been removed from the route table. This issue has been resolved. [111677] Some BFD enabled static routes might have remained inactive after the physical link carrying the relevant BFD sessions recovers after a rapid bounce. This issue has been resolved. [111681/111683]
IP
Page 14
Alcatel-Lucent
On SAS-M that had both IS-IS and OSPF configured, CSPF might have failed for directlyconnected interface addresses that were only in OSPF. This would occur if the routing table contained an IS-IS route that was the same as the prefix assigned to the OSPF interfaces. Workaround: Do not specify directly-connected interface addresses in strict-hop LSPs. This issue has been resolved.[111715]
On pre-configured node, insertion and removal of copper SFP multiple times resulted in ping failure to directly connected IP interface. This issue has been resolved. [118509] An MPLS LSR would incorrectly send RSVP RESV refresh messages to the upstream LSR after the link to that LSR had failed and recovered. This kept the state for the LSP alive, and the head-end LSR would be unable to set up a new LSP if it did not increase the LSP ID. This issue has been resolved.[111686] When traffic switched from secondary LSP to primary LSP with MBB, single packet loss was observed. This issue has been resolved.[112597] Unexpected TLVs that are received in LDP hello messages no longer cause system memory depletion over time.[111706] When scripts were used to configure multiple objects on a busy system, a newly added LDP interface might have remained operationally down with the reason interface Invalid despite the absence of any legitimate condition. This issue has been resolved.[111713] In FRR facility mode, if implicit-null-label was enabled on LSR, 7210 LER incorrectly populates the label when LSP was active on bypass tunnel. This results in traffic disruption. In this release, this issue has been resolved.[119035] In previous release, when performing mac-trace in VLL redundant services with control word, the box used to crash. This issue has been resolved.[114817] A system configured to use "exit-on-reject" that also had RADIUS authentication as the first of two or more authentication methods might not have attempted subsequent methods even if it did not receive an explicit REJECT from the RADIUS server (for example, first response time-out). This issue has been resolved.[111687] After a few hours, the 7210 SAS-M would fail to sync the system time with an NTP server. In this release, the 7210 SAS-M syncs with the server. This issue was observed with 3.0R3 and 3.0R4. [118779] In case of Eth ring service and ethring shutdown, if ethring was enabled first using "no shutdown" before Eth ring service was enabled using "no shutdown", ethring did not converge properly. If Eth ring service was enabled before eth ring, there was no problem with eth ring convergence. This issue has been resolved.[110993] "oam mac-ping/mac-trace" was failing when used with fc other than be. This issue has been resolved.[118865] For a LAG configuration with more than one port, every other jumbo frame was dropped. The solution was to increase the sap-ingress meter MBS from the default value of 128Kbits to 144Kbits for two port LAGs. From release 3.0R1 of SAS-M and its variants, sap-ingress meter default MBS value is set to 512. This issue has not been seen from 3.0R1. [73552]
MPLS
OAM
QOS
Alcatel-Lucent
Page 15
SERVICES
In an LAG, if port was down due to no lacp packets received from other end, then unlearned traffic sent on other active ports of lag was also flooded on the oper down port. This issue was specific to SAS-M configured in access-uplink mode and has been resolved. [107515] Services that carry traffic over the ports of a 10G MDA in SAS-M (in Network mode) now support IGMP snooping. [110177] In release 3.0R5 10G mda ports can be used for network boot and autoinit. [108139]
SYSTEM
RESOLVED IN R3.0R4
The following are specific technical issues that have been resolved in Release 3.0_R4 of 7210SAS M OS. Issue of system crash on executing lsp-trace on standby path with implicit null at LSR and LER has been fixed in this release. [115511] In earlier releases, sap ingress mirroring on Explicit Null sap was mirroring non-zero tag packets also. This issue has been fixed. [115210]
RESOLVED IN R3.0R3
CES
In previous releases, CES packets, when sent over a LAG, were load distributed causing packet re-ordering. In this release, CES is supported in a configuration where the packets egress out of a LAG. [97616] In previous release, Dot1ag CCMs did not egress out when 10GMDA ports were configured as "no service port" in bof. Issue has been fixed in this release.[109113] When Y1731 MEP is configured over the spoke "two-way-delay-test" and "one-waydelaytest" was not working, issue is resolved in this release. [111669] SAS-M crashed when an oam mac-ping or a mac-trace in an epipe service with QinQ access SAP with spoke configuration of vc type vc-vlan. This issue has been resolved in this release. [110987] In previous release, OAM tools such as lsp-ping was affected when SAS-M was the penultimate-hop to an egress LER that advertised an implicit null label. The SAS-M, on processing an incoming single-labeled (IP) packet, sent out the packet towards the egress LER by stripping the label, while maintaining the ether-type as 0x8847 instead of 0x0800. This issue has been resolved. [104649] In previous releases, system was assigning same MAC address to port 1/1/26 and first lag interface that was created. In this release, this issue has been resolved. [114246] In previous release, snmp query of "sysObjectID" for "SAS-M 24F 2XFP ETR 7210" returned a value of "timetraSASModel7210SASM24F2XPReg". In this release,
OAM
SYSTEM
Page 16
Alcatel-Lucent
sysObjectID returns correct value of "timetraSASModel7210SASM24F2XPETRReg". [113829]
RESOLVED IN R3.0R2
ACL
In prior release, Egress mac/ip filters was not working on 0.* access sap when box was in MPLS mode. This issue has been resolved. [108628] 7210 SAS-M 1.1 software release: When 7210 received a LS_UPD with a Type-10 LSA with no TLVs, LS_ACK was not sent and LS_UPD packet was dropped. This has been resolved. This issue was resolved from 7210 2.0_R1 [110971] In prior release, ARP resolution was not happening when qinq etype is changed to 0x9100(non default value) and clearing ARP database on a 0.* SAP in an IES service.This issue has been resolved. [109299] In prior release, oam cpe-ping was not forwarded from one spoke to another spoke with PHP enabled. This issue has been resolved.[108426] In prior release, with the node operating in network mode, when the IP interface was down, attaching or removing a different QoS policy to the IP interface multiple times resulted in exhaust of QoS resources, and new QoS policy could not be attached. This issue has been resolved. [97873] In prior release, SAS-M in access-uplink mode for network qos CLI allowed configuring egress dscp remarking value, but it did not take effect. CLI blocks that configuration from release 3.0r2. [108458] In previous release, for SAS-M with 10G MDA, access-egress qos policy queue cir-rate pir-rate max value configurable was 1000000(1G). In this release, max value of 10000000 (10G) can be configured. Similarly for port, ERL rate max value of 10000000 (10G) can be configured in this release.[111009] In prior release (for few 7210 SAS-E and 7210 SAS-M platforms), the system reported false fan alarms even when the fan module was working properly. The system would report fan failure alarm ("Fan 1 failed") followed by fan failure clear alarm ("Clear Fan 1 failure"). This issue has been resolved. [108035] In prior releases, the system used to raise an over-temperature alarm when the temperature measured by the chassis exceeded the threshold of 50C. This threshold has been increased to 58C for the standard variants of the 7210 SAS-M platforms (that is, 7210 SAS-M 24F, 7210 SAS-M 24F 2XFP) to allow for an offset between aisle ambient temperature and temperature measured by the chassis. Similarly, the threshold has been increased to 68C for the extended temperature range variants of 7210, that is, 7210 SAS-M 24F 2XFP ETR.[107935]
IP
OAM
QOS
SYSTEM
Alcatel-Lucent
Page 17
SERVICES
In prior releases, packet received on SAP was dropped if the VLAN CFI bit was set to 1 and egressing on the network port which was a dot1q interface. This issue has been resolved [104403] In previous release, When QinQ etype is modified to a non-default value more than 3 times then the traffic did not flow over sap's that was added. This issue has been resolved[108798]
RESOLVED IN R3.0R1
The following are specific technical issues that have been resolved in Release 3.0_R1 of 7210SAS M OS. In prior release, egress mirroring was stopped for the port which is part of a lag, after port shut-/no-shut is done. This issue has been fixed. [105269] FAN speed and sound oscillated when SAS-M was running with 2.0R5 7210 OS. This issue has been fixed in 3.0R1 7210 OS. [108461] In prior releases when IGMP join was received from IP addresses in the range of 225.0.0.1239.255.255.255.255 that share the MAC addresses with those in the link-local range 224.0.0.1-224.0.0.255, the system creates a entry in the MFIB table and replicates traffic only to the members. Now this issue is fixed. Entry in MFIB is not created and traffic is flooded in service. [107026] In prior release, if mac filter entry has match criteria "dot1p 0 0", after 'admin save", it was changed to "dot1p 0 7". If box is rebooted with above saved config file, all packets which do not have dot1p=0 were getting dropped. This issue has been fixed.[107592]
RESOLVED IN R2.0R5
The following are specific technical issues that have been resolved in Release 2.0_R5 of 7210SAS M OS. When system IP is modified and restarting ospf results in crash of the system. Now this issue is fixed. [98901] Issue of Static LSP flapping every 4 hours is resolved. [78168] The following issue is fixed: Description - while creating an MEP in a service and a domain, the following messages may appear: IOM:attach_meter_and_action Entry exists. IOM:program_default_ifp_entry Attach Meter failed for EID.[100784]
Changing the fdb-table-high-wmark and fdb-table-low-wmark values more than once will stop generating any notification. This issue is fixed now.[81188] Issue of DNS packets do not use the source IP configured for DNS applications is resolved. [75420] An access egress policy with remarking enabled in VPLS services with the vc-type equal to vlan or force-vlan-vc-forwarding does not remark Dot1p values. This is applicable to all traffic ingressing a spoke SDP and egressing out a Dot1q SAP. This issue is resolved.[81761]
Page 18
Alcatel-Lucent
A mgmt-access-filter with a deny-host-unreachable action now sends correct messageDestination Host Unreachable. [73676] When SAS-M is the penultimate-hop to an egress LER that advertised an implicit null label, transit service traffic going through the SAS-M towards the egress LER may get affected if the ingress network qos policy applied on the incoming ip interface is dynamically changed. This happens only if the SDPs are based on RSVP tunnels. This issue is resolved. [105115]
RESOLVED IN R2.0R4
CES
When the CES card is hot swapped out and swapped in, at times the following harmless message may appear on the console 1:iomMda-1-2:MDADRV:initiatePmonTransfer PMON XFER timed out for port 0 Now, this message will not appear. [103462]
MPLS
LDP graceful restart time was not accurately shown in the output of the command show router ldp session <peer-ip> detail. Now, the output shows correct time. [101201]. When MEPs were configured on active and standby spokes in a VLL pseudowire redundancy scenario, on a failover, the MEPs on the new active spoke would have the defect flag set. The issue was not seen if the MEP was configured only on the active spoke. This issue has been fixed. [100816] Lsp-ping/trace to ldp prefix with path-destination any other than 127.0.0.1 would fail. This issue has been fixed.[99489] tmnxOamMfibPingCtlTable for Mfib ping is enabled from this release. [104063]
OAM
QOS
Dynamic update of tos-marking-state at the ingress ip interface of an LSR (that uses RSVP tunnels) did not take effect. This issue has been fixed. [102733] 10Gig XFPs with the following part codes were not functional on the 7210. They are now functional. [99074] - SXP3102EX-W - SXP3102ZX-A8 - AFBR-720XPDZ - SXP3101LX-A4
SYSTEM
The 7210 showed high CPU utilization when a faulty SFP was inserted. This has been fixed. [82605/93904] The output of monitor port command now shows better port utilization statistics for a given port. [103278]
Alcatel-Lucent
Page 19
RESOLVED IN R2.0R2
The following are specific technical issues that have been resolved in Release 2.0_R2 of 7210SAS M OS. In a highly scaled configuration, under high CPU load conditions, at times a network LAG flap could cause other LAGs on the 7210 to flap. This issue has been fixed. [96776] In a highly IGMP snooping configuration, under high CPU load conditions, at times SDP keepalive failures occurred on certain events (such as a network lag flap). This issue has been fixed. [98042] Online insertion and removal of T1/E1 MDA is now supported. Using SNMP CES MDA reboot is now supported. The show port CLI command output showed DS1/E1 channel status up even when the port was in admin down state. This has been fixed. [93467] DS0 channel-group oper status was brought down when CEM SAP was deleted. Adding back the CEM SAP would bring up the channel-group. This has been fixed [97052]
CES
RESOLVED IN R1.1R8
The following are specific technical issues that have been resolved in Release 1.1_R8 of 7210SAS M OS. Creating a 2548th filter template along with the action criteria failed. This has been fixed. [95978] Changing the meter mode from srtcm to trtcm in a SAP ingress policy did not reset the PIR value to the default. Now, the PIR value is reset to max. [96267] The tools dump system-resources now displays the correct usage of resources for user ACLs. [91662] When a copper SFP is removed from a port configured in network mode, the MTU value for the port is changed to 1518. Now, the MTU value is retained. [96998]
RESOLVED IN R1.1R7
The following are specific technical issues that have been resolved in Release 1.1_R7 of 7210SAS M OS. When an egress ip-filter with a drop default-action is attached to an IP interface, it affected outgoing MPLS traffic through the spoke SDP associated with that IP interface. This issue was seen in 1.1R6 and is fixed. [92819] When an egress IP filter is attached to an IP interface, it affected incoming IP traffic through that IP interface. This has been fixed. [88816/92295] Pinging with the do-not-fragment option for certain packet sizes failed. This has been fixed. [92977] Spurious traps No NTP server available'/'NTP server available' were being sent out at times. This has been fixed. [93106] Ingress packet counts for 10Gig ports stopped incrementing under following events: Shutdown/no shutdown of a primary LSP over the 10Gig ports. Deconfiguring and configuring ports under IP interfaces configured on 10Gig LAG.
Page 20
Alcatel-Lucent
This is fixed and counters are updated post the events. [91643] The show router isis database id detail command did not show the correct bandwidth usage for different priorities. This has been fixed. [91163] Occasionally, on 10Gig ports, the following console messages appeared when line rate or close to line rate traffic is sent. CRITICAL: LOGGER #2002 Base 1:MDADRV:UNUSUAL_ERROR "xmacPollStats: MDA 1, port 25, stat 6 bogus read 2b4f72d0000004cb, last read was 5d439a1c000004ca, s/w count dcba5d97000004ca" [89089/91859]. This issue has been fixed. IGMP packets arriving on a default SAP belonging to a VPLS service with IGMP snooping enabled were being dropped. Now they are forwarded. [87029] MPLS packets with three labels were remarked to the default EXP while egressing. This issue is fixed. [81956] Single tagged EFM OAM packets were being processed by the CPU. Now they are forwarded in hardware. [82634] RADIUS packets went out with the system IP address as the source IP address even though a source address was configured for the RADIUS application. Now, they go out with the configured source address. [92018] When IGMP packets received from peers were forwarded to another peer, an extra 4 bytes was added in the Layer 2 frame (the IGMP packets were successfully processed though). Now, the extra 4 bytes are not added. [91891] SAP egress stats did not increment when an egress IP filter was applied on an IP interface. Now they increment. [90327]
RESOLVED IN R1.1.R6
ACLS
The following are specific technical issues that have been resolved in Release 1.1.R6 of 7210 SAS-M OS.
Under management access filters, the src-port match-criteria cpm option has been removed as it is not supported. [87556] Egress filters applied on a dot1q SAP of service (A) would match packets (with the same dot1q tag) of a different service (B) destined to a dot1q* SAP on the same physical port. Counters associated with the filters also incremented. This was applicable only when an ingress SAP of service (B) had either a null or dot1q* encapsulation. This issue is fixed. [84135]In order to fix this issue, egress ACLs are restricted to 256 for both mac and ip match criteria. Refer to Upgrading From Prior Releases on page 3. Disabling and enabling re-distribution of external routes in OSPF did not re-populate NSSA LSAs. This issue is fixed. [78868]
IP
Alcatel-Lucent
Page 21
QOS
In a SAP ingress policy, modifying the MAC or IP match criteria did not take affect. Traffic continued to hit the old rule. This is fixed. [91295] When EFM was put in local or remote loop-back mode, and then reverted back, remarking of DSCP values for IP traffic was incorrect. This is fixed. [90696] When traffic was destined to a dot1q* SAP the egress SAP statistics did not increment if there was another dot1q SAP on the same port (belonging to a different service) and the dot1q tag of the traffic was matching this dot1q SAP. This was applicable only when an ingress SAP had either a null or dot1q* encapsulation. This is fixed. [84162]
STATISTICS/ACCOUN
TING
RESOLVED IN R1.1.R5
QOS
When the description for ip-criteria in the SAP ingress QoS policy context is changed, the command may return an error message indicating that the number of resources (classifiers and/or meters) have been exceeded for that policy. This issue has been resolved. [88267/88379] In network ingress, metering and accounting did not take place under an IP interface if the spoke SDP is either configured with the vc-type vlan or has force-vlan-vc-forwarding enabled. This issue has been resolved. [86910/86844] In network ingress, dynamic updates of LSP-EXP to FC mapping did not take affect when the spoke SDP is either configured with vc-type vlan or has force-vlan-vc-forwarding enabled. This issue has been resolved. [86842/86968] On a spoke SDP, when force-vlan-vc is enabled with a vlan-vc-tag of 0 (zero), packets egressing out of the spoke did not contain the VLAN value 0. This has been resolved and the packets egress out with a VLAN value of 0 under such a configuration. [88269] The OAM-Learned Count field has been introduced in this release in the output of show service id service-id fdb. This field allows the user to identify the number of MACs installed in the FDB for that service through the mac-populate command. [88489]
SERVICES
RESOLVED IN R1.1.R4
ACLS
If there were a large number of filters attached to a number of SAPs, and if the box is rebooted with such a configuration, filter counters may not increment when the traffic matches relevant entries. This issue is fixed in this release. [81290]
Page 22
Alcatel-Lucent
Filter MAC entry creation using SNMP failed if the tMacFilterParamsEtherType is included while creating the entry. Now filter creation with ether-type value works through SNMP. [86962] LACP can now be enabled only on a maximum of 12 ports. [86730] In a scenario where a VPLS service and an Epipe service are using SAPs on the same port and if the Epipe SAP happens to be a default SAP or an explicit null SAP, a shutdown of the default SAP (or the explicit null SAP) or a shutdown of the Epipe service would stop traffic flowing through the VPLS service. This issue is fixed. [87275] Spoke SDP stats of the primary spoke SDP in an Epipe service resets to 0 (zero), when it is made non-primary (another spoke SDP is made primary in the service). This issue is fixed, and the stats do not reset on such an event. [87023] The monitor port and monitor lag commands showed incorrect statistics. Now they show correct statistics. [83757/86347] In a SAP ingress QoS policy, matching frame-type under mac-criteria is not supported. This frame-type option has been removed. [75162] Snmpget on tNetworkPolicyType for network QoS policy works now. [87314] The lsp-exp value is remarked to 0 (zero) rather than the default for the FC when executing a no lsp-exp-in/out-profile command in the egress of a network IP interface QoS policy. This issue is fixed. [86959] DSCP values of customer packets were reset to zero if the packets ingressed through an access SAP (if and only if the box was booted with a startup configuration in which the port is set to access mode). This issue is fixed and the DSCP values are preserved. [87966/87971] Under a network port policy with Dot1p classification, traffic for classifiers with outprofile were momentarily marked in-profile when some other classifier with profile in is changed to out. This issue is fixed. [85482] A copy of a network QoS policy worked only if the source policy had default egress configurations. [87091]. A copy of a network QoS policy with the sub-option overwrite did not work. [87033]. Both of the issues have been fixed.
LAG SERVICES
STATISTICS/ ACCOUNTING
SYSTEM
QOS
Alcatel-Lucent
Page 23
NEW FEATURES
RELEASE 5.0R2
FAULT PROPAGATION AND OAM MAPPING The following items describe features added to 5.0R2 of the 7210 SAS-M OS.
Platforms Supported: 7210 SAS-X, 7210 SAS-M network and access-uplink mode, and 7210 SAS-D Operators typically deploy many different technologies in the network. These technologies use specific notification methods to indicate or clear faults between peers. There is no native single approach for end-to-end Operation, Administration & Management (OAM). The fault mapping and propagation feature provides the mediation function to bridge the gap between different technologies and provide end-to-end OAM without requiring the operator to select a single OAM tool to run across the entire network. The mapping function is used to communicate and clear faults between the different OAM functions on the same node for a point-to-point service. Starting from 5.0R2, Epipe service can link and propagate or clear faults between endpoints using ETH-CFM with CCM and PseudoWire (PW) with LDP status bits. For instance, an Epipe service could span across the network using Ethernet access (CFM used for OAM), pseudowire (T-LDP status signaling used for OAM), and Ethernet access (CFM used for OAM or Link Loss Forwarding (LLF) used to propagate fault). Different Ethernet OAM strategies should not overlap the span of each other in order to avoid conflicts that can lead to fault propagation in the direction toward the original fault, a false positive, or worse, a deadlock condition that may require the operator to modify the configuration to escape the condition. For example, overlapping Link Loss Forwarding (LLF) and ETH-CFM fault propagation could cause these issues, as could using ETH-RDI as an ETHCFM fault trigger. NOTE: 7210 SAS-M in access-uplink mode and 7210 SAS-D platforms do not support MPLS and hence it does not support use of T-LDP status signaling for OAM. It supports use of CFM for OAM and LLF. For more information, see the 7210 SAS-MX and 7210 SAS-D Services and OAM and Diagnostics User Guides.
UP MEP SUPPORT FOR 7210 SAS-M ACCESS-UPLINK

MODE
From 7210 SAS 5.021, support is available for UP MEP on 7210 SAS-M access-uplink mode for VPLS and EPIPE service. Note that, for 7210 SAS-M network mode UP MEP was already supported in previous release. UP MEP allows operators to place a diagnostic point as close to the customer as possible. It allows operators to diagnose fault with services and measure service performance metrics up to the UNI demarcation point. 7210 UP MEP implementation supports both CFM and Y.1731, including SLM. It can also be used with SAA. NOTE: Before using UP MEP user needs to configure appropriate amount of resources using the CLI commands under "config> system> resource-profile". UP MEP shares resources with ACLs/ingress QOS, hence if upgrading from a previous release, user must ensure enough resources are available for use with UP MEP.
Page 24
Alcatel-Lucent
For more information, see the 7210 SAS-MX Basic System Configuration User Guide, 7210 SAS-M Services User Guide and 7210 SAS-MX OAM User Guide. IS-IS SUPPORT FOR IPV6 Platforms Supported: 7210 SAS-X, 7210 SAS-M network mode With this release, support for use of IS-IS routing protocol is available for IPv6. 7210 supports IS-IS IPv6 TLVs for IPv6 routing. This is considered native IPv6 routing with IS-IS. It has a limitation that IPv4 and IPv6 topologies must be congruent; otherwise IP traffic may be black holed. Service providers should ensure that the IPv4 topology and IPv6 topology are the same. 7210 also supports IS-IS multi-topology, that allows service providers to use different topologies for IPv4 and IPv6. For more information see, the 7210 SAS-MX Routing Protocols user guide. 1588V2 FOR FREQUENCY AND TOD Platforms Supported: 7210 SAS-D ETR and 7210 SAS-M access-uplink and network mode Precision Time Protocol (PTP) is a timing-over-packet technique defined in IEEE 1588-2008. PTP provides the capability to synchronize the network element to a Stratum 1/PRC-traceable source through a network that may or may not be PTP-aware. PTP provides an alternative to Adaptive Clock Recovery (ACR) with the advantages of being a standards-based messaging protocol, having lower bandwidth requirements, and potentially providing better performance. PTP also has the benefit of being able to transport both frequency and phase (time). 7210 SAS platforms (both 7210 SAS-M and 7210 SAS-D ETR) implements 2-step mechanisms as described in the standards. The IEEE 1588 functionality is integrated with the existing central clock mechanism. With both OC-Slave and BC, the frequency recovered from the PTP packet stream is made available as one of the input options to the central clock and can be distributed using synchronous Ethernet (syncE) to other nodes. Additionally, when acting as a BC, PTP recovered time can be distributed to other nodes, acting as PTP slaves, connected to 7210. Following are some of the major functionalities supported: OC-slave and BC support is available All Ethernet ports support PTP (both 1G and 10G ports are supported) Port-based timestamps in hardware is supported PTP hybrid mode is supported. In PTP hybrid mode, syncE is used to recover a stable frequency and PTP is used to recover ToD. PTP hybrid mode is highly recommended for use on 7210 platforms. Please read recommended PTP packet rates below. While acting as BC and OC-slave, 7210 supports use of lower rates up to 8pps for Sync/Delay-Request message exchange. In 7210 SAS-D ETR variant, only PTP hybrid mode with packet rate of 8pps or 16pps is recommended for use. The lower rates can be configured using the CLI command "config> system> ptp> log-sync-interval". Higher rates, i.e. 32pps and 64pps, are not recommended for use. These rates might possibly be used in a very small set off scenarios where users can ensure CPU availability for PTP.
Recommendations on PTP packet rates for 7210 platforms:
Alcatel-Lucent
Page 25
In 7210 SAS-M (all variants), it is highly recommended to use PTP hybrid mode with lower packet rates to achieve better scale. The lower rates can be configured using the CLI command "config> system> ptp> log-sync-interval". In 7210 SAS-M, PTP can be used for both frequency and ToD recovery in scenarios where the scaling requirement is very less (1 or 2 PTP clients). Users need to ensure CPU availability for PTP. In 7210 SAS-M, either Synchronous Ethernet can be used as a reference or 1588 PTP can be used as a reference. Both of them cannot be configured as a reference simultaneously. PTP cannot be used to distribute the recovered frequency to the T1/E1 ports on the CES MDA in this release. PTP OC-Master for frequency distribution is not supported in this release. Use of PTP timestamps for OAM messages is not supported in this release.
Following are some of the restrictions:
For more information, see the 7210 SAS-MX Basic System Guide. SUPPORT USB STORAGE Platforms Supported: 7210 SAS-M, and 7210 SAS-E. From 5.0R2 release 7210 SAS-M and 7210 SAS-E platforms support USB interface which provides storage functionality. It supports USB version 1.1. It allows the use of USB sticks providing them an alternate storage location with larger capacity than the internal flash. The USB storage device is identified as uf1: by the system and supports DOS file system similar to internal compact file system. The USB storage device can be used to store Timos images, configuration files, accounting records, and log files. The BOF file can point to images on USB and be used to load Timos images and configuration files. During bootup, the system USB storage cannot be used to load boot.tim (that is, the bootloader). Hence, the bootloader required to boot the device must not be stored on the USB (uf1). Following USB models from Sandisk are supported: Cruzer Fit size 4GB and 8GB Cruzer Blade size 4GB and 8GB
For more information, see the 7210 SAS-ME Basic System Configuration User Guide.
RELEASE 5.0R1
LDP-OVER-RSVP
The following items describe features added to 5.0R1 of the 7210 SAS-M OS.
Platforms Supported: 7210 SAS-X and 7210 SAS-M in network mode only The primary reason for LDP over RSVP-TE is to provide end-to-end tunnels that have two important properties, fast reroute and traffic engineering, which are not available with LDP. The solution is focused at large networks, where there are over 100 nodes in the network with MPLS extended up to the 7210 SAS devices used as the edge devices. Simply using end-to-end RSVP-
Page 26
Alcatel-Lucent
TE tunnels will not scale. While an LER may not have that many tunnels, any transit node will potentially have thousands of LSPs, and if each transit node also has to deal with detours or bypass tunnels, this number can make the LSR overly burdened. LDP over RSVP-TE allows tunneling of user packets using an LDP LSP inside an RSVP LSP. The main application of this feature is for deployment of MPLS based services, for example, VPRN, VLL, and VPLS services, in large scale networks across multiple IGP areas without requiring full mesh of RSVP LSPs between PE routers. In addition, without inter-area RSVPTE, the architecture of the network also becomes an issue. For scalability, isolation of local flaps, etc., it is prudent to design these networks with a core network connecting multiple smaller regional or metro networks. RSVP-TE in multi-area environments is significantly more complicated. NOTE: On 7210 SAS device, only FRR one-to-one is supported with LDP-over-RSVP. Implicit NULL label use must be enabled before use of LDP-over-RSVP feature. Please check the 7210 SAS-M,X MPLS user guide and the 7210 SAS-M and 7210 SAS-X services user guide for more information. BGP AUTO DISCOVERY (BGPAD) FOR LDP VPLS Platforms Supported: 7210 SAS-X and 7210 SAS-M in network mode only BGP Auto Discovery (BGP AD) for LDP VPLS is a framework for automatically discovering the endpoints of a Layer-2 VPN offering an operational model similar to that of an IP VPN. This allows carriers to leverage existing network elements and functions, including but not limited to, route reflectors and BGP policies to control the VPLS topology. BGP AD complements the existing Layer-2 VPN signaling method of targeted LDP. BGP AD provides one-touch provisioning for LDP VPLS where all related PEs are automatically discovered. The Service Provider can make use of existing BGP policies to regulate the exchanges between PEs in the same or in different AS domains. The addition of BGP AD procedures does not require carriers to uproot their existing VPLS deployments and to change the signaling protocol. Please check the 7210 SAS-M and 7210 SAS-X services user guide for more information. BGP RFC-3107 LABEL FOR L2 VPN
SERVICES
Platforms Supported: 7210 SAS-X and 7210 SAS-M in network mode only This feature adds support of Inter-AS BGP LSP tunnels to be used for L2 VPN services (VPLS and VLL services). Only Option-C is supported.. A new type of transport method is supported under SDP that allows using BGP LSP tunnels to reach the far end. VPLS and Epipe services are supported. The 7210 SAS devices support the 3-label version of BGP LSP tunnels. NOTE: On 7210 SAS device, only FRR one-to-one is supported for RSVP LSPs used with RFC 3107 BGP LSPs. BGP for exchange of IPv4 non-labelled routes is not supported on 7210. It must not be used. Only RFC 3107 labelled routes for L2 services is supported and validated. In software this has not been blocked though. Additionally use of BGP labeled route for /24 IP prefix is not supported as 7210 does not support 3107 for L3 services. Use policies to advertise only /32 prefixes required for L2 services. Please check the 7210 SAS-M and 7210 SAS-X services user guide for more information.
Alcatel-Lucent
Page 27
IES SERVICES (IPV4 ONLY)
Platforms Supported: 7210 SAS-X and 7210 SAS-M in network mode only Internet Enhanced Service (IES) is a routed connectivity service where the subscriber is connected to an IP router interface to send and receive Internet traffic. An IES has one or more logical IP routing interfaces each with a SAP which acts as the access point to the subscribers network. IES allows customer-facing IP interfaces to participate in the same routing instance (i.e. the base instance) used for service network core routing connectivity. IES services require that the IP addressing scheme used by the subscriber be unique between other provider addressing schemes and potentially the entire Internet. IP interfaces defined within the context of an IES service must have a SAP associated as the access point to the subscriber network. In this release, only IPv4 addressing with OSPF, IS-IS and static routing is supported for IES IP interfaces. Please check the 7210 SAS-M and 7210 SAS-X services user guide for more information.
VRRP (IPV4 ONLY)
Platforms Supported: 7210 SAS-X and 7210 SAS-M in network mode only The Virtual Router Redundancy Protocol (VRRP) for IPv4 is defined in the IETF RFC 3768, Virtual Router Redundancy Protocol. VRRP describes a method of implementing a redundant IP interface shared between two or more routers on a common LAN segment, allowing a group of routers to function as one virtual router. When this IP interface is specified as a default gateway on hosts directly attached to this LAN, the routers sharing the IP interface prevent a single point of failure. If the master virtual router fails, the backup router becomes the master virtual router. The new master router assumes the normal packet forwarding for the local hosts. VRRP can be implemented on IES service interfaces, VPRN service interfaces and on core network IP interfaces. It can be only used with IPv4 IP interfaces. Please check the 7210 SAS-M and 7210 SAS-X services user guide and the 7210 SAS-M,X Router Configuration guide for more information.
ROUTED VPLS (RVPLS)
Platforms Supported: 7210 SAS-D and 7210 SAS-M in access-uplink mode only Routed VPLS (R-VPLS) allows a VPLS instance to be bound to an IES IP interface. Within an R-VPLS service, traffic with a destination MAC matching that of the associated IP interface will be routed based on the IP forwarding table maintained in the base routing instance; all other traffic will be forwarded based on the VPLS forwarding table. In 7210, R-VPLS is designed for use of in-band management of the node. It eases operations by allowing for management of 7210 nodes in a ring topology using a single IP subnet. NOTE: R-VPLS must not be used to provide customer service. It is designed to be used for inband management of the node. In 7210, the following support is available with R-VPLS: Only IPv4 addressing is supported Only static routing is supported Only dynamic ARP is supported (static ARP is not supported)
Please check the 7210 SASD,E services guide and the 7210 SAS-M services guide for more information.
Page 28
Alcatel-Lucent
IES IPV4 IP
INTERFACE ON ACCESS PORTS
Platforms Supported: 7210 SAS-D and 7210 SAS-M in access-uplink mode only In prior releases, 7210 SAS-D and 7210 SAS-M (access-uplink mode) devices supported use of IES IPv4 IP interfaces on access-uplink ports for in-band management of the node. With this release, user has another option for in-band management of the node. Users can now use IES IPv4 IP interfaces on access ports for in-band management of the node. As before, only static routing support is available. Please check the 7210 SAS-D,E Services guide and 7210 SAS-M Services user guide for more information.
VLAN RANGES FOR VLL SAP
Platforms Supported: 7210 SAS-D, 7210 SAS-X and 7210 SAS-M (in both access-uplink and network mode) VLAN ranges provide a mechanism to group a range of VLAN IDs as a single service entity. This allows the operator to provide the service treatment (forwarding, ACL, QoS, and Accounting) to the group of VLAN IDs configured in the range. Use of VLAN ranges is supported only for Epipe services. The VLAN range values are specified using the connection-profile. Only one of the endpoints in an Epipe service can be a dot1q range SAP. On ingress of the access dot1q range SAP, VLAN tags are not stripped and retained when the ingress packet is forwarded out of the other endpoint with appropriate encapsulations. The ingress VLAN tag is only used to map the packet to appropriate dot1q range SAP and the service. For more information about use of access dot1q range SAP/service and restrictions, please read the 7210 SAS-D,E Services User guide, 7210 SAS-M Services user guide, and 7210 SAS-X Services user guide for more information.
MULTICAST VLAN
REGISTRATION
Platforms Supported: 7210 SAS-E, 7210 SAS-D, 7210 SAS-X and 7210 SAS-M in accessuplink mode only Multicast VLAN registration (MVR), allows operators to use a single network wide multicast VLAN (or a VPLS service) to deliver multicast traffic in the aggregation and access network and distribute the multicast traffic to subscribers using the VLANs specific to the subscribers. Use of single multicast VLAN saves bandwidth and eases operations. MVR must be used in conjunction with IGMP snooping. It uses the IGMP join and leave messages to determine the subscribers who are interested to receive a particular multicast stream. NOTE: In this release, support for MVR has been included for 7210 SAS-M access-uplink node. Support for MVR on 7210 SAS-M network mode is already available from prior releases. Please check the 7210 SAS-D,E Services user guide, 7210 SAS-M Services user guide and 7210 SAS-X Services guide for more information.
(MVR)
PTP IEEE 1588 (BETA ONLY)
Platforms Supported: 7210 SAS-M in network mode only Precision Time Protocol (PTP) is a timing-over-packet technique defined in IEEE 1588-2008. PTP provides the capability to synchronize the network element to a Stratum 1/PRC-traceable source through a network that may or may not be PTP-aware. PTP provides an alternative to Adaptive Clock Recovery (ACR) with the advantages of being a standards-based messaging
Alcatel-Lucent
Page 29
protocol, having lower bandwidth requirements, and potentially providing better performance. PTP also has the benefit of being able to transport both frequency and phase (time). 7210 SASM implements 2-step mechanisms as described in the standards. The IEEE 1588 functionality is integrated with the existing central clock mechanism. With both OC-Slave and BC, the frequency recovered from the PTP packet stream is made available as one of the input options to the central clock and can be distributed using synchronous ethernet to other nodes. NOTES: In 7210 SAS-M, either Synchronous Ethernet can be used as a reference or 1588 PTP can be used as a reference. Both of them cannot be configured as a reference simultaneously. Please check the 7210 SAS-M,X Basic System guide for more information. PTP is supported only on 1G interfaces. It must not be enabled on 10G ports. PTP cannot be used to distribute the recovered frequency to the T1/E1 ports on the CES MDA. PTP hybrid mode, that is, using syncE for frequency and PTP for ToD/phase is not supported. PTP OC-Master for frequency distribution is not supported. Use of PTP timestamps for OAM messages is not supported.
IPV6 FOR NETWORK PORT ON M/X (NETWORK MODE)
Platforms Supported: 7210 SAS-X and 7210 SAS-M in network mode only This release builds on the IPv6 support available in prior releases, by supporting IPv6 addressing for network port IP interfaces. This allows for use of IPv6 in in-band management of the node and for IPv6 transit traffic. OSPFv3 and static routing is supported. Please check the 7210 SAS-M and 7210 SAS-X Services User guide and System Management Guide for more information.
IES IPV6 INTERFACE

ON ACCESS UPLINK PORTS FOR IN-BAND MANAGEMENT
Platforms Supported: 7210 SAS-D and 7210 SAS-M in access-uplink mode only With this release, use of IPv6 for in-band management using the access-uplink ports is supported. Only static routing is supported. NOTE: IPv6 addressing is not supported for IES IP interfaces on access ports. Please check the 7210 SAS-D,E and 7210 SAS-M Services user guide for more information.
IPV4/IPV6 SAP INGRESS QOS

CLASSIFICATION
Platforms Supported: 7210 SAS-D, 7210 SAS-E, 7210 SAS-X and 7210 SAS-M (both network and access-uplink mode) With this release, IPv4 and IPv6 classification criteria is supported for SAP ingress QoS classification. With this release, support for IPv4 criteria has been extended to include IPv4 source address, IPv4 destination address, TCP/UDP source and destination port numbers and IP protocol. IPv6 classification entries can use IPv6 source address, IPv6 destination address, TCP/UDP source and destination port numbers, IPv6 next header field and IPv6 DSCP. More
Page 30
Alcatel-Lucent
details of support of IPv4 and IPv6 classification criteria is available in the 7210 SAS-D/E, 7210 SAS-M and 7210 SAS-D QoS user guide, along with information about resource usage for different match criteria. Note: Before using SAP ingress QoS IPv6 classification criteria, users need to configure appropriate amount of resources using the CLI commands under "config> system> resourceprofile>ingress-internal-tcam> qos-sap-ingress". Please read the 7210 SAS-D,E and 7210 SAS-M,X Basic System Configuration guide for more information on use of the resource-profile CLI commands. IPV6 ACLS Platforms Supported: 7210 SAS-D, 7210 SAS-X and 7210 SAS-M (in both network and access-uplink mode) With this release, support for ingress IPv6 ACLs has been extended to PBB I-VPLS service and Network port IP interfaces on 7210 SAS-X and 7210 SAS-M (network mode). Additionally, support has been added for egress IPv6 ACLs on 7210 SAS-X and 7210 SAS-M. With this release, support is available for ingress and egress IPv6 ACLs in VPLS and Epipe services on 7210 SAS-D. Note: Before using the ingress IPv6 ACLs, users need to configure appropriate amount of resources using the CLI commands under "config> system> resource-profile> ingress-internaltcam> acl-sap-ingress". Before using egress IPv6 ACLs, users need to configure appropriate amount of resources using the CLI commands under "config> system> resource-profile> egress-internal-tcam> acl-sap-egress". Please read the 7210 SAS-D,E and 7210 SAS-M,X Router Configuration Guide for more information on IPv6 match criteria supported and resource usage for different match criteria. Please read the 7210 SAS-M,X Basic System Configuration guide for more information on use of the resource-profile CLI commands. TWO-WAY ACTIVE MEASUREMENT PROTOCOL (TWAMP) Platforms Supported: 7210 SAS-D, 7210 SAS-X and 7210 SAS-M in both access-uplink and network mode only Two-Way Active Measurement Protocol (TWAMP) provides a standards-based method for measuring the round-trip IP performance (packet loss, delay and jitter) between two devices. TWAMP uses the methodology and architecture of One-Way Active Measurement Protocol (OWAMP) to define a way to measure two-way or round-trip metrics. There are four logical entities in TWAMP: the control-client, the session-sender, the server, and the session-reflector. The control-client and session-sender are typically implemented in one physical device (the client) and the server and session-reflector in a second physical device (the server) with which the two-way measurements are being performed. The 7210 SAS device acts as the server. Please read the 7210 SAS-D,E and 7210 SAS-M,X OAM user guide for more information. DOT1Q MIRROR DESTINATION Platforms Supported: 7210 SAS-E, 7210 SAS-D, 7210 SAS-X and 7210 SAS-M in both access-uplink and network mode
Alcatel-Lucent
Page 31
In prior releases, 7210 devices supported only local mirroring with the capability to use a NULL SAP as the mirror destination. With this release, support has been added for using a dot1q SAP or a Q1.* SAP as a mirror destination. This allows for sharing of a common uplink port to transport both mirrored traffic and service traffic. QoS policies can be specified for mirrored traffic so that users can apply appropriate policies for both service traffic and mirrored traffic. On 7210 SAS-E, 7210 SAS-M and 7210 SAS-X, before using a Dot1q SAP or Q1.* SAP as a mirror destination, the user must dedicate the resources of front-panel port for use with this feature using the command config> system> loopback-no-svc-port. No services can be configured on this port. On 7210 SAS-D, the software uses the resources associated with an internal port for mirror application. Please read the 7210 SAS-D,E and 7210 SAS-M,X OAM and Diagnostics User guide and Interfaces User Guide for more information. FORWARDING OF PACKETS WITH 3
TAGS RECEIVED ON
Platforms Supported: 7210 SAS-X and 7210 SAS-M in network mode only In prior releases, 7210 SAS-M did not support any mechanism to forward packets received with extra tags when a QinQ SAP is configured in a service and instead all such packets were dropped. With release 5.0R1, 7210 SAS devices operating in network mode provide an option to the user by supporting a mechanism to support forwarding of packets with 3 or more tags using a QinQ SAP in certain deployment scenarios. 7210 supports a new Epipe service type that will allow for configuration of a QinQ SAP as one endpoint and a MPLS spoke-SDP with vc-type set to vc-vlan as the other endpoint. The vc-vlantag VLAN ID value must match the inner-tag VLAN ID value specified with the QinQ SAP. For packets received on a QinQ SAP configured in the new service, the data plane will preserve the inner tag (and any of the following tags) of the packet received in a QinQ SAP and forward the packet over the SDP. For more details of the processing behavior and restrictions for the new service type please read the 7210 SAS-M and 7210 SAS-X Services user guide. NOTE: CFM/Y1731 is not supported sap and sdp configured in this service.
QINQ SAP IN EPIPE

SERVICE
RELEASE 4.0R7 RELEASE 4.0R6

IPV6 ACLS
There are no new features added to 4.0R7 of the 7210 SAS-M OS.
From 7210 SAS 4.0R6, support is available for IPv6 ACLs on SAP ingress on 7210 SAS-X and 7210 SAS-M (both network and access-uplink mode). IPv6 ACLs is supported on SAP ingress in Epipe and VPLS service is implemented in the hardware and can process packets at line-rate. IPv6 ACLs allows the operators to match on the IPv6 header fields and implement security policies. The 7210 operators typically use in-band management since most of the devices are in remote installations. With support for IPv6 OOB management available on 7210 platforms from 7210 SAS 4.0R1, operators who prefer to use IPv6 in-band management can use an external
Page 32
Alcatel-Lucent
loop and transport the IPv6 OOB management traffic using a Epipe or a VPLS service. In such a scenario, operators can use ACLs to match on IPv6 packet header fields and restrict management access of the node to a list of trusted remote peers. Note: Before using the IPv6 ACLs, the users need to configure appropriate amount of resources using the CLI commands under "config> system> resource-profile". The number of resources available when 64-bit IPv6 addresses and 128-bit IPv6 addresses are used as the match criteria is different. Please read the 7210 SAS-MX Router Configuration Guide for more information on IPv6 match criteria supported and the 7210 SAS-MX Basic Systems Configuration guide for more information on use of the resource-profile CLI commands. UP MEP SUPPORT EPIPE SERVICE From 7210 SAS 4.0R6, support is available for UP MEP on 7210 SAS-M (network mode only) only in an Epipe service (both MPLS and PBB Epipe is supported). UP MEP allows operators to place a diagnostic point as close to the customer as possible. It allows operators to diagnose fault with services and measure service performance metrics up to the UNI demarcation point. 7210 UP MEP implementation supports both CFM and Y.1731, including SLM. It can also be used with SAA. Note: Before using UP MEP user needs to configure appropriate amount of resources using the CLI commands under "config> system> resource-profile". UP MEP shares resources with ACLs, hence if upgrading from a previous release, user must ensure enough resources are available for use with UP MEP. Please read the 7210 SAS-MX Basic Systems Configuration user guide, 7210 SAS-M Services user guide and 7210 SAS-MX OAM user guide for more information. SYNTHETIC LOSS MEASUREMENT (SLM) Synthetic loss measurement provides a mechanism for operators to proactively trend packet loss for service based MEPs. The standards specify a single-ended mechanism that allows the operator to run on-demand and proactive tests to determine in, out loss and unacknowledged packets. This approach can be used between peer MEPs in both point to point and multipoint services. Only remote MEP peers within the association and matching the uni-cast destination responds to the SLM packet. Both on-demand and SAA support is available. Note: The 7210 SAS uses pre-standard OpCodes 54 (Synthetic Loss Reply) and 55 (Synthetic Loss Message) for the purpose of measuring loss using synthetic packets. SLM is supported on all 7210 SAS platforms. SLM uses hardware-based Rx timestamp and software-based Tx timestamp on 7210 SAS-D, 7210 SAS-M (access-uplink and network mode), and 7210 SAS-X. The 7210 SAS-E uses software-based Rx and Tx timestamp.
FOR
RELEASE 4.0R5
G.8032 FOR PBB BVPLS
In release 7210 SAS 4.0R5, G.8032 ring protection mechanism is enhanced to include support for PBB E-PIPE services. Starting from this release, PBB E-PIPE services can be protected in a ring deployment by use of G.8032 with B-VPLS service. Please refer 7210 SAS-M Services Guide for more information.
Alcatel-Lucent
Page 33
Note: PBB I-VPLS services use of G.8032 with B-VPLS is not supported in 7210 SAS 4.0R5. The G.8032 for PBB B-VPLS feature enhancement is available only for 7210 SAS-M in network mode.
RELEASE 4.0R4
EFFICENT ALLOCATION OF SAP INGRESS QOS RESOURCE
In previous releases of 7210 SAS, SAP ingress QoS resources must be configured with values in powers of 2 (example - 4, 8, 16, 32, 64 up to platform limit), potentially leading to inefficient allocation of available resources. With release 4.0R4, users can allocate SAP ingress QoS resources in multiples of 2 (example - 2, 4, 6, 8, 10, 12, 14., up to platform limit). With this users can allocate the available resources more efficiently. In 4.0R4.0 release, the SAP ingress default policy has been changed to allocate only 2 classification resources and single (1) meter (that is, num-qos-resources is set to a value of 2 by default). With the default policy only a single FC is defined and it uses meter 1 (the only meter) to meter all traffic types (that is, unicast, broadcast, multicast, and unknown-unicast). Additionally the use of multipoint keyword has been deprecated, except for use with meter 11. This allows users to use any meter with any traffic type allowing for efficient use of meters. If meter 11 is created by the user explicitly, then the system uses meter 11 for broadcast, unknownunicast and multicast traffic types. The system creates an additional index file by the name '<config-file-name>.sdx' at the same location where config file is located. This file needs to be preserved across a reboot. It is used by the system to guarantee allocation of resources to all the SAPs on a reboot. If the system does not find the file, it continues with booting up but there are no guarantees that the configuration file will execute successfully. More details are available in the 7210 SAS QoS Guide.
SAA FOR CFM/Y.1731
Service Assurance Agent (SAA) now supports the scheduling and accounting for loopback, linktrace and Y.1731 two-way-delay. SAA-specific CFM loopback, linktrace and DM functions support send-count, interval, timeout, forwarding class and continuous mode. Existing CFM OAM commands are now extended to support send-count and interval natively from this release. The SAA results may be monitored using configured event thresholds, including jitterevent, latency-event, and loss-event. SAA results can also be stored in accounting files. Release 4.0R4 supports Multicast VLAN registration (MVR). It allows operators to use a single network wide multicast VLAN (or a VPLS service) to deliver multicast traffic in the aggregation and access network and distribute the multicast traffic to subscribers using the VLANs specific to the subscribers. Use of single multicast VLAN saves bandwidth and eases operations. MVR must be used in conjunction with IGMP snooping. It uses the IGMP join and leave messages to determine the subscribers who are interested to receive a particular multicast stream. MVR is available only on 7210 SAS-M (network mode).
MULTICAST VLAN REGISTRATION (MVR)
Page 34
Alcatel-Lucent
RELEASE 4.0R3
PORT LOOPBACK MAC SWAP (ENABLES RFC 2544, NO TRAFFIC GENERATION)
WITH
From release 4.0R3, 7210 SAS-M 24F supports port loopback with MAC swap. In case of 7210 SAS-M, the system uses the resources associated with a virtual loopback port 1/1/25. User does not need to configure any port using the CLI command configure> system> loopback-no-svcport. Loopback with MAC swap can be configured using CLI "config port port-no ethernet loopback internal service id sap id src-mac mac-addr dst-mac mac-addr" When this command is executed, the system enables PHY/MAC loopback on the specified port. All the packets sent out of the port configured for loopback is received back by the system. On ingress to the system after the loopback, the node swaps the MAC addresses for the specified SAP and service. It only processes packets that match the specified source MAC address and destination MAC address, while dropping packets that do not match. It processes these packets as per the service configuration for the SAP. This is recommended for use with only VPLS and VLL services. This command affects all the services and protocols configured on the port as the port loops back all of the packets, hence exercise extra care when using this command. For more details and recommended procedure of usage please read the user guide. A loopback on the port is expected to be used with a external third-party Ethernet test device. They can be used to diagnose problems with the service provisioning or for testing end-to-end performance metrics for the service.
CPLD UPGRADE
With this release, support for firmware upgrade is supported. The firmware upgrade can be initiated through the CLI command "admin reboot upgrade". The upgrade process will upgrade the ROM and the CPLD on a reboot to the latest version, if required. Please refer to the user guide for the precautions to be taken care of before initiating the upgrade procedure. Note: If this command is used without precautions listed, it can result in RMA of the node.
G.8032-MULTI CHASSIS SUPPORT ON SAS-M ACCESSUPLINK
Release 4.0R3 enhances Ethernet Ring Protection for 7210 SAS-M access-uplink mode to include support for dual-connected hierarchical rings. Ethernet ring protection switching offers ITU-T G.8032v2 specification compliance to achieve resiliency and fast protection for native Ethernet Layer-2 networks. G.8032 (Eth-ring) is built on Ethernet OAM and is often referred to as Ring Automatic Protection Switching (R-APS). Eth-rings are supported on VPLS SAPs (VPLS service only). VPLS services supporting EthRing SAPs can connect to other rings and Ethernet services using VPLS SAPs. Eth-rings enable ring topologies for core network or access network resiliency. By utilizing rings and sub-rings, any flexible ring topology can be constructed. Eth-rings offer resiliency for Ethernet services optimized for ring topologies for any single link or node failure and the ability to manage traffic for both unicast and multicast services. By allowing multiple Eth-rings instances on the same physical topology, G.8032 can utilize all link resources in a ring. For MC 8032 control service on sub ring, split horizon need to be configured on each control sap using CLI option "g8032-shg-enable", for example, sap id g8032-shg-enable eth-ring ethring-index
Alcatel-Lucent
Page 35
Default version for eth-ring is v2.
RELEASE 4.0R2
G.8032-MULTI CHASSIS SUPPORT
Release 4.0R2 enhances Ethernet Ring Protection for 7210 SAS-M (network mode only), to include support for dual-connected hierarchical rings and LDP VPLS access rings. Ethernet ring protection switching offers ITU-T G.8032v2 specification compliance to achieve resiliency and fast protection for native Ethernet Layer-2 networks. G.8032 (Eth-ring) is built on Ethernet OAM and is often referred to as Ring Automatic Protection Switching (R-APS). Eth-rings are supported on VPLS SAPs (VPLS service only). VPLS services supporting EthRing SAPs can connect to other rings and Ethernet services using VPLS SAPs. Eth-rings enable ring topologies for core network or access network resiliency. By utilizing rings and sub-rings, any flexible ring topology can be constructed. Support for dual-connected access rings to LDP VPLS enable inter-connection flexibility and the ability to interact with other protection mechanisms for overall service protection. Eth-rings offer resiliency for Ethernet services optimized for ring topologies for any single link or node failure and the ability to manage traffic for both unicast and multicast services. By allowing multiple Eth-rings instances on the same physical topology, G.8032 can utilize all link resources in a ring. In release 4.0R2, dual-connected ring support (that is, G.8032v2) is available only for 7210 SAS-M network mode. Default version for eth-ring is v2.
RELEASE 4.0R1
IP VPRN
RFC 4364 details a method of distributing routing information and forwarding data to provide a Layer 3 Virtual Private Network (VPN) service to end customers. Each Virtual Private Routed Network (VPRN) consists of a set of customer sites connected to one or more PE routers. Each associated PE router maintains a separate IP forwarding table for each VPRN. Additionally, the PE routers exchange the routing information configured or learned from all customer sites via MP-BGP peering. Each route exchanged via the MP-BGP protocol includes a Route Distinguisher (RD), which identifies the VPRN association. The service provider uses BGP to exchange the routes of a particular VPN among the PE routers that are attached to that VPN. This is done in a way which ensures that routes from different VPNs remain distinct and separate, even if two VPNs have an overlapping address space. The PE routers distribute routes from other CE routers in that VPN to the CE routers in a particular VPN. Since the CE routers do not peer with each other there is no overlay visible to the VPN's routing algorithm.
Page 36
Alcatel-Lucent
When BGP distributes a VPN route, it also distributes an MPLS label for that route. On a 7210 devices, a single label is assigned to all routes in a VPN. Before a customer data packet travels across the service provider's backbone, it is encapsulated with the MPLS label that corresponds, in the customer's VPN, to the route which best matches the packet's destination address. The MPLS packet is further encapsulated with either another MPLS label header, so that it gets tunneled across the backbone to the proper PE router. In 4.0R1, The following support is available (For details refer 7210 User Guides): L3 SAP types of NULL, Dot1q and QinQ Service label per VRF Static spoke-sdp for PE to PE VRF export/import policies support QoS SAP ingress classification using mac-criteria or ip-criteria (5-tuple and DSCP) SAP Ingress per FC policing and per SAP aggregate policing (hierarchical policier) 7210 SAS-M Port based egress queuing and marking (DSCP bits) 7210 SAS-X SAP based egress queuing and port based marking (DSCP bits) MPLS EXP bits used for network side classification and marking for MPLS LSPs used to transport VPRN service packets
ACLs/Filter, SAP ingress/egress ACLs (ip-criteria only) MP-iBGP protocol (vpn-ipv4 family only) for VPRN route exchange 4-Byte ASN support available (enable/disable) BGP route policy support (export/import policies) Route reflector recommended (w/7210 as client only) VPRN aggregate route support is available Static routing with CPE-check connectivity eBGP RSVP-TE LSPs LDP LSPs ICMP ping and traceroute applications available in VPRN context vprn-ping and vrpn-traceroute OAM tools (SAA support available) SAP ingress accounting records is supported SAP egress accounting records is supported only on 7210 SAS-X
- PE-CE routing protocol -
- MPLS LSP for VRPN data forwarding -
- OAM Tools and Accounting -
VPRN service support is available only on 7210 SAS-M (network mode). In 4.0R1, Some of the features NOT supported (This is not a complete list): spoke termination on access side of vprn is not supported. BGP Multipath, Route Reflector Server, Confederation, BFD for BGP, Eibgp Load Balancing.
Alcatel-Lucent
Page 37
IPV6 SUPPORT FOR OOB INTERFACES
BGP ORF is not supported. Route leak between VRF using Route Policy is not supported.
The 7210 SAS provides support for use of IPv6 with the out-of-band ethernet management port. This allows for use of IPv6 addressing and IPv6 networks for management of the node. IEEE 802.1ah draft standard [IEEE802.1ah], also known as Provider Backbone Bridges (PBB) defines an architecture and bridge protocols for interconnection of multiple Provider Bridge Networks (PBNs). IEEE defines PBB as a connectionless technology based on multipoint VLAN tunnels. MSTP is available for use as the core control plane for loop avoidance and load balancing. The IEEE model for PBB is organized around a B-component handling the provider backbone layer and an I-component concerned with the mapping of Customer/Provider Bridge (QinQ) domain (for example, MACs, VLANs) to the provider backbone (for example, B-MACs, BVLANs): that is, the I-component contains the boundary between the Customer and Backbone MAC domains. PBB encapsulates customer payload in a provider backbone Ethernet header, providing for Customer MAC hiding capabilities. With PBB, 7210 devices can be used for tier2/3 aggregation, encapsulating customer service frames in PBB, allowing the PE-rs devices deployed in the metro core to be aware of only provider MAC addresses and for metro service scaling. Only 7210 SAS-M (network mode only) and 7210 SAS-X devices support PBB Epipe/ELINE service (for point-to-point connectivity) and VPLS/ELAN service (for multipoint-to-multipoint connectivity). Different transport options are supported for PBB ELAN and ELINE services: - A dedicated tunnel (one-to-one model) where one service is mapped to one backbone tunnel - Shared tunnel (many-to-one model) where many services are sharing one backbone tunnel. management VPLS (M-VPLS) with STP Multi-Chassis LAG (MC-LAG).
PBB
The PBB implementation supports the following capabilities for resiliency:
Some of these features may be used to provide support for a number of access resiliency options towards a customer edge (CE) device or a QinQ network: MC-LAG offers a simple scheme where just LAG (no STP) is required on the access device All STP protocols are supported e.g. RSTP, Provider/Enterprise MSTP for compatibility with deployed customer or provider QinQ protocols M-VPLS provides comprehensive loop-avoidance with load-balancing for any kind of topology through the localized, controlled use of RSTP/MSTP/PMSTP. standard-based Provider MSTP is available for loop avoidance MC-LAG (no STP required)
On the backbone side (B-Domain), the following options are available for tunnel resiliency:
Page 38
Alcatel-Lucent
Other VPLS features are also inherited by the PBB implementation: VPLS Management (FIB and SAP), L2PT, BPDU translation, filters, mirroring and QoS capabilities. The following features are not available (This is not complete list): PBB-VPLS (i.e. use of SDPs in PBB service is not supported) Split-horizon groups (service-based) IEEE 802.1ak (MMRP) CFM (802.1ag) / Y.1731 OAM G.8032 and G.8031 Black-hole avoidance mechanisms in case of MC-LAG B-SAP on LAG ports l2pt, BPDU translation across B-Domain is not supported. I-VPLS STP BPDU's are not transmitted over B-VPLS.
For more details please refer the 7210 Services user guide. ACTIVE/STANDBY PSEUDOWIRE REDUNDANCY IN VPLS This feature provides the ability to use 7210 SAS devices acting as MTUs (Multi Tenant Unit Switch) to be multi-homed for VPLS to multiple PEs without requiring the use of mVPLS. In such configurations, the MTU has two spoke-SDPs to two PE devices. One is designated as the primary spoke and the other as the secondary based on configurable precedence. The secondary spoke is in a blocking state (both on receive and transmit) as long as the primary spoke is available. When the primary spoke becomes unavailable (due to link failure, PE failure, etc.), the MTU switches traffic to the backup spoke and starts sending/receiving traffic over the standby spoke. This feature is supported on 7210 SAS-M (network mode only). MULTI CHASSIS LAG Multi-chassis LAG (MC-LAG) is an extension to the LAG feature to provide not only link redundancy but also node-level redundancy. This feature uses a proprietary solution developed by Alcatel-Lucent. A proprietary messaging between redundant-pair nodes supports coordinating the LAG switchover. Multi-chassis LAG supports LAG switchover coordination: one node connected to two redundant-pair peer nodes with the LAG. During the LACP negotiation, the redundant-pair peer nodes act like a single node using active/stand-by signalling to ensure that only links of one peer nodes is used at a time. Multi-chassis LAG is expected to be used primarily for supporting SAPs connecting to a VPLS and Epipe service with pseudowires on the network core side, so that MAC Flush messages can be used to ensure a loop-free and consistent end-to-end topology. ICB (Inter-Chassis Backup) spoke-sdp is supported for use with Epipe service in a MC-LAG configuration. Please note, that using MC-LAG for dual homing is not usable in ring topologies in the access network. The solution for such network configurations is not part of this feature. The solution is not usable for VPRN and IES SAPs.
Alcatel-Lucent
Page 39
Multi-Chassis Synchronization is an Alcatel-Lucent proprietary mechanism to synchronize dynamic state information (7210 supports only synchronization of IGMP snooping information) between redundant pair nodes (inter-node state synchronization). This mechanism is not a standalone feature, but rather a mechanism required to provide a solution for redundant access (dual homing) Multi-chassis LAG. This mechanism requires that the involved nodes are running at the same system times (NTP/SNTP). It is also required that the local service configuration of the involved nodes are similar. This feature is supported only on 7210 SAS-M (network mode only). SPLIT HORIZON GROUP SUPPORT In release 4.0R1, service-based split-horizon feature is available on 7210 SAS-M (network mode only). Use of this feature is mutually exclusive to use of mesh-sdps in the same service. Only a single split-horizon group per service is available for use. Traffic arriving on a SAP or spoke-sdp configured in a service and is configured in the same split horizon group is not copied to other SAP or spoke-sdp in the same service.It can be used to disable local switching on the 7210 SAS. A loop-free topology can be achieved using split horizon on 7210 SAS switches. The 7210 SAS provides support for port loopback with MAC swap. User needs to configure additional port as no service port using CLI "config system loopback-no-svc-port port-id" to support loop back with MAC swap. In case of 7210 SAS-M 24F 2XFP with 10G MDA, second port configured in bof's "no-service-ports" can be used as "loopback-no-svc-port". Then loopback with MAC swap can be configured using CLI "config port port-no ethernet loopback internal service id sap id src-mac mac-addr dst-mac mac-addr" When this command is executed, the system enables PHY/MAC loopback on the specified port. All the packets sent out of the port configured for loopback is received back by the system. On ingress to the system after the loopback, the node swaps the MAC addresses for the specified SAP and service. It only processes packets that match the specified source MAC address and destination MAC address, while dropping packets that do not match. It processes these packets as per the service configuration for the SAP. This is recommended for use with only VPLS and VLL services. This command affects all the services and protocols configured on the port as the port loops back all of the packets, hence exercise extra care when using this command. For more details and recommended procedure of usage please read the user guide. If multiple saps exist on loopbacked port, it is recommended to shutdown saps which are not configured for loopback. At a time, loopback can be enabled on only one sap. A internal loopback on the port is expected to be used with a external third-party Ethernet test device. They can be used to diagnose problems with the service provisioning or for testing endto-end performance metrics for the service. In release 4.0R1, this is available only on 7210 SAS-X and 7210 SAS-M 24F 2XFP variant. It is not supported on other platforms DEFAULT (*.*) QINQ SAPS FOR EPIPE AND VPLS IN SASM ACCESS-UPLINK MODE Default QinQ SAPs (notation - *.*) are used in ring ports to avoid the need to configure services on all the intermediate nodes in the ring which are transiting the service. Only one epipe service with default QinQ SAPs can be created for transit traffic on access-uplink ports. Default QinQ SAPs are allowed only on access-uplink ports and access ports. It can co-exist with 0.* SAP on an access-uplink or access port.
WITH
PORT LOOP BACK MAC SWAP (ENABLES RFC 2544, NO TRAFFIC GENERATION)
Page 40
Alcatel-Lucent
A default QinQ SAP accepts only tagged packets. Untagged packets or Priority tagged packets are not accepted on default QinQ SAP. When using an epipe service for transit traffic in a ring deployment, no protection mechanism (example: STP or G.8032) is supported for Default QinQ SAPs. The upstream or head-end node on which the service originates must ensure the correct path on the ring is selected using either G.8032 or STP. Default QinQ SAP is available for use only in an Epipe and a VPLS service created with svcsap-type parameter set to "null-star". Default QinQ SAP can be configured along with other SAPs allowed in the same service (that is, service with svc-sap-type parameter set to "nullstar"). Default QinQ SAPs in a VPLS service does not support any loop-avoidance mechanisms such as STP or G.8032. It is not recommended for use in a topology where Layer-2 loop exists. It must be used carefully and is typically helpful to aggregate a set of VLANs into a service towards an upstream node in a hub-spoke network topology without Layer-2 loops. Default QinQ SAPs is supported only on 7210 SAS-D and 7210 SAS-M (access-uplink mode). Following features are available for use with Default QinQ SAPs configured in Epipe and VPLS service (unless otherwise explicitly called out below listed features are applicable for both Epipe and VPLS service): For Default QinQ SAPs on either access ports or access-uplink ports: MAC learning and aging is available for use in a VPLS service Per SAP Mac limit is available for use in a VPLS service Mac-move detection and Mac-pinning is available for use in a VPLS service Discard-unknown and discard-unknown-source is available for use in a VPLS service CFM and Y.1731 is not available for use STP (and all its different flavors) is not available for use G.8032 is not available for use IGMP snooping is not available for use L2PT and BPDU translation is not available for use IP interface in a VPLS service is not available in a service using this SAP Ingress qos policy applied on an access uplink port is available for classification and policing on ingress. Egress qos policy applied on an access uplink port is available for egress queue shaping, scheduling and marking. SAP Ingress ACLs is available for use SAP Egress ACLs is not available for use SAP Ingress received count and SAP Egress forwarded count are available for use (appropriate accounting records can be used) SAP ingress qos policy is available for use
For Default QinQ SAPs created on Access-uplink Port:
For Default QinQ SAPs created on access ports:
Alcatel-Lucent
Page 41
Egress qos policy applied on an access port is available for egress shaping, scheduling and marking. SAP Ingress ACLs is available for use SAP egress ACLs is not available for use SAP Ingress Meter counters, SAP Ingress received count and SAP Egress forwarded counter are available for use (appropriate accounting records can be used)
RELEASE 3.0R6
24V SUPPLY SUPPORT
With this release, 7210 SAS-M and all variants supports +24V power supply. This allows users the choice of using a +24V DC power source to power the node. Users can use two +24V power supplies in a redundant configuration. DC power source failure detection is supported. AC power supply use along with DC (+24V or -48V) power supply is supported from 3.0R6 release. Configured DC power supply type (+24V or -48V) is displayed using snmp MIB object "tmnxChassisPowerSupplyAssignedDCType" Note: A mix of +24V DC and -48V power supplies must not be used together in the same chassis.
PORT INTERNAL LOOPBACK
With this release, 7210 SAS-M and its variants supports port internal loopback feature. This feature enables an internal PHY/MAC loopback. With the internal loopback configuration, packets that egress out of that port (or SAPs created on that port) are looped back into the node instead of being transmitted on to the line/wire. The packet that ingress the system after the loop back are mapped to the same SAP on which the packet was sent out, as if its being received from another device connected to the port and is processed as per the service configuration for that SAP. A internal loopback on the port is expected to be used with a external third-party Ethernet test device. They can be used to diagnose problems with the service provisioning or for testing end-to-end performance metrics for the service. It is highly recommended that this command be used only for testing a VLL service. The source/destination MAC address swap is not done. Hence, its use in a VPLS service will potentially lead to rapid MAC address movement from one port to another. It is not required to insert an SFP/XFP into the device OR plugin the ethernet cable in case of fixed copper ports for the loopback to be functional. This command affects all the services provisioned on the port, since packets are looped back and sent out back to the sender. It is expected to be used only with a VLL service. It is recommended to turn off Layer 2 and IP control protocols (like xSTP, LACP, EFM, 802.1x, LLDP, OSPF, etc.) on the device where the loopback command is executed and also on the peer device to avoid unnecessary protocol behavior (for example, protocol flaps due to time-out, etc.).
Page 42
Alcatel-Lucent
RELEASE 3.0R5
24V SUPPLY SUPPORT
With this release, 7210 SAS-M 24F 2XFP ETR +24V variant (part number #3HE06536AAAA) is supported. This allows users the choice of using a +24V DC power source to power the node. Users can use two +24V power supplies in a redundant configuration. DC power source failure detection is supported with these power supplies. A mix of +24V DC and -48V power supplies must not be used together in the same chassis. AC power supply use along with DC +24V power supply is not supported in this release.
EPIPE PBB
In this release, use of native Ethernet PBB in Epipe service (also known as ELINE service) with limited functionality is supported. E-LINE service is defined in PBB (IEEE 802.1ah) as a point-to-point service over the PBB B-component infrastructure. The use of Epipe scales the E-LINE services as no MAC switching, learning, or replication is required in order to deliver the point-to-point service. All packets received from the customer SAP are PBB encapsulated and sent through the BVPLS tunnel using the backbone destination MAC of the remote PBB PE. All the packets received from the B-VPLS and destined for the Epipe are PBB de-encapsulated and forwarded to the customer SAP. Only default QoS classification entry (that is, FC BE) is supported on SAP ingress. ACL support is not available. For more details, please refer to the 7210 SAS-M Services User Guide.
IP INTERFACES IN A VPLS SERVICE
The 7210 SAS-M in access-uplink mode supports IP interfaces in a VPLS service. IP interfaces in VPLS services provide only a host IP interface (non-routable). Only IP ping and IP traceroute applications are supported for this IP interface. It is primarily designed for use to verify service availability during service activation and/or during normal service use by using IP ping utility.
RELEASE 3.0R3
LINE TIMING OF ETHERNET PORTS USING SYNCE WITH SSM SUPPORT
This release provides support for Synchronous Status Message (SSM) (also known as ESMC) for Synchronous Ethernet. SSM provides a mechanism to allow the synchronization distribution network to both determine the quality level of the clock for a given synchronisation trail and to allow a network element to select the best of multiple input synchronization trails. Synchronization Status messages have been defined for various transport protocols including SONET/SDH, T1/E1, and synchronous Ethernet, for interaction with office clocks, such as BITS or SSUs and embedded network element clocks. SSM allows equipment to autonomously provision and reconfigure (by reference switching) their synchronization references, while helping to avoid the creation of timing loops. These
Alcatel-Lucent
Page 43
messages are particularly useful to allow synchronization reconfigurations when timing is distributed in both directions around a ring. In Synchronous Ethernet, SSM uses an Ethernet OAM PDU that uses the slow protocol subtype. For a complete description of the format and processing, see ITU-T G.8264. This feature is supported on 7210 SAS-M (both in network mode and access-uplink mode) DRIVING T1/E1 LINE TIMING USING SYNCE In prior releases, 7210 SAS-M supported ACR or node-timing (that is, free running system clock) to drive timing on T1/E1 ports. With this release, the system will drive the T1/E1 ports clock using the system clock that has been synchronised using SyncE, when 'nodetiming' option is selected. In a network that uses syncE for synchronisation, it allows the operator to deliver an accurate clock to the 7210 SAS-M using syncE and use that to deliver T1/E1 services. This feature is supported only on 7210 SAS-M in network mode only. Y.1731 HARDWARE TIME STAMPING In this release, the software uses the hardware timestamp capability for Y.1731 2-way delay and 1-way delay measurement. This allows for computing better accuracy in delay measurement in comparison to use of software timestamps. Hardware supports the capability of adding a timestamp to the Y.1731 delay measurement messages only in the Rx (receive) direction. The Tx timestamp continues to be added by the CPU/software. This feature is supported on 7210 SAS-M (both network mode and access-uplink mode) BFD FOR RSVP (FRR) AND STATIC ROUTES This release enables use of BFD for RSVP-TE and static routes. BFD for RSVP-TE allows for detection of the failure of RSVP neighbor and on failure of the neighbor, This triggers protection mechanisms, such as FRR, immediately on detection of the failure. BFD for static routes allows for detection of failure of next-hop gateway. Upon detection of failure of next-hop, the static route is marked as operationally down, triggering recomputation of the best path routes by the route manager. This feature is supported on 7210 SAS-M network mode only. MULTIPLE SPANNING TREE PROTOCOL (MSTP) The Multiple Spanning Tree Protocol (MSTP) extends the concept of the IEEE 802.1w Rapid Spanning Tree Protocol (RSTP) by allowing grouping and associating VLANs to Multiple Spanning Tree Instances (MSTI). Each MSTI can have its own topology, enabling load balancing by providing multiple forwarding paths. At the same time, the number of STP instances running in the network is significantly reduced as compared to Per VLAN STP (PVST) mode of operation. Network fault tolerance is also improved because a failure in one instance (forwarding path) does not affect other instances. The 7210 SAS implementation of Management VPLS (mVPLS) is used to group different VPLS instances under single RSTP instance. Introducing MSTP into the mVPLS allows interoperating with traditional Layer 2 switches in access network and provides an effective solution for dual homing of many business Layer 2 VPNs into a provider network. This feature is supported on 7210 SAS-M in both network mode and access-uplink mode
Page 44
Alcatel-Lucent
ACTIVE/STANDBY VLL/EPIPE WITH SUPPORT FOR SIGNALLING OF PSEUDOWIRE STANDBY STATUS
With this feature, the system signals the status of the pseudowire using the status TLV in TLDP signalling messages. The standby status of the pseudowire using appropriate bits in the status TLV sent with the TLDP signalling messages. The peer TLDP node, which receives the status TLV can be configured to take appropriate action. For example, if 7210 was dual-homed into a 7750 head-end node using VLL active/standby pseudowire, with the VLL spokes terminating in a VPLS service on the 7750, then the user could configure the pseudowire in the VPLS service to block transmit on the standby pseudowire, obviating the need to run STP protocol for avoid loop. Another example: IP VPN backhaul, in which 7210 is dual-homed to a 7750 head-end node using active/standby VLL, with the VLL spokes from 7210 being terminated into a 7750 IES/VPRN service. 7750 could advertise appropriate routes into the core network based on the standby status signalled by 7210. This feature is supported on 7210 SAS-M network mode only.
RELEASE 3.0R2
G.8032 FOR 7210 SAS-M ACCESSUPLINK MODE
In this release, G.8032 is supported in Access-Uplink mode for 7210 SAS-M. ITU-T G.8032 specification - version 1defines protocol mechanisms to provide ethernet ring protection to enable deployment of resilient Ethernet Layer 2 networks. G.8032(ETH-ring) is built on Ethernet OAM and is also referred to as Ring Automatic Protection Switching (R-APS). ETH-rings are supported only on VPLS access and access uplink SAPs (for VPLS Service). VPLS services supporting Eth-rings enables rings for core network or access network resiliency. ETH-ring multi-homing into other ETH-rings or VPLS PEs is not supported in the current release. ETH-rings offer fast resiliency for Ethernet services leveraging ring topologies for any single link or node failure. By configuring multiple ETH-rings instances on the same physical topology, G.8032 can utilize all link resources in a ring.
ETH-CFM FOR 7210 SAS-M ACCESSUPLINK MODE
In this release, Eth-CFM is supported in Access-Uplink mode for 7210 SAS-M. 7210 SAS-M uses the inherent capabilities of the hardware for CFM. CFM CCM message protocol processing is handled in hardware, allowing use of CCM timers at 100ms time interval for down MEPs.
Alcatel-Lucent
Page 45
Y.1731 FOR 7210 SAS-M ACCESSUPLINK MODE
Y.1731 is defined by ITU-T. It is built on top of the IEEE 802.1ag, but it has more functionalities compared to the former, such as AIS, performance monitoring, etc. In this release, the following Y.1731 functionalities are supported: ETH-CCM ETH-LB ETH-LT ETH-RDI ETH-AIS ETH-TST ETH-DM including one-way and two-way delay measurements.
Software timestamps are used for delay measurement.
RELEASE 3.0R1
G.8032
ITU-T G.8032 specification - version 1defines protocol mechanisms to provide ethernet ring protection to enable deployment of resilient Ethernet Layer 2 networks. G.8032(ETH-ring) is built on Ethernet OAM and is also referred to as Ring Automatic Protection Switching (R-APS). ETH-rings are supported only on VPLS SAPs (for VPLS Service). VPLS services supporting Eth-rings enables rings for core network or access network resiliency. ETH-ring multi-homing into other ETH-rings or VPLS PEs is not supported in the current release. ETH-rings offer fast resiliency for Ethernet services leveraging ring topologies for any single link or node failure. By configuring multiple ETH-rings instances on the same physical topology, G.8032 can utilize all link resources in a ring. In this release, G.8032 is supported only in network mode for 7210 SAS-M. It is supported only for access SAPs in a VPLS service.
LLDP
IEEE 802.1ab standard defines a protocol and management elements suitable for advertising information to stations attached to the same IEEE 802 LAN or LAN emulation for the purpose of populating physical or logical topology and device discovery management information databases. The protocol facilitates the identification of stations connected by IEEE 802 LANs/MANs, their points of interconnection, and access points for management protocols. For Provider Networks, it means automatic discovery of their internal Ethernet connectivity. Emulation and logical topology wording is applicable to the case of a customer bridge (enterprise/carrier of carrier use case) connected to a Provider Network offering a transparent LAN Emulation service to their customers. It helps the customer bridges detect misconnection by an intermediate provider by offering a view of the customer topology where the provider service is represented as a LAN interconnecting these customer bridges. IEEE 802.1ab LLDP support will allow SAM to auto discover Ethernet link topology and to rapidly troubleshoot miss-connectivity like cross linked cables and port connectivity.
Page 46
Alcatel-Lucent
2 X 10G MDA
This MDA provides the user an option to use an additional 2 x 10G ethernet ports with the expansion slot available on all the 7210 SAS-M variants. On 7210 SAS-M 24F, 2x10G MDA allows the operator to upgrade their access network bandwidth capacity to 10G, allowing them to transport the increasing amount of data from their customers. 2x10G MDA can be used as access ports to provide service with redundancy to large customers who need n x 1G or 10G connectivity. The system must be upgraded to use the bootloader version available with release R3.0r1. First time use of 2x10G MDA requires configuration of BOF parameters appropriately and a system reboot. Synchronous Ethernet (syncE), AutoInit, and Hot Swap is not supported for the 10G ethernet interfaces on this MDA in the current release. Please refer to the user installation guide and Basic System guide for more information.
QINQ ACCESS SAP
Operators use QinQ SAPs in network design to expand the VLAN space available for use to differentiate services or subscribers. QinQ SAPs is also used to provide transparent Layer-2 connectivity between customer LANs. Support of QinQ access SAPs allows operators to provide service differentiation when QinQ mechanisms are used in the access network built using 7210 devices. QinQ access SAPs is supported in VPLS and VLL services. Port encapsulation mode must be configured to be QinQ for use of QinQ access SAPs. QoS Ingress policies, filter policies, and accounting policies can be used with QinQ SAPs. Most of the features available on Dot1q SAPs is available with QinQ SAPs. Please read the user guide and release notes for more information. QinQ ports use 0x8100 as the default QinQ ether type value. Users can configure a different QinQ ether type value for use with QinQ encapsulated ports. Up to three unique QinQ ether type values per node (other than the default) can be specified.
BFD SUPPORT
Bidirectional Forwarding Detection (BFD) protocol is a light-weight, low-overhead, shortduration detection of failures in the path between two systems. If a system stops receiving BFD messages for a long enough period (based on configuration), it is assumed that a failure along the path has occurred and the associated protocol or service is notified of the failure. BFD can provide a mechanism used for liveness detection over any media (at any protocol layer) with a wide range of detection times and overhead to avoid a proliferation of different methods. BFD asynchronous mode is supported over a single hop. This mode uses periodic BFD control messages to test the path between the two systems. A path is declared operational when twoway communications has been established between both systems. A separate BFD session is created for each communications path and data protocol in use between two systems. Bidirectional Forwarding Detection allows either of the two systems to send a sequence of BFD echo packets to the other system, which loops them back within that systems forwarding plane. If a number of these echo packets are lost then the BFD session is declared down. 7210 supports being only a echo responder. BFD is supported for use with OSPF and IS-IS in the current release.
Alcatel-Lucent
Page 47
MPLS IMPLICIT NULL LABEL

OPTION SUPPORT ON EGRESS
LER
Implicit Null Label option allows a 7210 egress LER to receive MPLS packets from the previous hop without the outer LSP label. The operation of the previous hop is referred to as Penultimate Hop Popping (PHP). This option is signaled by the egress LER to the previous hop during the LSP signaling with LDP or RSVP control protocols. The 7210, as an egress LER, can be configured to receive MPLS packets with the Implicit Null label on LSPs signalled using LDP or RSVP, but not on a static LSP. On 7210, the Implicit NULL label option can only be enabled per node for either RSVP or LDP. It cannot be enabled/disabled per IP interface.
FRR FACILITY
BACKUP
In prior releases, only one-to-one FRR was supported on 7210. With this release, support for fast reroute (FRR) facility backup is available. FRR facility backup allows for the use of a single MPLS tunnel LSP to protect multiple MPLS tunnel LSPs between two tunnel endpoints. 7210 can perform a MPLS label lookup for up to a maximum of 2 labels. On egress LER, to use FRR facility backup feature, the implicit NULL label option must be enabled.
CESOP
In prior releases, 7210 SAS-M supported only SAToP encapsulation (unstructured mode) over MPLS networks for use with cpipe services (also known as CES services). With this release, support for CESoPSN encapsulation (structured mode) over MPLS networks is available. Structure-aware circuit emulation (CESoPSN) is used for transport of structured TDM, taking at least some level of the structure into account. By selecting only the necessary n 64 kb/s time slots to transport, bandwidth utilization is reduced or optimized (compared to a full DS1 or E1). Full DS1s or E1s can be transported by selecting all the time slots in the DS1 or E1 circuit. Framing bits (DS1) or FAS (E1) are terminated at the near end and reproduced at the far end. 7210 SAS-M supports CESoPSN without CAS for DS1 and E1 in the current release. Support for CESoPSN with CAS is planned for a subsequent release.
7210 SAS-M ACCESS-UPLINK MODE (A.K.A. L2 UPLINK MODE)
With this release, 7210 SAS-M and all its variants supports access-uplink mode of operation. In prior releases of 7210 SAS-M, the device can operate only in network mode. In network mode, the operator uses MPLS technology to transport service frames to the network core. In accessuplink mode, operator chooses to use QinQ uplinks towards the network core. With QinQ uplinks, the service frames are transported to the network core using QinQ encapsulation instead of MPLS. It allows operators who do not wish to extend MPLS technologies to the edge to use Layer 2 technologies (that is, QinQ encapsulation) for extending services to the customer edge. The system must be upgraded to use the bootloader version made available with release R3.0r1. First time use of access-uplink mode requires configuring the BOF parameter 'uplink-mode' to value 'access-uplink' and a system reboot. Note: configuration file with CLI commands applicable to network mode ports should not be used during a reboot. It is recommended to start with a empty configuration file and reboot the system. After the system boots up, new configuration can be added. In access-uplink mode, the device allows for configuration of port in access-uplink mode and allow for use of access-uplink SAPs for service configuration. In this mode, the system boots up with all ports configured in access mode. User can modify the port mode to access-uplink
Page 48
Alcatel-Lucent
after system boot up, but the software does not allow the mode to be set to network. The software allows the user to configure services to use only either access SAPs or access uplink SAPs, but not MPLS-based SDPs. In network mode, the device allows for configuration of port in network mode and allow for use of network IP interfaces and MPLS-based SDPs for service configuration. In this mode, the system boots up with all ports configured in network mode. User can modify the port mode to access after the system boot up, but the software does not allow the mode to be set to access-uplink. The software allows the user to configure services to use only either access SAPs or MPLS-based SDPs, but not access uplink SAPs. User should take care not to configure service entities (for example, MPLS LSPs, MPLS IP interfaces, RSVP, LDP, MPLS Path Objects, OSPF) related to MPLS while in access-uplink mode and similarly access-uplink related service entities while in MPLS mode. The system does not check for this. 2 x 10G MDA is available for use in the expansion slot when 7210 SAS-M is configured in access-uplink mode. The 4 x T1/E1 CES port is not available for use in access-uplink mode. Following are some of the major features supported in 7210 SAS-M in access-uplink mode: VPLS and VLL services IES service only for use in inband management of the device QoS (SAP ingress Qos policies with hierarchical metering, Access Egress QoS policies per port, Access uplink ingress and egress policies per port, etc.) Accounting policies ACLs (MAC and IP criteria) LAG (with support for active/standby to allow for being a MC-LAG client) STP/RSTP and mVPLS/RSTP LLDP EFM with dying gasp support SyncE IGMP V1, V2
CFM, G.8032, VPLS IP Interface (for Ping) IGMP V3 support is not available with accessuplink mode. Please refer to the user guide for more information.
RELEASE 2.0R3
SYNCHRONOUS ETHERNET
The 7210 SAS-M provides network synchronization using Ethernet ports. Synchronous Ethernet is a variant of line timing supported on the Ethernet SFP ports with SFPs that support Synchronous Ethernet. Synchronous Ethernet ports configured for line timing provide the best synchronization performance through a synchronization distribution network. Line timing mode derives the timing information from the Ethernet ports. This mode is immune to any packet delay variation (PDV) occurring on Layer 2 or Layer 3 links. When synchronous Ethernet is enabled on the node, the operator can select an Ethernet port as a candidate timing reference. The recovered timing from this port is then
Alcatel-Lucent
Page 49
used to time the system. In this release the recovered timing information is used to time only the Ethernet port output.
RELEASE 2.0R2
OUT-OF-BAND ETHERNET MANAGEMENT PORT
7210 SAS-M and all its variant platforms supports 10/100 Base-T ethernet management port. This port is available for out-of-band management of the node. Note: To use Ethernet management port, boot.tim image version should be 2.0R2 or greater.
LDP
This feature provides the capability to use Label Distribution Protocol (LDP) for setup of MPLS Label Switched Path (LSP). The MPLS LSPs setup using LDP is available for use by SDP. LDP is a protocol used to distribute labels in non-traffic-engineered applications. LDP allows routers to establish LSPs through a network by mapping network-layer routing information to MPLS LSPs. An LSP is defined by the set of labels from the ingress Label Switching Router (LSR) to the egress LSR. LDP associates a Forwarding Equivalence Class (FEC) with each LSP it creates. A FEC is a collection of common actions associated with a class of packets. When an LSR assigns a label to a FEC, it must let other LSRs in the path know about the label. LDP helps to establish the LSP by providing a set of procedures that LSRs can use to distribute labels. Y.1731 is defined by ITU-T. It is built on top of the IEEE 802.1ag, but it has more functionalities compared to the former, such as AIS, performance monitoring, etc. In this release, the following Y.1731 functionalities are supported: ETH-CCM ETH-LB ETH-LT ETH-RDI ETH-AIS ETH-TST ETH-DM including one-way and two-way delay measurements. Software timestamps are used for delay measurement.
Y.1731:
CIRCUIT EMULATION (CES) MDA
In Release 2.0R1, a new MDA m4-ds1 with 4 x T1/E1 ports, that supports Circuit Emulation Services (CES) was available only for BETA testing. In Release 2.0R2, it is available for deployment. Brief description of the MDA and CES is available under the heading Release 2.0R1 of this section.
Page 50
Alcatel-Lucent
RELEASE 2.0R1
CIRCUIT EMULATION (CES) MDA (ONLY FOR BETA TESTING)
In Release 2.0R1, a new MDA m4-ds1 with 4 x T1/E1 ports, that supports Circuit Emulation Services (CES) is available. This MDA is available for use on the 7210 SAS-M 24F, 7210 SAS-M 24F 2XFP and 7210 SAS-M 24F 2XFP ETR platforms. It can be inserted into the expansion slot available on these platforms. CES services is used to emulate TDM services over an IP/MPLS transport network. It allows operators to transport legacy T1/E1 services over an IP/MPLS transport network. This release supports only SAToP services as per RFC 4553, Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP), Adaptive Clock Recovery (ACR) is available for clock synchronisation. The 7210 SAS-M 24F, 7210 SAS-M 24F 2XFP and platforms supports alarm inputs (dry contact input) that allows the operator to monitor and report changes in the external environment (such as temperature changes, door open/close, etc.). It supports 4 alarm inputs pins. Provides a method to reroute transit LSPs in a bulk fashion away from the node during maintenance of a node. A PathErr message with a specific error code Local Maintenance on TE Link required Flag is sent during maintenance of a node. When an LER receives the message, it performs a make-before-break on the LSP path to move the LSP away from the links/nodes whose IP addresses were indicated in the PathErr message. Affected link/node resources are flagged in the TE database so that other routers will signal LSPs using the affected resources only as a last resort. Prior releases of 7210 SAS-M supported only spoke SDPs, allowing the node to deployed only in a H-VPLS topology. With the introduction of mesh SDPs, the node can be deployed in a VPLS topology. The 7210 SAS-M supports tunneling of LACP packets only in a VLL service. LACP tunneling can be enabled for an Ethernet port. When LACP tunneling is enabled, the port will not process any LACP packets but will tunnel them instead. This port cannot be added as a member of a LAG. Support for processing PVST packets received on a SAP enabled for STP. It allows the 7210 to interoperate with nodes that use PVST. When a PVST BPDU is received on Dot1q or a QinQ SAP, the packet is processed appropriately to update STP states and PVST BPDUs are sent out of that SAP.
ALARM INPUTS
TRAFFIC
ENGINEERING GRACEFUL SHUTDOWN
MESH SDP SUPPORT IN A VPLS SERVICE
LACP TUNNELING IN A VLL SERVICE
PROCESSING
SUPPORT FOR PVST

PACKETS
Alcatel-Lucent
Page 51
DIGITAL DIAGNOSTICS FOR SFPS AND XFPS
Digital Diagnostics Monitoring is a capability of some SFPs and XFPs where the transceiver module maintains information about its working status in device registers including: Temperature Supply voltage (for SFPs) TX bias TX output power RX received optical power
The transceiver is also programmed at the factory with Warning and Alarm thresholds for Low and High conditions of the above that can generate system events. The show port port-id detail command has been augmented to display the DDM data at the console, and the DDM data is accessible through SNMP for use with RMON threshold monitoring if traps are desired for custom thresholds.
Page 52
Alcatel-Lucent
ENHANCEMENTS
RELEASE 5.0R2
IS-IS ENHANCEMENTS The following item describe enhancements added to 5.0 R2 of the 7210 SAS-M OS.
Platforms Supported: 7210 SAS-X, and 7210 SAS-M network mode From 5.0R2 release following CLI commands are supported: "configure> router> is-is> if> tag", to configure a tag for the IP interface configured for IS-IS. This allows users to use the tag with route policies to match IS-IS routes that use the tag. "configure> router> is-is> advertise-passive-only", which allows IS-IS protocol to advertise only passive interfaces. "configure> router> is-is> lsp-mtu-size", to configure the size of the IS-IS LSPs. If this value is changed, IS-IS must be restarted for the new value to take effect. "configure> router> is-is> export-limit", to limit the number of routes that are exported into IS-IS from the route table.
For more information, see the 7210 SAS-MX Routing Protocols User Guide. FORWARDING OF PACKETS WITH 3
TAGS RECIEVIED ON
Platforms Supported: 7210 SAS-X, 7210 SAS-M network mode In prior releases, 7210 supported forwarding of packets received with 3 tags on a QinQ SAP in an Epipe service with MPLS SDP as the other endpoint. In this release, the support has been extended to allow for a Dot1q SAP to be configured as the other endpoint in an Epipe service. With this release, to forward packets received on a QinQ SAP with more than 3 tags, the user can configure an Epipe service with one endpoint configured to be a QinQ SAP and the other endpoint configured to be a Dot1q SAP. User must ensure that the Dot1q SAP VLAN tag value matches the QinQ SAPs inner tags VLAN value. For packets received on a QinQ SAP, data plane will remove the outermost tag and preserve the inner tag (and any of the following tags) and forward the packet over the Dot1q SAP (without adding additional tags). For packets received on a Dot1q SAP, data plane will preserve the inner tag (and any of the following tags) and forward the packet over the QinQ SAP after adding an additional VLAN tag (the additional VLAN tag added corresponds to the outermost VLAN tag configured for the QinQ SAP). For more details of the processing behavior and restrictions for the new service type please read the 7210 SAS-M and 7210 SAS-X Services user guide. Platforms Supported: 7210 SAS-X, and 7210 SAS-M network and access-uplink mode With 5.0R2 release, users can use 100ms timer (with about 300ms time out) with BFD and EFM OAM for fault detection. On 7210 platforms, only a few BFD or EFM sessions with 100ms timers are recommended for use simultaneously. User must ensure CPU availability before using 100ms timers.
QINQ SAP EGRESS ON DOT1Q SAP IN EPIPE SERVICE
SUPPORT OF 100MS EFM/BFD TIMER
Alcatel-Lucent
Page 53
TRANSMIT TIMESTAMP OPTIMIZATION FOR CFM/Y.1731 MESSAGES CHANGE IN 7210 CHASSIS PART NUMBER
Platforms Supported: 7210 SAS-M both modes, 7210 SAS-D With 5.0R2 release, CPU based transmit timestamps that are added to CFM/Y.1731 messages (For example: 2-DM) have been optimized to reduce the variance in the measurements. With this optimization, the majority of the 2-way delay measurements are much more accurate than they were previously. To allow customers to order 7210 chassis (7210 SAS-E, 7210 SAS-M and 7210 SAS-X platforms) and power supplies independently, new part numbers will be assigned to the 7210 chassis. The new Release 3.0R12, 4.0R8 and 5.0R1 supports appropriate display of part numbers (also known as, power neutral part numbers). On 7210 chassis shipped with power neutral part numbers and running with release 3.0R12, 4.0R8 or 5.0R1, "show chassis" and "show card detail" CLI display output for the field tagged 'Part Number' is as shown below: 7210 SAS-E 12F12T displays "part number" as 3HE04698AAAA01 (that is, new part number for 7210 SAS-E chassis without a power supply) 7210 SAS-M 24F displays "part number" as 3HE04699AAAA01 (that is, new part number for 7210 SAS-M chassis without a power supply) 7210 SAS-M 24F2XFP displays "part number" as 3HE05828AAAA01 (that is, new part number for 7210 SAS-M 10G chassis without a power supply) 7210 SAS-M 24F2XFP ETR displays "part number" as 3HE06035AAAA01 (that is, new part number for 7210 SAS-M 10G ETR chassis without a power supply) 7210 SAS-X 24F2XFP displays "part number" as 3HE05827AAAA01 (that is, new part number for 7210 SAS-X chassis without a power supply)
On 7210 chassis shipped with power neutral part numbers and running with release older than 3.0R12, 4.0R8 or 5.0R1, "show chassis" and "show card detail" CLI display output for the field tagged 'Part Number' is as shown below: 7210 SAS-E 12F12T displays "part number" as 3HE04410AAAD01 (that is, part number used for 7210 SAS-E chassis with an AC power supply) 7210 SAS-M 24F displays "part number" as 3HE05029AAAC01 (that is, part number used for 7210 SAS-M chassis with an AC power supply) 7210 SAS-M 24F2XFP displays "part number" as 3HE05169AAAB01 (that is, part number used for 7210 SAS-M 10G chassis with an AC power supply) 7210 SAS-M 24F2XFP ETR displays "part number" as 3HE05589AAAB01 (that is, part number used for 7210 SAS-M 10G ETR chassis with an AC power supply) 7210 SAS-X 24F2XFP displays "part number" as 3HE05170AAAA01 (that is, part number used for 7210 SAS-X chassis with an AC power supply) Chassis without power neutral part numbers (that is, those currently shipped or shipping) running with release 3.0R12 or 4.0R8 or 5.0R1. Chassis without power neutral part numbers (that is, those currently shipped or shipping) running with release older than 3.0R12 or 4.0R8 or 5.0R1.
There is no change in the display for:
NOTE:
Page 54
Alcatel-Lucent
The software changes mentioned above have been done in anticipation of the part number changes yet to be effected in manufacturing. It is expected that manufacturing will change over to the new part number scheme sometime in Q1 2013. The back of the chassis will also display the new power neutral part numbers once the change is effected in manufacturing. This will match the display output obtained using the show chassis or show card detail CLI command using release 3.0R12, 4.0R8 and 5.0R1. Please contact your IPD sales team to know the latest part numbers to use while ordering for 7210. Though the part numbers above are correct, do not use these while ordering, as it can potentially change over time.
RELEASE 5.0R1
UP MEP SUPPORT
FOR VPLS SERVICE
The following item describe enhancements added to 5.0 R1 of the 7210 SAS-M OS.
From 7210 SAS 5.0R1, support is available for UP MEP on 7210 SAS-M (network mode only) in VPLS service. UP MEP on Epipe service was already supported from 4.0R6 release. UP MEP allows operators to place a diagnostic point as close to the customer as possible. It allows operators to diagnose fault with services and measure service performance metrics up to the UNI demarcation point. 7210 UP MEP implementation supports both CFM and Y.1731, including SLM. It can also be used with SAA. Configuring MEP MAC which is different from system MAC is mandatory for an UP MEP configured on a VPLS SDP. NOTE: Before using UP MEP user needs to configure appropriate amount of resources using the CLI commands under "config> system> resource-profile". UP MEP shares resources with ACLs/ingress QOS, hence if upgrading from a previous release, user must ensure enough resources are available for use with UP MEP. Please read the 7210 SAS-MX Basic System Configuration user guide, 7210 SAS-M Services user guide and 7210 SAS-MX OAM user guide for more information.
LLDP TUNNELING
Platforms Supported: 7210 SAS-E, 7210 SAS-D, 7210 SAS-X and 7210 SAS-M With this enhancement tunneling of LLDP frames that use the nearest-bridge-dest-mac as destination MAC address is supported. When tunneling is enabled, using the command tunnelnearest-bridge-dest-mac, all frames received with the matching LLDP destination mac address are forwarded transparently to the remote end of the service. To forward these frames transparently, the port on which tunneling is enabled must be configured with NULL SAP and the NULL SAP must be configured in an Epipe service. Tunneling is not supported for any other port encapsulation or when using any other service. Additionally, before enabling LLDP tunneling, admin status for LLDP dest-mac nearest-bridge must be set to disabled or Tx only, using the command admin-status available under configure> port> ethernet> lldp> destmac nearest-bridge. If admin-status for dest-mac nearest-bridge is set to receive and process nearestbridge LLDPDUs (that is, if either rx or tx-rx is set) then it overrides the tunnel-nearest-bridgedest-mac command.
Alcatel-Lucent
Page 55
NOTE: Transparent forwarding of LLDP frames can be achieved using the standard defined mechanism when using the either nearest-non-tmpr or the nearest-customer as the destination MAC address in the LLDP frames. It is recommended that the customers use these MAC address where possible to conform to standards. This command allows legacy LLDP implementations that do not support these additional destinations MAC addresses to tunnel LLDP frames that use the nearest-bridge destination MAC address. DOT1X TUNNELING Platforms Supported: 7210 SAS-X and 7210 SAS-M network mode With this feature dot1x frames received on the port are transparently forwarded to the remote end of the service. To forward dot1x frames transparently, the port on which tunneling is enabled must be configured with NULL SAP and the NULL SAP must be configured in an Epipe service. Tunneling is not supported for any other port encapsulation or when using any other service. Additionally, dot1x protocol must be disabled on the port (using the command configure> port> ethernet> dot1x> port-control force-auth) before dot1x tunneling can be enabled using this command. If dot1x is configured to use either force-unauath or auto, then dot1x tunneling cannot be enabled. IPV6 MANAGEMENT
ACCESS FILTER
(MAF)
Release 5.0R1 supports configuring IPv6 MAF. Using "configure>system>security>management-access-filter >ipv6-filter" CLI IPv6 MAF can be configured. IPv6 MAF ACL can be used implement security policies for IPv6 traffic designed to CPU from In-band or Out of band management ports. Platforms Supported: 7210 SAS-E, 7210 SAS-D, 7210 SAS-X and 7210 SAS-M Prior to this enhancement the value of snmpEngineBoots (in the SNMP-FRAMEWORKMIB.mib and described in RFC3414) was always reset to a value of 1 after a full system reboot instead of incremented by 1 as specified in RFC3414. With this enhancement, the value of snmpEngineBoots is incremented by one after a system reboot or an snmp engineID change. If snmpEngineBoots reaches its maximum value (2147483647) it will no longer increment and remains at that value until the operator performs manual intervention by changing the snmp engineID. The value of snmpEngineBoots is saved in a file on the compact flash called nvsys.info.
SNMPENGINEBOOTS
SUPPORT FOR TUNABLE 10G DWDM XFP
Platforms Supported: 7210 SAS-X and 7210 SAS-M in network mode only With this release, 7210 SAS-X and M platforms provide support for use of tunable 10G DWDM XFPs. Please read the 7210 SAS-M,X Interfaces Guide for more information.
SUPPORT 24 MCLAG INSTANCES
Platforms Supported: 7210 SAS-X and 7210 SAS-M in network mode only With this release, 7210 SAS-X and 7210 SAS-M (network mode only) allows for use of 24 LAG instances. This allows user to use all the front panel ports to provide customer services when the 7210 devices are deployed as the head-end MC-LAG nodes. Please read the 7210 SAS-M,X Basic System Configuration User guide for more information about MC-LAG support.
Page 56
Alcatel-Lucent
SUPPORT MEMORY CACHE FOR

ACCOUNTING LOGS
Platforms Supported: 7210 SAS-E, 7210 SAS-D, 7210 SAS-X and 7210 SAS-M With this release, if user specifies use of memory cache (configured using the command configure> log> accounting-policy> log-memory), software allocates some RAM (i.e. volatile memory) as a temporary storage to write accounting records. The software writes to this memory cache every collection-interval, instead of writing directly to the flash. The accounting records are moved from the temporary storage to the specified file on non-volatile memory (that is, flash) when either the rollover period expires or when temporary storage location is full. This can potentially help users to extend the lifetime of the internal flash. Please read the 7210 SAS-D,E and 7210 SAS-M,X Systems Management User Guide for more information.
SUPPORT FOR
FLEXIBLE ALLOCATION OF HARDWARE RESOURCES
Platforms Supported: 7210 SAS-D, 7210 SAS-X and 7210 SAS-M in both access-uplink and network mode In prior releases, the system statically allocates ingress and egress TCAM resources for use by SAP Ingress QoS classification, Ingress and Egress access control list (ACLs), CFM MEPs, and so on. The resource allocation is not user configurable. In release 5.0R1, with introduction of new capabilities such as IPv6 classification, UP MEP support, and G8032-fast-flood, the static allocation of resources by software does not meet requirements of different customers, who typically want to use different features. The user can allocate a fixed amount of resources per system to be used for SAP ingress QoS, Ingress and Egress ACLs, CFM/Y.1731 MEPs and other features, as per their needs. Some of these parameters are boot-time and others are run-time. A change in current value of the parameter that is designated boot-time needs a reboot of the node, before the new value takes effect. Change in current value of the parameter that is designated run-time takes effect immediately, if the software determines resources are available for use to accommodate the change. NOTE: Maximum resources available for allocation and support available on different platforms have minor differences. Please read the platform-specific user guide for more information. Please read the 7210 SAS-D,E and 7210 SAS-M,X, Router Configuration User Guide, QoS User Guide, Basic System Configuration User guide for more information.
RELEASE 4.0R7
G8032 SUPPORT DEFAULT (*.*) QINQ SAPS FOR VPLS
The following item describe enhancements added to 4.0 R7 of the 7210 SAS-M OS.
FOR
The 7210 SAS 4.0R7 supports G8032 ring protection for Default QinQ SAPs (notation - *.*) on access-uplink ports in a VPLS service on a ring node. It is required to have a separate G8032 control instance to determine the forwarding state of the SAPs on the ring ports.
Alcatel-Lucent
Page 57
RELEASE 4.0R6
SAP INGRESS QOS
POLICY ENHANCEMENT FOR
The following items describe enhancements added to 4.0 R6 of the 7210 SAS-M OS.
From 7210 SAS 4.0R6, VPRN SAPs can be attached with SAP-ingress QoS policy where policies mac-criteria are set to "any". Using "any" mac-criteria, the user can classify packets at SAP ingress based on dot1p, smac, dmac, and etype. In previous release "dot1p-only" was supported with VPRN SAPs.
VPRN SAP
RELEASE 4.0R5 RELEASE 4.0R4

SYNC-E SUPORT ON 10G MDA PORTS AUTO-INIT ENHANCEMENTS
There are no new enhancements added to 4.0 R5 of the 7210 SAS-M OS.
From 4.0R4 release, sync-E with SSM is supported for 10G MDA ethernet ports. These ports can now be used as a reference or for distributing reference using sync-E. In previous releases, only priority tagged DHCP requests were sent out. With this release, In autoinit mode, DHCP requests are sent out by the node are in two formats. The system attempts to talk to the DHCP server in these two formats, one after another, if necessary. Initially the DHCP requests are sent out with a priority VLAN tag (VLAN ID = 0, Dot1p PCP bits set to 7). If no response is received from the DHCP server during the above request period, DHCP requests are sent out with no VLAN tag (a.k.a. null-tagged packets). This is supported on all platforms. In 4.0R4 release, 7210 SAS-M 24F 2XFP (10GigE) (both standard and ETR variant), the DHCP requests are sent out of port 1/1/25 and 1/1/26 as part of autoinit. The system will attempt to obtain the system parameters and the BOF file location by sending out DHCP requests on the following ports in the order that appears - 1/1/1, 1/1/2, 1/1/25 and 1/1/26. It sends out the DHCP request on a single port at a given time and waits for the DHCP server to respond. If a server responds successfully, the autoinit process uses the information provided to bootup the system. If no responses are received from the server within a stipulated time, it sends out DHCP requests on the next port in the order above, looping through all the ports until a successful response is received from the server or the user interrupts the boot process. NOTE: The above enhancements require 4.0R4 "boot.tim".
RELEASE 4.0R3
Page 58
Alcatel-Lucent
LAG PORT SUPPORT FOR PBB B-VPLS SAP ACLS FOR B-VPLS SAP
From release 4.0R3, PBB B-VPLS SAP configuration on LAG port is supported.
With 4.0R3 release, MAC filter is available for use with B-VPLS SAPs on 7210 SAS-X and 7210 SAS-M. For traffic ingressing a B-VPLS SAP and destined to a B-VPLS SAP, the MAC filter matches the B-domain MAC header fields (that is, B-DA, B-SA, etc.). The MAC filter can be used to match customer payload MAC header fields for traffic ingressing a B-VPLS SAP and destined to a I-VPLS SAP. In release 4.0 R3, 7210 SAS-M and its variants support generation of SNMP dying gasp trap on power failure. By default, the system generates EFM OAM dying gasp message. The user needs to explicitly configure the system to send out an SNMP trap on loss of power to the node. Generation of SNMP dying gasp trap is mutually exclusive to use of EFM OAM dying gasp message. For details, please refer to the 7210 SAS-M System Management Guide.
SNMP DYING-GASP TRAP
INPUT/OUTPUT DC POWER FAILURE

TRAP
From release 4.0R3, the software is capable of generating two traps, a separate one for DC power source failure (tmnxEqPowerInputFailure) and another for DC power supply failure (tmnxEqPowerOutputFailure). In releases prior to 4.0R3, the system generated a single trap (viz. tmnxEqPowerSupplyFailure). From release 4.0R3, by default only the trap identified by the name tmnxEqPowerSupplyFailure is generated. The new traps, that is, event-name (viz. tmnxEqPowerInputFailure and tmnxEqPowerOutputFailure) are optional and are suppressed by default. User needs to explicitly enable the generation of the new traps using the CLI command 'configure log event-control chassis event-name|event-number generate'. The old trap (viz. tmnxEqPowerSupplyFailure) will continue to be generated along with the new traps until user explicitly suppresses the generation using the CLI command 'configure log event-control chassis event-name|event-number suppress'. In prior releases, on a power source failure along with the trap the Critical LED would glow RED. From release 4.0R3, additionally the status LED will blink when a power source failure is detected. Irrespective of which feed failed, the status LED will blink at the same rate.
ETH-RING (G.8032) FAILOVER TIME IMPROVEMENT
With 4.0R3 release, failover time for eth-ring based services has been improved for 7210 SASM configured in network mode or access-uplink mode. When a failure is detected in the ring, all the nodes in the ring flush the MAC addresses learnt on the ring ports to allow faster convergence of service traffic. To support better switchover time during failures in the ring, in addition to MAC flush, the system floods the service traffic learnt through the ring ports (before the failure), which results in forwarding of traffic while the system flushes the MAC address learnt on the ring ports and learns the MAC addresses on the new active ring port. With this the failover time is much closer to sub-50ms. On 7210 SAS-M configured in network mode, use of this feature needs user configuration using the CLI command "config> system> resource-profile> g8032-fast-flood-enable", save config and a reboot of the node. On a reboot, the system will allocate resources for use by G8032, if this command is present in the configuration file by reducing the amount of resources available for use with ACLs. In other words, when this command is used, the amount of resources
Alcatel-Lucent
Page 59
available for use with ACLs is reduced by 512. User should ensure that the resource usage of ACLs has been appropriately modified, before the reboot, to make way for use of this feature. Please see the 7210 SAS-M user guide for more details on use of this command. Note that 7210 SAS-M configured in access-uplink mode supports improved timings without configuring "g8032-fast-flood-enable" TRAP GENERATION FOR EXCEEDING INVALID LOGIN ATTEMPTS A SNMP trap is generated by the device when the login attempts exceed the configured threshold for radius/tacacs/local user. The threshold can be configured using the CLI parameter 'count' in the command config> system> security> password> attempts <count> [time <minutes1>] [lockout <minutes2>]. tmnxUserLoginMaxAttempts trap is generated when a user failed to authenticate in more than permitted number of retires through telnet or console. tmnxSSHUserLoginMaxAttempts trap is generated when a user failed to authenticate in more than permitted number of retires through SSH. Generation of the trap can be suppressed, if need be, using the config>log> event-control command. By default, the device will generate the trap whenever the event is raised. The trap will carry information about the user ID, source IP address of the client used for the login attempt.
RELEASE 4.0R2
TRAP GENERATION WHEN FILE LIMIT THRESHOLD IS CROSSED
From release 4.0R2, a warning message is displayed on the console and trap (tmnxRootDirFull) is generated if the number of files and directories in the root directory crosses the threshold limit of 80. Warning will be generated for every new file or directory created after threshold limit is exceeded. This limit is applicable only for files and directories created in the root directory on cf1:\. There is no restriction on the number of files and directories created in the sub-directory. The number of files in the root directory might also increment by issuing the command admin save or bof save. When this event is displayed it is expected that the user will cleanup the root directory and remove unnecessary files and directories or move them to a sub-directory created under the root-directory to ensure that the number of entries (files or directories) in the root directory is below the limit. No warning is generated when the number of files and directories comes down below the threshold
RELEASE 4.0R1
CONTROL-WORD CONFIGURATION FOR VPLS SDP
From release 4.0R1, 7210 SAS-M and variants in network mode support "control-word" configuration for vpls sdp's. IGMP snooping is not supported for control word enabled SDP.
Page 60
Alcatel-Lucent
FORWARD/DROP COUNT FOR SAP METER STATS
From release 4.0, 7210 SAS-M supports forward and drop count for sap meter stats. In previous releases, Sap per Meter stats displayed packets and octets count "For. InProf" and "For. OutProf". From 4.0R1 supports Sap per Meter stats "Total Forwarded" and "Total Dropped", packets and octets count per sap. By default InProf/OutProf counts are displayed, for displaying Forwarded/Dropped count "sap>statistics>ingress>counter-mode" should be configured to "forward-drop-count". If the counter mode is specified as "forward-drop-count", one counter counts the forwarded packets and octets received on ingress of a SAP meter and another counts the dropped packets. The forwarded count is the sum of in-profile and out-of-profile packets/octets received on SAP ingress. The dropped count is count of packets/octets dropped by the policier. A packet is determined to be in-profile or out-of-profile based on the meter rate parameters configured. A packet is dropped by the policier if it exceeds the configured PIR rate. The InProf count and OutProf count is not individually available when operating in forward-drop-count mode. This feature is supported on 7210 SAS-M network and access-uplink modes. It is supported in VPLS, Epipe, VPRN, and PBB SAPs. It is not supported for cpipe SAP. For more details please refer the 7210 Services user guide. 4.0R1 release also supports display of sap based "Ingress Drop Stats". Software calculates and displays "Ingress Drop Stats" based on values obtained from sap "Ingress Stats" and meter's InProf/OutProf or Forwarded/Dropped. sap "Ingress Drop Stats" is not included in the accounting records.
ENHANCED NETWORK INGRESS QOS SUPPORT FOR MPLS PACKETS USING LDP TUNNELS (KNOWN ISSUE 99401)
With release 4.0, the network qos policies are enhanced to make it more intuitive to the user to configure and ensure the QoS treatment in the system is consistent for all MPLS traffic received on an IP interface. With the changes, the FC assignment for all MPLS packets is based on the LSP EXP bits to FC mapping defined in the network policy associated with an IP interface and the policier used is obtained from the same network policy. The EXP bits in the MPLS label in the packet determine the profile of the packet. This allows network designers to provision bandwidth per FC per IP interface taking in to account only EXP bits received in the ingress traffic, without the need to make special considerations for FRR and LDP traffic. Note: During upgrade from previous release configuration file to 4.0R1 release, system will take following action: For each network qos policy of ip-interface type in the configuration file, system creates "mpls-lsp-exp-profile-map" policy and attached to network qos policy. mplslsp-exp-profile-map policy id is equal to network qos policy id. "mpls-lsp-exp-profile-map" policy populated with "lsp-exp lsp-exp-value profile {in|out}" information, lsp-exp and profile values are copied from corresponding network qos policy configuration file. It is recommended to save the configuration file after upgrade to 4.0R1 release. To ease migration of users to the new set of provisioning commands, the node can operate in two modes. One mode supports existing R3.0 behavior and provisioning commands and another mode support the new R4.0 behavior and provisioning commands. The command ldp-uselocal-fc-enable allows the user to move to the new behavior. Once this CLI command is executed, user cannot revert to R3.0 mode.
Alcatel-Lucent
Page 61
In 4.0 mode, user can define profile policy (mpls-lsp-exp-profile-map policy) for use by all LDP tunnel labels, this can be configured using CLI configure qos use-global-mpls-lsp-exp-profile <policy-id>, where <policy-id> is any user defined mpls-lsp-exp-profile-map policy id. For more details and restrictions, please refer the 7210 SAS Services user guide. IP MTU SUPPORT IES INTERFACES This feature allows the user to set the IP MTU to use for an IES IP interface. IP MTU ensures that the IP packets sent out of the IP interface are less than the IP MTU specified. Users configure IES IP interface on access-uplink ports for in-band management of the node. With this feature operator can specify the IP MTU to use for CPU generated IP packets (e.g. SNMP, FTP, etc.), making it possible to use different MTU (possibly smaller MTU value than the port MTU) for management traffic and service traffic that share the same port. It is available for use on 7210 SAS-E, 7210 SAS-D and 7210 SAS-M (access-uplink mode only). IGMP SNOOPING V3
SUPPORT ON
ON
ACCESS-UPLINKS
Prior releases supported IGMPv1 and v2 snooping for a VPLS service. IGMP snooping in a VPLS service now supports IGMPv3. 7210 SAS-M now supports (S,G) records for multicast replication only in access-uplink mode. Note: IGMPv3 is not supported in 7210 SAS-M in network mode.
CONFIGURABLE
PERIOD FOR WRITING
ACCOUNTING RECORDS TO FLASH
With this enhancement, users have an option to configure the collection-interval for different accounting records supported in 7210. The collection-interval determines how frequently the system polls for counters to generate accounting records that are written to flash. Users can configure values other than the default value based on the how frequently they need to gather performance statistics for different service entities. Use of bigger value for collection-interval, can reduce the number of writes and frequency of writes to the flash. It is available on all 7210 platforms.
ENABLE/DISABLE OF MANAGEMENT / CONSOLE PORTS
In release 4.0, 7210 devices support the capability to disable console. In remote deployments, this provides the operator with additional security measure. Operator can disable the use of console to prevent access to the box by a malicious user. Use of console access is not available only when the Timos image is booted. It is always available for use when the bootloader image is executing. It is available on all 7210 platforms.
RESULTS IN
STORING OF SAA FLASH
OAM SAA test results can be saved in a file on the compact flash card, and the standard available file policy can be used to define how long the file is open/closed when 5620 SAM is informed to retrieve the file, similar to how accounting works. SAA TCAs and ad-hoc (nonscheduled/non-cron) results are sent as usual. Once the OAM SAA test results are put on the compact flash card and the file is closed, a trap is sent to the SNMP trap receiver that may then opt to obtain the file and process it as desired. This feature is available on 7210 platforms.
Page 62
Alcatel-Lucent
BOF PASSWORD RECOVERY
From release 4.0 onwards, the default BOF password can be modified by the user. To edit the BOF parameters, user needs to provide the correct password. If the user forgets the password and fails to provide a correct password after three attempts, the system prompts the user to reset the BOF password to factory default. As a security measure, to prevent a malicious user from using it to gain access to the configuration files, when the password is reset to default, the system also resets the flash to factory defaults (i.e. it removes all the files from the flash except for the boot image file (cf1:\boot.tim) and Timos image file (cf1:\both.tim)) and reboots the node with the factory default settings. The node is rebooted after the password is reset, to boot up with the factory default settings. After bootup, the user needs to setup the box using the same steps as used to boot the box the first time when it was received from the factory. User can use the factory default password password to edit the BOF parameters after the bootup subsequent to reboot and choose to change the password again. Note: It is highly recommended that user does not rename cf1:\boot.tim and cf1:\both.tim, if the system needs to retain them during the password recovery procedure. Additionally, it is highly recommended that the user takes a backup of all the image files, configuration files and other data.
COMPATIBLE BOOT LOADER
In prior releases, due to incompatible bootrom and bootloader, certain versions of bootrom did not load certain versions of the bootloader, resulting in a boot loop, which would mean a RMA of the affected device. The bootloader version (i.e. boot.tim) supplied with release 4.0, is compatible with all previous versions of bootrom. It is recommended to perform a upgrade of the bootloader to latest version supplied with release 4.0 image.
RELEASE 3.0R2
DC POWER SOURCE [-48V] FAILURE DETECTION
This enhancement introduces the capability to detect DC power source failure. 7210 chassis allows two DC power sources to be connected to the chassis. With this feature enhancement, the system detects if the DC power source has failed and raises a critical alarm (the Critical LED is lit and the Critical Alarm output pin is triggered). The alarm is cleared if the DC power source is restored. This enhancement is supported only on the new revision of the 7210 SAS-M hardware [3HE05029AAAC, 3HE05029ABAC, 3HE05168AAAB, 3HE05169AAAB, 3HE05589AAAB, 3HE05590AAAB]. There is no user configuration required to enable this feature. The software enables this feature automatically by detecting the capability of the hardware platform. The system has two slots to plug in AC or DC power supplies. It associates the DC power supply in top slot with power source feed #A (-48V Ret-A on the chassis) and DC power supply in the bottom slot with power source feed #B (-48V RetB on the chassis). The system detects the failure of power source feed #A only if the DC power supply is plugged into the top slot. Similarly, the system detects the failure of power source feed #B only if the DC power supply is plugged into the bottom slot. The trap message generated by the message indicates that there is an input failure for the power supply associated with power input feed that failed.
Alcatel-Lucent
Page 63
RELEASE 3.0R1
LDP 1K /32 PREFIXES VCCV TRACE
SUPPORT
In this release, the number LDP /32 prefixes that are supported has been increased to 1k(1000). From release 2.0r5, support is available for mpls oam tool, vccv trace.
SAP INGRESS MATCH CRITERIA CLASSIFICATION ENTRIES SCALING
From release 2.0R1, sap-ingress qos policy supports 64 match entry criteria and max of 256 classifiers per sap-ingress qos policy.
RELEASE 2.0R4
HIERARCHICAL INGRESS POLICING
This release introduces support for per SAP aggregate policing on the 7210 SAS-M. This is in addition to the per FC policier available in the previous releases. Users can configure an policier per SAP, which polices the aggregate traffic received on that SAP. This allows user to cap the traffic admitted into the system per SAP to the configured PIR rate and allows for bandwidth sharing among the FCs of the SAP when one or more of the FCs is not using its entire available (configured) bandwidth. For more information please refer the 7210 SAS-M QoS user guide for this release. Note: Policing is also referred to in 7210 user guides as metering. A new per FC policing algorithm based on RFC 4115 is introduced with this release. When a SAP aggregate policier is configured the per FC policier must be configured to use this.
IGMP SNOOPING ON SDP
With this enhancement in 7210 SAS-M, the system can process IGMP control protocol packets received over a pseudowire (both mesh and spoke SDPs). This allows the system to provide the following capabilities: Dynamically detect mrouter ports based on the IGMP queries received over a pushdown. Dynamically register/unregister multicast membership for IGMP joins/leaves received over a pseudowire. Apply IGMP filtering policies for IGMP control packets received over a pseudowire. Support IGMP fastleave processing for a pseudowire.
Page 64
Alcatel-Lucent
These capabilities are available only on pseudowire of type ethernet (that is, vc-type in CLI should be configured as 'vc-ether'). Pseudowire of type vlan (that is, vc-type in CLI configured as 'vc-vlan') require static configuration as in prior releases. PROCESSING OF IP
PACKETS RECEIVED OVER
MPLS
TUNNELS
(INTEROPERABILITY WITH CISCO)
Cisco devices by default use MPLS tunnel LSPs (a.k.a IGP shortcuts) for sending IP packets to a peer MPLS router when it is available. With this enhancement 7210 SAS-M can process IP packets received over MPLS tunnel LSPs. It can process both IP control protocol packets, Label Distribution Protocol (LDP) control packets, etc. and IP OAM packets, such as ping, etc. This allows the device to interoperate with Cisco device to establish LDP sessions and allow for transport of services.
RELEASE 2.0R2
SUPPORT FOR MICROSECOND TIMER GRANULARITY FOR OAM AND SAA TOOLS HARDWARE SUPPORT FOR ETHCFM
In earlier releases, the system could not compute and display packet round-trip times and packet delay for values less than 10millisecond. With this feature enhancement, from the current release, the system will compute and display packet round-trip times and packet delay for values less than 10 millisecond. Most of the OAM tools and SAA tools have been updated to provide display microsecond time intervals. With this release, the 7210 SAS-M uses the inherent capabilities of the hardware for CFM. Now, CFM CCM message protocol processing is handled in hardware, allowing use of CCM timers at 100ms time interval for down MEPs. SW based timestamps are used for Y.1731 delay measurements.
RELEASE 2.0R1
IMPROVEMENT IN FRR FAILOVER TIME
FRR failover time has been improved. With this enhancement FRR failover time is close to sub-50ms. This allows for increasing service availability in MPLS networks using this node. RSTP packets with one or more tags received on a null SAP or RSTP packets received with two or more tags on a Dot1q SAP or RSTP packets received with three or more tags on a QinQ SAP are forwarded in hardware. In prior releases, forwarding of such RSTP packets was done in software. Note that RSTP packets with null tag received on a null SAP or RSTP packets received with a single on Dot1q SAP or RSTP packets received with two tags on a QinQ SAP are processed locally, if STP is enabled. QinQ SAPs are supported only in 7210 SAS-E in this release.
RSTP FORWARDING IN HARDWARE
Alcatel-Lucent
Page 65
INCREASE IN SAP AND SERVICE SCALING
The number of SAPs and services available for use has been improved from the existing numbers. This allows the user to aggregate more number of services per node. The user is provided with an option to allocate QoS resources per SAP, according to service requirements and to balance this with service scaling requirements.
RELEASE 1.1R8
The following items describe enhancements added to 1.1.R8 of the 7210-SAS M OS. ETR PLATFORM Release R1.1R8 introduces a new platform, 7210 SAS-M 24F 2 XFP ETR, that supports an extended temperature range. The new platform is a variant of the 7210 SAS-M 24F. It is available in an ETSI-conforming chassis which is 1.5RU in height and 19-inch in width and supports an extended temperature range of -40C to +65C. Its a MPLS-capable switch and supports line-rate switching on all its ports. It supports 24 x 100/1000 SFP ports and 2 x 10G XFP ports and provides an additional expansion slot for future use. It requires the use of extended temperature range power supplies. It is feature compatible with 7210 SAS-M 24F 2XFP.
RELEASE 1.1R7
10G PLATFORM
This release supports a new platform, the 7210 SAS-M 24F 2XFP. This platform is a variant of the 7210 SAS-M 24F and supports an additional 2 x XFP ports, along with 24 x 100/1000 SFP ports. It is an MPLS switch/router capable of line-rate forwarding. It is feature compatible with the 7210 SAS-M 24F. Refer to the 7210-SAS-M OS Services Guide for relevant CLI commands. 7210 SAS-M and 7210 SAS-M 24F 2XFP platforms can accept and operate with a combination of AC and DC power supplies simultaneously. This feature provides a mechanism to disable service MTU validation in a service. This is required for interoperability with third-party devices. Service MTU Disable also allows the operator to work around the limitation (see Known Limitations on page 68) in 7210 SAS-M when service-mtu-check is enabled. Refer to the 7210-SAS-M OS Services Guide for relevant CLI commands. The 7210 SAS-M now supports Link Loss Forwarding in Epipe services. Link Loss forwarding enables fault propagation between the two endpoints of the Epipe service. The two endpoints in the Epipe service can be null SAPs or a null SAP and spoke SDP. Refer to the 7210-SAS-M OS Services Guide for relevant CLI commands. In R1.1R6, 7210 SAS M introduced IGMP snooping in a VPLS service support. 7210 SAS M supports IGMPv1 and IGMPv2. IGMP snooping allows the system to distribute
AC/DC POWER SUPPLIES SERVICE MTU DISABLE
LLF
IGMP SNOOPING
Page 66
Alcatel-Lucent
multicast streams to only interested receivers in a Layer 2/bridging domain. Refer to the 7210-SAS M OS Services Guide for relevant CLI commands.
Alcatel-Lucent
Page 67
KNOWN LIMITATIONS
With UP MEP, removing all lag member ports "defMacStatus" is not reported, "defRemoteCCM's" on both ends are reported. [136119] It is recommended to shutdown USB using CLI file shutdown uf1 before USB is physically removed from the system. If removed without shutdown, following error messages may appear. CONSOLE:PLATFORM:UMASS_BBB_Send_Command Bulk Transfer Failed UTC CRITICAL: LOGGER #2002 Base A:PLATFORM:UNUSUAL_ERROR It is recommended to shutdown 10 Gig MDA before physically removing it from 7210 SAS-M chassis. If 10 Gig MDA is removed without shutdown in some cases fixed 10 Gig ports 1/1/25 and 1/1/26 flap. [144816] BOF password configured by user gets reset in case 7210 rebooted with "boot.tim" version (prior to 4.0) which does not support BOF password. [145037] After 497 days, system up-time will wrap around due to the standard RFC 1213 MIB-II 32bit limit. 7210 SAS-M access-uplink mode, Vpls service with svc-sap-type as Any/Null-star the mac-learning will not happen when the packets are sent to ).* sap with the TPID not matching to QinQ-etype configured. The packets are taken for learning to the CPU but does not add the MAC to the fdb-table. [145962] On 7210 SAS, Implicit NULL (PHP) must be configured to use LDPoverRSVP tunnel. FRR support with LDPoRSVP or BGP 3107 will not be sub-50ms. For 3107 L2 services if BGP transport is LDP then LDPoRSVP is not supported, in such configuration sdp will remain down. LDP-over-RSVP transport is not supported for BGP SDPs (RFC 3107). SDPs configured in this manner will become operationally up but no traffic will be forwarded. [146172] Ospfv2/Ospfv3 would operationally go down on exceeding the FIB limit.[144137] SAS-M access-Uplink mode when port egress is mirror source , mirrored traffic would contain additional service internal tag. SAS-M access-Uplink mode in case of dot1q mirror destination, when sap ingress is mirror source and single priority tagged packet is mirrored, mirrored packet would not contain priority tag. All R-VPLS ies interfaces by default chassis mac is assigned, different mac can be configured using CLI interface <intf-name> mac.[139425] R-VPLS service not supported with *.* Saps. [140881] For R-VPLS service, mac address resolved by ARP is also learnt in L2 FDB table; hence ARP ages out upon FDB entry age out. In R-VPLS operational IP MTU is set to least of participating SAPs MTU. SAP MTU is Port MTU DLC header, wherein DLC header is 14 Bytes for NULL port, 18 Bytes for dot1q port and 22 Bytes for qinq port. [141391] Egress sap statistics not supported for VLAN range SAPS in SAS-M access-Uplink mode. SAS-M access-Uplink mode, Multicast data packets with ttl=1 are not forwarded in service when MVR is configured. [143559]
Page 68
Alcatel-Lucent
For epipe service of "svc-sap-type qinq-inner-tag-preserve", the priority of the first tag in the packet egressing will always be 0 unless remarking is enabled. For epipe service of "svc-sap-type qinq-inner-tag-preserve", Ingress and Egress IP classification and filter will not work if more than 2 tags are received. CLI file dir does not start to list when number files are more than 700+ files on flash cf1 When a SAP has UP MEP configured on it, the CFM frames would use the forwarding path of the service. This causes the Ingress Stats of SAP Statistics to increment when UP MEP sends packets. These packets are also counted in Ingress Drop Stats, if SAPs statistics ingress counter-mode set to default that is, in-out-profile-count. [141370] STP BPDUs received on uplink sap hits the unicast meter instead of multi-point meter.[128453] IGMP snooping is not supported for control word enabled SDP in vpls service. When continuos traffic is flowing through sap, "Ingress Drop Stats" may not display proper results if sap "statistics ingress counter-mode" is "in-out-profile-count". When the BGP routes fails to get installed due FIB is full, BGP Peer goes operationally down. Traffic that hits a blackhole route in a VPRN Service, would not get accounted under filter statistics.[125527] Source BMAC, B-SA learnt in B-VPLS service starts aging only after C-SA associated with B-SA are aged out in case of I-VPLS. In case of PBB-EPIPE, B-SA is not aged out once it is learnt. Fragmentation is not supported for IP Packets received on L3 SAP of vprn service [121145] PBB I-tag etype is not configurable, Its value is 0x88e7 PBB B-Tag etype is not configurable Its value is 0x8100 TTL=1 and ARP packets are not accounted in a vprn L3 SAP Statistics. Ethernet ports that use dual-rate fiber SFPs cannot participate in a Synchronous Ethernet Network. Applying the command "debug sync-if-timing" on a second qualified reference has no effect. SyncE Reference switch is based on LOS and not based on signal degradation. IP packets with options are not forwarded received on L3 SAP and Network IP interface. A maximum of 15 network QoS policies of type ip-interface with unique mapping of FC to EXP values can be created, and these policies must be shared among 32 IP interfaces. In cpipe service of type CESoPSN, if the port is configured for ACR then channel group #1 must be configured in a service and must be operationally up. Channel group #1 is used as the master tributary for deriving adaptive clock using ACR. QinQ access port configured with non-default qinq etype, that is, other than 0x8100, traffic sent on sap 0.* dropped if etype is 0x8100. This limitation is applicable to SAS-M in access-uplink mode. LSR PHP Node copies the tunnel label exp values to single vc-label packets destined to Egress LER but doesn't remark vc-label exp values.[108939]
Alcatel-Lucent
Page 69
7210 SAS-M does not display the remote MEP's MAC address in the display output of the CLI show command "show eth-cfm mep mep-id domain md-id association (ma-id) allremote-mepids" The show eth-cfm mep mep-id domain md-id association ma-id command would not display Last CCM Rx-Time, Last CCM Seq Number, CCM Tx Count. ETH-CFM CCM Sequence Check for out-of-sequence CCMs and Last CCM Sequence Number tracking is not done for received CCMs. ETH-CFM CCMs with incorrect DMAC are not dropped by hardware. ETH-CFM CCMs transmitted will always have the Sequence Number as zero. ETH-CFM CCMs with invalid Data TLV-s, Invalid Port/Interface TLV-s do not cause CCM Errors Under a high CPU load, ETH CFM defect reporting and clearing may be delayed. On access ports, protocol packets of EFM, LACP, Dot1x, and DWL are counted as part of SAP statistics if NULL SAP, Dot1q Explicit NULL SAP, or Dot1q Default SAP is configured on an access port. [95361] FRR failover time for unlearned traffic (such as broadcast, unknown-unicast, and multicast traffic types) will not be under sub-50ms. In a VPLS service, when IGMP snooping is enabled, the multicast replication is based on Layer 2 MAC addresses when SAS-M is in network mode. IGMPv3 is not supported when SAS-M is configured in network mode. In VPLS and VLL services, port MTU checks are performed only at the ingress. [92910] With service-mtu-check disabled, a null SAP allows 4 bytes more than the port MTU for tagged traffic (excluding FCS); a dot1q SAP allows 8 bytes more than the port MTU for tagged traffic (excluding FCS); and a dot1q-star SAP allows 4 bytes more than the port MTU for un-tagged traffic and 8 bytes more than the port MTU for tagged traffic (excluding FCS). If single -tagged multicast packets arrive on a null SAP belonging to a VPLS service with IGMP snooping enabled, they are forwarded based on the MFIB if the entry is present, else they are dropped. The same is applicable for double-tagged multicast packets arriving on a Dot1q SAP. [87551]
IGMP v2 leaves are sent upstream when V1 reports expire. [88271] IGMP Snooping on sdp with vc type "vc-vlan" requires static configuration. When packets are received on a Dot1q SAP, the incoming packet length (frame length along with the length of the encapsulation tag) is used to match against the service MTU configured. If the incoming packet length is greater than the service MTU configured, the packets are dropped. Therefore, while configuring the service MTU, one should account for the SAP encapsulation and spoke SDP VC-VLAN tags. [79679] Dual rate SFPs (3HE04116AA and 3HE04117AA) connected to GigE SFP require autonegotiation to be disabled to operate in 1G mode. [78737] SAP ingress meters (counters) are incremented for packets dropped by a filter on that SAP. [70878]
Page 70
Alcatel-Lucent
If the system IP address is not configured, RADIUS user authentication will not be attempted for in-band RADIUS servers unless a source address entry for RADIUS exists. SNMP access cannot be authorized for users by the RADIUS server. RADIUS can be used to authorize access to a user by FTP, console, or both. If the first server in the list cannot find a user the server will reject the authentication attempt. In this case, the 7210 node does not query the next server in the RADIUS server list and denies access. If multiple RADIUS servers are used, the software assumes they all have the same user database. In an Epipe service, traffic is not switched if the source MAC is a multicast or broadcast address [71437] A service configured with 'svc-type any" and null-sap to null-sap allows packets up to 1514 including 4 byte FCS if port MTU is default value 1514. Workaround is to increase port MTU from default value of 1514. [116239] In SAS-M Access-Uplink mode, the system accepts packets with sizes exceeding the port MTU by 4 bytes as listed in below scenarios if egress port has proper MTU to transmit these extra bytes. 1522 byte (includes 4 byte FCS) single vlan tagged or 1526 byte (includes 4 byte FCS) double vlan tagged packets received on null sap is forwarded where ingress is null port and egress is dot1q/qinq port. 1526 byte (includes 4 byte FCS) double vlan tagged packet received on dot1q sap is forwarded where ingress port is dot1q and egress is qinq port.
The similar behavior is seen when SAS-M is in MPLS mode and service-mtu-check is disabled. [75221] A MAC will not age out as long as STP BPDUs from that source are received, although data traffic is not present. [71658] If the TACACS+ start-stop parameter option is enabled for accounting, every command will result with two commands in the accounting log. If TACACS+ is first in the authentication order and a TACACS+ server is reachable, the user will be authenticated for access. If the user is authenticated, the user can access the console and has the rights assigned to the default TACACS+ authenticated user template config>system>security>user-template tacplus_default. Unlike RADIUS, TACACS+ does not have fine granularity for authorization to define if the user has only console or FTP access. The 7210 SAS OS supports a default template for all TACACS+ authenticated users. If TACACS+ is first in the authentication order and the TACACS+ server is not reachable, the authorization for console access for the user is checked against the users local or RADIUS profile if configured. If the user is not authorized in the local/RADIUS profile, the user is not allowed to access the box. Note that inconsistencies can arise depending on certain combinations of local, RADIUS and TACACS+ configurations. For example, if the local profile restricts the user to only FTP access, the authentication order is TACACS+ before local, the TACACS+ server is up and the TACACS+ default user template allows console access, an authenticated TACACS+ user will be able to log into the console using the default user template because TACACS+ does not provide granularity in terms of granting FTP or console access. If the
Alcatel-Lucent
Page 71
TACACS+ server is down, the user will be denied access to the console as the local profile only authorizes FTP access. [39392] If a source-address entry is configured for in-band RADIUS servers, the source address (IP address) is used as the NAS IP address, otherwise the IP address of the system interface is used. default.cfg is a file name reserved by the system. Do not create a file with this name in the root directory. [76972] For a LAG configuration with more than one port, if a meter configuration does not specify a CBS value, some packets may be marked yellow and be treated accordingly when buffer management begins. The solution is to increase the CBS setting whenever the CIR configured for the meter is greater than 1Gbps. For a LAG with two ports, a CBS value of 64Kbits is recommended. [72497] In an ingress MAC filter policy, the etype and frame-type match criteria do not match packet fields in those packets received with more than one VLAN tag. [72839] MACs that are already learned do not age out after a filter is added to drop packets from those MACs. [73370] Packets with CRC errors are accounted for in the ingress meter calculations. [80966] Packets discarded as the result of a discard-unknown-source and discard-unknown configuration are accounted for in the ingress meter calculations. [84842] Meter buckets are re-initialized when the rate value is modified. Rate values are modified by explicitly changing the rate values using the appropriate CLI command or by changing the adaptation rule. [84395] In a spoke SDP with the control word configuration enabled, vccv-ping from the remote end does not return a response when the LSP is shutdown. [80905] Ethernet ports that use copper SFPs cannot participate in a Synchronous Ethernet Network.
Page 72
Alcatel-Lucent
KNOWN ISSUES
The following are specific technical issues and limitations that exist in Release 5.0R2 of 7210 SAS-M OS. The topics are arranged alphabetically. 10G MDA Ports used as "no-service-ports" in bof should not be used in configuration, else execution of configuration file errors out.[120103] 7210 SAS-M network mode, MAC filter assigned to egress sap fails to work for IPv4 traffic when "mac-ipv4-match-enable" set to 0, if it is non-zero then it works fine. config>system>res-prof>egr-internal-tcam>acl-sap-egr# info mac-ipv4-match-enable 0 mac-ipv6-64bit-match-enable 2 Similarly, MAC filter assigned to egress sap fails to work for IPv6 traffic when "mac-ipv664bit-match-enable" set to 0, , if it is non-zero then it works fine. config>system>res-prof>egr-internal-tcam>acl-sap-egr# info mac-ipv4-match-enable 2 mac-ipv6-64bit-match-enable 0 [149024] Time of day policies cannot be combined with IPv6 ACLs [136880] On SAP Ingress, if SAP-ingress QoS policy is having mac-criteria attached, then IPv6 ACL cannot be used on that SAP. This process can also be done contrariwise. [137396] IP filter match criteria option-present cannot be used to match packet fields for traffic on IES interfaces when SAS-M is in access-Uplink mode. [113272] If dot1q and * sap created on same port but belonging to different services, traffic matching dot1q sap hits the ingress filter attached to * sap only if no ingress filter attached to dot1q sap. This issue happens when SAS-M configured in network, that is, mpls mode [109037]. When Q1.Q2 and Q1.* sap are configured on the same port, traffic sent with Q1.Q2 tag hits ingress filter attached to Q1.* sap. This issue happens when SAS-M configured in network, that is, mpls mode [109133] Egress Filter counters does not work for IES service when SAS-M is in access-Uplink mode, however, ACL functionality works fine. [10813] An IP filter applied at SAP ingress to filter IGMP packets does not work. [89256] A filter entry action value configured as action should force the filter to pick up the default action configured for the filter. This does not work. It is recommended to explicitly configure the action for each filter entry. [76620] CESoPSN with CAS signaling is not supported in this release. [107704] Commands executed quickly after provisioning a T1/E1 MDA would get delayed response due to the MDA initialization (given that the commands needed IOM/MDA routines to be called such as show port). [94277] SAP ingress statistics in a CPIPE service does not increment when LOS is reported on a DS1/E1 port. [98828]
ACLS
CES
Alcatel-Lucent
Page 73
Provisioning m24-100fx-1gb-sfp MDA (which is pre-provisioned as MDA1) on MDA2 can lead to undesired behavior especially when a CES card is installed in the MDA 2 slot. [97786] TDM ports cannot participate in a split horizon group (although it is user configurable). It is not a supported feature. [101695] The execution of configuration file saved with CLI 'admin save detail' errors out. It is recommended not to save configuration using "admin save detail". There are some unsupported CLI and CLI options displayed in the CLI command set. Some of the show, monitor, and tools CLI command output displays unsupported fields and modules. The output of the tools dump command is not aligned properly when issued from a Telnet session. [76876] In the Telnet session, the output for tools dump is not properly displayed. [80661] 7210 SAS does not support Sub Second hello timer for VRRP Disabling Ospf under Management Routing Instance brings down the Ospf Neighbors in Base Routing instance. [106441] The CLI commands under the context config>router for the management routinginstance are not supported. [101636] Sometimes Packet failed authFailure authentication messages are seen on OSPF MD5enabled interfaces. They are harmless. [90099] IP packets that need fragmentation are not forwarded. However, if the ARP is not resolved for the next-hop, only the first packet is fragmented and sent out as soon as the ARP is resolved. Only CPU-generated packets are fragmented. [76353] Performing an SNMP GET on an interface description may not return the correct description of that interface if the same CLI command was used to create the interface and its description (for example, configure router interface ifName description ifDesc). This is not an issue if the interface was created first, followed by the description. [65622] The show router interface command output incorrectly truncates the Port/SapId field for any interface when the string length of this field is more than 14 characters. [66751] 7210 SAS M does not support secondary IP interfaces. However, these are configurable through SNMP, and should be avoided. [76848]. The ping ip-address detail command should report the interface on which the ping reply was received. This information does not display in the output. [76887] SNMP query of the vRtrActiveArpEntries object does not return the correct value. The CLI reports the correct number of ARP entries. [80788] For older 7210-M and 7210-X nodes, 44 MAC addresses were allotted per node by manufacturing. Starting from release 5.0R1, when all of the 24 LAGs are configured the system assigns MAC addresses which is outside the range of 44 MAC addresses allotted to the node. The issue will be seen only in older nodes. Out of the total pool of 44 MAC addresses, 1 is allotted for Chassis MAC address, 1 for
CLI
IP
LAG
Page 74
Alcatel-Lucent
management port, one for each of the ports on the system and the rest is available for LAGs. Thus on 7210-M nodes, about 16 LAGs will have proper MAC addresses assigned, while the rest, which is about 9 LAGs, will be assigned MAC addresses that are outside the range and belongs to other 7210-M nodes which were manufactured with the next lot of 44 MAC addresses. Workaround: Users to assign the MAC addresses statically to LAG, for those which are above the range of MAC addresses assigned to the node. Note that, Base MAC address and number of MAC's assigned to node are printed on the rear side of 7210 chassis. [151308] When all of the traffic is egressing out of one port of a two-port LAG, the traffic switchover time onto the other port (due to a link down event) is higher compared to when traffic is shared between the two ports. [86060] If in a two-port LAG containing two sub-groups with one port each, a shutdown on the port belonging to the active sub-group will flap the LAG. This happens only if the LAG is associated with an IP interface. [85967] If there are NTP broadcast client configurations over the management routing-instance, and if the out of band eth-management port is disabled, on configuring an NTP server and removing it will remove the broadcast client configurations as well. [101255] If a source-address is configured for NTP, and if the system is rebooted with an older time set (using admin set-time), NTP takes a few iterations to synchronize for the first time. [86897] LACP flaps when starting an SSH server (no shutdown of SSH server). [75648] SNMP operations on some unsupported SNMP MIBs might succeed. There is currently no show command to display the current values of password hash settings. [32747] When logged in with the Telnet client supplied with Windows and issuing an SSH command to a remote server, an unexpected carriage return may be sent causing the SSH connection to fail. [50657] An asterisk * indicating an unsaved configuration change may not be displayed after changing some of the parameters under some contexts such as the system and log contexts, (for example, *A:ALU-7210>config>system or A:ALU-7210>config>log). Additionally, the Change Since Last Save field in the show system information command output may not be updated. [61271] The CLI allows the user to specify a TFTP location for the destination for the admin save and admin debug-save commands which will overwrite any existing file of the specified name. [18554] SNMP walk of vRtrConfEntry shows the vpls-management and management instance as active even though these are not currently supported. [76832] SNMP query of the following operational rates does not return the correct values. The value returned is 0. CLI reports correct operational values. [76853]. tAccessEgressQueueOperPIR tAccessEgressQueueOperCIR.
MANAGEMENT
Alcatel-Lucent
Page 75
If an ongoing FTP is aborted, the console and Telnet become unresponsive for a duration that depends on the size of the file being transferred. [76734, 74294] The 7210 SAS M does not support storing more than 500 events for log destinations memory and SNMP. Although the CLI and MIB allows up to 1024 to be configured, it is recommended not to exceed 500. Not all traffic would be mirrored on mirror dest port when mirror source is 10G LAG egress. [108957] Up to 25 SAPs can be ingress mirrored. [98026] Log events are not generated for mirror application. [72100] CPU-generated STP packets are not mirrored when port egress mirroring is enabled. [84200] Ingress QoS policies applied for forwarded traffic will also be reflected on its mirrored traffic. [73951] A small amount of traffic loss is seen for any MBB event for traffic sent at line rate with a configuration of 200 or more LSPs. [95811] In certain conditions, VPLS traffic may be affected due to a network LAG flap. This was seen only with LDP tunnels. [101142] The operational state of LDP will go down with the reason code IOM Failure if the number of /32 prefixes learnt go beyond 1000. [98085] The show router rsvp interface interface-name detail command displays incorrect Auth Rx Seq Num and Auth Tx Seq Num values. [86903] ETH-CFM is not supported with service of svctype qinq-inner-tag-preserve, but CLI is available for configuration. [150606] UP MEP doesnot converge if port qinq etype configured is other than 0x8100 and 0x9100. Local MEP shows "bDefRDICCM" and remote MEP goes in to "bDefRemoteCCM". [142892] It is not recommended to use fault-propagation when the service entities (e.g. SAP and SDP binding) are configured on a LAG. A LAG flap can result in CFM defect being raised which inturn results in a false fault propagation event. This issue is seen only when CCM timers of less than 10seconds are in use. This configuration is not blocked in CLI but it is highly recommended that users do not use fault propagation with LAG when using CCM timers of less than 10seconds. [150233] On PBB Epipe SAP, if the UP MEP is configured, it is recommended to enable CCM, with CCM disabled loopback, linktrace, DM, and SLM tests fails. [136751] In 7210 SAS-M configured in network mode, temporary data loop around 10-20 msec during revertive mode of 8032.[129307] When SAP in the parent MVPLS instance goes into STP blocked state, the associated SAP in the child VPLS instance is shut down. This prevents any packets from being generated in the host path. In 7210, CCM-s are hardware generated and hence the CCM state m/c works
MIRROR
MPLS
OAM
Page 76
Alcatel-Lucent
properly. However, the LB-s and LT-s, which are generated and processed in software, stops working.[109722] Eth-Cfm convergence fails when llf is enabled on the LAG SAP and Lag shut and no-shut is done, or box is admin saved and rebooted. Workaround: Remove and add back MEPs. [116513] For QinQ saps (q1.q2, q.* and 0.*), dot1ag loopback reply messages (LBR) will take the priority from configuration field ccm-ltm-priority (config=>service=>vpls=>sap=>ethcfm=>mep=>ccm-ltm-priority) instead of using the priority of corresponding Loopback message (LBM) received. Note that this is applicable only when box is in access-uplink mode. For network mode, LBR will have same priority as corresponding LBM.[109767] lsp-trace fails over bypass tunnel when the LER is the PLR in FRR Facility backup configuration. [109165] When FRR with facility backup kicks in and the merge point is the LSR with implicit null is 1 hop away, lsp-ping/trace does not work. [108025] The show eth-cfm mep mep-id domain md-id association ma-id command would not display CCM ERROR, CCM XCON frames in its output. The show eth-cfm mep mep-id domain md-id association ma-id remote-mep rmep-id command would not display some TLVs and details. ETH-CFM session on standby pseudowire does not come up in a VLL pseudowire redundancy configuration. [100594] ETH-CFM CCM/LTM priority is not correctly mapped to the EXP values when egressing out of SDPs. ETH-CFM RDI will not be generated for defMacStatus [98332] ETH-CFM defect is not reported on booting the 7210 with a configuration that has the ETH CFM session over a LAG with no member ports [100813] The probe-count option with value greater than 1 used in oam lsp-trace and oam vccvtrace will not send more than one echo-request. It works appropriately with SAA. [85119] ICMP pings with higher packet sizes sent at higher rates will fail. [77611] Under a heavy load condition, CFM/LACP may flap due to any of the following triggers [74223]: Executing a clear fdb or a show fdb command. Transferring large files using FTP onto the flash. Mac moves occur at a rate of approximately 40 macs/sec.
OAM DNS lookups do not work correctly unless the full DNS name is provided. [54239, 54689] For EFM OAM with timers less than the default values can result in EFM flaps due to events such as STP topology change, clearing FDB, or adding and removing ports to a LAG when CPU utilization is high, it is recommended to ensure enough CPU cycles when EFM configured with 100ms timer. [81218, 82228] For mac-ping and mac-trace when used with the fc and return-control options, do not use the egress queue as specified by the fc option. [82306]
Alcatel-Lucent
Page 77
Using mac-populate and mac-purge simultaneously on several VPLS services (for example, 64) could result in instability of the router. To avoid this anomaly, it is recommended to carry out this operation per VPLS service.[79690] For SAA tests for mac-trace, the result shows success for unknown MAC addresses. [81891] The timestamps are all 0s when cpe-ping is performed with SAA. [81726] Ingress qos resources are not getting freed up when the ingress qos policy is removed from the sap with tod-suite configured. [141896]. When SAS-M is LSR, on interface connected to PHP enabled LER, egress MPLS packets dot1p is remarked when the network port QoS policy remarking is not enabled. This issue is resolved, if PHP is not enabled on LER. [109868] PBB: Ingress classification on B-SAP using I-TAG PCP bits and egress remarking of ITAG PCP bits is not supported.[123642] Access-Egress policy enabled with dscp remarking will remark DSCP bits in data packets egressing out of L2 SAPs (vpls/epipe/i-vpls/b-vpls). It is recommended not to enable dscp remark for ports carrying L2 SAPs.[121134] When configuring network qos policy using snmp, it is recommended to first create policy specifying type of policy (ip-interface or port type) and then modify policy to set userdefined or default values of the policy.[123171] For vprn L3 SAP, per SAP egress remarking is not supported. It is recommended to use port based egress remarking. Operational values for some user configured values of ERL rate are incorrect in the show pool output of a port. [90549] L2PT tunneled STP packets do not have the appropriate MPLS EXP bits set. They are set to zero. [90580] SRTCM meter configured on 10Gig ports with the CBS value default and MBS value of 33547 or greater, the ingress metering is not correct. [89089] When a 10Gig port is congested, a small amount of excess traffic is sent out of the lower priority queues. The amount of excess traffic depends on the packet sizes. [89963, 89094, 89095] If a network QoS policy with classification based on match of a Dot1p value 0 is associated to a network port, which has IP interfaces using either a null or a dot1q:0 encapsulation, any untagged IP packet received on the network IP interface will get classified to the FC designated by this rule. The same behavior is applicable to a null SAP when it receives untagged packet. [98819] When remarking is enabled on access egress for a Dot1q port, the Dot1p bits in the customer tags get remarked when the traffic is sent out of a Dot1q default SAP or a NULL SAP. [86818] The workaround: In the case of a NULL SAP, remarking can be disabled to preserve the Dot1p bits.
QOS
Under a network port policy with Dot1p classification, traffic for classifiers with outprofile will be momentarily marked in-profile when some other classifier with profile in is changed to out. [85482]
Page 78
Alcatel-Lucent
With a slope policy, queue depths for queues 1 to 7 for a port do not get limited to maxaverage when the scheduler is in strict mode. [85063] The keyword max in the meter command configuration does not set the rate properly. The semantics of this keyword should set the metered rate to the maximum rate applicable to the interface over which the SAP attached to the meter is created. However, max sets the rate to 4Gbps. Use the applicable numeric value instead. [75845]. The maximum entry-id value for the IP/MAC-criteria in the SAP ingress policy context is restricted to 63 although the CLI allows up to 64. Entry-id 64 should not be specified. [76790/76964] In defining RADIUS Vendor Specific Attributes (VSAs), the TiMetra-Default-Action parameter is required even if the TiMetra-Cmd VSA is not used. [13449] When L2PT termination or BPDU translation is enabled on VPLS PW redundancy, STP BPDU packets are forwarded on both active and standby PWs. [150872] OAM mfib-ping utility displays information only for node where the mfib-ping is originated. [144449] Before configuring any port as "loopback-svc-port", it is recommended to remove configs applied on port like accouting policy, qos policy, LLDP and other configs. Otherwise system may crash and re-boot. [146632] In case of PBB BCB (B-SAP to BSAP) packet, C-SA (customer mac) is learned in ivpls service when ivpls isid matches transit packet's isid. Note: a small amount of C-SA (upto a maximum of few hundreds) are learnt and not all CSA are learnt. [129525]
RADIUS
SERVICES
"configure router bgp family" by default is set to "ipv4". It needs to be configured to "vpnipv4"for VPRN configuration.[122553] If sap is configured as static mrouter port, port loop back with mac swap does not work in unregistered multicast traffic. Unregistered multicast traffic being sent out of the SAP is not looped back but registered/learnt multicast is looped back.[130327] Max value that can be set for svcVRouterId snmp mib object is 66 for 7210 SAS-M pltform.[127090] When SAS-M is configured as PE, in igmp enabled vpls service if spoke sdp is blocked due to reception of standby bit from connected MTU and then moves to forwarding statel There would be multicast data traffic loss till the next set of query/report is received. [121470] "allow-directed-broadcast" is not supported for vprn L3 SAP interfaces.[122203] PBB-packets received on B-SAP forwarded to epipe SAP if B-SA MAC matches "backbone-dest-mac" configured in pbb-epipe service. Packets with other B-SA MAC are dropped. [113910] PBB packets with UCA (Use Customer Address) bit set are not forwarded.[113909] Default sap (:* sap) does not participate in igmp-snooping process. Igmp query sent on default sap is flooded to all the saps and not learned in MFIB. Igmp report sent on the default sap is dropped if there is no entry in the MFIB and follows MFIB if there are entries. Registered Multicast Data packets sent on default sap follows MFIB.
Alcatel-Lucent
Page 79
Un-Registered Multicast Data packets sent on default sap gets flooded in the service.[109045] Priority tagged packets received on 0.* sap may not forwarded if qinq etype for Access/Uplink Qinq port is set to non default value in SAS-M access-uplink mode.[108959] Ingress SDP statistics are accounted against the primary spoke SDP, even if traffic is received on other secondary spoke SDP. (93627). In a scaled setup with spoke SDPs configured as mrouter port multicast traffic for some services is not forwarded over some spokes when the LAG flaps. Remove and re-configure the mrouter port for the spoke SDP restores the traffic. [97851] IGMP packets sent out of a SAP or spoke SDP are not accounted in SAP or spoke SDP egress statistics. If they are received from a peer and forwarded out of a SAP or spoke SDP, they are accounted. [88332] In an IGMP snooping enabled VPLS service, if the IP interface is removed and added back, multicast traffic between spoke SDPs may not resume towards one or more spokes. The spoke SDPs mentioned here are configured for the Mrouter port. The work-around is to remove the static Mrouter configuration and add it back; or execute a shutdown command and a no shutdown command of the spoke SDPs. [91856] There may be a small amount of traffic flow between services when LSPs are removed and added back within a very short duration, or when the LSPs are cleared under a given SDP. [84963] Packets larger than port MTU are learned and are accounted for by rate limiters. However, they are dropped as expected. [73497] When all the member ports of a LAG are removed and added back, the stats for a SAP on that LAG, belonging to a VPLS or an Epipe service, is reset to zero [73439] Dot1p priority is not preserved for RSTP packets forwarded by the node (for example doubly tagged STP packets received on a SAP). The dot1p is remarked to 7. Additionally, these packets are not matched against egress filter policies. [71855/75921] A set of source MAC addresses are learned on a spoke SDP. If this traffic ceases to come onto this spoke SDP, and if the same traffic (the source MACs) is received on another spoke SDP that is in STP discarding state, then the MACs do not age out. [77996] Changing the fdb-table-size on multiple services simultaneously (for example, by a script) may affect MAC learning in some services. [82362] Accounting statistics for a spoke SDP in a VPLS service show extra egress packets when the destination to which the traffic stream is being sent is already learned, but actual packets on the wire are correct. The percentage of error depends upon the packet sizes, FDB size, rate of traffic and the duration of the traffic. [81608/94306] Attaching accounting-policy on SAS-M L2 Uplink SAP is not supported and should not be configured, however CLI commands exists.[111897] LACP and CFM protocol packets are not shown in the output packets column of the show lag lag-id statistics command. [77986] RSTP convergence fails if force-vlan-vc is enabled on a mesh SDP. [94928]
STATISTICS/ ACCOUNTING
STP
Page 80
Alcatel-Lucent
If 7210 SAS-Ms are connected in a ring topology with LAG configuration and FRR, when ring is broken, STP flaps for some service is observed.[95969] If an ingress CPU forwarded RSTP/L2PT/PVST packet rate exceeds 128kbps on access, 265kbps on network, RSTP flaps. [73189] If a large number of MAC addresses exists in the VPLS FDB and the entire FDB is flushed and relearned, there may be a period of when RSTP BPDUs are not sent. A partial workaround is to configure fdb-table-size limits. [40532] 7210 SAS-M with 10 Gig port as mirror destination port, 1588 PTP packets are not getting mirrored. [150308] It is recommended to configure 7210 node in network such that 7210 receives 1588 packets directly instead of receiving through TC node. [150309] "IEEE 1588/PTP Clock Recovery Event Statistics" of CLI "show system ptp statistics" gets reset after PTP shut/no shut. [150062] With PTP configured, it is not recommended to remove system IP, this can result PTP flaps. If system IP is shutdown when PTP uses system IP as source, the PTP sessions continue to use the system IP. [143255] On a 7210 node which is acting as a PTP BC clock, users must ensure that NC queue is not congested and sufficient bandwdith is available for sending out PTP packets without any loss. In the current release, PTP packet loss is not handled correctly due to which the PTP slave cannot recover the clock correctly. [147414] When SSM clock quality selection is enabled, clock references are selected based on clock quality if revertive mode is configured. [111524] During AutoInit using DHCP, it is recommended to store proper bof, config files in defined location. In lab scenario, it is observed that, through dhcp if 7210 SAS fethes ip address, but bof or config file is not stored in defined location, after several dhcp request or replies, dhcp starts failing. A reboot of 7210 SAS is required to recover from dhcp failures.[131915] Internal loopback of port does not work when loopbacked port speed is set to 100Mb and autoneg is turned off.[113995] 10Gig XFPs with the part code SXP3100SX-A8 is not functional on the 7210. [104832] In a scaled configuration with STP enabled, when on an event (such as a network LAG flap) causes an enormous amount of traps sent out of the 7210, STP may flap. [95969] 10Gig alarms, no-frame-lock and high-ber, are not supported on the 7210 although they are configurable. The configure port port-id ethernet report-alarm command option no-frame-lock or high-ber are allowed to be configured but they are not supported. This command is applicable only for 10G ports. In loaded CPU conditions and scaled configurations, CPU spikes may cause STP to flap. This was seen in one condition when CPU spiked due to link down event and was processing 16K OSPF routes. [84889]
TIMING
SYSTEM
Alcatel-Lucent
Page 81
In loaded CPU conditions and scaled configurations, CPU spikes may cause LAGs to flap. This was seen under the following events: Addition and deletion of an OSPF interface in non-backbone area. [84537] Addition and deletion of port (or LAG port) to ip-interface. [84165/86007] Enabling an SSH server. [84166] The workaround or to lessen the chances of flaps occurring in this case, it is suggested to enable the preserve-key option before enabling SSH.
A port LED may glow if a 1Gig fiber SFP is inserted (without connecting a cable) with 100Mbps speed configured. (Note: 100Mbps mode is not supported for 1Gig Fiber SFPs excepting dual-rate fiber SFPs and copper SFPs). [85620] Traffic drops are seen in line rate bi-directional conditions where BUM traffic contributes to greater than or equal to 50% of line rate. Traffic loss depends on packet size.[85380] In certain scenarios (such as Cu SFP connected to Fixed Cu), the show port command does not display the MDI/MDX value as expected. Functionality is not affected. [76765] In certain scenarios, traffic drops are seen during source learning when copper ports are operating in half duplex modes. Once learned, there are no other observed drops. [75875] When the show service fdb-mac command is executed through the console while the MDA is initializing (and when traffic is coming into the box), a software crash could occur. To avoid this anomaly, wait until the MDA is initialized and the ports are up before issuing the command. [74051] When the password aging option is enabled, the reference time is the time of the last boot, not the current time. The password expiry will also be reset on every reboot. [64581] The system time MIB object stiDateAndTime is the UTC time and should not include the time zone offset in SNMP get and set requests. [66553] During auto-config, if a DHCP relay packet for an unrelated DHCP session is received by the system, the system may be non-responsive. [76811]. Control protocols may flap when the file copy command is initiated, using FTP, from the system if the specified FTP server is not reachable. This happens under loaded CPU conditions. Before initiating the file copy command using FTP, verify that the FTP server is reachable. [76566]. Inserting and removing SFPs in rapid succession cause the following message to display on the CLI session. SFP/XFP Checksums do not match. If this message is seen, execute a shutdown command followed by a no shutdown command on the offending port to resolve the issue. [76935].
The system saves core dumps at the URL specified in the BOF, while coming up. Specifying a remote location as a core file destination has two issues. If a remote URL is specified, and if the uplinkA cannot be brought up, saving the core dump may not succeed, even if uplinkB is up. If uplinkAs BOF is configured to use DHCP, the IP address acquired by DHCP is not released by the system after saving the core file.
Thus, it is recommended to configure the core file destination to be the local flash (cf1). [76764, 76736].
Page 82
Alcatel-Lucent
During an auto-boot through DHCP when a ping-address is used in the BOF, the system may enter an inconsistent state during the ping-check phase. This was observed only once during which the user was viewing certain debug commands. [76858] When 1G fiber SFPs are configured with a 100Mbps speed may result in un-predictable behavior. Do not set the speed to 100Mbps for 1G fiber SFPs. [81948] For dual rate fiber SFPs to operate successfully, both sides should be configured with the correct speeds. [82194] When using 100FX SFPs, autonegotiation should be disabled. [99132] The number of files in the root directory is limited to 100. As a possible workaround, create a directory in the root directory to use to save/store files. [75227] Only one of the two port LEDs is used to indicate port status and link activity. If the LED is lit steady it indicates link up. If the LED is blinking it indicates link activity.
HARDWARE
Alcatel-Lucent
Page 83

930430sddsd02v5.0.r2 - v1 - 7210-Sas M Os 5.0r2 Software Release Notes

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

930430sddsd02v5.0.r2 - v1 - 7210-Sas M Os 5.0r2 Software Release Notes

Загружено:

Авторское право:

Доступные форматы

7210-SAS M OS 5.

0R2 JANUARY 7, 2013

7210-SAS M OS 5.0R2 SOFTWARE RELEASE NOTES

RELEASE NOTE ORGANIZATION

7210 SAS-M OS 5.0R2 Software Release Notes

SOFTWARE UPGRADE PROCEDURES

7210 SAS-M OS 5.0R2 Software Release Notes

7210 SAS-M OS 5.0R2 Software Release Notes

UPGRADE FROM PRIOR RELEASES

NON SUPPORTED CLI

7210 SAS-M OS 5.0R2 Software Release Notes

7210 SAS-M OS 5.0R2 Software Release Notes

7210 SAS-M OS 5.0R2 Software Release Notes

7210 SAS-M OS 5.0R2 Software Release Notes

7210 SAS-M OS 5.0R2 Software Release Notes

7210 SAS-M OS 5.0R2 Software Release Notes

7210 SAS-M OS 5.0R2 Software Release Notes

7210 SAS-M OS 5.0R2 Software Release Notes

7210 SAS-M OS 5.0R2 Software Release Notes

7210 SAS-M OS 5.0R2 Software Release Notes

7210 SAS-M OS 5.0R2 Software Release Notes

7210 SAS-M OS 5.0R2 Software Release Notes

7210 SAS-M OS 5.0R2 Software Release Notes

sysObjectID returns correct value of "timetraSASModel7210SASM24F2XPETRReg". [113829]

7210 SAS-M OS 5.0R2 Software Release Notes

7210 SAS-M OS 5.0R2 Software Release Notes

7210 SAS-M OS 5.0R2 Software Release Notes

7210 SAS-M OS 5.0R2 Software Release Notes

7210 SAS-M OS 5.0R2 Software Release Notes

7210 SAS-M OS 5.0R2 Software Release Notes

7210 SAS-M OS 5.0R2 Software Release Notes

UP MEP SUPPORT FOR 7210 SAS-M ACCESS-UPLINK

7210 SAS-M OS 5.0R2 Software Release Notes

Recommendations on PTP packet rates for 7210 platforms:

7210 SAS-M OS 5.0R2 Software Release Notes

Following are some of the restrictions:

7210 SAS-M OS 5.0R2 Software Release Notes

7210 SAS-M OS 5.0R2 Software Release Notes

IES SERVICES (IPV4 ONLY)

VRRP (IPV4 ONLY)

ROUTED VPLS (RVPLS)

7210 SAS-M OS 5.0R2 Software Release Notes

VLAN RANGES FOR VLL SAP

PTP IEEE 1588 (BETA ONLY)

7210 SAS-M OS 5.0R2 Software Release Notes

IPV6 FOR NETWORK PORT ON M/X (NETWORK MODE)

IES IPV6 INTERFACE

IPV4/IPV6 SAP INGRESS QOS

7210 SAS-M OS 5.0R2 Software Release Notes

7210 SAS-M OS 5.0R2 Software Release Notes

QINQ SAP IN EPIPE

RELEASE 4.0R7 RELEASE 4.0R6

7210 SAS-M OS 5.0R2 Software Release Notes

7210 SAS-M OS 5.0R2 Software Release Notes

SAA FOR CFM/Y.1731

MULTICAST VLAN REGISTRATION (MVR)

7210 SAS-M OS 5.0R2 Software Release Notes

G.8032-MULTI CHASSIS SUPPORT ON SAS-M ACCESSUPLINK

7210 SAS-M OS 5.0R2 Software Release Notes

Default version for eth-ring is v2.

7210 SAS-M OS 5.0R2 Software Release Notes

- PE-CE routing protocol -

- MPLS LSP for VRPN data forwarding -