Cisco 7600 Series Router SIP, SSC, and SPA Software Configuration Guide

Required Configuration Tasks

This section lists the required configuration steps to configure the Fast Ethernet and Gigabit Ethernet SPAs. The commands in the section are applicable for both Fast Ethernet and Gigabit Ethernet SPAs; however, the examples below are for configuring a Gigabit Ethernet SPA. If you are configuring a Fast Ethernet SPA, replace the gigabitethernet command with the fastethernet command.

Some of the required configuration commands implement default values that might be appropriate for your network. If the default value is correct for your network, then you do not need to configure the command. These commands are indicated by “(As Required)” in the Purpose column.

Note Cisco Discovery Protocol (CDP) is disabled by default on Cisco 7600 SIP-400 interfaces.

To configure the Fast Ethernet or Gigabit Ethernet SPAs, complete the following steps:

Specifying the Interface Address on a SPA

SPA interface ports begin numbering with “0” from left to right. Single-port SPAs use only the port number 0. To configure or monitor SPA interfaces, you need to specify the physical location of the SPA interface processor (SIP), SPA, and interface in the command-line-interface (CLI.) The interface address format is slot / subslot / port, where:

• slot —Specifies the chassis slot number in the Cisco 7600 series router where the SIP is installed.
• subslot —Specifies the secondary slot of the SIP where the SPA is installed.
• port —Specifies the number of the individual interface port on a SPA.

The following example shows how to specify the first interface (0) on a SPA installed in the first subslot of a SIP (0) installed in chassis slot 3:

This command shows a serial SPA as a representative example, however the same slot / subslot / port format is similarly used for other SPAs (such as Asynchronous Transfer Mode [ATM] and packet over SONET [POS]) and other non-channelized SPAs.

Modifying the MAC Address on the Interface

The Gigabit Ethernet SPAs use a default MAC address for each port that is derived from the base address that is stored in the electrically erasable programmable read-only memory (EEPROM) on the backplane of the Cisco 7600 series router.

To modify the default MAC address of an interface to some user-defined address, use the following command in interface configuration mode:

To return to the default MAC address on the interface, use the no form of the command.

Verifying the MAC Address

To verify the MAC address of an interface, use the show interfaces gigabitethernet privileged EXEC command and observe the value shown in the “address is” field.

The following example shows that the MAC address is 000a.f330.2e40 for interface 1 on the SPA installed in subslot 0 of the SIP installed in slot 2 of the Cisco 7600 series router:

Gathering MAC Address Accounting Statistics

The ip accounting mac-address [ input | output ] command can be entered to enable MAC Address Accounting on an interface. After enabling MAC Address Accounting, MAC address statistics can be gathered by entering the show interfaces mac-accounting command.

Configuring HSRP

Hot Standby Router Protocol (HSRP) provides high network availability because it routes IP traffic from hosts without relying on the availability of any single router. HSRP is used in a group of routers for selecting an active router and a standby router. (An active router is the router of choice for routing packets; a standby router is a router that takes over the routing duties when an active router fails, or when preset conditions are met).

HSRP is enabled on an interface by entering the standby [ group-number ] ip [ ip-address [ secondary ]] command. The standby command is also used to configure various HSRP elements. This document does not discuss more complex HSRP configurations. For additional information on configuring HSRP, see the refer to the HSRP section of the Cisco IP Configuration Guide publication that corresponds to your Cisco IOS software release.

In the following HSRP configuration, standby group 2 on GigabitEthernet port 2/1/0 is configured at a priority of 110 and is also configured to have a preemptive delay should a switchover to this port occur:

Router(config)# interface GigabitEthernet 2/1/0

Router(config-if)# standby 2 ip 120.12.1.200

Router(config-if)# standby 2 priority 110

Router(config-if)# standby 2 preempt

Verifying HSRP

To display HSRP information, use the show standby command in EXEC mode:

Customizing VRRP

Customizing the behavior of Virtual Router Redundancy Protocol (VRRP) is optional. Be aware that as soon as you enable a VRRP group, that group is operating. It is possible that if you first enable a VRRP group before customizing VRRP, the router could take over control of the group and become the master virtual router before you have finished customizing the feature. Therefore, if you plan to customize VRRP, it is a good idea to do so before enabling VRRP.

To customize your VRRP configuration, use any of the following VRRP commands in Table 13-1 in interface configuration mode.

Table 13-1 VRRP Commands

Enabling VRRP

To enable VRRP on an interface, use the following commands beginning in global configuration mode:

Verifying VRRP

To verify VRRP, use either of the following commands in EXEC mode:

Modifying the Interface MTU Size

The Cisco IOS software supports three different types of configurable maximum transmission unit (MTU) options at different levels of the protocol stack:

• Interface MTU—Checked by the SPA on traffic coming in from the network. Different interface types support different interface MTU sizes and defaults. The interface MTU defines the maximum packet size allowable (in bytes) for an interface before drops occur. If the frame is smaller than the interface MTU size, but is not smaller than the minimum frame size for the interface type (such as 64 bytes for Ethernet), then the frame continues to process.
• IP MTU—Can be configured on an interface or subinterface and is used by the Cisco IOS software to determine whether fragmentation of a packet takes place. If an IP packet exceeds the IP MTU size, then the packet is fragmented.
• Tag or Multiprotocol Label Switching (MPLS) MTU—Can be configured on an interface or subinterface and allows up to six different labels, or tag headers, to be attached to a packet. The maximum number of labels is dependent on your Cisco IOS software release.

Different encapsulation methods and the number of MPLS MTU labels add additional overhead to a packet. For example, Subnetwork Access Protocol (SNAP) encapsulation adds an 8-byte header, dot1q encapsulation adds a 2-byte header, and each MPLS label adds a 4-byte header ( n labels x 4 bytes).

For the Fast Ethernet and Gigabit Ethernet SPAs on the Cisco 7600 series router, the default MTU size is 1500 bytes. When the interface is being used as a Layer 2 port, the maximum configurable MTU is 9216 bytes. The SPA automatically adds an additional 22 bytes to the configured MTU size to accommodate some of the additional overhead.

Interface MTU Configuration Guidelines

When configuring the interface MTU size on a Fast Ethernet and Gigabit Ethernet SPA on a Cisco 7600 series router, consider the following guidelines:

• The default interface MTU size accommodates a 1500-byte packet, plus 22 additional bytes to cover the following additional overhead:

– Layer 2 header—14 bytes

– Dot1q header—4 bytes

– CRC—4 bytes

Note Depending on your Cisco IOS software release, a certain maximum number of MPLS labels are supported. If you need to support more than two MPLS labels, then you need to increase the default interface MTU size.

• If you are using MPLS, be sure that the mpls mtu command is configured for a value less than or equal to the interface MTU.
• If you are using MPLS labels, then you should increase the default interface MTU size to accommodate the number of MPLS labels. Each MPLS label adds 4 bytes of overhead to a packet.

Interface MTU Guidelines for Layer 2 Ports

On Layer 2 ports, it is important to understand the idea of the jumbo MTU. The jumbo MTU can be configured using the system jumbomtu command, although this command is only supported under the following scenarios:

• The port is a member of a Layer 2 EtherChannel.
• The new MTU size on the Layer 2 port is less than the currently configured maximum MTU for the port.

If neither of the above conditions applies to your configuration, neither does “jumbo MTU.”

Note Fast Ethernet SPAs cannot function as Layer 2 ports.

Interface MTU Configuration Task

To modify the MTU size on an interface, use the following command in interface configuration mode:

To return to the default MTU size, use the no form of the command.

Verifying the MTU Size

To verify the MTU size for an interface, use the show interfaces gigabitethernet privileged EXEC command and observe the value shown in the MTU field.

The following example shows an MTU size of 1500 bytes for interface port 1 (the second port) on the Gigabit Ethernet SPA installed in the top subslot (0) of the SIP that is located in slot 2 of the Cisco 7600 series router:

Configuring the Encapsulation Type

By default, the interfaces on the Fast Ethernet and Gigabit Ethernet SPAs support Advanced Research Projects Agency (ARPA) encapsulation. They do not support configuration of service access point or SNAP encapsulation for transmission of frames; however, the interfaces will properly receive frames that use service access point and SNAP encapsulation.

The only other encapsulation supported by the SPA interfaces is IEEE 802.1Q encapsulation for virtual LANs (VLANs).

Configuring Autonegotiation on an Interface

Fast Ethernet and Gigabit Ethernet interfaces use a connection-setup algorithm called autonegotiation. Autonegotiation allows the local and remote devices to configure compatible settings for communication over the link. Using autonegotiation, each device advertises its transmission capabilities and then agrees upon the settings to be used for the link.

