COMMAND DESCRIPTION     11/190 82-CRA 119 1170/1-V1 Uen B

Commands: lj through mo

Copyright

© Ericsson AB 2009–2010. All rights reserved. No part of this document may be reproduced in any form without the written permission of the copyright owner.

Disclaimer

The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.

Trademark List

Contents

1   Command Descriptions

Commands starting with “lj” through “mo” are included.

1.1   llc-xid-processing

1.1.1   Purpose

Enables the SmartEdge router to detect the access interface change of a mobile node (MN) based on logical link control (LLC) exchange ID (XID) messages received on a circuit.

1.1.2   Command Mode

• FA configuration

1.1.3   Syntax Description

This command has no keywords or arguments.

1.1.4   Default

The detection of access interface changes of a MN based on LLC XID messages received on a circuit is enabled.

1.1.5   Usage Guidelines

Use the llc-xid-processing command to enable SmartEdge router to detect the access interface changes of a MN based on LLC XID messages received on a circuit.

When XID is enabled, the SmartEdge router uses the received LLC XID frame to change the access interface and circuit associated with the MN and transmits traffic to the MN over the new circuit. This feature allows for a quick traffic switchover if the relocation of an MN remains in the same FA instance.

If you disable XID, the SmartEdge router must process a Mobile IP registration message on the new interface before the MN can be moved to a new access interface.

Use the no form of this command to disable LLC XID message processing.

1.1.6   Examples

The following example disables LLC XID message processing:

[local]Redback(config)#context fa

[local]Redback(config-ctx)#router mobile-ip

[local]Redback(config-mip)#foreign-agent

[local]Redback(config-mip-fa)#no llc-xid-processing

1.2   lns card

1.2.1   Purpose

Configures slot redundancy for Layer 2 Tunneling Protocol (L2TP) sessions.

1.2.2   Command Mode

• L2TP peer configuration

1.2.3   Syntax Description

1.2.4   Default

The default algorithm is route, and if multiple traffic cards are available, sessions are load balanced between them (equal preference for all cards).

1.2.5   Usage Guidelines

Use the lns card command to configure slot redundancy for L2TP sessions between the SmartEdge router and an L2TP access concentrator (LAC). You enter this command to first select the algorithm by which a traffic card is selected to carry L2TP subscriber sessions; you enter it again one or more times to specify the traffic cards that can carry L2TP subscriber sessions. You must specify the lns-only keyword with the function command in L2TP peer configuration mode for this peer before entering this command.

The route algorithm establishes the traffic card with the route to the LAC as the preferred traffic card without explicitly specifying it. This algorithm allows you to establish the preference of one traffic card over all others when its slot is not known. The priority algorithm fixes the traffic card preferences based on an explicit configuration statement. If you specify the priority keyword, you must identify all the traffic cards on which L2TP sessions are to be carried.

The values that you specify for the preference argument are relative to each other and can be any integer: a smaller number has a higher preference. Cards with equal preference numbers are load balanced.

You must configure the traffic cards using the card command (in global configuration mode) prior to configuring slot redundancy for them. Sessions are not assigned to unconfigured traffic cards.

To display the status of slot redundancy, use the show l2tp global command in any mode with the ipc keyword.

Use the no or default form of this command to specify the default algorithm and traffic card preferences.

Note:  

The maximum number of sessions that a traffic card can carry is not configurable and depends on the amount of memory in each traffic card.

1.2.6   Examples

The following example shows how to enable slot redundancy by load balancing the sessions between the traffic cards in slots 10 and 11, using the priority algorithm and equal preferences:

[local]Redback(config-l2tp)#lns card selection priority

[local]Redback(config-l2tp)#lns card 10 preference 10

[local]Redback(config-l2tp)#lns card 11 preference 10

The following example shows how to enable slot redundancy using the route algorithm; the traffic card with the route to a LAC is the preferred traffic card, and then, when that traffic card reaches its maximum number of circuits, sessions are apportioned between the traffic cards in slots 1, 2, and 3, with card 1 having the highest preference and card 3 having the lowest preference. The traffic card with the route, whatever its slot, always has the highest priority:

[local]Redback(config-l2tp)#lns card selection route

[local]Redback(config-l2tp)#lns card 1 preference 10

[local]Redback(config-l2tp)#lns card 2 preference 20

[local]Redback(config-l2tp)#lns card 3 preference 30

1.3   local-address

1.3.1   Purpose

Specifies the interface for the home agent (HA) local address used by remote foreign agent (FA) peers for this HA instance.

1.3.2   Command Mode

• HA configuration

1.3.3   Syntax Description

1.3.4   Default

None

1.3.5   Usage Guidelines

Use the local-address command to specify the interface for the HA local address used by FA peers for this HA instance. Enter this command multiple times to specify multiple HA interfaces. This command specifies an existing interface as the HA interface; you must first create that interface using the interface command in context configuration mode.

Use the no form of this command to remove the HA local address.

1.3.6   Examples

The following example creates the local address interface in a context called ha and specifies it as the local address interface for the HA instance:

[local]Redback(config)#context ha 

[local]Redback(config-ctx)#interface ha

[local]Redback(config-if)#ip address 10.1.1.2/16

[local]Redback(config-if)#exit

[local]Redback(config-ctx)#router mobile-ip

[local]Redback(config-mip)#home-agent

[local]Redback(config-ha)#local-address ha

1.4   local-as

1.4.1   Purpose

Configures the autonomous system number (ASN) that the Border Gateway Protocol (BGP) routing process uses to peer with the specified external BGP (eBGP) neighbor.

1.4.2   Command Mode

BGP neighbor configuration

1.4.3   Syntax Description

1.4.4   Default

None

1.4.5   Usage Guidelines

Use the local-as command to specify the ASN that the BGP routing process uses to peer with the specified eBGP neighbor. Under most circumstances, the BGP routing process peers with neighbors that use the same ASN, which is configured through the router bgp command in context configuration mode. The local-as command allows the configuration of a different ASN to be used with the specified eBGP neighbor.

Use the no form of this command to remove the local ASN.

1.4.6   Examples

The following example configures an ASN of 100 for the SmartEdge router. The SmartEdge router peers with the neighbors at IP address, 102.210.210.1, and IP address, 103.220.220.3, using ASN 100. However, it peers with the neighbor at IP address, 68.68.68.68, using ASN 200:

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

[local]Redback(config-bgp)#neighbor 102.210.210.1 external

[local]Redback(config-bgp-neighbor)#remote-as 500

[local]Redback(config-bgp-neighbor)#address-family ipv4 unicast

[local]Redback(config-bgp-peer-af)#exit

[local]Redback(config-bgp-neighbor)#exit

[local]Redback(config-bgp)#neighbor 103.220.220.3 external

[local]Redback(config-bgp-neighbor)#remote-as 500

[local]Redback(config-bgp-neighbor)#address-family ipv4 unicast

[local]Redback(config-bgp-peer-af)#exit

[local]Redback(config-bgp-neighbor)#exit

[local]Redback(config-bgp)#neighbor 68.68.68.68 external

[local]Redback(config-bgp-neighbor)#remote-as 400

[local]Redback(config-bgp-neighbor)#local-as 200

[local]Redback(config-bgp-neighbor)#address-family ipv4 unicast

1.5   localdir

1.5.1   Purpose

Specifies the local directory on the SmartEdge router where bulkstats data for this policy is stored.

1.5.2   Command Mode

bulkstats configuration

1.5.3   Syntax Description

1.5.4   Default

None

1.5.5   Usage Guidelines

Use the localdir command to specify the local directory where bulkstats collection files for this policy are stored.

You must first create a local directory using the mkdir command (in exec mode) before you enable bulkstats collection. For more information on the mkdir command, see the Command List. You can specify a directory on the local file system (/flash) or the mass-storage device (/md). (The mass-storage device is preferable due to faster write speed.) You can limit the space allowed for bulkstats storage with the limit command.

You cannot change the local directory while bulkstats collection is enabled; you must first disable bulkstats collection for this policy using the collection command in bulkstats configuration mode and then re-enable bulkstats collection after entering the localdir command.

Use the no form of this command to remove the configuration of the current local directory used to store bulkstats data for this policy. You should disable bulkstats collection for the policy using the collection command in bulkstats configuration mode before you delete the configuration.

1.5.6   Examples

The following example stores bulkstats collection files for the policy, bulk, in the /md/blksts directory:

[local]Redback(config)#context local

[local]Redback(config-ctx)#bulkstats policy bulk

[local]Redback(config-bulkstats)#localdir /md/blksts

1.6   local-mode

1.6.1   Purpose

Sets the local mode of operation for the neighbor connection.

1.6.2   Command Mode

VPLS profile neighbor configuration

1.6.3   Syntax Description

1.6.4   Default

The PE-rs mode is set.

1.6.5   Usage Guidelines

Use the local-mode command to set the local mode of operation for the neighbor connection. This command applies only if a spoke connection type is configured for the neighbor. With a spoke connection type, one end of the connection must be set to MTU-s mode and the other must be set to PE-rs mode.

