|
|
This chapter describes the procedures for configuring the Cisco Optical Networking System (ONS) 15304 to be managed remotely through the in-band SDH Regenerator Section Data Communications Channel (SDCC) links. This chapter also describes possible strategies for interfacing to the wide-area data communications network (DCN) that provides management connectivity between management sites and one or more SDH rings.
In this document, the management network within the SDH ring formed from the SDCC links is distinguished from the lower speed management wide-area network referred to as DCN. The term SDCC refers to the 192 kbps in-band channel formed from overhead bytes D1, D2, and D3. The DCN is a separate, packet-based wide-area network usually based on X.25 or TCP/IP protocols.
When the Cisco ONS 15304 is first installed, SDCC and DCN network interfaces need to be configured and activated as part of the node installation process to permit remote management. The procedures described in this chapter should be conducted in close physical proximity to the Cisco ONS 15304, as remote management can only be partially configured. Consequently, recovery from accidental misconfiguration can be difficult if access to the console port is not available. Configuration of the Cisco ONS 15304 through remote modem attached to the console is viable alternative, although physical access to the Cisco ONS 15304 can still be required to help isolate fiber connectivity problems during node installation if the SDCC interfaces do not come up.
The Cisco ONS 15304 is a Cisco IOS-based device managed principally through IP protocols but also supports CLNS protocols for interoperability with other "foreign" network elements manufactured by other vendors. The Cisco ONS 15304 supports IP natively as well as CLNS for compatibility. The support for both IP and CLNS protocol stacks allow the Cisco ONS 15304 to have rich management capabilities afforded by IP protocols, while preserving SDH/GR-253 compatibility with network elements manufactured by other vendors on the same ring.
From an application layer perspective, the Cisco ONS 15304 is managed through Telnet, SNMP, TFTP, DNS, and other Internet-based protocols. This IP-oriented management methodology contrasts with traditional SDH/GR-253-based network elements that support only OSI protocols, and specify the use of CLNS, IS-IS, ES-IS at the network layer.
In order to be compatible and to allow management traffic to traverse jointly between the Cisco ONS 15304 and foreign network elements manufactured by other vendors, the Cisco ONS 15304 needs to be configured to enable CLNS so that existing ring management capabilities and traffic are not disrupted. This usually implies the SDCC interfaces on the Cisco ONS 15304 will need to be configured to run CLNS as a minimum under nominal circumstances. CLNS can be activated on other interfaces if desired, but this may not be necessary. The information given in this section focuses primarily on setting up CLNS only on the SDCC interfaces.
This chapter describes the process for setting up the management plane network, which is comprised of three types of interfaces within the Cisco ONS 15304:
The SDCC channels provide an in-band management path within STM-1 fiber rings, of which there are two interfaces---one for each side of the fiber. The management Ethernet interface is used primarily as a high-speed local access port for craft user access, but could be used to connect to another router to connect to the DCN network. The serial E1 interfaces, which are normally used for user services, can be redirected and used to carry management traffic instead if so desired.
The provisioning of the Cisco ONS 15304 to permit remote manageability involves the configuration processes described below. The remaining sections in this chapter are organized according to this series of processes, in the order specified:
1. Enabling CLNS---CLNS packet forwarding and ISR-IS and ES-IS routing processes should be enabled. A CLNS Network Entity Title (NET) needs to be assigned as part of this process. Without proper CLNS configuration, traffic to other network elements can be disrupted.
2. Configuring SDCC Interfaces---Two SDCC interfaces are present for the Cisco ONS 15304, both of which must be configured with Q.921 and CLNS to achieve interoperability with other SDH standards-based network elements. The Q.921 protocol support and CLNS feature set will permit interoperability with other vendors' network elements.
3. Setting Up IP over CLNP Tunnels---One or more IP over CLNP tunnels need to be created to allow IP traffic to be carried within CLNS packets. IP over CLNS tunnels can be used wherever CLNS traffic is carried. From the perspective of CLNS, each Cisco ONS 15304 can be seen as a "separate" IP island in a sea of CLNS. The tunnels are links that provide connectivity between the IP islands.
The IP over CLNP tunnels can be built between Cisco ONS 15304s on the same ring, or between the Cisco ONS 15304 and EMS separate across a DCN. The Cisco Transport Manager/ConnectWay tunnelling software, which is available as part of the Element Management Software, can be used to terminate the tunnel at EMS sites. In other instances, it can be useful to build tunnels between a designated Cisco ONS 15304 serving as a hub for management traffic and other Cisco ONS 15304s. This nominated Cisco ONS 15304 then becomes a point where IP traffic can be directed before being forwarded to other Cisco ONS 15304 network elements on the ring. Therefore, the Cisco ONS 15304 is designated a "management hub for the ring."
4. Enabling the Ethernet Management Interface---The Ethernet management port is intended for use as a craft access port or an attachment to a central office LAN. CLNS or IP can be configured on this port if using a central office LAN.
5. Using a Serial E1 Channel as a Management Interface---As an alternate connectivity solution, the serial channels in the Cisco ONS 15304 can serve as a management interface. A serial channel (that would otherwise be used for user traffic), could be used to carry management traffic instead. Typically, a single E1 channel would terminate on a designated Cisco ONS 15304 serving as a management hub, with IP over CLNP tunnels to other Cisco ONS 15304s on the ring. The Serial E1 channel is treated like any other interface and can run both IP and CLNS.
The serial E1 channel can also be used to overcome congestion within the Cisco Transport Manager/GateWay by using one of the user E1 channels as a management data link. This configuration helps off-load some packet processing activities from the GNE.
6. Specifying an Access List---As a final step, Cisco recommends that IP access lists be established to prevent user traffic from entering the management network, and vice versa. Because access lists vary from one network deployment to another, it is hard to specify in advance the necessary configurations in a way that is sufficiently general for multiple applications. Therefore, this step is described only briefly.
As an alternative strategy, out-of-band management through an asynchronous modem or terminal server is also possible. This management strategy is not discussed here, but can be an option for some applications. The console port can interface to most standard modems which support the ability to disable the AT command set. In this scenario, the SDCC links and CLNS can still need to be configured to allow traffic to transit the Cisco ONS 15304 for compatibility.
In scenarios where only Cisco ONS 15304s are present in the SDH ring, it is also possible to set up the SDCC network to operate with only IP protocols. Currently, there are no standards governing usage of IP within the SDCC, but is supported by the Cisco ONS 15304 using HDLC, PPP, or Q.921 link layers. The SDCC interfaces can be treated like any other IP-capable interface. An IP address can be assigned to the SDCC link. Bridging across the SDCC links is also possible, but not recommended at this time due to limited testing. Because IP can be used in its native form, tunneling will not be required.
CLNS will need to be enabled if any of the other network elements on the SDH/GR-253 ring require CLNS. The "Enabling CLNS" section provides a summary of configurations that will work in most applications.
For additional information on setting up the CLNS software in the Cisco ONS 15304, see the CLNS Configuration Guide.
As a first step, CLNS needs to be enabled on the Cisco ONS 15304. The process involves turning on CLNS routing with the IS-IS and ES-IS routing. The Network Entity Title (NSAP address + N-Selector) also needs to be specified. This NET will typically use the MAC address of the management Ethernet interface (Ethernet 0) as the system id. The configuration process is described below. The commands need to be entered in configuration mode.
Step 1 Log in to the Cisco ONS 15304 at the ONS > prompt, and provide the username and password when prompted:
login
Step 2 Enter configuration mode:
configure terminal
Step 3 Specify the Network Entity Title (NET) that will be used by the IS-IS routing process:
net (40-byte-nsap-and-n-selector)
Step 4 Activate CLNS routing and the IS-IS routing process:
clns routing
router isis
Step 5 Leave configuration mode:
exit
For more information about other configuration options for CLNS, refer to the Network Protocols Configuration Guide.
Before any management traffic can traverse the SDCC links embedded in the STM-1 overhead, the SDCC interfaces need to be configured and activated. The interfaces are turned off in their default initial configuration, and need to be activated. In most SDH standard applications, the Q.921 protocol need to be setup in Acknowledge Information Transfer Mode (AITS), which is a reliable data link layer protocol.
Step 1 Log in to the Cisco ONS 15304 at the ONS > prompt, and provide the username and password when prompted:
login
Step 2 Enter configuration mode:
configure terminal
Step 3 Configure the Section DCC interface connected to SAM A:
interface SDCCA 0
Step 4 Enable Q.921 encapsulation with the specified local operating mode. If the remote end of the SDCC link is running in "user" mode, then the local side should be running "network" mode, and vice versa:
encapsulation q921 <network | user> clns
Step 5 Activate CLNS routing on the SDCC interface:
clns router isis
Step 6 (Optional) Adjust the CLNS MTU if necessary. See comment below about setting the CLNS MTU to no larger than the Q.921 I-Frame size parameter given by N201:
clns mtu 512
Step 7 Turn on the interface:
no shutdown
Step 8 Leave configuration mode:
exit
Repeat Step 3 through Step 7 for the Section DCC interface that terminates on SAM B. This interface is referred to as "SDCCB," and the instance number for the interface remains set to the value 0 (for example, interface SDCCB 0).
It might be necessary to tune the maximum transmission unit (MTU) size for optimum performance. Some network elements on the SDH ring can have limitations and can require a small setting than the default value of 1500 bytes. If you choose to set the CLNS MTU, it should be set to a value no greater than Q.921 N201 maximum I-Frame size parameter. As a general rule, it is suggested that you configure CLNS MTU equal to Q.921 N201. Generally, you will not need to configure interface MTU---as the default value 1500 is large enough). If you still decide to configure interface MTU, make sure the following holds true:
CLNS MTU <= Q.921 N201 <= interface MTU (<= means: less than or equal to)
The Cisco ONS 15304 supports a tunneling mode where an IP packet can be encapsulated within a CLNP frame, sent across a CLNS network, and then de-encapsulated at the tunnel destination to recover the original IP packet. The CLNP over IP tunnel is a virtual interface named "CTunnel" that needs to be established before IP communication can commence across a CLNS network. Like other tunnels, a CTunnel might be viewed as a point-to-point link. The CTunnels will normally be established between the following devices:
Several steps are necessary when configuring a CLNP over IP tunnel. The steps involve, instantiating a CTunnel virtual interface, assigning an IP address to the interface, and then specifying the destination NSAP address of the remote tunnel endpoint. The NSAP address specifies where the tunnel terminates, and where the IP packet will be extracted. The specific steps are illustrated below.
Step 1 Log in to the Cisco ONS 15304 at the ONS > prompt, and provide the username and password when prompted:
login
Step 2 Enter configuration mode:
configure terminal
Step 3 Create an IP over CLNP Tunnel. (Note that the instance of the virtual interface is 0 in the example below. This number needs to be incremented for each unique tunnel. Interface numbering starts with the number 0):
interface CTunnel tunnel-id
Step 4 Specify the destination NSAP address of the tunnel. This address specifies where the tunnel ends, and where IP packet is extracted.
ctunnel destination remote-NSAP-address
Step 5 Assign an IP address to the tunnel and specify the NSAP address of the remote tunnel endpoint:
ip address interface-address subnet-mask
Step 6 Activate the interface. This is not necessary as the virtual interfaces automatically come up in the active state when created:
no shutdown
Step 7 Leave the configuration mode:
exit
Multiple tunnels can be created if desired to provide broader and more robust connectivity. For each new tunnel, the interface number needs to be incremented to ensure uniqueness.
The Cisco ONS 15304 supports an Ethernet port that can be used to support management activities. Please refer to "Configuring Ethernet LAN Interfaces" for instructions on how to configure this interface.
Step 1 Log in to the Cisco ONS 15304 at the ONS > prompt, and provide the username and password when prompted:
login
Step 2 Enter configuration mode:
configure terminal
Step 3 Configure the management Ethernet port:
interface Ethernet 0
Step 4 Assign an IP address to the tunnel and specify the NSAP address of the remote tunnel endpoint:
ip address interface-address subnet-mask
Step 5 Activate the interface. This is not necessary as the virtual interfaces automatically come up in the active state when created:
no shutdown
Step 6 Leave the configuration mode:
exit
The Cisco ONS 15304 supports up to 21 E1 channels, of which one or more can be used to carry management traffic. These E1 channels are normally used to carry user traffic, but can be used for management traffic in instances where network elements do not interoperate adequately or where more management bandwidth is required. For example, a serial channel might be used to extract management traffic from an SDH ring instead of using a separate out-of-band path. In this case a serial E1 channel terminates at the Cisco ONS 15304 and the Cisco ONS 15304 might be designated as a gateway for extracting and inserting traffic into the SDH ring. An example of how the serial channels can be used for management traffic is illustrated in Figure 2-1.
The serial E1 interface is treated as another routable interface within the system. In most instances, the serial channel is configured to run IP, but could be configured to run CLNS as well. The instructions below illustrate how to drop-terminate a channel and configure it for IP operation. CLNS can be configured on the serial interface in the same manner as the SDCC interfaces, but this configuration mode is not described below.
Step 1 Log in to the Cisco ONS 15304 at the ONS > prompt, and provide the username and password when prompted:
login
Step 2 Enter configuration mode:
configure terminal
Step 3 Activate the STM-1 optical interface and the associated VC-4. These two steps may not be necessary if the STM-1 and VC-4 have already been created. It is necessary for the STM-1 and VC-4 to be in the "in-service" state.
ine enter stm1 ab admin is
ine enter vc4 vc4-id path-type drop admin is
Step 4 Terminate the VC-12 and cross-connect it to the Serial E1 interface:
ine enter vc12 vc12-id path-type drop admin is
ine enter seriale1 ser-id admin is
ine enter crs seriale1 ser-id vc12 vc12-id
Step 5 Go to the interface configuration mode for the serial interface:
interface seriale1 ser-id
Step 6 Assign an IP address and activate the selected interface:
ip address interface address subnet mask
no shutdown
Step 7 Leave the configuration mode:
exit
If a serial channel is used as a management channel, Cisco highly recommends that access lists be used to restrict user traffic from entering the serial channel. If access to the serial channel is not restricted, congestion can occur as well as possible breach of security between the user and management plane networks. Use Cisco security features to protect all management plan interfaces.
After interfaces and the network layer are configured, access lists should be specified to prevent traffic from the user payload interfaces from entering the management interfaces and vice versa. Access lists will help ensure that no unauthorized traffic is routed between the user and management planes of the network.
To define an access list, perform one of the following tasks in global configuration mode:
| Task | Command |
|---|---|
Define a standard IP access list. | access-list access-list-number {deny | permit} source [source-wildcard] |
Define an extended IP access list. | access-list access-list-number {deny | permit} protocol source source-wildcard destination destination-wildcard [precedence precedence] [tos tos] [established] [log] |
After you create an access list, you can apply it to one or more interfaces. Access lists can be applied on either outbound or inbound interfaces. When controlling access to an interface, you can use a name or number.
Perform the following task in interface configuration mode:
| Task | Command |
|---|---|
Control access to an interface. | ip access-group {access-list-number | name} {in | out} |
For outbound access lists, after receiving and routing a packet to a controlled interface, the software checks the source address of the packet against the access list. If the access list permits the address, the software transmits the packet. If the access list rejects the address, the software discards the packet and returns an ICMP Host Unreachable message.
When you apply an access list that has not yet been defined to an interface, the software will act as if the access list has not been applied to the interface and will accept all packets. Remember this behavior if you use undefined access lists as a means of security in your network.
Posted: Sun Apr 9 22:19:11 PDT 2000
Copyright 1989 - 2000©Cisco Systems Inc.