Table Of Contents
Management Network Connectivity
9.2.1 Scenario 1: CTC and ONS 15310-CL Nodes on the Same Subnet
9.2.2 Scenario 2: CTC and ONS 15310-CL Nodes Connected to a Router
9.2.3 Scenario 3: Using Proxy ARP to Enable an ONS 15310-CL Gateway
9.2.4 Scenario 4: Default Gateway on CTC Computer
9.2.5 Scenario 5: Using Static Routes to Connect to LANs
9.2.7 Scenario 7: Provisioning the ONS 15310-CL Proxy Server
9.7.2 Link Access Protocol on the D Channel
9.7.3 OSI Connectionless Network Service
Management Network Connectivity
This chapter provides an overview of ONS 15310-CL data communications network (DCN) connectivity. Cisco Optical Networking System (ONS) network communication is based on IP, including communication between Cisco Transport Controller (CTC) computers and ONS 15310-CL nodes, and communication among networked ONS 15310-CL nodes. The chapter provides scenarios showing Cisco ONS 15310-CL nodes in common IP network configurations as well as information about provisionable patchcords, the IP routing table, external firewalls, and open gateway network element (GNE) networks.
Although ONS 15310-CL DCN communication is based on IP, ONS 15310-CL nodes can be networked to equipment that is based on the Open System Interconnection (OSI) protocol suites. This chapter describes the ONS 15310-CL OSI implementation and provides scenarios that show how the ONS 15310-CL can be networked within a mixed IP and OSI environment.
Chapter topics include:
Note
This chapter does not provide a comprehensive explanation of IP networking concepts and procedures, nor does it provide IP addressing examples to meet all networked scenarios. For ONS 15310-CL networking setup instructions, refer to the "Turn Up Node" chapter of the Cisco ONS 15310-CL Procedure Guide.
Note
9.1 IP Networking Overview
ONS 15310-CL nodes can be connected in many different ways within an IP environment:
•
•
•
•
•
•
9.2 IP Addressing Scenarios
ONS 15310-CL IP addressing generally has seven common scenarios or configurations. Use the scenarios as building blocks for more complex network configurations. Table 9-1 provides a general list of items to check when setting up ONS 15310-CL nodes in IP networks.
9.2.1 Scenario 1: CTC and ONS 15310-CL Nodes on the Same Subnet
Scenario 1 shows a basic ONS 15310-CL LAN configuration (Figure 9-1). The ONS 15310-CL nodes and CTC computer reside on the same subnet. All ONS 15310-CL nodes connect to LAN A and have DCC connections.
Figure 9-1 Scenario 1: CTC and ONS 15310-CL Nodes on the Same Subnet
9.2.2 Scenario 2: CTC and ONS 15310-CL Nodes Connected to a Router
In Scenario 2 the CTC computer resides on a subnet (192.168.1.0) and attaches to LAN A (Figure 9-2). The ONS 15310-CL nodes reside on a different subnet (192.168.2.0) and attach to LAN B. A router connects LAN A to LAN B. The IP address of router interface A is set to LAN A (192.168.1.1), and the IP address of router interface B is set to LAN B (192.168.2.1).
On the CTC computer, the default gateway is set to router interface A. If the LAN uses Dynamic Host Configuration Protocol (DHCP), the default gateway and IP address are assigned automatically. In Figure 9-2, a DHCP server is not available.
Figure 9-2 Scenario 2: CTC and ONS 15310-CL Nodes Connected to Router
9.2.3 Scenario 3: Using Proxy ARP to Enable an ONS 15310-CL Gateway
ARP matches higher-level IP addresses to the physical addresses of the destination host. It uses a lookup table (called ARP cache) to perform the translation. When the address is not found in the ARP cache, a broadcast is sent out on the network with a special format called the ARP request. If one of the machines on the network recognizes its own IP address in the request, it sends an ARP reply back to the requesting host. The reply contains the physical hardware address of the receiving host. The requesting host stores this address in its ARP cache so that all subsequent datagrams (packets) to this destination IP address can be translated to a physical address.
Proxy ARP enables one LAN-connected ONS 15310-CL to respond to the ARP request for ONS 15310-CL nodes not connected to the LAN. (ONS 15310-CL proxy ARP requires no user configuration.) For the proxy ARP node to require no user confirmation, the DCC-connected ONS 15310-CL nodes must reside on the same subnet. When a LAN device sends an ARP request to an ONS 15310-CL that is not connected to the LAN, the gateway ONS 15310-CL returns its MAC address to the LAN device. The LAN device then sends the datagram for the remote ONS 15310-CL to the MAC address of the proxy ONS 15310-CL. The proxy ONS 15310-CL uses its routing table to forward the datagram to the non-LAN ONS 15310-CL.
Scenario 3 is similar to Scenario 1, but only one ONS 15310-CL (#1) connects to the LAN (Figure 9-3). Two ONS 15310-CL nodes (#2 and #3) connect to ONS 15310-CL 1 through the SONET DCC. Because all three ONS 15310-CL nodes are on the same subnet, Proxy ARP enables ONS 15310-CL #1 to serve as a gateway for ONS 15310-CL #2 and #3.
Note
Figure 9-3 Scenario 3: Using Proxy ARP
You can also use proxy ARP to communicate with hosts attached to the craft Ethernet ports of DCC-connected nodes (Figure 9-4). The node with an attached host must have a static route to the host. Static routes are propagated to all DCC peers using OSPF. The existing proxy ARP node is the gateway for additional hosts. Each node examines its routing table for routes to hosts that are not connected to the DCC network but are within the subnet. The existing proxy server replies to ARP requests for these additional hosts with the node MAC address. The existence of the host route in the routing table ensures that the IP packets addressed to the additional hosts are routed properly. Other than establishing a static route between a node and an additional host, no provisioning is necessary. The following restrictions apply:
•
•
In Figure 9-4, Node 1 announces to Node 2 and 3 that it can reach the CTC host. Similarly, Node 3 announces that it can reach the ONS 152xx. The ONS 152xx is shown as an example; any network element can be set up as an additional host.
Figure 9-4 Scenario 3: Using Proxy ARP with Static Routing
9.2.4 Scenario 4: Default Gateway on CTC Computer
Scenario 4 is similar to Scenario 3, but ONS 15310-CL #2 and #3 reside on different subnets, 192.168.2.0 and 192.168.3.0, respectively (Figure 9-5). Node 1 and the CTC computer are on subnet 192.168.1.0. Proxy ARP is not used because the network includes different subnets. For the CTC computer to communicate with Nodes 2 and 3, Node 1 is entered as the default gateway on the CTC computer.
Figure 9-5 Scenario 4: Default Gateway on a CTC Computer
9.2.5 Scenario 5: Using Static Routes to Connect to LANs
Static routes are used for two purposes:
•
•
In Figure 9-6, one CTC residing on subnet 192.168.1.0 connects to a router through interface A. (The router is not set up with OSPF.) ONS 15310-CL nodes residing on different subnets are connected through Node 1 to the router through interface B. Because Nodes 2 and 3 are on different subnets, proxy ARP does not enable Node 1 as a gateway. To connect to CTC computers on LAN A, a static route is created on Node 1.
Figure 9-6 Scenario 5: Static Route with One CTC Computer Used as a Destination
The destination and subnet mask entries control access to the ONS 15310-CL nodes:
•
•
•
The IP address of router interface B is entered as the next hop, and the cost (number of hops from source to destination) is 2.
Figure 9-7 Scenario 5: Static Route with Multiple LAN Destinations
9.2.6 Scenario 6: Using OSPF
Open Shortest Path First (OSPF) is a link-state Internet routing protocol. Link-state protocols use a "hello protocol" to monitor their links with adjacent routers and to test the status of their links to their neighbors. Link-state protocols advertise their directly connected networks and their active links. Each link state router captures the link state "advertisements" and puts them together to create a topology of the entire network or area. From this database, the router calculates a routing table by constructing a shortest path tree. Routes are recalculated when topology changes occur.
The ONS 15310-CL uses OSPF protocol in internal ONS 15310-CL networks for node discovery, circuit routing, and node management. You can enable OSPF on the ONS 15310-CL so that the ONS 15310-CL topology is sent to OSPF routers on a LAN. Advertising the ONS 15310-CL network topology to LAN routers eliminates the need to enter static routes for ONS 15310-CL subnetworks manually.
OSPF divides networks into smaller regions, called areas. An area is a collection of networked end systems, routers, and transmission facilities organized by traffic patterns. Each OSPF area has a unique ID number, known as the area ID. Every OSPF network has one backbone area called "area 0." All other OSPF areas must connect to area 0.
When you enable an ONS 15310-CL OSPF topology for advertising to an OSPF network, you must assign an OSPF area ID in decimal format to the ONS 15310-CL network. Coordinate the area ID number assignment with your LAN administrator. All DCC-connected ONS 15310-CL nodes should be assigned the same OSPF area ID.
Figure 9-8 shows a network enabled for OSPF.
Figure 9-8 Scenario 6: OSPF Enabled
Figure 9-9 shows the same network without OSPF. Static routes must be manually added to the router for CTC computers on LAN A to communicate with Nodes 2 and 3 because these nodes reside on different subnets.
Figure 9-9 Scenario 6: OSPF Not Enabled
9.2.7 Scenario 7: Provisioning the ONS 15310-CL Proxy Server
The ONS 15310-CL proxy server is a set of functions that allows you to network ONS 15310-CL nodes in environments where visibility and accessibility between ONS 15310-CL nodes and CTC computers must be restricted. For example, you can set up a network so that field technicians and network operating center (NOC) personnel can both access the same ONS 15310-CL nodes while preventing the field technicians from accessing the NOC LAN. To do this, one ONS 15310-CL is provisioned as a gateway network element (GNE) and the other ONS 15310-CL nodes are provisioned as end network elements (ENEs). The GNE tunnels connections between CTC computers and ENEs, which provides management capability while preventing access for non-ONS 15310-CL management purposes.
The ONS 15310-CL proxy server performs the following tasks:
•
•
•
The ONS 15310-CL proxy server is provisioned using the Enable proxy server on port check box on the Provisioning > Network > General tab. If checked, the ONS 15310-CL serves as a proxy for connections between CTC clients and ONS 15310-CL nodes that are DCC-connected to the proxy ONS 15310-CL. The CTC client establishes connections to DCC-connected nodes through the proxy node. The CTC client can connect to nodes that it cannot directly reach from the host on which it runs. If the Enable proxy server on port check box is not checked, the node does not proxy for any CTC clients, although any established proxy connections continue until the CTC client exits. In addition, you can set the proxy server as an ENE or a GNE:
Note
•
In addition, firewall is enabled, which means that the node prevents IP traffic from being routed between the DCC and the LAN port. The ONS 15310-CL can communicate with machines connected to the LAN port or connected through the DCC. However, the DCC-connected machines cannot communicate with the LAN-connected machines, and the LAN-connected machines cannot communicate with the DCC-connected machines. A CTC client using the LAN to connect to the firewall-enabled node can use the proxy capability to manage the DCC-connected nodes that would otherwise be unreachable. A CTC client connected to a DCC-connected node can only manage other DCC-connected nodes and the firewall itself.
•
•
Figure 9-10 shows an ONS 15310-CL proxy server implementation. A GNE is connected to a central office LAN and to ENEs. The central office LAN is connected to a NOC LAN, which has CTC computers. The NOC CTC computer and craft technicians must both be able to access the ENEs. However, the craft technicians must be prevented from accessing or seeing the NOC or central office LANs.
In the example, the GNE is assigned an IP address within the central office LAN and is physically connected to the LAN through its LAN port. ENEs are assigned IP addresses that are outside the central office LAN and given private network IP addresses. If the ENEs are collocated, the LAN ports could be connected to a hub. However, the hub should have no other network connections.
Figure 9-10 ONS 15310-CL Proxy Server with GNE and ENEs on the Same Subnet
Table 9-2 shows recommended settings for ONS 15310-CL GNEs and ENEs in the configuration shown in Figure 9-10.
Figure 9-11 shows the same proxy server implementation with ONS 15310-CL ENEs on different subnets. In this example, ONS 15310-CL GNEs and ENEs are provisioned with the settings shown in Table 9-2.
Figure 9-11 Scenario 7: ONS 15310-CL Proxy Server with GNE and ENEs on Different Subnets
Figure 9-12 shows the implementation with ONS 15310-CL ENEs in multiple rings. In this example, ONS 15310-CL GNEs and ENEs are provisioned with the settings shown in Table 9-2.
Figure 9-12 Scenario 7: ONS 15310-CL Proxy Server with ENEs on Multiple Rings
Table 9-3 shows the rules the ONS 15310-CL follows to filter packets when Enable Firewall is enabled.
Table 9-4 shows additional rules that apply if the packet addressed to the ONS 15310-CL is discarded. Rejected packets are silently discarded.
If you implement the proxy server, keep the following rules in mind:
1.
2.
3.
4.
If nodes become unreachable in cases 1, 2, and 3, you can correct the setting with one of the following actions:
•
•
9.3 Provisionable Patchcords
A provisionable patchcord is a user-provisioned link that is advertised by OSPF throughout the network. Provisionable patchcords, also called virtual links, are needed if an ONS 15310-CL optical port is connected to an ONS 15454 transponder or muxponder client port provisioned in transparent mode. Provisionable patchcords are required on both ends of a physical link. The provisioning at each end includes a local patchcord ID, slot/port information, remote IP address, and remote patchcord ID. Patchcords appear as dashed lines in CTC network view.
Table 9-5 lists the supported combinations for ONS 15310-CL optical ports and the ONS 15454 transponder/muxponder cards used in a provisionable patchcord. For more information about the ONS 15454 transponder and muxponder cards, refer to the Cisco ONS 15454 DWDM Installation and Operations Guide.
Optical ports have the following requirements when used in a provisionable patchcord:
•
•
•
9.4 Routing Table
ONS 15310-CL routing information appears on the Maintenance > Routing Table tabs. The routing table provides the following information:
•
•
•
•
•
–
–
–
Table 9-6 shows sample routing entries for an ONS 15310-CL.
Entry 1 shows the following:
•
•
•
•
Entry 2 shows the following:
•
•
•
•
Entry 3 shows the following:
•
•
•
•
Entry 4 shows the following:
•
•
•
•
Entry 5 shows a DCC-connected node that is accessible through a node that is not directly connected:
•
•
•
•
9.5 External Firewalls
Table 9-7 shows the ports that are used by the 15310-CL-CTX.
Table 9-7 Ports Used by the 15310-CL-CTX
0
Never used
D
20
FTP
D
21
FTP control
D
22
SSH (Secure Shell)
D
23
Telnet
D
80
HTTP
D
111
SUNRPC (Sun Remote Procedure Call)
NA
161
SNMP traps destinations
D
162
SNMP traps destinations
D
513
rlogin
NA
683
CORBA IIOP
OK
1080
Proxy server (socks)
D
2001-2017
I/O card Telnet
D
2018
DCC processor on active 15310-CL-CTX
D
2361
TL1
D
3082
Raw TL1
D
3083
TL1
D
5001
Bidirectional line switch ring (BLSR) server port
D
5002
BLSR client port
D
7200
SNMP alarm input port
D
9100
EQM port
D
9401
TCC boot port
D
9999
Flash manager
D
10240-12287
Proxy client
D
57790
Default TCC listener port
OK
1 D = deny, NA = not applicable, OK = do not deny
The following access control list (ACL) examples show a firewall configuration when the proxy server gateway setting is not enabled. In the example, the CTC workstation address is 192.168.10.10 and the ONS 15310-CL address is 10.10.10.100. The firewall is attached to the GNE, so the inbound path is CTC to the GNE and the outbound path is from the GNE to CTC. The CTC CORBA Standard constant is 683 and the TCC CORBA Default is TCC Fixed (57790).
access-list 100 remark *** Inbound ACL, CTC -> NE ***access-list 100 remarkaccess-list 100 permit tcp host 192.168.10.10 host 10.10.10.100 eq wwwaccess-list 100 remark *** allows initial contact with the 15310-CL using http (port 80) ***access-list 100 remarkaccess-list 100 permit tcp host 192.168.10.10 host 10.10.10.100 eq 57790access-list 100 remark *** allows CTC communication with the 15310-CL GNE (port 57790) ***access-list 100 remarkaccess-list 101 remarkaccess-list 101 permit tcp host 10.10.10.100 host 192.168.10.10 eq 683access-list 101 remark *** allows alarms etc., from the 15310-CL (random port) to the CTC workstation (port 683) ***access-list 100 remarkaccess-list 101 permit tcp host 10.10.10.100 host 192.168.10.10 establishedaccess-list 101 remark *** allows ACKs from the 15310-CL GNE to CTC ***The following ACL examples show a firewall configuration when the proxy server gateway setting is enabled. As with the first example, the CTC workstation address is 192.168.10.10 and the ONS 15310-CL address is 10.10.10.100. The firewall is attached to the GNE, so the inbound path is CTC to the GNE and the outbound path is from the GNE to CTC. The CTC CORBA Standard constant is 683 and the TCC CORBA Default is TCC Fixed (57790).
access-list 100 remark *** Inbound ACL, CTC -> NE ***access-list 100 remarkaccess-list 100 permit tcp host 192.168.10.10 host 10.10.10.100 eq wwwaccess-list 100 remark *** allows initial contact with the 15310-CL using http (port 80) ***access-list 100 remarkaccess-list 100 permit tcp host 192.168.10.10 host 10.10.10.100 eq 1080access-list 100 remark *** allows CTC communication with the 15310-CL GNE proxy server (port 1080) ***access-list 100 remarkaccess-list 100 permit tcp host 192.168.10.10 host 10.10.10.100 establishedaccess-list 100 remark *** allows ACKs from CTC to the 15310-CL GNE ***access-list 101 remark *** Outbound ACL, NE -> CTC ***access-list 101 remarkaccess-list 101 permit tcp host 10.10.10.100 eq 1080 host 192.168.10.10access-list 101 remark *** allows alarms and other communications from the 15310-CL (proxy server) to the CTC workstation(port 683) ***access-list 100 remarkaccess-list 101 permit tcp host 10.10.10.100 host 192.168.10.10 establishedaccess-list 101 remark *** allows ACKs from the 15310-CL GNE to CTC ***9.6 Open GNE
The ONS 15310-CL can communicate with non-ONS nodes that do not support point-to-point protocol (PPP) vendor extensions or OSPF type 10 opaque link-state advertisements (LSA), both of which are necessary for automatic node and link discovery. An open GNE configuration allows the DCC-based network to function as an IP network for non-ONS nodes.
To configure an open GNE network, you can provision SDCC and LDCC terminations to include a far-end, non-ONS node using either the default IP address of 0.0.0.0 or a specified IP address. You provision a far-end, non-ONS node by checking the "Far End is Foreign" check box during SDCC and LDCC creation. The default 0.0.0.0 IP address allows the far-end, non-ONS node to provide the IP address; if you set an IP address other than 0.0.0.0, a link is established only if the far-end node identifies itself with that IP address, providing an extra level of security.
By default, the proxy server only allows connections to discovered ONS peers and the firewall blocks all IP traffic between the DCC network and LAN. You can, however, provision proxy tunnels to allow up to 12 additional destinations for SOCKS version 5 connections to non-ONS nodes. You can also provision firewall tunnels to allow up to 12 additional destinations for direct IP connectivity between the DCC network and LAN. Proxy and firewall tunnels include both a source and destination subnet. The connection must originate within the source subnet and terminate within the destination subnet before either the SOCKS connection or IP packet flow is allowed.
To set up proxy and firewall subnets in CTC, use the Provisioning > Network > Proxy and Firewalls subtabs. The availability of proxy and/or firewall tunnels depends on the network access settings of the node:
•
•
•
Figure 9-13 shows an example of a foreign node connected to the DCC network. Proxy and firewall tunnels are useful in this example because the GNE would otherwise block IP access between the PC and the foreign node.
Figure 9-13 Proxy and Firewall Tunnels for Foreign Terminations
Figure 9-14 shows a remote node connected to an ENE Ethernet port. Proxy and firewall tunnels are useful in this example because the GNE would otherwise block IP access between the PC and foreign node. This configuration also requires a firewall tunnel on the ENE.
Figure 9-14 Foreign Node Connection to an ENE Ethernet Port
9.7 TCP/IP and OSI Networking
ONS 15310-CL DCN communication is based on the TCP/IP protocol suite. However, ONS 15310-CL nodes can also be networked with equipment that uses the OSI protocol suite. While TCP/IP and OSI protocols are not directly compatible, they do have the same objectives and occupy similar layers of the OSI reference model. Table 9-8 shows the protocols that are involved when TCP/IP-based NEs are networked with OSI-based NEs.
Table 9-8 TCP/IP and OSI Protocols
Layer 7 Application
•
•
•
•
•
•
•
•
•
Layer 6 Presentation
•
Layer 5 Session
•
Layer 4 Transport
•
•
•
•
Layer 3 Network
•
•
•
•
•
Layer 2 Data link
•
•
•
Layer 1 Physical
DCC, LAN, fiber, electrical
DCC, LAN, fiber, electrical
1 TARP = TID Address Resolution Protocol
2 FTAM = File Transfer and Access Management
3 ACSE = association-control service element
4 PST = Presentation layer
5 CLNS = Connectionless Network Layer Service
6 CLNP = Connectionless Network Layer Protocol
7 ES-IS = End System-to-Intermediate System
8 IS-IS = Intermediate System-to-Intermediate System
9 LAP-D = Link Access Protocol on the D Channel
9.7.1 Point-to-Point Protocol
PPP is a data link (Layer 2) encapsulation protocol that transports datagrams over point-to-point links. Although PPP was developed to transport IP traffic, it can carry other protocols including the OSI CLNP. PPP components used in the transport of OSI include:
•
•
CTC automatically enables IP over PPP whenever you create an SDCC or LDCC. The SDCC or LDCC can be provisioned to support OSI over PPP.
9.7.2 Link Access Protocol on the D Channel
LAP-D is a data link protocol used in the OSI protocol stack. LAP-D is assigned when you provision an ONS 15310-CL SDCC as OSI-only. Provisionable LAP-D parameters include:
•
–
–
•
•
Note
•
–
–
Fixed values are assigned to the following LAP-D parameters:
•
•
•
9.7.3 OSI Connectionless Network Service
OSI connectionless network service is implemented by using the Connectionless Network Protocol (CLNP) and Connectionless Network Service (CLNS). CLNP and CLNS are described in the ISO 8473 standard. CLNS provides network layer services to the transport layer through CLNP. CLNS does not perform connection setup or termination because paths are determined independently for each packet that is transmitted through a network. CLNS relies on transport layer protocols to perform error detection and correction.
CLNP is an OSI network layer protocol that carries upper-layer data and error indications over connectionless links. CLNP provides the interface between the CLNS and upper layers. CLNP performs many of the same services for the transport layer as IP. The CLNP datagram is very similar to the IP datagram. It provides mechanisms for fragmentation (data unit identification, fragment/total length, and offset). Like IP, a checksum computed on the CLNP header verifies that the information used to process the CLNP datagram is transmitted correctly, and a lifetime control mechanism (Time to Live) limits the amount of time a datagram is allowed to remain in the system.
CLNP uses network service access points (NSAPs) to identify network devices. The CLNP source and destination addresses are NSAPs. In addition, CLNP uses a network element title (NET) to identify a network-entity in an end system (ES) or intermediate system (IS). NETs are allocated from the same name space as NSAP addresses. Whether an address is an NSAP address or a NET depends on the network selector value in the NSAP.
The ONS 15310-CL supports the ISO Data Country Code (ISO-DCC) NSAP address format as specified in ISO 8348. The NSAP address is divided into an initial domain part (IDP) and a domain-specific part (DSP). NSAP fields are shown in Table 9-9. NSAP field values are in hexadecimal format. All NSAPs are editable. Shorter NSAPs can be used. However NSAPs for all NEs residing within the same OSI network area usually have the same NSAP format.
Table 9-9 NSAP Fields
AFI
Authority and format identifier
Specifies the NSAP address format. The initial value is 39 for the ISO-DCC address format.
IDI
Initial domain identifier
Specifies the country code. The initial value is 840F, the United States country code padded with an F.
DFI
DSP format identifier
Specifies the DSP format. The initial value is 80, indicating the DSP format follows American National Standards Institute (ANSI) standards.
ORG
Organization
Organization identifier. The initial value is 000000.
Reserved
Reserved
Reserved NSAP field. The Reserved field is normally all zeros (0000).
RD
Routing domain
Defines the routing domain. The initial value is 0000.
AREA
Area
Identifies the OSI routing area to which the node belongs. The initial value is 0000.
System
System identifier
The ONS 15310-CL system identifier is set to its IEEE 802.3 MAC address. Each ONS 15310-CL supports one OSI virtual router.
SEL
Selector
The selector field directs the protocol data units (PDUs) to the correct destination using the CLNP network layer service. Selector values supported by the ONS 15310-CL include:
•
•
•
•
•
•
NSELs are only advertised when the node is configured as an ES. They are not advertised when a node is configured as an IS. Tunnel NSELs are not advertised until a tunnel is created.
Figure 9-15 shows the ISO-DCC NSAP address with the default values delivered with the ONS 15310-CL. The System ID is automatically populated with the node MAC address.
Figure 9-15 ISO-DCC NSAP Address
The ONS 15310-CL main NSAP address is shown on the node view Provisioning > OSI > Main Setup subtab. This address is also the Router 1 primary manual area address, which is viewed and edited on the Provisioning > OSI > Routers subtab. See the "OSI Virtual Routers" section for information about the OSI router and manual area addresses in CTC.
9.7.4 OSI Routing
OSI architecture includes ESs and ISs. The OSI routing scheme includes:
•
•
•
In OSI networking, discovery is based on announcements. An ES uses the ES-IS protocol end system hello (ESH) message to announce its presence to ISs and ESs connected to the same network. Any ES or IS that is listening for ESHs gets a copy. ISs store the NSAP address and the corresponding subnetwork address pair in routing tables. ESs might store the address, or they might wait to be informed by ISs when they need such information.
An IS composes intermediate system hello (ISH) messages to announce its configuration information to ISs and ESs that are connected to the same broadcast subnetwork. Like the ESHs, the ISH contains the addressing information for the IS (the NET and the subnetwork point-of-attachment address [SNPA]) and a holding time. ISHs might also communicate a suggested ES configuration time recommending a configuration timer to ESs.
The exchange of ISHs is called neighbor greeting or initialization. Each router learns about the other routers with which they share direct connectivity. After the initialization, each router constructs a link-state packet (LSP). The LSP contains a list of the names of the IS's neighbors and the cost to reach each of the neighbors. Routers then distribute the LSPs to all of the other routers. When all LSPs are propagated to all routers, each router has a complete map of the network topology (in the form of LSPs). Routers use the LSPs and the SPF algorithm to compute routes to every destination in the network.
OSI networks are divided into areas and domains. An area is a group of contiguous networks and attached hosts that is designated as an area by a network administrator. A domain is a collection of connected areas. Routing domains provide full connectivity to all ESs within them. Routing within the same area is known as Level 1 routing. Routing between two areas is known as Level 2 routing. LSPs that are exchanged within a Level 1 area are called L1 LSPs. LSPs that are exchanged across Level 2 areas are called L2 LSPs. Figure 9-16 shows an example of Level 1 and Level 2 routing.
Note
Figure 9-16 Level 1 and Level 2 OSI Routing
When you provision an ONS 15310-CL for a network with NEs that use both the TCP/IP and OSI protocol stacks, you will provision it as one of the following:
•
•
9.7.4.1 End System-to-Intermediate System Protocol
ES-IS is an OSI protocol that defines how ESs (hosts) and ISs (routers) learn about each other. ES-IS configuration information is transmitted at regular intervals through the ES and IS hello messages. The hello messages contain the subnetwork and network layer addresses of the systems that generate them.
The ES-IS configuration protocol communicates both OSI network layer addresses and OSI subnetwork addresses. OSI network layer addresses identify either the NSAP, which is the interface between OSI Layer 3 and Layer 4, or the NET, which is the network layer entity in an OSI IS. OSI SNPAs are the points at which an ES or IS is physically attached to a subnetwork. The SNPA address uniquely identifies each system attached to the subnetwork. In an Ethernet network, for example, the SNPA is the 48-bit MAC address. Part of the configuration information transmitted by ES-IS is the NSAP-to-SNPA or NET-to-SNPA mapping.
9.7.4.2 Intermediate System-to-Intermediate System Protocol
IS-IS is an OSI link-state hierarchical routing protocol that floods the network with link-state information to build a complete, consistent picture of a network topology. IS-IS distinguishes between Level 1 and Level 2 ISs. Level 1 ISs communicate with other Level 1 ISs in the same area. Level 2 ISs route between Level 1 areas and form an intradomain routing backbone. Level 1 ISs need to know only how to get to the nearest Level 2 IS. The backbone routing protocol can change without impacting the intra-area routing protocol.
OSI routing begins when the ESs discover the nearest IS by listening to ISH packets. When an ES wants to send a packet to another ES, it sends the packet to one of the ISs on its directly attached network. The router then looks up the destination address and forwards the packet along the best route. If the destination ES is on the same subnetwork, the local IS knows this from listening to ESHs and forwards the packet appropriately. The IS also might provide a redirect (RD) message back to the source to tell it that a more direct route is available. If the destination address is an ES on another subnetwork in the same area, the IS knows the correct route and forwards the packet appropriately. If the destination address is an ES in another area, the Level 1 IS sends the packet to the nearest Level 2 IS. Forwarding through Level 2 ISs continues until the packet reaches a Level 2 IS in the destination area. Within the destination area, the ISs forward the packet along the best path until the destination ES is reached.
Link-state update messages help ISs learn about the network topology. Each IS generates an update specifying the ESs and ISs to which it is connected, as well as the associated metrics. The update is then sent to all neighboring ISs, which forward (flood) it to their neighbors, and so on. (Sequence numbers terminate the flood and distinguish old updates from new ones.) Using these updates, each IS can build a complete topology of the network. When the topology changes, new updates are sent.
IS-IS uses a single required default metric with a maximum path value of 1024. The metric is arbitrary and typically is assigned by a network administrator. Any single link can have a maximum value of 64, and path links are calculated by summing link values. Maximum metric values were set at these levels to provide the granularity to support various link types while at the same time ensuring that the shortest-path algorithm used for route computation is reasonably efficient. Three optional IS-IS metrics (costs)—delay, expense, and error—are not supported by the ONS 15310-CL. IS-IS maintains a mapping of the metrics to the quality of service (QoS) option in the CLNP packet header. IS-IS uses the mappings to compute routes through the internetwork.
9.7.5 TARP
TARP is used when TL1 target identifiers (TIDs) must be translated to NSAP addresses. The TID-to-NSAP translation occurs by mapping TIDs to the NETs, then deriving NSAPs from the NETs by using the NSAP selector values (Table 9-9).
TARP uses a selective PDU propagation methodology in conjunction with a distributed database (that resides within the NEs) of TID-to-NET mappings. TARP allows NEs to translate between TID and NET by automatically exchanging mapping information with other NEs. The TARP PDU is carried by the standard CLNP Data PDU. TARP PDU fields are shown in Table 9-10.
Table 9-10 TARP PDU Fields
TARP Lifetime
tar-lif
2
The TARP time-to-live in hops.
TARP Sequence Number
tar-seq
2
The TARP sequence number used for loop detection.
Protocol Address Type
tar-pro
1
Used to identify the type of protocol address that the TID must be mapped to. The value FE is used to identify the CLNP address type.
TARP Type Code
tar-tcd
1
The TARP Type Code identifies the TARP type of PDU. Five TARP types, shown in Table 9-11, are defined.
TID Target Length
tar-tln
1
The number of octets that are in the tar-ttg field.
TID Originator Length
tar-oln
1
The number of octets that are in the tar-tor field.
Protocol Address Length
tar-pln
1
The number of octets that are in the tar-por field.
TID of Target
tar-ttg
n = 0, 1, 2...
TID value for the target NE.
TID of Originator
tar-tor
n = 0, 1, 2...
TID value of the TARP PDU originator.
Protocol Address of Originator
tar-por
n = 0, 1, 2...
Protocol address (for the protocol type identified in the tar-pro field) of the TARP PDU originator. When the tar-pro field is set to FE (hex), tar-por will contain a CLNP address (that is, the NET).
Table 9-11 shows the TARP PDUs types that govern TARP interaction and routing.
9.7.5.1 TARP Processing
A TARP data cache (TDC) is created at each NE to facilitate TARP processing. In CTC, the TDC is displayed and managed on the node view Maintenance > OSI > TDC subtab. The TDC subtab contains the following TARP PDU fields:
•
•
•
Provisionable timers, shown in Table 9-12, control TARP processing.
Table 9-13 shows the main TARP processes and the general sequence of events that occurs in each process.
9.7.5.2 TARP Loop Detection Buffer
The TARP loop detection buffer (LDB) can be enabled to prevent duplicate TARP PDUs from entering the TDC. When a TARP Type 1, 2, or 4 PDU arrives, TARP checks its LDB for a NET address of the PDU originator match. If no match is found, TARP processes the PDU and assigns a tar-por, tar-seq (sequence) entry for the PDU to the LDB. If the tar-seq is zero, a timer associated with the LDB entry is started using the provisionable LDB entry timer on the node view OSI > TARP > Config tab. If a match exists, the tar-seq is compared to the LDB entry. If the tar-seq is not zero and is less than or equal to the LDB entry, the PDU is discarded. If the tar-seq is greater than the LDB entry, the PDU is processed and the tar-seq field in the LDB entry is updated with the new value. The Cisco ONS 15310-CL LDB holds approximately 500 entries. The LDB is flushed periodically based on the time set in the LDB Flush timer on the node view OSI > TARP > Config tab.
9.7.5.3 Manual TARP Adjacencies
TARP adjacencies can be manually provisioned in networks where ONS 15310-CLs must communicate across routers or non-SONET NEs that lack TARP capability. In CTC, manual TARP adjacencies are provisioned on the node view Provisioning > OSI > TARP > MAT (Manual Area Table) subtab. The manual adjacency causes a TARP request to hop through the general router or non-SONET NE, as shown in Figure 9-17.
Figure 9-17 Manual TARP Adjacencies
9.7.5.4 Manual TID to NSAP Provisioning
TIDs can be manually linked to NSAPs and added to the TDC. Static TDC entries are similar to static routes. For a specific TID, you force a specific NSAP. Resolution requests for that TID always return that NSAP. No TARP network propagation or instantaneous replies are involved. Static entries allow you to forward TL1 commands to NEs that do not support TARP. However, static TDC entries are not dynamically updated, so outdated entries are not removed after the TID or the NSAP changes on the target node.
9.7.6 OSI Virtual Routers
The ONS 15310-CL supports one OSI virtual router. The router is provisioned on the Provisioning > OSI > Routers tab. The router has an editable manual area address and a unique NSAP System ID that is set to the node MAC address. The router can be enabled and connected to different OSI routing areas. The Router 1 manual area address and System ID create the NSAP address assigned to the node's TID. Router 1 supports OSI TARP and tunneling functions. These include:
•
•
•
In addition to the primary manual area address, you can also create two additional manual area addresses. These manual area addresses can be used to:
•
•
•
9.7.7 IP-over-CLNS Tunnels
IP-over-CLNS tunnels are used to encapsulate IP for transport across OSI NEs. The ONS 15310-CL supports two tunnel types:
•
•
Figure 9-18 shows the protocol flow when an IP-over-CLNS tunnel is created through four NEs (A, B, C, and D). The tunnel ends are configured on NEs A and D, which support both IP and OSI. NEs B and C only support OSI, so they only route the OSI packets.
Figure 9-18 IP-over-CLNS Tunnel Flow
9.7.7.1 Provisioning IP-over-CLNS Tunnels
IP-over-CLNS tunnels must be carefully planned to prevent nodes from losing visibility or connectivity. Before you begin a tunnel, verify that the tunnel type, either Cisco IP or GRE, is supported by the equipment at the other end. Always verify IP and NSAP addresses. Provisioning of IP-over-CLNS tunnels in CTC is performed on the node view Provisioning > OSI > IP over CLNS Tunnels tab. For procedures, see the "Turn Up Node" chapter in the ONS 15310-CL Procedures Guide.
Provisioning IP-over-CLNS tunnels on Cisco routers requires the following prerequisite tasks, as well as other OSI provisioning:
•
•
•
•
•
The Cisco IOS commands used to create IP-over-CLNS tunnels (CTunnels) are shown in Table 9-14.
If you are provisioning an IP-over-CLNS tunnel on a Cisco router, always follow procedures provided in the Cisco IOS documentation for the router you are provisioning. For information about ISO CLNS provisioning including IP-over-CLNS tunnels, refer to the "Configuring ISO CLNS" chapter in the Cisco IOS Apollo Domain, Banyon VINES, DECnet, ISO CLNS, and XNS Configuration Guide.
9.7.7.2 IP Over CLNS Tunnel Scenario 1: ONS Node to Other Vendor GNE
Figure 9-19 shows an IP-over-CLNS tunnel created from an ONS node to another vendor GNE. The other vendor NE has an IP connection to an IP DCN to which a CTC computer is attached. An OSI-only (LAP-D) SDCC and a GRE tunnel are created between the ONS NE 1 to the other vender GNE.
IP-over-CLNS tunnel provisioning on the ONS NE 1:
•
•
•
•
•
IP-over-CLNS tunnel provisioning on the other vender GNE:
•
•
•
•
•
Figure 9-19 IP Over CLNS Tunnel Scenario 1: ONS NE to Other Vender GNE
9.7.7.3 IP Over CLNS Tunnel Scenario 2: ONS Node to Router
Figure 9-20 shows an IP-over-CLNS tunnel from an ONS node to a router. The other vendor NE has an OSI connection to a router on an IP DCN, to which a CTC computer is attached. An OSI-only (LAP-D) SDCC is created between the ONS NE 1 and the other vender GNE. The OSI over IP tunnel can be either the Cisco IP tunnel or a GRE tunnel, depending on the tunnel types supported by the router.
IP-over-CLNS tunnel provisioning on ONS NE 1:
•
•
•
•
•
CTunnel (IP over CLNS) provisioning on Router 1:
ip routing
clns routing
interface ctunnel 102
ip address 10.10.30.30 255.255.255.0
ctunnel destination 39.840F.80.1111.0000.1111.1111.dddddddddddd.00
interface Ethernet0/1
clns router isis
router isis
net 39.840F.80.1111.0000.1111.1111.bbbbbbbbbbbb.00
Figure 9-20 IP Over CLNS Tunnel Scenario 2: ONS Node to Router
9.7.7.4 IP Over CLNS Tunnel Scenario 3: ONS Node to Router Across an OSI DCN
Figure 9-21 shows an IP-over-CLNS tunnel from an ONS node to a router across an OSI DCN. The other vendor NE has an OSI connection to an IP DCN to which a CTC computer is attached. An OSI-only (LAP-D) SDCC is created between the ONS NE 1 and the other vender GNE. The OSI over IP tunnel can be either the Cisco IP tunnel or a GRE tunnel, depending on the tunnel types supported by the router.
IP-over-CLNS tunnel provisioning on ONS NE 1:
•
•
•
•
•
IP over OSI tunnel provisioning on Router 2 (sample Cisco IOS provisioning):
ip routing
clns routing
interface ctunnel 102
ip address 10.10.30.30 255.255.255.0
ctunnel destination 39.840F.80.1111.0000.1111.1111.dddddddddddd.00
interface Ethernet0/1
clns router isis
router isis
net 39.840F.80.1111.0000.1111.1111.aaaaaaaaaaaa.00
Figure 9-21 IP Over CLNS Tunnel Scenario 3: ONS Node to Router Across an OSI DCN
9.7.8 Provisioning OSI in CTC
Table 9-15 shows the OSI actions that are performed from the node view Provisioning tab. Refer to the Cisco ONS 15310-CL Procedure Guide for OSI procedures and tasks.
Table 9-16 shows the OSI actions that are performed from the node view Maintenance tab.