Note:  

For proper VPLS operation, ensure that the local mode at both ends is set correctly.

Use the no or default form of this command to return the local mode of operation to PE-rs.

1.6.6   Examples

The following example sets the local mode to mtu-s:

[local]Redback#config

[local]Redback(config)#vpls profile foo

[local]Redback(config-vpls-profile)#neighbor 10.10.10.1

[local]Redback(config-vpls-profile-neighbor)#local-mode mtu-s

[local]Redback(config-vpls-profile-neighbor)#

1.7   local-name

1.7.1   Purpose

Creates a local name for the SmartEdge router, to be used in outbound Start-Control-Connection-Request (SCCRQ) or Start-Control-Connection-Reply (SCCRP) control messages to an Layer 2 Tunneling Protocol (L2TP) peer.

1.7.2   Command Mode

• L2TP peer configuration

1.7.3   Syntax Description

1.7.4   Default

The system hostname, as specified by the system hostname command in global configuration mode, is used as the local name.

1.7.5   Usage Guidelines

Use the local-name command to create a local name for the SmartEdge router. Usually, the system hostname is used as the local name for the SmartEdge router.

You can create a different local name for the SmartEdge router for each tunnel that you configure, but the names must be unique.

The local-name argument is sent in the SCCRQ message when initializing the tunnel.

Use the no or default form of this command to specify the default local name. To change a local name, create a new one and it overwrites the existing one.

1.7.6   Examples

The following example shows how to specify the local name, cardinal:

[local]Redback(config-ctx)#l2tp-peer name peer1

[local]Redback(config-l2tp)#local-name cardinal

1.8   local-preference

1.8.1   Purpose

Configures the value of the local preference number, a value that is applied to Border Gateway Protocol (BGP) routes that do not have the local-preference attribute.

1.8.2   Command Mode

BGP router configuration

1.8.3   Syntax Description

1.8.4   Default

The default preference is 100.

1.8.5   Usage Guidelines

Use the local-preference command to configure the value of the local preference number.

Use the no form of this command to restore the default local preference value of 100.

1.8.6   Examples

The following example sets the preference to 300:

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

[local]Redback(config-bgp)#local-preference 300

1.9   local-protection

1.9.1   Purpose

Permits a label-switched path (LSP) to be protected by a bypass Resource Reservation Protocol (RSVP) LSP.

1.9.2   Command Mode

RSVP LSP configuration

1.9.3   Syntax Description

This command has no keywords or arguments.

1.9.4   Default

Local protection is permitted.

1.9.5   Usage Guidelines

Use the local-protection command to permit an LSP to be protected by a bypass RSVP LSP. When configured, the LSP advertises to the ingress and transit nodes that a bypass RSVP LSP can be used to provide Multiprotocol Label Switching (MPLS) fast reroute protection. This configuration will affect both ingress node and the transit nodes of the LSP operation.

Use the no form of this command to deny an LSP from being protected by a bypass RSVP LSP. Local protection can be denied for operational or resource issues.

1.9.6   Examples

The following example configures an RSVP LSP, to-r2-core, to deny MPLS fast reroute protection:

[local]Redback(config-ctx)#router rsvp

[local]Redback(config-rsvp)#lsp to-r2-core

[local]Redback(config-rsvp-lsp)#no local-protection

1.10   logging active

1.10.1   Purpose

Enables the logger to send logging and debug messages from the active controller card to the standby controller card.

1.10.2   Command Mode

• global configuration

1.10.3   Syntax Description

This command has no keywords or arguments.

1.10.4   Default

Logging and debug messages are sent to the standby controller card.

1.10.5   Usage Guidelines

Use the logging active command to enable the sending of logging and debug messages from the active controller card to the standby controller card.

Note:  

The SmartEdge 100 router does not support this command.

Note:  

If you do not specify the short keyword, the message is logged on the active controller card using the same severity as the original log message.

Use the no or default form of this command to disable the sending of logging and debug messages to the standby controller card.

1.10.6   Examples

The following example enables the sending of logging and debug messages to the standby controller card:

[local]Redback(config)#logging active

1.11   logging cct-valid

1.11.1   Purpose

Enables the filtering of debug messages for valid circuits only.

1.11.2   Command Mode

• global configuration

1.11.3   Syntax Description

This command has no keywords or arguments.

1.11.4   Default

Filtering of logging and debug messages for circuits is disabled.

1.11.5   Usage Guidelines

Use the logging cct-valid command to enable the filtering of debug messages for valid circuits only.

Use the no or default form of this command to disable the filtering of debug messages by circuit.

1.11.6   Examples

The following example enables the filtering of debug messages for valid circuits only:

[local]Redback(config)#logging cct-valid

1.12   logging console

1.12.1   Purpose

Enables event logging messages to the console.

1.12.2   Command Mode

context configuration

1.12.3   Syntax Description

This command has no keywords or arguments.

1.12.4   Default

Console logging for contexts other than local is disabled.

1.12.5   Usage Guidelines

Use the logging console command (in context configuration mode) to quickly isolate problems by displaying event log messages directly to the console rather than to a file. Messages sent to the console can be further constrained by using the logging filter command in context configuration mode to establish a logging filter.

Use the no form of this command to disable event logging to the console.

1.12.6   Examples

The following example enables event logging messages to the console:

[local]Redback(config-ctx)#logging console

1.13   logging debug

1.13.1   Purpose

Stores messages that have been generated by all enabled debug processes in the log buffer.

1.13.2   Command Mode

global configuration

1.13.3   Syntax Description

1.13.4   Default

Debugging messages are not stored in the log buffer.

1.13.5   Usage Guidelines

Use the logging debug command to store messages for all enabled debugging processes in the log buffer. Use the show log command in any mode to display the logged messages. Use the active keyword to configure the system to send debug events from the active to standby XCRP and the standby keyword to configure the system to send debug events from the standby to active XCRP.

The default and no forms of this command without keywords to revert to default behavior, where the system does not store debug messages in the log buffer.

After you enable the logging debug command, you can use no logging debug active or default logging debug active to stop sending debug messages from the active to standby XCRP, while still sending debug messages to the log buffer. Similarly, after you enable the logging debug command, you can use no logging debug standby or default logging debug standby to stop sending debug messages from the standby to the active XCRP, while still sending debug messages to the log buffer.

1.13.6   Examples

The following example enables the logging of debugging messages to the log buffer:

[local]Redback(config)#logging debug

The following example shows how to store messages for enabled debugging processes in the log buffer, send debug messages to standby to active XCRP, and stop sending debug messages from the active to standby XCRP.

[local]Redback(config)#logging debug
[local]Redback(config)#logging debug standby
[local]Redback(config)#no logging debug active

1.14   logging file

1.14.1   Purpose

Enables event logging messages to a file.

1.14.2   Command Mode

context configuration

1.14.3   Syntax Description

1.14.4   Default

If you do not use this command, events are not logged to a file. If you use this command without the optional text keyword, the file is saved in binary form.

1.14.5   Usage Guidelines

Use the logging file command to enable event logging messages to a file. You can also configure up to four log files per context.

Use the filename argument to specify the name and path of the logging file. If the full path is not specified, the file is saved to the /flash directory.

Use the show log command in any mode to display log files. For more information on the show log command, Command List.

Use the no form of this command to disable the enabling of event log messages to a file.

1.14.6   Examples

The following example enables the storing of event logs to a file, /flash/log_file:

[local]Redback(config-ctx)#logging file /flash/log_file 

1.15   logging filter

1.15.1   Purpose

Isolates events based on message severity in the logs and trims the flow of information.

1.15.2   Command Mode

context configuration

1.15.3   Syntax Description

1.15.4   Default

The default filter levels for the console, file, monitor, and syslog keywords are set to debug.

Table 1 describes the default input and output filter levels for each filter type.

1.15.5   Usage Guidelines

Use the logging filter command to isolate events based on certain severities in the logs and trim the flow of information.

Use the show logging command in any mode to display the configured filter levels for the current context. For more information on the show log command, see the Command List.

Use the default form of this command to set a logging filter back to its default level.

1.15.6   Examples

The following example modifies the severity level for several log facilities:

[local]Redback(config-ctx)#logging filter monitor error

The following example modifies the severity level for console:

[local]Redback(config-ctx)#logging filter console critical

1.16   logging standby

1.16.1   Purpose

Enables the logger to send logging and debug messages from the standby controller card to the active controller card.

1.16.2   Command Mode

• global configuration

1.16.3   Syntax Description

1.16.4   Default

Logging and debug messages are sent from the standby controller card to the active controller card.

1.16.5   Usage Guidelines

Use the logging standby command to enable the sending of logging and debug messages from the standby controller card to the active controller card.

Use the short keyword to display a message on the active controller card using a shorter, less verbose form.

Note:  

The SmartEdge 100 router does not support this command.

Note:  

If you do not specify the short keyword, the message is logged on the active controller card using the same severity as the original log message.

