|
|
This chapter provides information about how to achieve efficient internet connectivity for your Release 10 of CWM network management station for SVC connections and PNNI links. Figure A-1 shows a typical network configuration for a workstation running Release 10 of CWM.
This section describes the IP Connectivity feature of the MGX 8850 Release 2. IP connectivity builds a IP data-path between a PXM and another IP host/workstation. Through IP connectivity, MGX 8850 Release 2 can be managed by a network management system such as CWM using standard TCP/IP and proprietary protocols.
The typical, most-likely configuration will include the following:
Figure A-2 shows the logical connectivity between MGX 8850 Release 2 nodes and CWM workstations.
IP connectivity relies on three disjoint IP hosts to build the IP data path. The first are the PXMs, where servers for the CWM, FTP, Telnet, etc. reside. The PXMs are the end-point for the MGX 8850 Release 2 being managed.
The second are router or routers. This routers interface with the PXMs using SVCs to transfer IP data. The routers will also interface with the CWM workstations that are managing the MGX 8850 Release 2 through some other network interface (usually ethernet).
The third are the CWM workstations managing the MGX 8850 Release 2. The CWM workstations initiate data being sent on the data-path to the MGX 8850 Release 2. The CWM workstation knows or learns that the routers are the go-between for all data to and from the MGX 8850 Release 2.
The CWM workstations will have clients such as CWM, FTP, Telnet, and TimeOfDay (among others) that will make IP connections with the appropriate servers on the MGX 8850 Release 2.
The PXM software provides for setting up the IP Connectivity data-path. This connectivity comes in several pieces. The first piece is the implementation of a custom interface for the VxWorks TCP/IP protocol stack. This custom interface will hook-up to the IP layer of the protocol stack and will have the ability of transferring data between the ATM SAR and the IP stack. This custom interface will be assigned a unique IP address and will have the ability of creating and deleting IP host-routes that use the interface.
The custom interface will support IP over ATM as described in RFC1483. It will also be an ATMARP client as described by RFC1577. Figure A-3 shows the custom interface that for the remainder of this chapter will be referred to as the IPATM interface.
The IPATM requires the following configuration:
The IPATM interface actually communicates to a router or a set of routers. The interface from IPATM to the router is an SVC connection. The IPATM interface has configuration that specifies a well-known AESA for the router. When the IPATM interface is configured and attached to VxWorks IP layer, it will perform the following steps.
1. Register the IPATM AESA with the SVC Signalling API (SIGAPI) service.
2. Make a series of SVC call requests to the routers the interface knows about.
3. When a call is established, send an ATMARP request to the router to inform router of the IP address of the IPATM interface.
The SIGAPI provides access to the PXM SAR for the purpose of terminating the SVC on the PXM. It also provides a connection establishment procedure for obtaining VC identifiers and procedures for SVC termination.
Note, that PNNI can be used for routing of call requests from the IPATM interface to IP routers. If PNNI is not available, then static routes must be specified for IPATM to router communication.
Internal to the router is configuration as well. This configuration allows the router to route packets from the IPATM interface SVC to a IP host that wishes to manage or access the MGX 8850 Release 2 using TCP/IP clients. This configuration can be separated into two distinct parts.
The router configuration required for IPATM interface SVC is as follows:
The router configuration required for IP host/workstation communication to MGX 8850 Release 2:
Figure A-4 describes the IP router function that provides IP connectivity to MGX 8850 Release 2.
Once the IPATM interface on every MGX 8850 Release 2 is hooked to the IP layer of VxWorks TCP/IP stack and every SVC has been established between IPATM interface and routers, full connectivity will exist between all MGX 8850 Release 2 nodes through all routers. This communication path has also been relayed to the IP host/workstation using a routing protocol such as RIP. The IP host/workstation will now know, via a IP route, which router will accept data for each MGX 8850 Release 2.
 |