For the Fast Ethernet and Gigabit Ethernet interfaces on the Cisco 7600 series router, flow control is autonegotiated when autonegotiation is enabled. Autonegotiation is enabled by default.

The following guidelines should be followed regarding autonegotiation:

• If autonegotiation is disabled on one end of a link, it must be disabled on the other end of the link. If one end of a link has autonegotiation disabled while the other end of the link does not, the link will not come up properly on both ends.
• Autonegotiation is not supported on the 10-Port Gigabit Ethernet SPA on the Cisco 7600 SIP-600.
• Flow control can be configured separately of autonegotiation when Ethernet SPAs are installed in a Cisco 7600 SIP-600.
• Flow control is enabled by default.
• Flow control will be on if autonegotiation is disabled on both ends of the link.
• Flow control cannot be disabled on a Fast Ethernet SPA.

Disabling Autonegotiation

Autonegotiation is automatically enabled and can be disabled on the Fast Ethernet interfaces on the Cisco 7600 SIP-200, and the Gigabit Ethernet interfaces on the Cisco 7600 SIP-400 or Cisco 7600 SIP-600. During autonegotiation, advertisement for flow control, speed, and duplex occurs. If the Gigabit Ethernet interface is connected to a link that has autonegotiation disabled, autonegotiation should either be re-enabled on the other end of the link or disabled on the Fast Ethernet or Gigabit Ethernet SPA, if possible. Both ends of the link will not come up properly if only one end of the link has disabled autonegotiation.

Note Speed and duplex configurations are negotiated using autonegotiation. However, the only values that are negotiated are 100 Mbps for speed and full-duplex for duplex for Fast Ethernet SPAs, and 1000 Mbps for speed and full-duplex for duplex for Gigabit Ethernet SPAs. Therefore, from a user’s perspective, these settings are not negotiated, but enabled using autonegotiation.

To disable autonegotiation on Fast Ethernet or Gigabit Ethernet SPAs, use the following commands in interface configuration mode:

Enabling Autonegotiation

Autonegotiation is automatically enabled and can be disabled unless it is on a SPA installed in a Cisco 7600 SIP-400, or on a 10-Port Gigabit Ethernet SPA, 5-Port Gigabit Ethernet SPA, or a 10-Port Gigabit Ethernet SPA when installed in a Cisco 7600 SIP-600. See the “Configuring Flow Control for an Ethernet SPA Interface on a Cisco 7600 SIP-600” section. To re-enable autonegotiation on a Fast Ethernet or Gigabit Ethernet interface, use the following commands in interface configuration mode:

SFP-GE-T Support

The SFP-GE-T supports speeds of 10 Mbps, 100 Mbps, and 1000 Mbps. Speed is not autonegotiated; you must configure it using the speed command. Only full-duplex mode is supported.

Note Because autonegotiation of full-duplex is not supported, you must manually configure full-duplex mode.

You can configure each Ethernet interface independently using any combination of 10 Mbps, 100 Mbps, or 1000 Mbps.

To set the interface speed, use the following command in the interface configuration mode:

Configuring an Ethernet VLAN

For information on configuring Ethernet VLANs, see the “Creating or Modifying an Ethernet VLAN” section of the “Configuring VLANs” chapter in the Cisco 7600 Series Cisco IOS Software Configuration Guide publication that corresponds to your Cisco IOS software release.

Configuring a Subinterface on a VLAN

You can configure subinterfaces on the Fast Ethernet SPA interfaces and Gigabit Ethernet SPA interfaces on a VLAN using IEEE 802.1Q encapsulation. Cisco Discovery Protocol (CDP) is disabled by default on the 2-Port Gigabit Ethernet SPA interfaces and subinterfaces on the Cisco 7600 SIP-400.

To configure a SPA subinterface on a VLAN, use the following commands beginning in interface configuration mode:

Note On any Cisco 7600 SIP-600 Ethernet port subinterface using VLANs, a unique VLAN ID must be assigned. This VLAN ID cannot be in use by any other interface on the Cisco 7600 series router.

Verifying Subinterface Configuration on a VLAN

To verify the configuration of a subinterface and its status on the VLAN, use the show vlans privileged EXEC command.

The following example shows the status of subinterface number 1 on port 0 on the SPA in VLAN number 200:

Configuring Layer 2 Switching Features

The Cisco 7600 series router supports simultaneous, parallel connections between Layer 2 Ethernet segments. After you review the SPA-specific guidelines described in this document, refer to the “Configuring Layer 2 Ethernet Interfaces” section of the Cisco 7600 Series Router Cisco IOS Software Configuration GuideCatalyst 6500 Series Switch Cisco IOS Software Configuration Guide, 12.2SX for more information about configuring the Layer 2 switching features.

Configuring Multipoint Bridging

Multipoint bridging (MPB) enables the connection of multiple ATM PVCs, Frame Relay permanent virtual circuits (PVCs), Bridging Control Protocol (BCP) ports, and WAN Gigabit Ethernet subinterfaces into a single broadcast domain (virtual LAN), together with the LAN ports on that VLAN. This enables service providers to add support for Ethernet-based Layer 2 services to the proven technology of their existing ATM and Frame Relay legacy networks. Customers can then use their current VLAN-based networks over the ATM or Frame Relay cloud. This also allows service providers to gradually update their core networks to the latest Gigabit Ethernet optical technologies, while still supporting their existing customer base.

For MPB configuration guidelines and restrictions and feature compatibility tables, see the “Configuring Multipoint Bridging” section.

Configuring the Bridging Control Protocol

The Bridging Control Protocol (BCP) enables forwarding of Ethernet frames over SONET networks and provides a high-speed extension of enterprise LAN backbone traffic through a metropolitan area. The implementation of BCP on the SPAs includes support for IEEE 802.1D, IEEE 802.1Q Virtual LAN (VLAN), and high-speed switched LANs.

For BCP configuration guidelines and restrictions and feature compatibility tables, see the “BCP Feature Compatibility” section of Chapter5, “Configuring the SIPs and SSC”

Configuring AToM over GRE

MPLS over generic routing encapsulation (MPLSoGRE) encapsulates MPLS packets inside IP tunnels, creating a virtual point-to-point link across non-MPLS networks. This allows users of primarily MPLS networks to continue to use existing non-MPLS legacy networks until migration to MPLS is possible. AToM (any transport over MPLS) over GRE includes support the following transports:

• ATM over MPLS
• Frame Relay over MPLS (FRoMPLS)
• High-Level Data Link Control (HDLC) over MPLS
• Scalable Ethernet over MPLS (EoMPLS)
• Circuit Emulation over Packet (CEoP)
• Hardware-based EoMPLS

AToMoGRE is supported only on the following hardware:

• SIP-400, 5x1 GE SPA, 2x1 GE SPA (Core facing)
• ATM SPA (SPA-2xOC3-ATM, SPA-4xOC3-ATM, SPA-1xOC12-ATM, SPA-1xOC48-ATM, CEoPs SPA (such as OC3, 24T1/E1) with Inverse Multiplexing (IMA) support, and all Ethernet interfaces
• Sup32, Sup720, RSP720

AToMoGRE supports the following features:

• Provider edge (PE)-to-PE, P-to-PE, and P-to-P tunneling of MPLS packets (See Figure 13-1, Figure 13-2, and Figure 13-3.)

Figure 13-1 PE-to-PE GRE Tunnel

Figure 13-2 P-to-PE GRE Tunnel

Figure 13-3 P-to-P GRE Tunnel

• IPv4 on customer edge (CE) facing interfaces.
• IPv4 on core facing interfaces.
• GRE 4-byte headers (no option fields).
• Nondedicated physical interface supporting both tunneled and nontunneled traffic.
• Multiple routes for the tunnel between the Cisco 7600 SIP-400 physical interface or subinterface and the IP cloud may exist. The routing protocol will pick only one route for MPLSoGRE traffic.
• No software-imposed limit on the maximum number of tunnels. The Cisco 7600 SIP-400 supports a maximum number of 128 tunnels. Tunnel traffic can be routed through Cisco 7600 SIP-400 main interfaces or subinterfaces.
• The Cisco 7600 SIP-400 physical interface or subinterface used for the tunnel endpoint can be used to carry native MPLS and AToMoMPLS and its variations: Hardware-based EoMPLS, FRoMPLS, PPPoMPLS, HDLCoMPLS, Scalable EoMPLS, and CEoP.

Note Switched Virtual Interfaces (SVI) are not supported with MPLSoGRE.

AToMoGRE Configuration Guidelines

The following guidelines apply to AToMoGRE:

• Ingress/egress features are not supported on the tunnel interface; they are supported on the physical interface or subinterface.
• Unsupported GRE options are: sequencing, checksum, key, source route.
• Some tunnel options are not supported: Carry Security Options of Client Packet, Unidirectional Link Routing, Mobile IP Path MTU Discovery.
• The Cisco 7600 SIP-400 physical interface or subinterface used for the tunnel endpoint cannot be used to carry Software-based EoMPLS and VPLS. Advanced features such as Carrier Supporting Carrier (CSC) and Inter-Autonomous Systems (Inter-AS) are not supported.
• AToM over GRE cannot be combined with the AToM Tunnel Select feature.

Configuring mVPNoGRE

The multicast Virtual Private Network over generic routing encapsulation (mVPNoGRE) provides a mechanism to send unicast and multicast packets across a non-MPLS network. This is accomplished by creating a GRE tunnel across the non-MPLS network. When MPLS (unicast VRF) or mVPN (multicast VRF) packets are sent across the non-MPLS network, they are encapsulated within a GRE packet and transverse the non-MPLS network through the GRE tunnel. Upon receiving the GRE packet at the other side of the non-MPLS network, it removes the GRE header and forwards the inner MPLS or unicast VRF or mVPN packet to its final destination.

Note For mVPNoGRE, there is one outer packet and two inner packets. The outer packet is unicast GRE. The first inner packet is multicast GRE (mVPN), and the second inner packet is normal (customer) multicast.

Note mVPNoGRE is not supported on Fast Ethernet SPAs on the Cisco 7600 SIP-200.

PE-to-PE Tunneling

mVPNoGRE uses the Provider Edge-to-Provider Edge (PE-to-PE) tunneling variation. mVPNoGRE provides a scalable way to connect multiple customer networks across a non-MPLS network. It does this by multiplexing traffic destined to multiple customer networks through a single GRE tunnel.

On each side of the non-MPLS network, each Customer Edge (CE) router is assigned a VPN Routing and Forwarding (VRF) number by the PE router. The IP networks behind the CE routers are learned by the PE router through a routing protocol such as BGP, OSPF or RIP. Routes to these networks are then stored in the VRF routing table for that CE router.

The PE router on one side of the non-MPLS network is learned by the PE router on the other side of the non-MPLS network though a routing protocol running within the non-MPLS network. Routes between the PE routers are stored in the main or default routing table.

Routes of the customer networks behind the PE router are learned by the other PE router through BGP and are not known to the non-MPLS network. This is accomplished by defining a static route to the BGP neighbor (the other PE router) through a GRE tunnel across the non-MPLS network. When routes are learned from the BGP neighbor, they will have the next-hop of the GRE tunnel and thus all customer network traffic will be sent using the GRE tunnel.

GRE Tunnel Attached to a Cisco 7600 SIP-400 Interface or Subinterface

For the Cisco 7600 series router to perform the MPLS and mVPN processing and have the Cisco 7600 SIP-400 perform the GRE processing, interfaces or subinterfaces must have an IP address. The MPLS and protocol independent multicast (PIM) configuration must be on the tunnel interface. The Cisco 7600 series router views the Cisco 7600 SIP-400 main interface or subinterface as an MPLS or PIM interface, so MPLS and mVPN processing is performed, and provides the Cisco 7600 SIP-400 with the correlation information needed to perform GRE processing.

Tunnel Interface Configuration

The ip pim sparse-mode command must be configured on the tunnel interface. It should not be configured on the physical interface or subinterface facing core. It is automatically configured on the Cisco 7600 SIP-400 interface or subinterface when a tunnel is attached to the interface or subinterface. The tunnel source IP address is typically a lookback address.

Displaying Unicast Routes

The display of unicast routes (Main Routing Table) shows the next hop for the BGP neighbor to be the Cisco 7600 SIP-400 interface or subinterface. On a router that natively supports this feature, the next hop for the BGP neighbor is the tunnel interface.

The following example shows the output from the show ip route command:

Displaying Multicast Routes

The display of multicast routes (groups) shows the output interface for the 239.0.0.0/8 group to be the Cisco 7600 SIP-400 interface or subinterface. On a router that natively supports this feature, the output interface is the tunnel interface.

The following example shows the output from the show ip mroute command:

Displaying Tunnel-to-Interface Mappings

The show cwan mplsogre command displays the tunnel-to-interface mappings. The following example illustrates the output of the show cwan mplsogre command:

Scalable EoMPLS

In Cisco IOS Release 12.2(33)SRA and later, Scalable EoMPLS now allows a Cisco 7600 SIP-400-based line card to face the CE. This configuration allows the platform to scale the number of EoMPLS virtual connections (VCs) that it can support from 4K to 12K. When AToM xconnect commands are placed on Cisco 7600 SIP-400 subinterfaces, the line card performs AToM imposition and disposition. Supervisor hardware will perform only MPLS switching on traffic from these interfaces. Additionally, configuring xconnect commands on Cisco 7600 SIP-400 subinterfaces will not consume globally significant VLANs on a per-xconnect basis. This change also provides the ability to support FRR on EoMPLS VCs with the same model as other CEF/MFI-based AToM configurations.

To achieve this scalability, Cisco 7600 SIP-400 must be the CE facing line card as opposed to the current model of a LAN line card facing the CE. With Cisco 7600 SIP-400 configured for Scalable EoMPLS, any line card capable of switching MPLS packets may be core facing.

On a Sup720 system, configuring EoMPLS under a non-VLAN interface is considered hardware-based EoMPLS. Configuring EoMPLS on a VLAN interface is considered to be software-based MPLS. Configuring EoMPLS on Cisco 7600 SIP-400 subinterfaces is considered to be Scalable EoMPLS.

Configuring Flow Control Support on the Link

Flow control is turned on or off based on the result of autonegotiation. Flow control is not supported on the Cisco 7600 SIP-200 and Cisco 7600 SIP-400, so it will always negotiate to off. Flow control can be configured independently of autonegotiation on the Cisco 7600 SIP-600. For information on this process, see the “Configuring Autonegotiation on an Interface” section.

This section discusses the following topics:

• Verifying Flow Control Status for an Ethernet SPA Interface on a Cisco 7600 SIP-200
• Verifying Flow Control Status for a Gigabit Ethernet SPA Interface on a Cisco 7600 SIP-400
• Configuring Flow Control for an Ethernet SPA Interface on a Cisco 7600 SIP-600

Verifying Flow Control Status for an Ethernet SPA Interface on a Cisco 7600 SIP-200

The following example shows how to verify that flow control pause frames are being transmitted and received for a Fast Ethernet SPA on the Cisco 7600 SIP-200.

Verifying Flow Control Status for a Gigabit Ethernet SPA Interface on a Cisco 7600 SIP-400

To verify flow control status on a Gigabit Ethernet interface on a SPA, use the show interfaces gigabitethernet privileged EXEC command and view the “output flow-control is” and “input flow-control is” output lines to see if input and output flow control is on or off. The “pause input” and “pause output” counters of the output of this command can be used to view the number of pause frames sent or received by the interface.

The following example shows that zero pause frames have been transmitted and received by the MAC device for interface port 1 (the second port) on the SPA located in subslot 0 of the SIP that is installed in slot 2 of the Cisco 7600 series router:

Configuring Flow Control for an Ethernet SPA Interface on a Cisco 7600 SIP-600

On the Cisco 7600 SIP-600, flow control can be configured on Ethernet SPA interfaces by entering the flowcontrol send command to configure the interface to transmit pause frames or the flowcontrol receive command to configure the interface to receive pause frames.

Note When a user configures flow control for either the transmit or receive direction, it is automatically enabled for both transmit and receive directions simultaneously.

Fast Ethernet SPAs have flow control enabled by default and it cannot be disabled.

Configuring 2-Port Gigabit Synchronous Ethernet SPA in Unicast Mode

In unicast mode, the slave port and the master port need to know each other’s IP address. Unicast mode has one to one mapping between the slave and the master. One master can have just one slave and vice-versa. Unicast mode is not a good option for scalability.

The command used for configuring 2-Port Gigabit Synchronous Ethernet SPA on unicast mode is clock-port.

Before configuring 2-Port Gigabit Synchronous Ethernet SPA on different modes, you need to configure the ToP 32 bit mask IP address. Note that ToP interface is addressed as ToP slot/subslot/2.

The following example shows the configuration of ToP 32 bit mask IP address:

The following example shows the configuration of 2-Port Gigabit Synchronous Ethernet SPA on the unicast mode:

Configuring 2-Port Gigabit Synchronous Ethernet SPA in Unicast Neg Mode

In unicast neg mode, master port knows the slave port at the outset. Slave port sends negotiation TLV when active and master port figures out that there is some slave port for synchronization. Unicast neg mode is a good option for scalability as one master has multiple slaves.

The command used for configuring 2-Port Gigabit Synchronous Ethernet SPA on unicast neg mode is clock-port.

The following example shows the configuration of 2-Port Gigabit Synchronous Ethernet SPA on the unicast neg mode:

Configuring 2-Port Gigabit Synchronous Ethernet SPA in Multicast Mode

In multicast mode, the master port sends sync message and announce on 224.0.1.129. The master port explicitly specifies multicast egress interface. The slave receives multicast message from the master port and gets to know master port’s IP address. To this IP address, slave port sends a unicast delay request. Master sends delay response back to slave port’s ip addreess in unicast mode. Multi cast mode is a good option for scalability as master needs to send just one set of sync messages instead of as many as number of slaves port.

The command used for configuring 2-Port Gigabit Synchronous Ethernet SPA on multicast mode is clock-port.

The following example shows the configuration of 2-Port Gigabit Synchronous Ethernet SPA on the multicast mode:

Verifying the PTP modes

Use the show ptp clock dataset current command to display the sample output.

Use the show ptp clock dataset default command to display the sample output.

Use the ptp clock dataset parent domain command to display the sample output.

Use the show ptp clock dataset time-properties domain command to display the sample output.

Configuring ToD on 1588V2 Master

These commands are used to configure ToD on a 1588V2 master:

This example shows the configuration of ToD on 1588V2 Master:

Verifying ToD Configuration on the 1588V2 Master

This example helps you verify the ToD configuration for 1588V2 Master.

Use the show platform ptp tod all command to display the sample output.

Configuring ToD on 1588V2 Slave

These commands are used to configure ToD on the 1588V2 slave:

This example shows the ToD configuration on the 1588V2 slave:

Verifying ToD Configuration on the 1588V2 Slave

This example helps you verify the ToD configuration on the1588V2 slave.

Use the show platform ptp tod all command to display the sample output.

Configuring Boundary Clock for 2-Port Gigabit Synchronous Ethernet SPA on Cisco 7600 SIP-400

Use the following configuration to configure the 2-Port Gigabit Synchronous Ethernet SPA on the Cisco SIP-400:

Configuring Network Clock for 2-Port Gigabit Synchronous Ethernet SPA on Cisco 7600 SIP-400

The 2-Port Gigabit Synchronous Ethernet SPA supports time, phase and frequency awareness through Ethernet networks. The 2-Port Gigabit Synchronous Ethernet SPA on the Cisco SIP-400 enables clock selection and translation between the various clock frequencies. If the 2-Port Gigabit Synchronous Ethernet SPA interoperates with devices that do not support synchronization, synchronization features can be disabled or partially enabled to maintain backward compatibility.

The network clock can be configured in global configuration mode and interface configuration mode:

• Configuring Network Clock in Global Configuration Mode
• Configuring Network Clock in Interface Configuration Mode

Configuring Network Clock in Global Configuration Mode

Use the following commands to configure the 2-Port Gigabit Synchronous Ethernet SPA on the Cisco SIP-400:

Command	Purpose
Router(config)# [no] network-clock synchronization automatic	Enables G.781 based automatic clock selection process. G.781 is the ITU-T Recommendation that specifies the synchronization layer functions.
Router(config)# [no] network-clock eec {1 | 2} Example Router(config)# network-clock eec 1	Configures the clocking system hardware with the desired parameters. These are the options: For option 1, the default value is EEC-Option 1 (2048). For option 2, the default value is EEC-Option 2 (1544).
Router(config)#[no] network-clock synchronization ssm option {1| 2 {GEN1 | GEN2}} Example Router(config)#network-clock synchronization ssm option 2 GEN1	Configures the router to work in a synchronized network mode as described in G.781. The following are the options: Option 1: refers to synchronization networks designed for Europe (SDH/ E1 framings are compatible with this option). Option 2: refers to synchronization networks designed for the US (SONET/T1 framings are compatible with this option). The default option is 1 and while choosing option 2, you need to specify the second generation message (GEN2) or first generation message (GEN1). Note Network-clock configurations that are not common between options need to be configured again.
Router(config)#[no] network-clock synchronization mode QL-enabled	Configures the automatic selection process for quality level QL-enabled mode. Note QL-enabled mode succeeds only if there are any synchronization interfaces that are capable of sending SSM.
Router(config)#[no] esmc process	Enables or disables the ESMC process at system level. Note This command fails if there is no SyncE capable interface installed in the platform.
Router(config)#network-clock hold-off {0 | <50-10000>} global Example Router(config)#network-clock hold-off 75 global	Configures general hold-off timer in milliseconds. The default value is 300 milliseconds. Note Displays a warning message for values below 300 ms and above 1800 ms.
Router(config)#network-clock external <slot/card/port> hold-off {0 | <50-10000>} Example Router(config)#network-clock external 3/1/1 hold-off 300	Overrides hold-off timer value for external interface. Note Displays a warning message for values above 1800 ms, as waiting longer causes the clock to go into the holdover mode.
Router(config)#network-clock wait-to-restore <0-86400> global Example Router(config)#network-clock external wait-to-restore 1000 global	Sets the value for the wait-to-restore timer globally. The wait to restore time is configurable in the range of 0 to 86400 seconds. The default value is 300 seconds. Caution Ensure that you set the wait-to-restore values above 50 seconds to avoid a timing flap.
Router(config)# [no] network-clock input-source <priority> {interface <interface_name> <slot/card/port> | top <slot/card/port/session> | {external <slot/card/port> [t1 {sf | efs | d4} | e1 [crc4| fas| cas [crc4] | 2m | 10m]}} Example Router(config)# network-clock input-source 23 top 2/0/1/3 Example for GPS interface Router(config)# network-clock input-source 1 external 3/0/0 10m	Configures a clock source line interface, an external timing input interface, GPS interface, or a packet-based timing recovered clock as the input clock for the system and defines its priority. Priority is a number between 1 and 250. This command also configures the type of signal for an external timing input interface. These signals are: T1 with Standard Frame format or Extended Standard Frame format. E1 with or without CRC4 2 MHz signal Default for Europe or Option I is e1 crc4 if the signal type is not specified. Default for North America or Option II is t1 esf if signal type is not specified. Note The no version of the command reverses the command configuration, implying that the priority has changed to undefined and the state machine is informed.
Router(config)#[no] network-clock revertive	Specifies whether or not the clock source is revertive. Clock sources with the same priority are always non-revertive. The default value is non-revertive. In non-revertive switching, a switch to an alternate reference is maintained even after the original reference recovers from the failure that caused the switch. In revertive switching, the clock switches back to the original reference after that reference recovers from the failure, independent of the condition of the alternate reference.
Router(config)#network-clock quality-level {tx | rx} <value> {interface <interface name> <slot/card/port> | external <slot/card/port> | controller <slot/card/port>} Example Router(config)# network-clock quality-level rx QL-PRC external 4/0/0 e1 crc4	Specifies the QL value for line or external timing input or output. The value is based on a global interworking Option. If Option 1 is configured, the available values are QL-PRC, QL-SSU-A, QL-SSU-B, QL-SEC, and QL-DNU. If Option 2 is configured with GEN 2, the available values are QL-PRS, QL-STU, QL-ST2, QL-TNC, QL-ST3, QL-SMC, QL-ST4 and QL-DUS. If option 2 is configured with GEN1, the available values are QL-PRS, QL-STU, QL-ST2, QL-SMC, QL-ST4 and QL-DUS
Router(config)#network-clock output-source line <priority> {interface <interface_name> | controller {t1 | e1} <slot/card/port>} {external <slot/card/port> [t1 {sf | efs | d4} | e1 [crc4| fas| cas [crc4] | 2m | 10m] } Example Router(config)# network-clock output-source line 1 interface GigabitEthernet3/0/0	Transmits the line clock sources to external timing output interfaces. Note A line can be configured to be the output source for only one external interface. This command provides the station clock output as per G.781. We recommend that you use the interface level command instead of global commands. Global command should preferably be used for interfaces that do not have an interface sub mode. For more information on configuring network clock in interface level mode, see Configuring Network Clock in Interface Configuration Mode.
Router(config)#network-clock output-source system <priority> {external <slot/card/port> [t1 {sf | efs | d4} | e1 [crc4| fas| cas [crc4] | 2m | 10m] } Example Router(config)#network-clock output-source system 55 external 3/0/1 t1 efs	Allows transmitting the system clock to external timing output interfaces. This command provides station clock output as per G.781. We recommend that you use the interface level command instead of global commands. Global command should preferably be used for interfaces that do not have an interface sub mode. For more information on configuring network clock in interface level mode, see Configuring Network Clock in Interface Configuration Mode.
Router(config)#[no] network-clock synchronization participate <slot number> Example Router(config)# [no] network-clock synchronization participate 2	Enables or disables a slot from participating in network-clock algorithm. By default all slots are participating slots. Note A slot cannot be disabled from participation if it's primary source, secondary source, or system to external is valid.

Configuring Network Clock in Interface Configuration Mode

Use the following commands in the interface configuration mode to configure the network clock and timers on the Cisco 7600 SIP-400, 2-Port Gigabit Synchronous Ethernet SPA.

Command	Purpose
Router(config-if)#[no] clock cleanup bits <slot> <subslot> [t1 {sf | esf} | e1 crc4 | 2m | japan] Example: Router(config-if)#clock cleanup bits 2/0 t1 esf	Enables or disables clock clean up on 2-Port Gigabit Synchronous Ethernet SPA.
Router(config-if)#clock source {internal | line| loop} Example: Router(config-if)#clock source internal	Sets the clock source on the interface to: Line: The system clock selection process selects the clock source line as the interface and uses the system clock for TX. Internal: The system clock selection process does not select clock source as the interface but it uses the system clock for TX. Loop: The system clock selection process selects the clock source line as the interface. For TX clock the interface uses the clock source received on the same interface. Note By default, the clock source on the interface is set to internal.
Router(config-if)#synchronous mode	Configures the ethernet interface to synchronous mode and this automatically enables the ESMC and Quality Level process on the interface. Note This command is applicable to Synchronous Ethernet capable interfaces. The default value is asynchronous mode.
Router(config-if)#esmc mode [tx | rx |<cr>] Example: Router(config-if)# esmc mode tx	Enables or disables ESMC process on the interface. Note If the interface is configured as line source but does not receive ESMC message from peer node on the interface, then the interface is removed from selectable clock source list. By default this is enabled for synchronous mode and disabled for asynchronous mode. Note This command is not supported for non-synchronous ethernet interfaces.
Router(config-if)#network-clock source quality-level <value> {tx | rx} Example: Router(config-if)# network-clock source quality-level QL-PRC	The command forces QL value to local clock selection process and it is considered by the clock selection process as a value from network. The value is based on global interworking Option. If Option 1 is configured, the available values are QL-PRC, QL-SSU-A, QL-SSU-B, QL-SEC, and QL-DNU. If Option 2 is configured with GEN 2, the available values are QL-PRS, QL-STU, QL-ST2, QL-TNC, QL-ST3, QL-SMC, QL-ST4 and QL-DUS. If option 2 is configured with GEN1, the available values are QL-PRS, QL-STU, QL-ST2, QL-SMC, QL-ST4 and QL-DUS
Router(config-if)#network-clock hold-off <0 | 50-10000> Example: Router(config-if)#network-clock hold-off 1000	Configures hold-off timer for interface. The default value is 300 milliseconds.
Router(config-if)#[no] network-clock wait-to-restore <0-86400> Example: Router(config-if)#network-clock wait-to-restore 1000	Configures the wait-to-restore timer on the SyncE interface. Caution Ensure that you set the wait-to-restore values above 50 seconds to avoid timing flap.
Router(config-if)# [no] esmc mode ql-disabled	Disables the quality level mode. The default mode for synchronous ethernet is ql-enabled. Note This command is not supported for non-synchronous ethernet interfaces.

Managing Synchronization

You can manage the synchronization using the following management commands:

Sample configuration

Example 13-1 Configuration for QL-enabled mode clock selection.

Example 13-2 Configuration for Line to External

Example 13-3 Configuration for Hybrid Mode Clock Selection

Example 13-4 GPS Configuration

Verifying the Synchronous Ethernet configuration

Use the show network-clock synchronization command to display the sample output.

Use the show network-clock synchronization detail command to display all details of network-clock synchronization parameters at the global and interface levels.

Use the show interface accounting command to display the sample output.

Use the show esmc command to display the sample output.

Use the show esmc detail command to display all details of esmc parameters at the global and interface levels.

Troubleshooting the Synchronous Ethernet configuration

The following debug commands are available for troubleshooting the Synchronous Ethernet configuration on the Cisco 7600 ES+ Line Card:

Troubleshooting Scenarios

Note Before you troubleshoot, ensure that all the network clock synchronization configurations are complete.

Table 13-2 provides the troubleshooting scenarios encountered while configuring the synchronous ethernet.

Table 13-2 Troubleshooting scenarios

Problem	Solution
Incorrect clock limit set or disabled queue limit mode	Verify that there are no alarms on the interfaces. Use the show network-clock synchronization detail RP command to confirm. Warning We suggest you do not use these debug commands without TAC supervision. Use the show network-clock synchronization command to confirm if the system is in revertive mode or non-revertive mode and verify the non-revertive configurations as shown in this example: RouterB#show network-clocks synchronization Symbols: En - Enable, Dis - Disable, Adis - Admin Disable NA - Not Applicable - Synchronization source selected # - Synchronization source force selected & - Synchronization source manually switched Automatic selection process : Enable Equipment Clock : 1544 (EEC-Option2) Clock Mode : QL-Enable ESMC : Enabled SSM Option : GEN1 T0 : POS3/1/0 Hold-off (global) : 300 ms Wait-to-restore (global) : 0 sec Tsm Delay : 180 ms Revertive : Yes<<<<If it is non revertive then it will show NO here. Nominated Interfaces Interface SigType Mode/QL Prio QL_IN ESMC Tx ESMC Rx Internal NA NA/Dis 251 QL-ST3 NA NA SONET 3/0/0 NA NA/En 3 QL-ST3 NA NA *PO3/1/0 NA NA/En 1 QL-ST3 NA NA
	SONET 2/3/0 NA NA/En 4 QL-ST3 NA NA
	Reproduce the current issue and collect the logs using the debug network-clock errors, debug network-clock event, and debug network-clock sm RP commands. Warning We suggest you do not use these debug commands without TAC supervision. Contact Cisco technical support if the issue persists.
Incorrect quality level (QL) values when you use the show network-clock synchronization detail command.	Use the network clock synchronization SSM ( option 1 |option 2) command to confirm that there is no framing mismatch. Use the show run interface command to validate the framing for a specific interface. For the SSM option 1 framing should be SDH or E1 and for SSM option 2, it should be SONET or T1. Reproduce the issue using the debug network-clock errors, debug network-clock event and debug platform ss m RP commands or enable the debug hw-module subslot command (this command is specific to SIP-400). Warning We suggest you do not use these debug commands without TAC supervision.
Error message “%NETCLK-6-SRC_UPD: Synchronization source SONET 2/3/0 status (Critical Alarms(OOR)) is posted to all selection process" displayed.	Interfaces with alarms or OOR cannot be the part of selection process even if it has higher queue limit or priority. Use the debug platform network-clock RP command to troubleshoot network clock issues. Reproduce the issue using the debug platform network-clock command enabled in a route processor or enable the debug network-clock event and debug network-clock errors RP commands. Warning We suggest you do not use these debug commands without TAC supervision.
Problem	Solution
Incorrect clock limit set or disabled queue limit mode	Verify that there are no alarms on the interfaces. Use the show network-clock synchronization detail RP command to confirm. Warning We suggest you do not use these debug commands without TAC supervision. Use the show network-clock synchronization command to confirm if the system is in revertive mode or non-revertive mode and verify the non-revertive configurations as shown in this example: RouterB#show network-clocks synchronization Symbols: En - Enable, Dis - Disable, Adis - Admin Disable NA - Not Applicable - Synchronization source selected # - Synchronization source force selected & - Synchronization source manually switched Automatic selection process : Enable Equipment Clock : 1544 (EEC-Option2) Clock Mode : QL-Enable ESMC : Enabled SSM Option : GEN1 T0 : POS3/1/0 Hold-off (global) : 300 ms Wait-to-restore (global) : 0 sec Tsm Delay : 180 ms Revertive : Yes<<<<If it is non revertive then it will show NO here. Nominated Interfaces Interface SigType Mode/QL Prio QL_IN ESMC Tx ESMC Rx Internal NA NA/Dis 251 QL-ST3 NA NA SONET 3/0/0 NA NA/En 3 QL-ST3 NA NA *PO3/1/0 NA NA/En 1 QL-ST3 NA NA
	SONET 2/3/0 NA NA/En 4 QL-ST3 NA NA

Configuring EtherChannels

An EtherChannel bundles individual Ethernet links into a single logical link that provides the aggregate bandwidth of up to eight physical links.

Note EtherChannel is only supported on the 10-Port Gigabit Ethernet SPA and the 1-Port 10-Gigabit Ethernet SPA on the Cisco 7600 SIP-600. EtherChannel is not supported on the Cisco 7600 SIP-400 or on a Fast Ethernet SPA on the Cisco 7600 SIP-200.

For additional information on EtherChannels, see the “Configuring EtherChannels” section in the “Configuring Layer 3 and Layer 2 EtherChannel” chapter of the Cisco 7600 Series Router Cisco IOS Software Configuration Guide publication that corresponds to your Cisco IOS software release.

Configuring Virtual Private LAN Service (VPLS) and Hierarchical VPLS

VPLS enables geographically separate LAN segments to be interconnected as a single bridged domain over a packet switched network, such as IP, MPLS, or a hybrid of both bridging techniques.

VPLS with EoMPLS uses an MPLS-based provider core, where the PE routers have to cooperate to forward customer Ethernet traffic for a given VPLS instance in the core. VPLS uses the provider core to join multiple attachment circuits together to simulate a virtual bridge that connects the multiple attachment circuits together. From a customer point of view, there is no topology for VPLS. All of the CE devices appear to connect to a logical bridge emulated by the provider core.

For VPLS and hierarchical virtual private LAN service (H-VPLS) configuration guidelines, restrictions, and feature compatibility tables, see the “Configuring Virtual Private LAN Service” section.

Note H-VPLS is not available on Fast Ethernet SPAs.

Configuring Connectivity Fault Management (CFM)

A Metro Ethernet network consists of networks from multiple operators supported by one service provider and connects multiple customer sites to form a virtual private network (VPN). Networks provided and managed by multiple independent service providers have restricted access to each others equipment. Because of the diversity in these multiple-operator networks, failures must be isolated quickly. As a Layer 2 network, Ethernet needs to be capable of reporting network faults at Layer 2.

IEEE 802.3ah is a point-to-point and per physical wire OAM protocol that detects and isolates connectivity failures in the network.

Ethernet Connectivity Fault Management (CFM) is an end-to-end per-service-instance Ethernet layer Operation, Administration, and Management (OAM) protocol. It includes proactive connectivity monitoring, fault verification, and fault isolation for large Ethernet metropolitan-area and wide-area networks (MANs and WANs). See the Ethernet Connectivity Fault Management document for more information on this feature.

CFM includes a family of protocols that provides capabilities to detect, verify, isolate, and report end-to-end Ethernet connectivity faults. The protocols employ regular Ethernet frames that travel in-band with the customer traffic. Devices that cannot interpret CFM Messages forward them as normal data frames. CFM frames are distinguishable by Ether-Type 89-02 (and MAC Address for multicast messages). This technology was standardized by the IEEE standard 802.1ag-2007.

Connectivity Fault Management (CFM) is the indispensable capability service providers require to deploy large-scale multi-vendor Metro Ethernet services. This feature upgrades the implementation of CFM to be compliant with the IEEE 802.1ag with the current standard, 802.1ag-2007 and implementation of CFM over L2VFI (Layer 2 Virtual Forwarding Instance Information), Xconnect, EVC, and Switchport.

IEEE 802.1ag draft 8.1 Metro Ethernet Connectivity Fault Management (CFM) incorporates several OAM facilities that allow you to manage Metro Ethernet networks, including an Ethernet continuity check, end-to-end ethernet traceroute facilty using Linktrace message (LTM), Linktrace reply (LTR), ethernet ping facility using Loopback Message (LBM), and a Loopback Reply (LBR). These Metro Ethernet CFM protocol elements quickly identifies problems in the network.

CFM Concepts

An understanding of the following concepts is essential for configuring the CFM for Cisco 7600:

• A maintenance domain (MD) is an administrative domain used to manage and administer a network. A Domain is assigned a unique maintenance level, in the range of 0 to 7, by the administrator. This maintenance level is useful for defining the hierarchical relationship of domains. Maintenance Domains may nest or touch, but cannot intersect. For two nested domains, the outer domain must have a higher maintenance level than the one it engulfs. A maintenance domain is defined by provisioning bridge ports are interior to the domain.
• A Maintenance Association (MA) identifies a service that can be uniquely identified within the maintenance domains. The CFM protocol runs within a particular Maintenance Association
• Maintenance association end points (MEPs) reside at the edge of the maintenance domains and are active elements of Ethernet CFM. They periodically transmit messages to and receive messages from other MEPs within a domain.
• Maintenance domain intermediate points (MIPs) are internal to the maintenance domain and are passive elements of Ethernet CFM. They catalog information received from MEPs, and only respond to particular CFM messages
• Protocols (Continuity Check, Loopback, and Linktrace) that are used to manage faults.

– Continuity Check Messages (CCM) are multicast heart-beat messages exchanged periodically between maintenance association End Points. They allow Maintenance association End Points to discover other Maintenance association End Points within a Maintenance Association, and allow Maintenance association Intermediate Points to discover Maintenance association End Points. They are transmitted frequently enough so that consecutive message can be lost without causing the information to time out in any of the receiving Maintenance association End Points.

– Link Trace or Traceroute Messages (LTM) are multicast messages that are intercepted at the Maintenance Points along the path and processed, and either retransmitted or dropped. Each hop where there is a Maintenance Point at the same level, an LTR message transmits back to the originating MEP. It is similar in concept to IP Traceroute.

– Loopback Messages are sent by MEPs to indicate whether or not the destination is reachable. Loopback does not allow hop-by-hop discovery of the path. Loopback messages are destined for unicast addresses

• Fault alarms are unsolicited notifications generated when CFM detects a fault in a Maintenance Association and alert the system administrator.
• Y.1731 is an ITU-T standard that extends support for Ethernet loopback, multicast loopback, AIS, maintenance communication channel and performance measurements to the CFM frame format.
  
  The following table highlights the support for Y1731 Loopback for SIP-600 on 7600 platform:

LCK Type	SIP-600
VLAN LCK	Supported
PORT LCK	Supported
EEP LCK	Not Supported
VLAN LCK on L2 PC	Not Supported
EFP LCK on EVC PC	Not Supported
VLAN LCK on L3 PC	Not Supported
PORT LCK on L2/L3/EVC PC	Not Supported
PORT LCK on L2/L3/EVC PC member	Not Supported
VLAN/EFP LCK on L2/L3/EFP PC member	Not Supported
EFP LCK on xconnect	Not Supported
LCK on VFI MEP	Not Supported

For more information on CFM, see Cisco IOS Carrier Ethernet Configuration Guide, Release 12.2SR at

http://www.cisco.com/en/US/docs/ios-xml/ios/cether/configuration/12-2sr/ce-elmi.html

For more information about the commands used in this section, see Cisco IOS Ethernet Command Reference guide at http://www.cisco.com/en/US/docs/ios/cether/command/reference/ce_book.html

Ethernet CFM Support on Cisco 7600 SIP Line Cards

The following guidelines apply to the Cisco 7600 series routers SIP line cards:

• Ethernet SPAs on SIP-400 cannot be configured as switchport..
• SIP-400 only supports CFM D8.1 over routed ports and L2 VFI.
• SIP-600 supports CFM D8.1 over switchports and routed ports.
• SIP-200 does not support CFM D8.1.
• CFM D8.1 QinQ configuration is not supported on sub- interface.
• Ping and traceroute do not work with OFM on supervisor and LAN ports.
• With lower CC intervals, CC packets are transmitted in bursts. Rate-limiters should be configured appropriately; otherwise, remote MEPs may flap.
• Port-mep ping and traceroute for Meps on trunk port native vlans, fails. This will work only on ES-20 and ES-40 LCs..
• 802.3ah E-OAM-The remote-loopback TEST status is not retained across switchovers and works with longer OAM timeout value greater than 10 secs.
• CFM D1.0 to D8.1 Migration works with reduced scale of 2k MEPs on routed ports.
• Null Maintenance Domain name is not supported
• You must explicitly configure Maintenance Associations that have services for VLAN for devices that have MPs. This is not required for EVC since the EVC name is used for MA implicitly
• Port Maintenance End Point is not supported for MEPs with no VLANs
• You cannot configure MIPs at a lower or an equal level to a MEP on port
• Scheduled linktrace is not supported
• Multiple domains with the same level can be configured, that is, different domain names at the same maintenance level. Associating a single domain name with multiple maintenance levels is not supported.
• Routed (Layer 3) ports may only have outward facing MEPs; no MIPs are allowed. MIP configuration on a routed port will be rejected and an error message will be generated.
• Configuring a MEP on an interface with a level higher than the MIP level will generate an error message.
• A single interface may belong to multiple domains, configuring multiple instances of the ethernet cfm mep level command for different domains is supported.
• A specified domain must be configured or an error message will be displayed.
• If an interface is provisioned to be a MIP for a certain maintenance level, and MEP is configured for a VLAN on the same level, an error message will be displayed.
• If the VLAN for which a MEP is configured gets removed from an interface, the MEP configuration will be removed as well, since the definition of the MEP is tied to the VLAN.
• Hardware EoMPLS is not supported.

Supported Line Cards

CFM is disabled by default; it must be enabled explicitly. Use the [no] ethernet cfm global command to enable or disable CFM D8.1 feature on the following line cards:

• ES20 and ES40:Switchports, routed ports, EVC BD and and Layer 2 Virtual Forwarding Instance (L2VFI). Refer to the Cisco 7600 Series Ethernet Services 20G Line Card Configuration Guide
• SIP400:Routed ports, and Layer 2 Virtual Forwarding Instance ( L2VFI).
• SIP600:Switchports, and routed ports.

Configuring Maintenance Domains and Maintenance Points

This section describes configuring maintenance domains and maintenance points.

Configuring the Ethernet Domain

Use the following command to configure the Ethernet domain:

SUMMARY STEPS

1. enable

2. configure terminal

3. ethernet cfm domain domain-name level 0 to 7 direction outward

DETAILED STEPS

Configuring Maintenance Points

To set a port as internal to a maintenance domain and define it as a MEP, use the following command.

SUMMARY STEPS

1. enable

2. configure terminal

3. interface interface

4. ethernet cfm mep level 0 to 7 inward | outward domain-name mpid id vlan vlan-id | any | vlan-id - vlan-id vlan-id - vlan-id

DETAILED STEPS

\

Command	Purpose
enable   Router> enable	Enables privileged EXEC mode. Enter your password if prompted.
configure terminal   Router# configure terminal	Enters global configuration mode.
Router(config)# interface interface Example Router(config)# interface interface1	Enters the interface configuration mode
Router(config-interface)# ethernet cfm mep level 0 to 7 inward | outward domain-name mpid id vlan vlan-id | any | vlan-id - vlan-id vlan-id - vlan-id Example Router(config-interface1)# ethernet cfm mep level 7 inward domain1 mpid 22718 vlan 32	inward | outward—Indicates the direction of the MEP as either inward (towards the bridge) or outward (towards the wire). The default is inward facing. domain-name —A string of maximum length of 256 characters. id —A string of maximum length of 256 characters. vlan-id —An integer from 1 to 4095. Note A comma must be entered to separate each VLAN ID range from the next range. Note Hyphen must be entered to separate the starting and ending VLAN ID values that are used to define a range of VLAN IDs.

Configuring CFM in the EVC

Use the commands in the following sections to configure CFM on the EVC.

SUMMARY STEPS

1. enable

2. configure terminal

3. ethernet cfm global

4. ethernet cfm mip {autocreate|filter}

5. ethernet cfm mip auto-create level

6. ethernet cfm mip auto-create level {evc|vlan}

7. ethernet cfm mip auto-create level evc name

8. ethernet cfm domain domain level

9. service {word|number|vlan-id |vpn-id}

10. service evc {evc|port}

11. service evc evc name

12. service evc {direction|vlan}

DETAILED STEPS

Sample Configuration

The following example shows the CFM configuration for an EVC interface.

interface GigabitEthernet3/0/10

description connec to CE1 GigabitEthernet0/0

ip arp inspection limit none

no ip address

mls qos trust dscp

ethernet uni id customer1

service instance 1 ethernet evc10

encapsulation dot1q 2

ethernet lmi ce-vlan map 1-10

bridge-domain 2

cfm mep domain L7 mpid 1502

The following example shows CFM configuration over a switchport interface configuration mode.

interface GigabitEthernet3/0/10

switchport

switchport mode trunk

shutdown

mls qos trust dscp

no keepalive

ethernet cfm mep domain L7 mpid 1001 vlan 10

end

The following example shows CFM configuration over a switchport interface configuration mode.

ethernet cfm domain L6 level 6

service xconn evc xconn

Verifying Ethernet CFM Configuration

The following commands can be used to verify CFM configuration:

The show ethernet cfm maintenance-points local displays the local maintenance points that are configured:

The ping ethernet command shows loopback messages on the destination MAC address:

Debugging the Ethernet CFM Configuration

Use the following commands to debug the Ethernet CFM configuration:

Troubleshooting CFM Features

Table 13-3 provides troubleshooting solutions for the CFM features.

Table 13-3 Troubleshooting Scenarios

Configuring Ethernet Operations, Administration, and Maintenance

The Gigabit Ethernet SPAs support OAM as defined by IEEE 802.3ah, Ethernet in the First Mile. IEEE 802.3ah operates on a single point-to-point link between two devices using slow protocol packets called OAM protocol data units (OAMPDUs) that are never forwarded.

IEEE 802.3ah defines five functional areas, of which the Gigabit Ethernet SPAs on the Cisco 7600 series router support the following three:

• OAM discovery—Supports identification of OAM support and capabilities on a peer device.
• Link monitoring—Provides event notification and link information. It also supports polling and response (but not writing) of the 802.3ah MIB.
• Remote failure indication—Supports informing a peer device that the receive path is down. This requires support of unidirectional operation on the link.

Ethernet OAM Configuration Guidelines

When configuring Ethernet OAM on the SPAs, consider the following guidelines:

• See Table 13-4 for information about where the OAM features for SPA interfaces are supported.
• On Gigabit Ethernet links, the unidirectional fault signaling support in OAM and the autonegotiation capabilities of Gigabit Ethernet (IEEE 802.3z) are mutually exclusive. You must disable autonegotiation for OAM fault signaling to be sent over unidirectional links.
• Ethernet OAM requires point-to-point links where OAMPDUs are created and terminated.
• On a 7600 HA system, you have to explicitly set the timeout session to more than 5 seconds. Use the ethernet oam timeout < time > command to configure the timeout session. If the timeout session is less than 5 seconds, the EOAM sessions do not get terminated while switchover.
• When configuring Ethernet OAM interface modes, consider the following guidelines:

– At least one of the peer interfaces must be in active mode.

– The peer interfaces either can be both in active mode, or one can be in active mode and the other in passive mode.

– You can change Ethernet OAM modes without disabling OAM.

• When using templates to configure Ethernet OAM interfaces, consider the following guidelines:

– If you use a template to configure common or global OAM characteristics and apply it an interface, you can override any of the configuration statements in the template by configuring the same command at the interface with a different value.

– You can define multiple templates to create different sets of link monitoring characteristics.

– You can only apply one template to any single Ethernet OAM interface.

Table 13-4 provides information about where the OAM features for SPA interfaces are supported.

Ethernet OAM Configuration Tasks

The following sections describe the Ethernet OAM configuration tasks:

• Enabling OAM on an Interface (required)
• Enabling and Disabling a Link Monitoring Session (optional)
• Starting and Stopping Link Monitoring Operation (optional)
• Configuring Link Monitoring Options (optional)
• Configuring Remote Failure Indication Actions (optional)
• Configuring Global Ethernet OAM Options Using a Template (optional)
• Verifying Ethernet OAM Configuration

Enabling OAM on an Interface

OAM is disabled on an interface by default. When you enable OAM on an interface, the interface automatically advertises to the remote peer that it supports link monitoring during OAM discovery. Link monitoring support must be agreed upon by the peer interfaces for monitoring to operate across the link.

Once link monitoring support is achieved between the peer interfaces, the interface will start the link monitoring operation, and send event OAMPDUs when errors occur locally, and interpret event OAM PDUs received by the remote peer.

You do not need to explicitly configure link monitoring support, or start the link monitoring operation on the link unless you have previously disabled monitoring support or operation on the interface.

To enable OAM features on a Gigabit Ethernet interface, use the following commands beginning in global configuration mode:

Enabling and Disabling a Link Monitoring Session

The OAM peer interfaces must establish a link monitoring session before the actual operation of link monitoring can begin. If you have enabled OAM on the interface, and have not explicitly disabled link monitoring support on the interface, then you do not need to explicitly configure link monitoring support on the interface to establish a session.

The ethernet oam link-monitor supported command automatically runs in the background when you configure the ethernet oam interface configuration command. Be sure that at least one of the Ethernet OAM peers is configured for active mode so that a session can be established.

To explicitly configure and enable a link monitoring session on an interface, use the following command in interface configuration mode:

To disable a link monitoring session on an interface, use the following command in interface configuration mode:

Starting and Stopping Link Monitoring Operation

If a link monitoring session is established among the Ethernet OAM peer interfaces, then sending and receiving of Event Notification OAMPDUs can begin between the peers. This link monitoring operation across the link automatically starts when you enable OAM on the interface.

The ethernet oam link-monitor on command automatically runs in the background when you configure the ethernet oam interface configuration command.

You can stop and restart the operation of link monitoring (or, the sending and receiving of Event Notification OAMPDUs on a link). Stopping link monitoring operation is not the same thing as disabling link monitoring support. When you stop link monitoring operation, the interface is still configured to support link monitoring with its peer, but just is not actively sending and receiving Event Notification OAMPDUs.

To explicitly configure and start link monitoring operation on an interface, use the following command in interface configuration mode:

To stop link monitoring operation on an interface, use the following command in interface configuration mode:

Configuring Link Monitoring Options

When OAM link monitoring is active, Event Notification OAMPDUs are sent to a remote OAM client when errors are detected locally. You can configure certain windows and thresholds to define when these error event notifications are triggered. If you do not modify the link monitoring options, default values are used for the window periods and low thresholds.

The Gigabit Ethernet SPAs support the following types of error events as defined by IEEE 802.3ah:

• Errored Symbol Period (errored symbols per second)—This event occurs when the number of symbol errors during a specified period exceeds a threshold. These are coding symbol errors (for example, a violation of 4B/5B coding).
• Errored Frame (errored frames per second)—This event occurs when the number of frame errors during a specified period exceeds a threshold.
• Errored Frame Period (errored frames per N frames)—This event occurs when the number of frame errors within the last N frames exceeds a threshold.
• Errored Frame Seconds Summary (errored seconds per M seconds)—This event occurs when the number of errored seconds (one second intervals with at least one frame error) within the last M seconds exceeds a threshold.

Cisco Systems adds the following types of vendor-specific error events:

• Receive CRC (errored frames per second)—This event occurs when the number of frames received with CRC errors during a specified period exceeds a threshold.
• Transmit CRC (errored frames per second)—This event occurs when the number of frames transmitted with CRC errors during a specified period exceeds a threshold.

The link monitoring options can be configured in a global template that can be applied to one or more interfaces, and also can be explicitly configured at the interface.

Specifying Errored Symbol Period Link Monitoring Options

The errored symbol period link monitoring options include the ability to specify the number of symbols to be tracked or counted for errors, and the high and low thresholds for triggering the Errored Symbol Period Link Event.

To specify errored symbol period link monitoring options, use the following commands in interface configuration or template configuration mode:

Specifying Errored Frame Link Monitoring Options

The errored frame link monitoring options include the ability to specify a period of time during which frame errors are tracked or counted, and the high and low thresholds for triggering the Errored Frame Link Event. The Gigabit Ethernet SPAs on the Cisco 7600 series router count general frame errors, such as CRC errors and corrupted packets, as errored frames.

To specify errored frame link monitoring options, use the following commands in interface configuration or template configuration mode:

Specifying Errored Frame Period Link Monitoring Options

The errored frame period link monitoring options include the ability to specify the number of error frames to be tracked or counted for errors, and the high and low thresholds for triggering the Errored Frame Period Link Event. The Gigabit Ethernet SPAs on the Cisco 7600 series router count general frame errors, such as CRC errors and corrupted packets, as errored frames.

To specify errored frame period link monitoring options, use the following commands in interface configuration or template configuration mode:

Specifying Errored Frame Seconds Summary Link Monitoring Options

The errored frame seconds summary link monitoring options include the ability to specify a period of time during which tracking of a number of errored-seconds periods (one-second intervals with at least one frame error) occurs, and the high and low thresholds for triggering the Errored Frames Seconds Summary Link Event.

To specify errored frame seconds summary link monitoring options, use the following commands in interface configuration or template configuration mode:

Specifying Receive CRC Link Monitoring Options

The receive CRC link monitoring options include the ability to specify a period of time during which tracking of frames received with CRC occurs, and the high and low thresholds for triggering the error. Receive CRC link monitoring is a Cisco-specific implementation and is only locally significant to the Ethernet OAM interface on the Cisco 7600 series router.

To specify receive CRC link monitoring options, use the following commands in interface configuration or template configuration mode:

Specifying Transmit CRC Link Monitoring Options

The transmit CRC link monitoring options include the ability to specify a period of time during which tracking of frames transmitted with CRC occurs, and the high and low thresholds for triggering the error. Transmit CRC link monitoring is a Cisco-specific error event and is only locally significant to the Ethernet OAM interface on the Cisco 7600 series router.

To specify transmit CRC link monitoring options, use the following commands in interface configuration or template configuration mode:

Specifying a High Threshold Action

When you configure high thresholds for OAM link monitoring, you can specify an action to be taken when the high threshold is exceeded.

When configuring high threshold actions, consider the following guidelines:

• There is no default action.
• If you configure a high threshold but do not configure any corresponding action, only a message appears on the syslog and no other action is taken on the interface.
• If you want to associate different high threshold actions for different kinds of link monitoring functions, you can use configuration templates. However, only one configuration template can be applied to any Ethernet OAM interface.
• Only one high threshold action can be configured for any Ethernet OAM interface.

To configure an action when a high threshold for an error is exceeded on an Ethernet OAM interface, use the following command in interface configuration or template configuration mode:

Configuring Remote Failure Indication Actions

When an RFI event occurs locally, the local client sends an Information OAMPDU to its peer with a bit selected that indicates the type of failure. The Gigabit Ethernet SPAs on the Cisco 7600 series router process all of the following types of Remote Failure Indication (RFI) conditions as defined by IEEE 802.3ah:

• Critical Event—This type of RFI is sent when an unspecified critical event has occurred. These events are vendor specific, and the failure indication might be sent immediately and continuously.
• Dying Gasp—This type of RFI is sent when an unrecoverable condition (for example, a power failure) has occurred. The conditions for a dying gasp RFI are vendor specific, and the failure indication might be sent immediately and continuously. The Gigabit Ethernet SPAs on the Cisco 7600 series router generate a Dying Gasp RFI when an interface is error-disabled or administratively shut down. This is the only type of RFI that the Gigabit Ethernet SPAs on the Cisco 7600 series router generate.
• Link Fault—This type of RFI is sent when a loss of signal is detected by the receiver (for example, a peer's laser is malfunctioning). A link fault is sent once per second in the Information OAMPDU. The link fault RFI applies only when the physical sublayer is capable of independent transmit and receive.

When the Gigabit Ethernet SPAs receive an OAMPDU with an RFI bit selected, a syslog message is created providing the failure reason, as shown in the following example:

You can configure a response, or action, by the local client to shut down the OAM interface when it receives Information OAMPDUs with a Dying Gasp RFI bit selected.

To configure an error disable action for the local Ethernet OAM interface, use the following command in interface configuration or template configuration mode:

Configuring Global Ethernet OAM Options Using a Template

Create configuration templates when you have a common set of link-monitoring or remote-failure characteristics that you want to apply to multiple Ethernet OAM interfaces. This streamlines Ethernet OAM interface configuration.

Although you can configure multiple configuration templates, only one template can be associated with any single Ethernet OAM interface. You can override any commands defined within a template by explicitly configuring the same command (that is predefined by the template) in interface configuration mode.

To configure global Ethernet OAM interface options using a template, use the following command beginning in global configuration mode:

Verifying Ethernet OAM Configuration

To verify the Ethernet OAM configuration, use the following commands in privileged EXEC configuration mode:

This section includes the following topics:

• Verifying an OAM Session
• Verifying OAM Discovery Status
• Verifying Information OAMPDU and Fault Statistics
• Verifying Link Monitoring Configuration and Status

Verifying an OAM Session

To verify an OAM session, use the show ethernet oam summary command.

The following example shows that the local OAM client is established on the second Gigabit Ethernet SPA interface (1) located in subslot 1 of the SIP installed in chassis slot 6 of the Cisco 7600 series router (Gi6/1/1).

The local client interface is in session with a remote client with MAC address 0012.7fa6.a700 and organizationally unique identifier (OUI) 00000C, which is the OUI for Cisco Systems. The remote client is in active mode, and has established capabilities for link monitoring and remote loopback for the OAM session.

Verifying OAM Discovery Status

To verify OAM Discovery status on the local client and remote peer, use the show ethernet oam discovery command as shown in the following example:

Verifying Information OAMPDU and Fault Statistics

To verify statistics for information OAMPDUs and local and remote faults, use the show ethernet oam statistics command as shown in the following example:

Verifying Link Monitoring Configuration and Status

To verify link monitoring configuration and status on the local client, use the show ethernet oam status command. The highlighted “Status” field in the following example shows that link monitoring status is supported and enabled (on).

Verifying Status of the Remote OAM Client

To verify the status of a remote OAM client, use the show ethernet oam summary and show ethernet oam status commands.

To verify the remote client mode and capabilities for the OAM session, use the show ethernet oam summary command and observe the values in the Mode and Capability fields. The following example shows that the local client (local interface Gi6/1/1) is connected to the remote client

Configuring IP Subscriber Awareness over Ethernet

Container interfaces are used to apply hardware specific features like Security Access Control List (ACL) and Policy Based Routing (PBR) which then can be inherited to all IP session interfaces attached to a container interface.

To form the association between a container interface and an IP session interface/subinterface, use the container command under IP session interfaces/subinterfaces.

It is required to configure the VRF (not required in the case of global VRF) on the container and the subinterface in order to make an association between them using the container command.