Use the no or default form of this command to disable the sending of logging and debug messages from the standby controller card to the active controller card.

1.16.6   Examples

The following example enables the sending of logging and debug messages to the standby controller card:

[local]Redback(config)#logging standby

1.17   logging syslog

1.17.1   Purpose

Enables the logging of system events to a remote syslog server that is reachable within the context.

1.17.2   Command Mode

• context configuration

1.17.3   Syntax Description

1.17.4   Default

System events logging is disabled.

1.17.5   Usage Guidelines

Use the logging syslog command to enable the logging of system events to a remote syslog server that is reachable within the context. The remote syslog server is identified by its IP address. You can also configure up to four syslog servers per context.

Use the no form of this command to disable the logging of system events to a remote syslog server.

1.17.6   Examples

The following example enables logging to a remote syslog server at IP address, 10.10.3.46, in the newworld context:

[local]Redback(config)#context newworld

[local]Redback(config-ctx)#logging syslog 10.10.3.46

The following example shows a configuration using a non-default syslog facility:

[local]Redback(config)#context gretzky 

[local]Redback(config-ctx)#logging syslog 1.2.3.4 local4

1.18   logging timestamp millisecond

1.18.1   Purpose

Enables the display of logged system event messages with a millisecond resolution timestamp.

1.18.2   Command Mode

• global configuration

1.18.3   Syntax Description

This command has no keywords or arguments.

1.18.4   Default

Millisecond resolution is disabled and is not displayed.

1.18.5   Usage Guidelines

Use the logging timestamp millisecond command to enable the display of logged system event messages with a millisecond resolution timestamp.

Use the no or default form of this command to disable the display of logged system event messages with millisecond resolution.

1.18.6   Examples

The following example enables the display of logged system event messages with millisecond resolution:

[local]Redback(config)#logging timestamp millisecond

The following example displays system event log messages when millisecond resolution is enabled:

Oct 21 03:44:47.697: [0001]: %ISIS-7-ADJ: sent PTPT IIH on inter-ctx intf black 
Oct 21 03:44:48.610: [0002]: %ISIS-7-ADJ: rcvd L2 LAN IIH from 001e.1000.0002 seq 16835 on inter-ctxintf bluefoo

1.19   log-neighbor-changes

1.19.1   Purpose

Configures the Border Gateway Protocol (BGP) routing process to log BGP neighbor resets.

1.19.2   Command Mode

BGP router configuration

1.19.3   Syntax Description

This command has no keywords or arguments.

1.19.4   Default

BGP neighbor resets are logged.

1.19.5   Usage Guidelines

Use the log-neighbor-changes command to configure the BGP routing process to log BGP neighbor resets. Frequent resets could indicate excessive packet loss or other network problems.

Use the no form of this command to ensure that resets are not logged.

1.19.6   Examples

The following example configures the BGP routing process so that BGP neighbor resets are not logged:

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

[local]Redback(config-bgp)#no log-neighbor-changes 

1.20   log-neighbor-up-down

1.20.1   Purpose

Logs an informational message when a neighbor transitions to or from the full adjacency state.

1.20.2   Command Mode

• OSPF router configuration
• OSPF3 router configuration

1.20.3   Syntax Description

This command has no keywords or arguments.

1.20.4   Default

Transitions are not logged.

1.20.5   Usage Guidelines

Use the log-neighbor-up-down command to log an informational message when a neighbor transitions to or from the full adjacency state.

Use the no form of this command to disable the logging of messages for neighbor transition events.

1.20.6   Examples

The following example logs neighbor transitions:

[local]Redback(config-ospf)#log-neighbor-up-down

1.21   log-lsp-up-down

1.21.1   Purpose

Enables the logging of RSVP-INFO messages when any Resource Reservation Protocol (RSVP) label-switched path (LSP) changes state.

1.21.2   Command Mode

RSVP router configuration

1.21.3   Syntax Description

This command has no keywords or arguments.

1.21.4   Default

RSVP-INFO messages are not logged.

1.21.5   Usage Guidelines

Use the log-lsp-up-down command to enable the logging of RSVP-INFO messages when any RSVP LSP changes state. The state can change from Up to Down, or from Down to Up.

Note:  

The generation of RSVP-INFO messages cannot be disabled using the no terminal monitor command.

Use the no form of this command to disable the logging of RSVP-INFO messages.

1.21.6   Examples

The following example enables the logging of RSVP-INFO messages when any RSVP LSP changes state:

[local]Redback(config-ctx)#router rsvp

[local]Redback(config-rsvp)#log-lsp-up-down

1.22   log-pw-up-down

1.22.1   Purpose

Logs the state of any XCs that have the specified L2VPN profile attached.

1.22.2   Command Mode

• L2VPN profile peer configuration

1.22.3   Syntax Description

This command has no keywords or arguments.

1.22.4   Default

The state of an XC is not logged.

1.22.5   Usage Guidelines

Use the log-pw-up-down command to log the state of any XCs that have the specified L2VPN profile attached.

A log is created each time an XC transitions to the down, up, and standby states. The logs are saved in the ex syslog file or in a user-specified log file.

Use the no form of this command to disable the state logging for any XCs attached to the specified L2VPN profile.

1.22.6   Examples

The following example shows how to enable state logging for any XCs that have the L2VPN profile called profile1 attached:

[local]Redback(config)#l2vpn profile profile1

[local]Redback(config-l2vpn-xc-profile)#peer 100.100.100.1

[local]Redback(config-l2vpn-xc-profile-peer)#log-pw-up-down

1.23   log-state-changes

1.23.1   Purpose

Enables the generation of a TUNNEL-INFO or GRE-INFO message each time the tunnel changes state (from up to down or down to up).

1.23.2   Command Mode

• tunnel configuration

1.23.3   Syntax Description

This command has no keywords or arguments.

1.23.4   Default

The generation of TUNNEL-INFO messages is disabled.

1.23.5   Usage Guidelines

Use the log-state-changes command to enable the generation of a message each time the tunnel changes state (from up to down or down to up).

Enables the generation of a TUNNEL-INFO or GRE-INFO message each time the tunnel changes state (from up to down or down to up).

To display the TUNNEL-INFO or GRE-INFO messages, enter the show log command (in any mode).

Note:  

You cannot disable the generation of TUNNEL-INFO or GRE-INFO messages with the no terminal monitor command (in exec mode).

Use the no form of this command to disable the generation of TUNNEL-INFO or GRE-INFO messages.

1.23.6   Examples

The following example shows how to enable the generation of a TUNNEL-INFO message each time the overlay tunnel, DenverTn1, in the local context changes state:

[local]Redback(config)#tunnel ipv6v4-manual DenverTnl

[local]Redback(config-tunnel)#log-state-changes

1.24   loopback (ATM, POS, Ethernet, WAN-PHY)

1.24.1   Purpose

1.24.2   Command Mode

• ATM DS-3 configuration
• ATM OC configuration
• port configuration

1.24.3   Syntax Description

1.24.4   Default

Port operation is in a normal state.

1.24.5   Usage Guidelines

Use the loopback command to change the operation of a port or channel to a loopback state.

Use the show port detail command (in any mode) to display the administrative state of the port. The Admin state field must be up to verify the remote link connectivity and quality with the remote keyword.

Note:  

This command is also described in Configuring Channels and Clear-Channel and Channelized Ports for channelized STM-1 ports.

Use the no form of this command to restore the port operation to a normal state.

1.24.6   Examples

The following example shows how to change the port operation of an ATM OC port to loop transmitted frames back to the receive line:

[local]Redback(config)#port atm 3/1
[local]Redback(config-atm-oc)#loopback internal

The following example shows how to change the port operation of an Ethernet port to a loopback state:

[local]Redback(config)#port ethernet 5/1
[local]Redback(config-port)#loopback

1.25   loopback (CFM)

1.25.1   Purpose

The no and default forms of this command specify that the maintenance points in the current maintenance domain (MD) not respond to loopback messages (LBMs).

1.25.2   Command Mode

CFM configuration

1.25.3   Syntax Description

This command has no keywords or arguments.

1.25.4   Default

Maintenance points respond to LBMs, unless disabled by this command.

1.25.5   Usage Guidelines

Use the no loopback or default loopback command to specify that the maintenance points in the current MD do not respond to LBM.

The no loopback or default loopback commands allow a MEP to initiate loopback messages and respond only to messages it initiates.

Use the loopback command to enable responses.

1.25.6   Examples

In the following example, the no loopback command disables responses to LBMs in the sbc CFM instance (sbc.com maintenance domain):

[local]Redback(config)#ethernet-cfm instance-1
[local]Redback(config-ether-cfm)#level 4
[local]Redback(config-ether-cfm)#no loopback

1.26   loopback (channels)

1.26.1   Purpose

Changes the operation of a DS-1 channel, DS-3 channel or port, E3 port, E1 channel or port, or channelized OC-12 or STM-1 port to a loopback state.

1.26.2   Command Mode