Note If the IP host/workstation does not support the routing protocols used by the routers, the IP routes for each MGX 8850 Release 2 will have to be manually added on the CWM workstation. |
All that remains for the IP host to do is to determine the IP address for each IPATM interface with which it wants to establish TCP/IP communication. This can be as simple as manually entering these IP addresses into the host's host table, or as complex as dynamically determining these IP addresses via another protocol such as ILMI. In either case it is assumed that the IP host/workstation knows the IP addresses of the IPATM interfaces for the remainder of this chapter.
Figure A-5 shows the complete IP data-path between the MGX 8850 Release 2 and the IP host/workstation. The IP Cloud signifies an IP network and can be as simple as a directly attached ethernet or as complex as a multi-hop, multi-interface type network. Router #1 and Router #2 may or may not be part of the same IP Cloud.
It is the job of the IP host/workstation to initiate the IP communication to the MGX 8850 Release 2 by sending IP data addressed to the IPATM interface of the MGX 8850 Release 2 to the correct router.
Once received by the router, the IP address of the destination of the data (MGX 8850 Release 2) is looked up in the router's IP route table. Because the IP address of the MGX 8850 Release 2 has been previously added to this interfaces route table, the data is given to the ATM interface driver. There, a map table specifies which SVC on the router should be used. The ATM interface on the router, if using LLC encapsulation as described in RFC1483, prefixes the data with a header that specifies to the remote end of the SVC that the data is encapsulated IP data. The router then transmits the data onto the SVC.
The encapsulated IP data is received by the MGX 8850 Release 2 IPATM interface on one of its router SVCs. Using RFC1483 if the data is on an SVC supporting LLC encapsulation, IPATM interface strips off the prefixed header and verifies that the data is truly IP data. If it is, the IPATM interface performs a very important function: it adds an entry to a local cache to remember which SVC was used by the IP host/workstation to reach the MGX 8850 Release 2. The cache has the following format:
Should the cache entry already exist for the IP host/workstation it is updated if the SVC being used has changed. This allows the IPATM interface to dynamically choose the correct SVC necessary. After setting up the cache entry, IPATM interface then adds a new VxWorks IP host-route for the IP host/workstation. The IP host-route will allow VxWorks IP stack to give all IP data that is to be sent to the IP host/workstation to the IPATM interface. Once the IP host-route is setup, the IPATM interface gives the received IP data to VxWorks IP layer. From there, it will be routed to the appropriate server application of the MGX 8850 Release 2.
Should the server application of the MGX 8850 Release 2 need to respond to the data received from the IP host/workstation, it will do so by making a client/server API call to VxWorks. The data from the server will eventually reach the VxWorks IP layer, where a IP route table will be searched to determine the correct interface that should be used for the transmission. The VxWorks IP layer will find the IP host-route that was previously added by the IPATM interface when the data was originally received and the data will be given to IPATM.
The IPATM interface, when given IP data from VxWorks IP layer, will perform a cache lookup of the destination IP address of the data. In the cache, an entry should exist that specifies which SVC VC identifier should be used for sending the IP data. If found, the data is prefixed with a header as described by RFC1483 if the SVC supports LLC encapsulation and sent. If not, the data is dropped and a statistic is kept for the dropped data.
The router will receive the data transmitted by the IPATM interface, strip the RFC1483 header if required, and transmit the data to the correct IP interface for reaching the IP host/workstation. Again, this will be accomplished using a IP route table lookup in the router.
The IP host/workstation will receive the data transmitted by the MGX 8850 Release 2 server and forward the data to the appropriate TCP/IP client running on the host/workstation.
To configure the type of network as shown in Figure A-1, you must first create an SVC connection between an MGX 8850 Release 2 node (MGX 8850 C) and a router (CWM RTR-1). Configure the connection to MGX 8850 C as your CWM gateway. Next, configure SVC connections between the CWM router and each of the other MGX 8850s.
The following two sections provide information about ample configurations and the features they offer.
The first sample configuration provides the following features:
The following MGX 8850 Release 2 configuration is required:
ipifconfig atm0 172.24.29.190 arp
Step 2 Configure local AESA
svcifconfig atm0 local <nsap address > (for example 47.0091.8100.0000.1010.1010.1010.1010.1010.1010.10)
Step 3 Configure router AESA of Router
svcifconfig atm0 router <nsap address > (for example 47.0091.8100.0000.0101.0101.0101.0101.0101.0101.01) arp llcencap
interface atm 0 ip address atm0 172.29.23.118 255.255.255.0
Step 2 Configure local AESA
atm nsap-address 47.0091.8100.0000.0101.0101.0101.0101.0101.0101.01
Step 3 Configure the router to be ATMARP server:
atm arp-server self
Step 4 Configure the signalling PVC:
atm pvc 1 0 5 qsaal
Step 5 Configure UNI 3.1:
atm uni-version 3.1
Step 6 Ensure that IP routing is enabled:
ip routing
The first sample configuration provides the following features:
The following MGX 8850 Release 2 configuration is required.
ipifconfig atm0 172.29.24.190 arp
Step 2 Configure local AESA:
svcifconfig atm0 local 47.0091.8100.0000.1010.1010.1010.1010.1010.1010.10
Step 3 Configure router AESA of Router:
svcifconfig atm0 router 47.0091.8100.0000.0101.0101.0101.0101.0101.0101.01 noarp vcmux
You must configure a static route that specifies endpoint for router AESA so that PNNI learns about this endpoint.
interface atm 0 ip address atm0 172.29.23.118 255.255.0.0
Step 2 Configure local AESA:
atm nsap-address 47.0091.8100.0000.0101.0101.0101.0101.0101.0101.01
Step 3 Configure the signalling PVC:
atm pvc 1 0 5 qsaal
Step 4 Configure UNI 3.1:
atm uni-version 3.1
Step 5 Manually configure mapping for MGX 8850 Release 2:
map-list atm ip 172.29.24.190 atm-nsap 47.0091.8100.0000.1010.1010.1010.1010.1010.1010.10
Step 6 Manually setup IP route table entries for MGX 8850 Release 2:
ip route 172.29.24.190 255.255.255.0 172.29.23.118
Step 7 Make sure IP routing enabled:
ip routing
You must create a PNNI link between the MGX 8850 Release 2 node (for the node which is physically connected to the router) and the router. To create a PNNI link, complete the following described below:
popeye10.6.AXSM.a > addport 1 1.1 48000 48000 6 1
Step 2 Create a partition,
popeye10.6.AXSM.a > addpart 1 1 2 1000000 1000000 1000000 1000000 1 255 33 65535 100 1000
i
popeye10.7.PXM45.a > dsppnports
Step 2 Check whether the port is up and normal
PortId IF status Admin status ILMI state Total Activeconns 7.35 up up Undefined 0 7.36 up up Undefined 0 7.37 up up Undefined 0 7.38 up up Undefined 0 6:1.1:1 up up UpAndNormal 1
Step 3 If the port is displayed, then do the following:
popeye10.7.PXM45.a > addpnport 6:1.1:1
popeye10.7.PXM45.a > cnfpnportsig 6:1.1:1 -univer uni31
popeye10.7.PXM45.a > uppnport 6:1.1:1
popeye10.7.PXM45.a >
addaddr 6:1.1:1 47.0091.8100.0000.1010.1010.1010.1010.1010.1010.10 160
|
Note The value of 160defines the length of the AESA address. |
Posted: Fri Sep 29 12:06:33 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.