• DS-1 configuration
• DS-3 configuration
• E1 configuration
• E3 configuration
• port configuration
• STM-1 configuration

1.26.3   Syntax Description

1.26.4   Default

Port or channel operation is in a normal state.

1.26.5   Usage Guidelines

When you use the loopback command to change the operation of a DS-1 channel to a loopback state, follow these guidelines:

• For the network net-type construct:

  • Use the line keyword to loop all received bits (a full loopback) to the transmit line. The time slots (for DS-0 channels) must be set to the default (1–24).
  • Use the payload keyword to loop back only the received payload to the transmit line. The time slots (for DS-0 channels) must be set to the default (1–24).

• For the remote rem-type construct:

  • Use the line fdl ansi keywords to request the remote end, using the FDL, to loop back the bits transmitted by the local end. This option is available only if the DS-1 channel has ESF framing and its admin state is up.
  • Use the line fdl bellcore keywords to request the remote end, using the FDL, to loop back the bits transmitted by the local end. This option is available only if the DS-1 channel has ESF framing and its admin state is up.
  • Use the line inband keywords to request within the payload, that the remote end perform a full loopback. This option is available only if the admin state of the DS-1 channel is up.
  • Use the payload keyword to request that the remote end loop back only the payload. This option is available only if the DS-1 channel has ESF framing and its admin state is up.

    	Caution!
    Risk of data loss. To specify a different framing for a DS-1 channel, and the DS-1 channel is operating in a remote (line fdl ansi, line inband, or payload) loopback state, and the new framing is not compatible with the type of remote loopback that you have operating, the system terminates the remote loopback (change the DS-1 channel operation to a normal state) before changing the framing. To reduce the risk, postpone issuing the framing command until you are ready to terminate the remote loopback.

• After changing a DS-1 channel to the loopback state, you can use the bert command to perform a bit error rate test (BERT) to qualify the link.

When you use the loopback command to change the operation of a channelized or clear-channel DS-3 channel or port or E3 port to a loopback state, follow these guidelines:

• Use the line keyword to loop received frames back to the transmit line.
• Use the local keyword to loop transmitted frames back to the receive line without actually transmitting them.
• Use the remote keyword to verify remote link connectivity and quality at the DS-3 signal level. This option is available only if the DS-3 channel or port has C-bit framing and the admin state is up.
• After changing a DS-3 channel or port or E3 port to the loopback state, you can use the bert command to perform a bit error rate test (BERT) to qualify the links.

When you use the loopback command to change the operation of an E1 channel or port to a loopback state, follow these guidelines:

• Use the line keyword to loop received frames back to the transmit line.
• Use the local keyword to loop transmitted frames back to the receive line without actually transmitting them.

When you use the loopback command to change the operation of a channelized OC-12 or STM-1 port to a loopback state, follow these guidelines:

• Use the internal keyword to test the internal functions of the port.
• Use the line keyword to test the line operation.

Use the no form of this command to restore the port or channel operation to a normal state.

Note:  

This command is also described in Configuring ATM, Ethernet, and POS Ports for Packet over SONET/SDH (POS) and Asynchronous Transfer Mode (ATM) OC ports.

1.26.6   Examples

The following example shows how to change the channel operation of a DS-1 channel to a loopback state to verify remote link connectivity:

[local]Redback(config)#port ds1 3/1:1

[local]Redback(config-ds1)#loopback remote

The following example shows how to change the channel operation of a DS-3 channel 1 to a loopback state to verify remote link connectivity:

[local]Redback(config)#port ds3 3/1:1

[local]Redback(config-ds3)#loopback remote

The following example tests the internal functions of port 1 on the channelized E1 traffic card in slot 1 by looping the transmit line to the receive line:

[local]Redback(config)#port e1 1/1

[local]Redback(config-e1)#loopback line

The following example tests the line operation of the channelized STM-1 port 1 on the E1 traffic card in slot 1 by looping the receive line to the transmit line:

[local]Redback(config)#port channelized-stm1 1/1

[local]Redback(config-stm1)#loopback line

1.27   loop-detection

1.27.1   Purpose

In bridge configuration mode, enables or disables loop detection and blocking based on MAC moves. In bridge profile configuration mode, enables or disables configuration of loop detection priority applied to a circuit, port, pseudowire, or link group.

1.27.2   Command Mode

• bridge configuration
• bridge profile configuration

1.27.3   Syntax Description

This command has no keywords or arguments.

1.27.4   Default

In bridge configuration mode, detection of bridging loops using the MAC moves process is disabled. In bridge profile configuration mode, loop detection circuit priority is disabled.

1.27.5   Usage Guidelines

Use the loop-detection command (in bridge configuration mode) to enable loop detection based on MAC moves. Use the loop-detection command (in bridge profile configuration mode) to enable loop detection circuit priority.

This command does not interfere with the spanning-tree process of detecting bridging loops.

1.27.6   Examples

The following example shows how the loop-detection command (in bridge configuration mode) enables loop detection, and sets the loop detection interval attribute to 10 seconds:

[local]Redback(config)#context ink
[local]Redback(config-ctx)#bridge lbdl
[local]Redback(config-bridge)#loop-detection
[local]Redback(config-ld)#interval 10

In the following example, the loop-detection command (in bridge profile configuration mode) enables you to set the loop-detection priority for circuits associated with the bridge profile (plow) to the value 2:

[local]Redback(config)#bridge profile plow
[local]Redback(config-bridge-profile)#loop-detection
[local]Redback(config-bridge-profile-ld)#priority 2

1.28   lossless-large-mtu

1.28.1   Purpose

Enables guaranteed lossless flow control for jumbo frames (packet sizes 1,519 to 9,600 bytes) and specifies the port groups for which this capability is enabled.

1.28.2   Command Mode

card configuration

1.28.3   Syntax Description

1.28.4   Default

Guaranteed lossless flow control is not enabled for any port group.

1.28.5   Usage Guidelines

Use the lossless-large-mtu command to enable guaranteed lossless flow control for jumbo packets (packet sizes 1,519 to 9,600 bytes) and specify the port groups for which this capability is enabled. This command is available for Fast Ethernet-Gigabit Ethernet (FE-GE) 10/100 ports only.

Note:  

The GE ports on an FE-GE traffic card support lossless flow control for jumbo frames (packet sizes 1,519 to 9,600 bytes) without the use of this command.

FE ports are organized into port groups; each group has either six or eight member ports. When you configure a port group for guaranteed lossless flow control, two of the member ports are enabled; these ports are guaranteed to support lossless flow control for maximum transmission unit (MTU) sizes up to 9,600 bytes. The other ports in the group are shut down.

FE ports in groups that are not explicitly enabled by this command also support lossless flow control but only for oversized frames (MTU sizes to up to 2,000 bytes). You can specify larger MTUs (up to 9,600 bytes) for these ports, but lossless flow control is not guaranteed.

Use the all keyword to enable all port groups for guaranteed lossless flow control.

Note:  

If you enter this command more than once, each succeeding entry overwrites the data you previously entered. For example, if you have configured one or more port groups for lossless flow control and later configure other port groups using this command, you must also specify all the port groups that you previously configured.

Table 2 lists the ports that are members of each port group and the ports that are enabled or shut down for lossless flow control.

Use the no or default form of this command to disable lossless flow control for all port groups.

1.28.6   Examples

The following example shows how to configure port groups 1 and 2 for guaranteed lossless flow control. In this instance the command enables ports 49 and 53 (in group 1) and ports 37 and 57 (in group 2), and shuts down all the other ports (50 to 52, 54 to 56, 38 to 40, and 58 to 60) in those groups:

[local]Redback(config)#card fege-60-2-port 1
[local]Redback(config-card)#lossless-large-mtu port-group 1 2

1.29   lsp

1.29.1   Purpose

When entered in MPLS static router configuration mode, creates a static label-switched path (LSP), and enters MPLS static LSP configuration mode.

When entered in RSVP router configuration mode, creates an Resource Reservation Protocol (RSVP) LSP, and enters RSVP LSP configuration mode.

1.29.2   Command Mode

• MPLS static router configuration
• RSVP router configuration

1.29.3   Syntax Description

(1)  This construct is only available when configuring an RSVP LSP in RSVP LSP configuration mode.

1.29.4   Default

None

1.29.5   Usage Guidelines

Use the lsp command in MPLS static router configuration mode to create a static LSP, and enter MPLS static LSP configuration mode.

Use the lsp command in RSVP router configuration mode to create an RSVP LSP, and enter RSVP LSP configuration mode.

Use the backup-for lsp-name construct to create a backup RSVP LSP for a primary RSVP LSP, or for another backup RSVP LSP in a backup-to-backup LSP configuration. A backup RSVP LSP remains in hot standby, which means that it is always consuming resources and available for passing traffic. If RSVP signals that the primary RSVP LSP has gone down, the backup RSVP LSP immediately begins passing traffic. If that backup RSVP LSP goes down, then the RSVP LSP that backs up that backup RSVP LSP begins passing traffic.

Backup and backup-to-backup RSVP LSP tunnels are configured on a one-to-one, end-to-end path backup basis. Failover occurs in a hierarchy: if the primary LSP fails, traffic fails over to the backup LSP; if the backup LSP also fails, traffic fails over to the backup to the backup LSP. In both cases, failover is revertive: if the higher-order LSP becomes active again, traffic reverts to the higher-order LSP.

Switchover to the backup RSVP LSP occurs within 100 milliseconds (ms) after the primary LSP goes down.

The operating system also supports fast failover to a backup or backup-to-backup LSP when the ingress router fails.

Switchover to the backup LSP occurs within 100 milliseconds after one of the following errors is received by the LSP on the ingress router:

• RSVP Reservation Tear message
• RSVP Hello timeout

Switchover over to the backup LSP occurs within 50 ms if a link-down event at the ingress router causes a failure.

Use the bypass ip-addr construct to configure the RSVP LSP as a bypass LSP for NFRR link protection. A bypass LSP is no different from any other RSVP LSP, except that it does not carry traffic under normal conditions. It is configured to reach the next-hop router in the event of a link failure. Any type of traffic intended to use the next hop can be switched onto the bypass LSP.

Use the node-protect-lsp-egress ip-addr construct to use the bypass LSP for NFFR node protection. In the event of a link failure or a next-hop node failure, traffic is switched to the bypass LSP. If a bypass LSP is configured without enabling node protection, then the bypass LSP is used only for link protection.

Use the no form of this command to delete an LSP.

1.29.6   Examples

The following example configures the static LSP, sl10, to use the next-hop label-switched router (LSR), 192.168.1.24, the egress LSR, 192.168.100.2, and to set the outgoing label value to 3:

[local]Redback(config-ctx)#router mpls-static
[local]Redback(config-mpls-static)#lsp sl10
[local]Redback(config-mpls-static-lsp)#next-hop 192.168.1.24
[local]Redback(config-mpls-static-lsp)#egress 192.168.100.2
[local]Redback(config-mpls-static-lsp)#out-label 3

The following example configures the RSVP LSP, 12, to use the ingress LSR, 13.1.1.1, the egress LSR, 14.1.1.1, and the explicit route two as its source path:

[local]Redback(config-ctx)#router rsvp
[local]Redback(config-rsvp)#lsp 12
[local]Redback(config-rsvp-lsp)#ingress 13.1.1.1
[local]Redback(config-rsvp-lsp)#egress 14.1.1.2
[local]Redback(config-rsvp-lsp)#source-path two

The following example shows how to configure the RSVP LSP 12-bkup as a backup for the primary LSP 12 and the RSVP LSP 12-bkup2 as a backup for the backup RSVP LSP 12-bkup:

[local]Redback(config-ctx)#router rsvp
[local]Redback(config-rsvp)#lsp 12-bkup backup-for 12
[local]Redback(config-rsvp-lsp)#exit
[local]Redback(config-rsvp)#lsp 12-bkup-2 backup-for 12-bkup

The following example configures the RSVP LSP, to-r2-core, as a bypass LSP for link protection:

[local]Redback(config-ctx)#router rsvp
[local]Redback(config-rsvp)#lsp to-r2-core bypass 10.1.1.1
[local]Redback(config-rsvp-lsp)#egress 192.168.1.1

1.30   lsp block-flooding

1.30.1   Purpose

Prevents intermediate link-state protocol data units (LSPs) from being flooded out through the Intermediate System-to-Intermediate System (IS-IS)-enabled interface.

1.30.2   Command Mode

IS-IS interface configuration

1.30.3   Syntax Description

1.30.4   Default

LSPs are flooded over IS-IS-enabled interfaces. When you enter this command without specifying either level 1 or level 2 routing, LSPs are flooded on both IS-IS levels 1 and 2.

1.30.5   Usage Guidelines

Use the lsp block-flooding command to prevent LSPs from being flooded out through the IS-IS-enabled interface. When a network topology has many redundant connections among IS-IS devices, LSPs can be flooded excessively inside the network, costing extra CPU cycles and bandwidth consumption. This feature is especially useful in a large, fully-meshed IS-IS topology.

Note:  

This command is typically used for point-to-point (P2P) IS-IS interfaces.

Note:  

Avoid blocking some LSPs completely.

Use the no form of this command to restore to the default behavior of flooding LSPs on the interface.

1.30.6   Examples

The following example blocks LSP flooding on level 1 only for the fa4/1 interface running the IS-IS instance ip-backbone:

[local]Redback(config-ctx)#router isis ip-backbone

[local]Redback(config-isis)#interface oc48-4/1

[local]Redback(config-isis-if)#lsp block-flooding level-1

1.31   lsp gen-interval

1.31.1   Purpose

Controls how frequently a link-state protocol data unit (LSP) can be regenerated with new content for the Intermediate System-to-Intermediate System (IS-IS) instance.

1.31.2   Command Mode

IS-IS router configuration

1.31.3   Syntax Description

1.31.4   Default

An LSP can be regenerated every 10 seconds.

1.31.5   Usage Guidelines

Use the lsp gen-interval command to control how frequently an LSP can be regenerated with new content for the IS-IS instance.

Decreasing the frequency at which an LSP can be regenerated with new content can stabilize a network at the cost of slower convergence. New versions of LSPs with updated content are generated less often and produce less load on the network than the load caused by flooding and route recomputation. Typically, the value set by the lsp gen-interval command should be lower than the values set through the lsp max-lifetime and lsp refresh-interval commands in IS-IS router configuration mode.

Use the no form of this command to restore the default.

1.31.6   Examples

The following example sets the LSP regeneration frequency for IS-IS level-1 to 30 seconds:

[local]Redback(config-ctx)#router isis ip-backbone

[local]Redback(config-isis)#lsp gen-interval 30 level-1 

1.32   lsp interval

1.32.1   Purpose

Controls the pace at which link-state protocol data unit (LSP) transmissions are flooded on the interface to Intermediate System-to-Intermediate System (IS-IS) neighbors.

1.32.2   Command Mode

IS-IS interface configuration

1.32.3   Syntax Description

1.32.4   Default

The minimum delay time is set to 33 milliseconds.

1.32.5   Usage Guidelines

Use the lsp interval command to control the pace at which LSPs are flooded on the interface to IS-IS neighbors. In dense-meshed IS-IS network topologies with a large number of devices and IS-IS neighbors, LSP flooding is the key scaling factor. Ensure that devices are not overloaded by LSPs from neighbors.

Use the no form of this command to restore the default, minimum delay value.

1.32.6   Examples

The following example configures the SmartEdge router to transmit LSPs every 100 milliseconds (10 packets per second) on the serial1/1 interface:

[local]Redback(config-ctx)#router isis ip-backbone

[local]Redback(config-isis)#interface serial1/1

[local]Redback(config-isis-if)#lsp interval 100

1.33   lsp max-lifetime

1.33.1   Purpose

Modifies the length of time that Intermediate System-to-Intermediate System (IS-IS) link-state protocol data units (LSPs) can live on the network before timing out.

1.33.2   Command Mode

IS-IS router configuration

1.33.3   Syntax Description

1.33.4   Default

The maximum lifetime of an LSP is 1,200 seconds.

1.33.5   Usage Guidelines

Use the lsp max-lifetime command to modify the length of time LSPs can live on the network before timing out. Use this command in conjunction with the lsp refresh-interval command in the case of large networks. Longer-lived LSPs allow for less flooding and higher stability.

The value set by the lsp max-lifetime command should be at least 60 seconds more than the value set through the lsp refresh-interval command, and should also be more than the value set through the lsp gen-interval command.

Use the no form of this command to restore the default maximum lifetime value of 1,200 seconds.

1.33.6   Examples

The following example sets the maximum lifetime for LSPs to 900 seconds, which is 300 seconds more than the LSP refresh interval:

[local]Redback(config-isis)#lsp refresh-interval 600

[local]Redback(config-isis)#lsp max-lifetime 900

1.34   lsp receive-only-mode

1.34.1   Purpose

Prevents the specified Intermediate System-to-Intermediate System (IS-IS) interface from forwarding link-state protocol data units (LSPs).

1.34.2   Command Mode

IS-IS interface configuration

1.34.3   Syntax Description

This command has no keywords or arguments.

1.34.4   Default

None

1.34.5   Usage Guidelines

Use the lsp receive-only-mode command to prevent the specified IS-IS interface from forwarding LSPs

Use the no form of this command to reestablish forwarding of LSPs.

1.34.6   Examples

The following example prevents the IS-IS interface, isis1, on a lab router from forwarding LSPs:

[local]Redback(config-ctx)#router isis ip-backbone

[local]Redback(config-isis)#interface isis1

[local]Redback(config-isis-if)#lsp receive-only-mode

1.35   lsp refresh-interval

1.35.1   Purpose

Controls how frequently a link-state protocol data units (LSPs) can be regenerated for the Intermediate System-to-Intermediate System (IS-IS) instance.

1.35.2   Command Mode

IS-IS router configuration

1.35.3   Syntax Description

1.35.4   Default

LSPs can be regenerated every 900 seconds.

1.35.5   Usage Guidelines

Use the lsp refresh-interval command to control how frequently an LSP can be regenerated for the specified IS-IS instance.

Use this command in conjunction with the lsp max-lifetime command in the case of large networks. Longer-lived LSPs allow for less flooding and higher stability. This value should be at least 60 seconds less than the value set through the lsp max-lifetime command, and should also be less than the value set through the lsp gen-interval command. This LSP refresh interval also determines the IS-IS periodical Shortest Path First (SPF) calculations on the system.

Use the no form of this command to restore the default.

1.35.6   Examples

The following example sets the LSP refresh interval to 600 seconds, which is 300 seconds less than the maximum lifetime value:

[local]Redback(config-isis)#lsp refresh-interval 600

[local]Redback(config-isis)#lsp max-lifetime 900

1.36   lsp retransmit-interval

1.36.1   Purpose

Configures the length of time the system should wait for an acknowledgment from the neighbor before resending Intermediate System-to-Intermediate System (IS-IS) link-state protocol data units (LSPs).

1.36.2   Command Mode

IS-IS interface configuration

1.36.3   Syntax Description

1.36.4   Default

The retransmission interval is five seconds.

1.36.5   Usage Guidelines

Use the lsp retransmit-interval command to configure how long the system should wait for an acknowledgment from the neighbor before resending an IS-IS LSP. The number of seconds should be greater than the expected round-trip delay between any two devices on the attached network.

This command has no effect on LAN interfaces. On point-to-point links, the interval argument can be increased to enhance network stability. The retransmission interval can be larger for serial lines. More neighbors and paths over which LSPs are flooded allow for a longer interval.

Use the no form of this command to restore the default retransmission interval of five seconds.

1.36.6   Examples

The following example configures the pos11/1 interface to retransmit LSPs every 10 seconds:

[local]Redback(config-ctx)#router isis ip-backbone

[local]Redback(config-isis)#interface pos11/1

[local]Redback(config-isis-if)#lsp retransmit-interval 10

1.37   mac-address (ATM)

1.37.1   Purpose

Assigns a medium access control (MAC) address on an Asynchronous Transfer Mode (ATM) OC or ATM DS-3 port.

1.37.2   Command Mode

• ATM DS-3 configuration
• ATM OC configuration

1.37.3   Syntax Description

1.37.4   Default

When the ATM OC or ATM DS-3 traffic card or ATM OC MIC is inserted in the SmartEdge router, the MAC address is extracted from the EEPROM and assigned to each port on the card as sequential addresses starting with the base address for port 1.

1.37.5   Usage Guidelines

Use the mac-address command to assign a MAC address on an ATM port.

Use the default form of this command to return the MAC address to the address that has been extracted from the EEPROM on the ATM OC or ATM DS-3 traffic card.

1.37.6   Examples

The following example shows how to assign 00:03:04:10:a4:bc as the MAC address on port 1 of the ATM DS-3 traffic card in slot 3:

[local]Redback(config)#port atm 3/1

[local]Redback(config-atm-ds3)#mac-address 00:03:04:10:a4:bc 

1.38   mac-address (DHCP)

1.38.1   Purpose

Creates a static mapping between a medium access control (MAC) address and an IP address in this subnet.

1.38.2   Command Mode

• DHCP subnet configuration

1.38.3   Syntax Description

1.38.4   Default

No mapping exists between the MAC address and an IP address.

1.38.5   Usage Guidelines

Use the mac-address command to create a static mapping between a MAC address and an IP address in this subnet.

The value for the ip-addr argument must be an IP address within this subnet, but not within any range of IP addresses that you have specified using the range command (in DHCP subnet configuration mode).

Use the no form of this command to specify the default condition.

1.38.6   Examples

The following example creates a static mapping between a MAC address and an IP address:

[local]Redback(config)#context dhcp
[local]Redback(config-ctx)#dhcp server policy
[local]Redback(config-dhcp-server)#subnet 12.1.1.0/24 name sub2
[local]Redback(config-dhcp-subnet)#range 12.1.1.50 12.1.1.100
[local]Redback(config-dhcp-subnet)#mac-address 02:12:34:56:78:90 ip-address 12.1.1.10

1.39   mac-address (Dot1Q PVC)

1.39.1   Purpose

Assigns a medium access control (MAC) address to an 802.1Q permanent virtual circuit (PVC).

1.39.2   Command Mode

• dot1q PVC configuration

1.39.3   Syntax Description

1.39.4   Default

When the Gigabit or Fast Ethernet traffic card is inserted in the SmartEdge router, the MAC address is extracted from the EEPROM and assigned to each port on the Gigabit or Fast Ethernet traffic card as sequential addresses starting with the base address for port 1. Every tunnel and PVC on a port has the same default address as the port.

1.39.5   Usage Guidelines

Use the mac-address command to assign a MAC address on a Gigabit or Fast Ethernet port.

The mac-address command is only available under the dot1q PVC configuration mode. This command is not available when configuring 802.1Q PVCs virtual LAN (VLAN) link group.

Note:  

Do not enter a point-to-multipoint MAC address. There must not be an odd number in the first byte of the mac-addr argument.

Use the no or default form of this command to return the MAC address to the MAC address of the parent circuit.

1.39.6   Examples

The following example assigns 02:03:04:05:06:07 as the MAC address on an 802.1Q PVC within a tunnel on port 2 of the Gigabit or Fast Ethernet traffic card in slot 1:

[local]Redback(config)#port ethernet 2/1

[local]Redback(config-port)#no shutdown

[local]Redback(config-port)#encapsulation dot1q

[local]Redback(config-port-dot1q)#dot1q pvc 2 1qtunnel

[local]Redback(config-port-dot1q)#dot1q pvc 2:1

[local]Redback(config-dot1q-pvc)#mac-address 02:03:04:05:06:07 

As a result, the port and the 802.1Q tunnel have the same default address stored in the EEPROM. Only the 802.1Q PVC has an assigned MAC address.

1.40   mac-address (link group)

1.40.1   Purpose

Specifies or automatically generates a medium access control (MAC) address for the Ethernet, 802.1Q, or access link group.

1.40.2   Command Mode

• link group configuration

1.40.3   Syntax Description

1.40.4   Default

The MAC address of a constituent FE or GE port in the link group is used as the MAC address for the link group.

1.40.5   Usage Guidelines

Use the mac-address command to specify or automatically generate a MAC address for the Ethernet, 802.1Q, or access link group.

If the command includes the auto keyword, the link group uses the address of its constituent FE or GE port whenever it is available and automatically generates a new MAC address whenever the port address is not available, such as when the traffic card containing the port is removed.

Note:  

This command is applicable only to an Ethernet, 802.1Q, or access link group.

You must use this command to specify a MAC address when configuring an access link group.

Use the no form of this command to specify the default condition.

1.40.6   Examples

The following example shows how to specify 00:00:26:26:26:26 as the MAC address for the Ethernet link group:

[local]Redback(config)#link-group lg-ether ether
[local]Redback(config-link-group)#mac-address 00:00:26:26:26:26 

1.41   mac-addr (pseudowire)

1.41.1   Purpose

Sets the MAC address for the port pseudowire connection.

1.41.2   Command Mode

port pseudowire configuration

1.41.3   Syntax Description

1.41.4   Default

None

1.41.5   Usage Guidelines

Use the mac-addr command to set the MAC address of the port pseudowire connection.

Use the no form of this command to set the MAC address of the port pseudowire connection to the previously set value.

1.41.6   Examples

The following example shows how to set the MAC address of the port pseudowire connection to 11:22:33:44:55:66:

[local]Redback(config-port)#mac-addr 11:22:33:44:55:66

1.42   mac-entry

1.42.1   Purpose

Specifies a medium access control (MAC) address that is not allowed on this bridge.

1.42.2   Command Mode

• bridge configuration

1.42.3   Syntax Description

1.42.4   Default

Packets with any MAC address are accepted.

1.42.5   Usage Guidelines

Use the mac-entry command to specify a MAC address that is not allowed on this bridge. Packets with this MAC address, either as source or destination, are dropped unconditionally.

Use the no form of this command to remove the MAC address from the list of MAC addresses that are not allowed on this bridge.

1.42.6   Examples

The following example shows how to specify the MAC addresses that are not allowed on this bridge:

[local]Redback(config)#context bridge

[local]Redback(config-ctx)#bridge isp1

[local]Redback(config-bridge)#mac-entry drop 00:0d:ab:40:8d:50

[local]Redback(config-bridge)#mac-entry drop 00:a0:a0:40:d8:60

1.43   mac-limit

1.43.1   Purpose

Specifies the maximum number of medium access control (MAC) addresses that can be learned by the bridge or specified manually for any port, circuit, or Virtual Private LAN Service (VPLS) pseudowire circuit to which this profile is assigned.

1.43.2   Command Mode

• bridge profile configuration

1.43.3   Syntax Description

1.43.4   Default

The maximum number of learned MAC addresses is four for a tributary circuit to which a profile is assigned. Trunk and VPLS circuits have no MAC limit.

1.43.5   Usage Guidelines

Use the mac-limit command to specify the maximum number of MAC addresses that can be learned by the bridge or specified manually for any port, circuit, or VPLS pseudowire circuit to which this profile is assigned. For more information about VPLS pseudowire circuits, see Configuring VPLS.

MAC addresses are specified manually using the bridge mac-entry command (in ATM PVC, dot1q PVC, or port configuration mode).

Use the no or default form of this command to specify the default limitation.

1.43.6   Examples

The following example shows how to specify 10 as the maximum number of MAC addresses for this profile:

[local]Redback(config)#bridge profile prof-isp1

[local]Redback(config-bridge-profile)#mac-limit 10

1.44   mac-list

1.44.1   Purpose

Creates a list of MAC addresses that can be used drop incoming packets when their source MAC address matches any entry in the MAC list.

1.44.2   Command Mode

global configuration

1.44.3   Syntax Description

1.44.4   Default

No default

1.44.5   Usage Guidelines

Use the mac-list command to create a list of MAC addresses that can be used drop incoming packets when their source MAC address matches any entry in the MAC list. The examples below show how a bridge filter with one or more MAC can be applied to an 802.1Q PVC bound to a bridge.

To configure a MAC list on an 802.1Q PVC, follow these steps:

1. Specify the name of the MAC list and push the Enter key:

   mac-list MAC-list-name

2. When you see the config-mac-list prompt, enter the first address in the MAC-list.
   • To add an address to the MAC list, simply type the MAC address followed by the Enter key; that is, the subcommand that adds MAC addresses to the MAC list is simply the MAC-address argument without keywords. In other words, the mac-list command creates a container for a list of MAC address called a MAC list, and these addresses can be applied to PVCs bound to bridges to filter incoming packets.
   • To remove an address, enter the no MAC-address form of the subcommand.
3. Add or remove as many addresses as needed by repeating step 2.
4. Include the MAC list in a bridge profile. You can include multiple MAC lists in any bridge profile.

   Use the drop source command (in bridge profile configuration mode) to include a MAC list filter in a bridge profile.

5. Use the bridge profile command to apply the MAC lists it contains to a bridged 802.1Q PVC.

   The 802.1Q PVC must be bound to the interface of a bridge.

Use the show circuit counters detail command to show the dropped packets.

Use the show circuit counters detail command to see the dropped packets statistics. The field, MAC filter Drops, appears among the other bridge counters. It displays the count in bytes and packets.

The following restrictions apply to MAC list filters:

• A maximum of ten MAC addresses can be contained in each MAC list
• No more than eight unique MAC lists can be applied to a bridge.

  For example, suppose you have two 802.1Q PVCs bound to a bridge. The first PVC specifies bridge profile Profile-A and the second PVC specifies Profile-B. Also suppose the following:

  • Profile-A includes three MAC-lists: MAC-list-2, MAC-list-3, and MAC-list-5.
  • Profile-B includes two MAC-lists: MAC-list-4 and MAC-list-5. The number of unique MAC-lists applied to the bridge in this example is four. They are: MAC-list-2, MAC-list-3, MAC-list-4, and MAC-list-5.
• MAC lists are not supported on first-generation (PPA1) traffic cards.
• MAC lists are not supported on VPLS pseudowire circuits.
• MAC lists are supported on learning bridges only.
• MAC list filtering on circuits aggregated in link groups is not supported.
• MAC list filtering has less than a 3% impact on the overall Layer 2 forwarding performance of the SmartEdge router.

1.44.6   Examples

The following example illustrates how to create a MAC list named “noloops” with the mac-list command:

[local]Redback(config)#mac-list noloops
[local]Redback(config-mac-list)#11:11:11:ab:cd:cd
[local]Redback(config-mac-list)#11:13:44:ab:cd:ab
[local]Redback(config-mac-list)#end

The following example shows how to incorporate the created list in a bridge profile:

[local]Redback(config)#bridge profile mynetworkbridges
[local]Redback(config-bridge-profile)#drop source noloops
[local]Redback(config-bridge-profile)#end

The following example shows how to apply the bridge profile with the MAC list filter to a 802.1Q PVC that interfaces to a bridge where the filter is required:

[local]Redback(config)#port ethernet 5/2
[local]Redback(config-port)#encapsulation dot1q
[local]Redback(config-port)#dot1q pvc 5
[local]Redback(config-dot1q-pvc)#bridge profile mynetworkbridges
[local]Redback(config-bridge-profile)#end

1.45   mac-move-drop

1.45.1   Purpose

Enables the legacy method of detection of bridging loops.

1.45.2   Command Mode

bridge configuration

1.45.3   Syntax Description

This command has no keywords or arguments.

1.45.4   Default

The legacy method of detecting bridging loops is enabled by default, but only if the loop detection command (in bridge configuration mode) is not enabled. When loop-detection is enabled, the legacy method is disabled.

1.45.5   Usage Guidelines

The mac-move-drop command enables the legacy method of detection of bridging loops; however, you cannot enable the legacy method if loop-detection has been enabled.

Use the no or default form of this command to disable the legacy method of detection of bridging loops.

1.45.6   Examples

The following example shows how to configure a bridge to use the legacy method of detecting bridging loops:

[local]Redback(config-bridge)#mac-move-drop

1.46   macro

1.46.1   Purpose

Defines an alias for a sequence of commands and accesses macro configuration mode.

1.46.2   Command Mode

• global configuration

1.46.3   Syntax Description

1.46.4   Default

No macros are defined.

1.46.5   Usage Guidelines

Use the macro command to define an alias for a sequence of commands. After entering macro configuration mode, you enter the commands to be included in the macro using the seq command (in macro configuration mode).

Table 3 lists all the mode prompts and keyword exceptions for the macro command. Except for the modes listed in Table 3, the keyword for the mode argument is the command mode prompt. For a list of all keywords, see the command-line interface (CLI) online Help.

Use the exit command (in macro configuration mode) to complete the macro and exit to global configuration mode.

Use the no form of this command to delete the macro.

1.46.6   Examples

The following example defines a macro, show-port-all, to display port information:

[local]Redback(config)#macro inherit show-port-all

[local]Redback(config-macro)#seq 10 show port $1/$2

[local]Redback(config-macro)#seq 20 show circuit $1/$2

[local]Redback(config-macro)#exit

The following example displays port data for port 3 of the traffic card in slot 4 using the show-port-all macro:

[local]Redback>show-port-all 4 3

The following example defines the macro, show-all, that uses the $ character:

[local]Redback(config)#macro inherit show-all

[local]Redback(config-macro)#seq 10 show config $*

[local]Redback(config-macro)#seq 30 show circuit $*

[local]Redback(config-macro)#exit

The following example displays Asynchronous Transfer Mode (ATM) and Frame Relay configuration and circuits using the show-all macro:

[local]Redback>show-all atm frame-relay

1.47   maintenance-association

1.47.1   Purpose

Creates a maintenance association (MA) on an Ethernet or VLAN-based circuit to verify the integrity of the circuit. If the MA already exists, the command simply enters the MA configuration mode.

1.47.2   Command Mode

CFM configuration

1.47.3   Syntax Description

1.47.4   Default

No MA exists.

1.47.5   Usage Guidelines

Use the maintenance-association command to create a MA on an Ethernet or VLAN-based circuit to verify the integrity of the circuit. If the MA already exists, the command simply enters the MA configuration mode.

When the MD is divided into multiple maintenance associations (MAs) (as shown level 3 in the following illustration), the maintenance association endpoints (MEPs) can be adjacent, but cannot overlap.

Each Ethernet or VLAN-based circuit is a single Ethernet Virtual Connection (EVC); that is a single customer service instance.

An MA is defined as a mesh of MEPs, each of which has a Domain Service Access Point (DSAP) to which a user can connect for CFM operations. In addition the network mesh can contain intermediate maintenance points not having DSAPs. If an intermediate maintenance point is configured to be reported in the CFM user’s domain, it is called a maintenance association intermediate point (MIP). in the MA.

The Continuity Check Message (CCM) PDU is broadcast by an MA endpoint (MEP), is used to check the continuity of the MA.

Maintenance points are ingress and egress Ethernet ports, Ethernet circuit interfaces, or interfaces to emulated Ethernet circuits. See “CFM Supported Circuits” in Configuring Ethernet CFM for details.

The following drawing illustrates two Operator MAs. Each MA is corresponds to separate VLAN. If the two VLANs are operated by separate companies and have DSAPs, they should be created in separate MDs. If they are supplied by the same company, they should be created in a single domain:

1.47.6   Examples

The following example shows how to use this command to create an MA bayarea in the MD named sbc.com:

[local]Redback(config)#ethernet-cfm instance-1
[local]Redback(config-ether-cfm)#level 4
[local]Redback(config-ether-cfm)#domain-name sbc.com
[local]Redback(config-ether-cfm)#disable-linktrace
[local]Redback(config-ether-cfm)#group-mac 01:01:01:01:01:01
[local]Redback(config-ether-cfm)#maintenance-association bayarea

1.48   mapping-schema

1.48.1   Purpose

Defines the default quality of service (QoS) translation schema to use with a classification map.

1.48.2   Command Mode

class map configuration

1.48.3   Syntax Description

1.48.4   Default

Maps all entries to the default 8P0D values.

1.48.5   Usage Guidelines

Use the mapping-schema command to define the default QoS translation schema to use with a classification map. This command overrides any existing configuration for the classification map.

You can use this command to specify default values for all mapping entries, then override that value for a subset of entries by entering subsequent mapping commands.

Use the no or default form of this command to revert values for all map entries to the default 8P0D values.

Table 4 lists the default values for 8P0D ingress mappings.

Table 5 lists the default values for 8P0D egress mappings.

Table 6 lists the default values for 7P1D ingress mappings.

Table 7 lists the default values for 7P1D egress mappings.

Table 8 lists the default values for 6P2D ingress mappings.

Table 9 lists the default values for 6P2D egress mappings.

Table 10 lists the default values for 5P3D ingress mappings

Table 11 lists the default values for 5P3D egress mappings.

1.48.6   Examples

The following example defines the classification map pd-to-exp for PD values on egress, then defines the default mapping schema as 6P2D. It overrides the default mapping for PD user priority value af33 to MPLS EXP value 4, and specifies the default DSCP-to-EXP mapping for PD value 13:

[local]Redback(config)#qos class-map pd-to-exp mpls out

[local]Redback(config-class-map)#mapping-schema 6P2D

[local]Redback(config-class-map)#qos af33 to mpls 4

[local]Redback(config-class-map)#qos 13 use-ip

1.49   mark dscp

1.49.1   Purpose

Assigns a quality of service (QoS) Differentiated Services Code Point (DSCP) priority to IP packets. For IPv4 packets, the DSCP marking is the upper six bits of the IPv4 header Type of Service (ToS) field. For IPv6 packets, the DSCP marking is the upper six bits of the IPv6 header Traffic Class field.

1.49.2   Command Mode

• metering policy configuration
• policy ACL class configuration
• policing policy configuration

1.49.3   Syntax Description

1.49.4   Default

Packets are not assigned a DSCP priority.

1.49.5   Usage Guidelines

Use the mark dscp command to assign a QoS DSCP priority to packets.

Table 12 lists the keywords for the dscp-class argument.

Note:  

RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, defines the Class Selector code points.

Use the no form of this command to specify the default behavior.

1.49.6   Examples

The following example configures the policy, GE-in policing, to mark all packets within the VOIP class as high-priority packets, while all packets within the best-effort class are marked as low-priority packets:

[local]Redback(config)#qos policy GE-in policing

[local]Redback(config-policy-policing)#access-group myacl cont2

[local]Redback(config-policy-group)#class VOIP

[local]Redback(config-policy-group-class)#mark dscp ef

[local]Redback(config-policy-group-class)#exit

[local]Redback(config-policy-group)#class best-effort

[local]Redback(config-policy-group-class)#mark dscp df

1.50   mark dscp destination

1.50.1   Purpose

Sets the Differentiated Services Code Point (DSCP) byte, based on Border Gateway Protocol (BGP) attributes, such as community list and autonomous system (AS) path, for incoming IP traffic on the specified interface.

1.50.2   Command Mode

interface configuration

1.50.3   Syntax Description

This command has no keywords or arguments.

1.50.4   Default

Disabled

1.50.5   Usage Guidelines

Use the mark dscp destination command to set the DSCP byte, based on BGP attributes, such as community list and autonomous AS path, for incoming IP traffic on the specified interface.

BGP destination-based quality of service (QoS) provides multiple levels of service based on a customer’s IP destination. BGP routes can be assigned a DSCP value based on the BGP traffic indexing and table map features associated with route maps. BGP routes can be assigned a traffic index. The byte and packet counters for the traffic index are incremented based on the route traversed by IP traffic received on the ingress interface.

When a packet is received on an interface with mark dscp destination enabled and the packet is routed using a route with associated DSCP, the packet's DCSP is updated and the IP header checksum is recalculated.

Use the no form of this command to disable the DSCP byte marking for incoming IP traffic for the specified interface.

1.50.6   Examples

The following example enables BGP-based marking on the appropriate ingress interface:

[local]Redback(config)#context local

[local]Redback(config-ctx)#interface CustomerOne

[local]Redback(config-if)#ip address 10.200.1.1/30

[local]Redback(config-if)#mark dscp destination

1.51   mark precedence

1.51.1   Purpose

Assigns a quality of service (QoS) Differentiated Services Code Point (DSCP) drop-precedence value to IP packets that exceed the configured QoS rate. For IPv4 packets, the DSCP marking is the upper six bits of the IPv4 header Type of Service (ToS) field. For IPv6 packets, the DSCP marking is upper six bits of the IPv6 header Traffic Class field. In either case, the specific bits affected are those denoted by dd in the octet field with the format pppddxxx.

1.51.2   Command Mode

• metering policy configuration
• policy ACL class configuration
• policing policy configuration

1.51.3   Syntax Description

1.51.4   Default

Packets are not marked with an explicit drop precedence value.

1.51.5   Usage Guidelines

Use the mark precedence command to assign a QoS drop precedence value to packets.

Only one mark instruction can be in effect at a time. To change the mark instruction, enter the mark precedence command, specifying a new value for the prec-value argument, which supersedes the one previously configured.

Use the no form of this command to specify the default behavior.

In general, the level of forwarding assurance of an IP packet is based on: (1) the resources allocated to the AF class to which the packet belongs, (2) the current load of the AF class, and, in case of congestion within the class, (3) the drop precedence of the packet. In case of congestion, the drop precedence of a packet determines the relative importance of the packet within the assured forwarding (AF) Differentiated Services Code Point (DSCP) class. Packets with a lower drop precedence value are preferred and protected from being lost, while packets with a higher drop precedence value are discarded. (For more information see RFC 2597, Assured Forwarding PHB Group.)

With AF classes AF1 (AF11, AF12, AF13), AF2 (AF21, AF22, AF23), AF3 (AF31, AF32, AF33), and AF4 (AF41, AF42, AF43), the second integer represents a drop precedence value. Table 13 shows how the AF drop precedence value of an incoming packet is changed when it exits the SmartEdge router after being tagged with a new drop precedence. (See also RFC 2597, Assured Forwarding PHB Group.)

1.51.6   Examples

The following example configures the policy, GE-in policing, to mark all packets within the VOIP class as preferred packets, while all packets within the best-effort class are marked as less-preferred packets:

[local]Redback(config)#qos policy GE-in policing

[local]Redback(config-policy-policing)#access-group myacl cont2

[local]Redback(config-policy-group)#class VOIP

[local]Redback(config-policy-group-class)#mark precedence 1

[local]Redback(config-policy-group-class)#exit

[local]Redback(config-policy-group)#class best-effort

[local]Redback(config-policy-group-class)#mark precedence 3

1.52   mark priority

1.52.1   Purpose

Sets the internal packet descriptor (PD) quality of service (QoS) classification value for specified packets, while preserving the packet’s IP header Differentiated Services Code Point (DSCP) value.

1.52.2   Command Mode

• metering policy configuration
• policing policy configuration
• policy group class configuration

1.52.3   Syntax Description

1.52.4   Default

The PD QoS values for a packet are not modified.

1.52.5   Usage Guidelines

;

Use the mark priority command to set the internal PD QoS classification value for specified packets, while preserving the packet’s IP header DSCP value.

A priority group is an internal value used by the SmartEdge router to determine into which egress queue the inbound packet should be placed. The type of service (ToS) value, DSCP value, and Multiprotocol Label Switching (MPLS) experimental (EXP) bits are unchanged by this command. The actual queue number depends on the number of queues configured on the circuit. For more information, see the num-queue command in Configuring Scheduling

The SmartEdge router uses the factory preset, or default, mapping of a priority group to a queue, according to the number of queues configured on a circuit; see Table 14.

Only one mark instruction can be in effect at a time. To change the mark instruction, enter the mark priority command, specifying a new value for the group-num arguments. This supersedes the value previously configured.

Note:  

By default, the SmartEdge router assigns a priority group to each egress queue, according to the number of queues configured on a circuit. You can override the default mapping of packets into egress queues by creating a customized queue priority map through the qos queue-map command (in global configuration mode).

If neither the drop-precedence nor the af-drop keyword is specified, the priority bits are set to the specified value and the drop-precedence bits are cleared.

Use the no form of this command to return to the default behavior.

1.52.6   Examples

The following example configures the policy, GE-in policing, to mark all packets within the VOIP class as high-priority packets, while all packets within the best-effort class are marked as low-priority packets: