|
|
This chapter describes techniques for modeling additional Cisco WAN network types and products. The information in this chapter is most helpful if you already know how to use the NMT, have created a configuration, and want to make changes to address specific needs.
The first part of this chapter deals with some common complex networks, and contains the following sections:
The second part deals with some common network aplications, that occur in both simple and complex networks. It contains the following sections:
The third part deals with additional NMT features, and contains the following sections:
Each section in this chapter consists of a description of a topic, followed by configuration notes. The configuration notes provide information about the tables and fields that need to be modified.
NMT9.2 introduces a new node type - MGX8850 (Popeye1 and Popeye2). NMT allows you to model MGX8850 as a stand-alone node, as a BPX feeder node (Popeye1 only), and an AutoRoute switch node inPopeye only or mixed node networks. The Popeye2 node can be modeled with switch software releases starting only from 920.
As a stand-alone node, the MGX 8850 switch concentrates narrow-band and medium-band ATM, Frame Relay, and voice into a single ATM line to at third-party switch. The MGX 8850 interface in this application is a UNI or an NNI.
As a routing Node the MGX 8850 can be a WAN backbone switch, supporting OC48 trunks and OC12 connections.
As a feeder node, the MGX 8850 connects to the BPX.
Refer to Table 4-1 for the basics of MGX8850 modeling. For more details about modeling the MGX8850 (Popeye1) as a feeder to BPX, also see Table 4-3.
| Topic | Required Settings | Comments |
|---|---|---|
Set Release | Model Settings table
|
|
Define node | Sites table
| NMT will not star the MGX8850 node; thus implicit feeder parameters are ignored. |
Define link | Links table
| If the MGX8850 is a stand-alone Popeye node, you do not need to use the Links table.
The PXM1 and AXSM cards are compatible only with BXM and UXM cards.Trunks to generic node via ATMC card are also allowed. There is no compatibility restriction for virtual trunks. |
Define connection | Bursty Traffic Table
| The RPM, VISM, and HAUSM cards are not modeled in current NMT release.
Connections may terminate on FRSM, AUSM, or CESM cards, and also on PXM1 and AXSM cards.
PXM1 and AXSM cards allow trunk and line ports on the same card. But, virtual trunks and virtual lines are not allowed on the same physical port. (NMT does not model Virtual Interfaces on PXM1 and AXSM line ports). |
Tiered networks are a special network configuration of Cisco WAN switches. A tiered network consists of a BPX or IGX hub node linked to a maximum of 16 IPX/IGX nodes or MGX 8220/ MGX 8850 edge concentrators designated as feeder nodes. A feeder node expands the port capacity of the BPX/IGX switch. A feeder node has no routing capabilities, so it is not counted against the maximum number of switches allowed in the network. It must be used when the BPX switch does not support a required line interface, such as T1/E1/V35/X21, or does not provide required network services, such as Frame Relay or circuit emulation. In a tiered network, each feeder has only one link to the hub node.
In NMT, tiered network generation is driven by the type and the line interface of the connection for creating IPX/IGX feeders and MGX 8220/MGX 8850 edge concentrators.
Figure 4-1 shows an example of a tiered network.
If an IPX/IGX/MGX8220 feeder is not in the Sites table but is generated by NMT, it is called an implicit feeder. When the node is in the Sites table, it is called an explicit feeder. The requirements for modeling implicit and explicit feeders differ.
To allow NMT to generate implicit feeders, you enter information about the hub site and the link connecting the hub to the feeder in the Site table, and you enter information about both the hub and feeder interfaces in the Traffic tables. For implicit feeders, connection endpoints are the hub nodes. The actual feeder ends cannot be referenced directly.
IGX, IPX, and MGX8820 feeder nodes can be implicitly generated by NMT. The MGX 8850, if used as a feeder, may not be an implicit feeder; it must be an explicit feeder.
Implicit IGX and IPX feeders are generated when a BPX is used as the hub node for Voice or Data Traffic. They are also generated when a BPX is used as the hub node for Frame Relay Traffic not designated for MGX8220.
Implicit IGX and IPX feeders can be generated when an IGX is used as the hub, but only when the traffic demands on the IGX exceed the resources of one node. Therefore, if the hub is an IGX, and you want to be assured that you design IGX or IPX feeders, it is better to make the feeders explicit.
Implicit MGX8820 feeders are generated when a BPX is used as a hub node, and the Bursty Traffic table contains connections designated for MGX8220.
Refer to Table 4-2 for information on modeling an implicit feeder tiered network with the NMT.
| Topic | Required Settings | Comments |
|---|---|---|
|
| Sites table Site field: Enter the name of the hub node Type field: Enter BPX or IGX. Tiered feeder flag: Enter Y if implicit IPX should be a tiered feeder. IGX field: Enter N for IPX and Y for IGX. BC field: Enter T3 or E3. FC field: Enter AIT. RLC field: Enter Y for trunk card redundancy. | Only IGX and BPX can be used as hubs. An IGX hub will only generate implicit feeders when the resources required exceed those allowed by an IGX.
Specify type of feeder for BPX/IGX type of site in the Sites table; specify the type of the link between hub and feeder.
The redundancy of feeder links is determined by the RLC field in the Sites table. |
| Voice, Data, or Bursty Traffic tables Site fields: Enter the name of the hub node Type field: Enter any valid IGX or IPX Voice, Data, or Frame Relay connection type (that is not supported on BPX.) BC field: Enter T1, E1, V, X, or other valid voice or data back cards. Fdr BC field: Leave blank or enter line interface for access feeder such as Port Concentrator, MC3810, or FastPAD. | Voice and data connections on IPX or IGX tiered network feeders may only terminate on another IPX or IGX feeder.
Hub IDs and feeder IDs are not defined for implicit IPX/IGX feeders. To specify the physical location of feeder trunks and lines, you must make the feeder node explicit by having it appear in the Sites table. In the Bursty Traffic table, verify that the connection originates or terminates on the IPX feeder as a Frame Relay connection. |
MGX 8220 Feeders: General Instructions
| Bursty Traffic table Site field: Enter the site name. Must be BPX site. Type field: any from the list of choices. BC (Back Card) field: Enter the back card that connects the BPX to the BNM card on the MGX 8220 edge concentrator. Fdr BC (Feeder Back Card) field: Enter the customer interface on the MGX 8220 service module. | MGX 8220 edge concentrators are provisioned from the BC and Fdr BC fields in the Bursty Traffic table. If the back card specified can support MGX 8220 , and the feeder back card can support the traffic type with an MGX 8220 service module, NMT will provision an MGX 8220 edge concentrators. If connection type implies AUSM card, the PCR value determines the port speed and whether more than one T1/E1 is required. |
Bursty Traffic table Fdr I/D fields (Feeder identification fields): ID values must be assigned. ID values can be
| By assigning IDs to the ports of the MGX 8220 service module cards, you can put the connection on a particular port. Feeder IDs can also control port-to-multiport connections.
| |
MGX 8220 Feeders: Multiple Feeders at a Site | Bursty Traffic table Hub ID field
| You need to configure a site with multiple MGX 8220 feeders only if you require connections between the feeders or if you need to associate specific connections with specific feeders (e.g., if the feeders are at different locations). Assign hub IDs to identify the port of the BNI/BXM card on the BPX switch that connects to the specific MGX 8220 edge concentrator. |
To allow NMT to model explicit feeders, you enter information about the feeder site in the Site table, about the link connecting the hub and feeder in the Link table, and about connection interfaces in the Traffic tables (as if the node were not a feeder). For explicit feeders, connection endpoints are the feeder nodes.
IGX and IPX nodes can be modeled as either hub or feeder nodes. The MGX 8820 can be modeled only as a feeder. Beginning with NMT 9.2, the MGX 8820 can be an explicit feeder as well as an implicit feeder.
The MGX 8850 is also modeled in NMT 9.2. As a feeder node, the MGX connects to the BPX. The MGX 8850 node, if modeled as a feeder, must be explicit.
Refer to Table 4-3 for information on modeling an explicit feeder tiered network with the NMT.
| Topic | Required Settings | Comments |
|---|---|---|
Explicit Feeders: General Instructions
| Model Settings table Make sure that the value of Switch Software Release is set to the release that is to be modeled. |
|
| Site Table Node Type field: Enter IGX, IPX, BPX, MGX8220, MGX8850, or any other valid Node Type. Fdr field: Enter Y. PC field: Leave blank, for all nodes except Popeye 2; if you are configuring a Popeye 2, enter PXM45. |
|
| Link Table Site1/Site2 fields: Enter the hub site name and the feeder site name. Trunk fields: Enter the appropriate T1, E1, T3, E3, OC3, or OC12 interface that connects the hub and feeder nodes. Trunk Card fields: Enter the front cards at the hub and the feeder nodes for the trunk that connects them. | You must enter the trunk between the hub and the feeder manually. NMT will not automatically generate it. Only IGX and BPX nodes may be hubs. IGX nodes may have only IGX or IPX feeders. BPX nodes can have MGX8220 and MGX8850 feeders as well.
|
| Voice, Data, or Bursty Traffic tables Site field: Enter the explicit feeder site name. Must be a site that has Y in the Fdr field in the Site table. Type field: any from the list of choices. BC (Back Card) fields: Enter the customer interface on the feeder node. | Only IGX and IPX feeders support Voice and Data Traffic. You must enter a feeder site name for NMT to put the connection on the feeder node.
Even though you are referencing a feeder node, use the BC fields, and not the FdrBC fields. |
Explicit Feeders: Port to Multiport | Bursty Traffic table Hub I/D fields: ID values must be assigned. ID values can be
| By assigning Hub IDs to the connection endpoints, you can put the connection on a particular port. Hub IDs can also control port-to-multiport connections.
|
A star network is found only within NMT; it is initiated when the link and connection requirements can be supported only by more than one switch or by a switch different from the one specified in the Sites table.
A star network is created when an IPX or IGX node exceeds its configuration capacity, or when a BPX node cannot provide the line interfaces (T1/E1/V35/X21/HSSI) or network services (voice, data) that the connections require. Switches that NMT creates implicitly in a star network can be routers or feeders for tiered networks. The NMT can add to the hub node up to 16 local IGX/IPX star-feeder nodes to serve the connections. Star-feeder nodes count against routing resources in NMT, even if they are tiered network feeders.
A star network is generated when a site requires more than one switch to serve the connection. Star network behavior with an IPX/IGX switch as the hub is different than it is with a BPX switch at the hub:
Refer to Table 4-4 for information on modeling a star network with the NMT.
| Topic | Required Settings | Comments |
|---|---|---|
Specifying types of switches and links for a star network | Sites table Tiered Feeder Flag: Enter N if starred implicit node is a router. IGX field: Y, if feeders should be IGX; N, if feeders should be IPX. BC (back card) field: Specify a back card for the link between hub and feeder. FC (front card) field: Specify a front card for the link between hub and feeder. RLC (redundant link card) field: Y, if you want to have a redundant trunk card. | To find out if a network has starred, select Sites from the Display menu, which displays the number of switches at a site. If the number is greater than 1, the site has starred. |
IPX and IGX switches can include devices that concentrate small connections into large ones or convert normal voice or legacy data connections into Frame Relay connections. NMT supports three access feeders that concentrate or convert data: the MC3810, the FastPAD, and the Port Concentrator. One IGX or IPX node can support up to 64 of these devices.
Using NMT to model connections that terminate on these access feeders is similar to the modeling of MGX 8220 feeders for a tiered network.
The NMT supports the MC3810 configured as a feeder to an IGX switch. The MC3810 can concentrate voice and data connections into Frame Relay connections. The NMT configures as many MC3810s as are required to support the traffic. NMT generally sets the feeder trunk speed to the minimum speed that can carry the traffic.
NMT designs MC3810s automatically when MC3810 connections are added to the Voice Traffic, Data Traffic, or Bursty Traffic table and the model is based on switch software release versions 8.2.5 to 8.3.9, or 8.5.0 and above.
Refer to Table 4-5 for information on modeling a network that uses the MC3810.
| Topic | Required Settings | Comments |
|---|---|---|
Model Settings table Make sure that the value of Switch Software Release is set to the release that is to be modeled. If that value is one that defaults to MC3810 (825 to 839, or 850 and above), NMT will design MC3810s for any non-voice feeder connections. All other values default to FastPAD for non-voice feeder connections.
| If the NMT default value (920) is used, NMT will automatically design MC3810s for all feeder connections, except for voice connection types that are exclusively for FastPad. | |
Data Traffic table Type field: Enter the data traffic speed. If the speed exceeds 512 Kbps, do not use the Data Traffic table; use the Bursty Traffic table instead. BC (Back Card) field: For each end of the connection, enter the back card of the FTC/ FTM card that links the hub IPX/IGX switch to the MC3810 (T1, E1, V, or X). Fdr BC (Feeder Back Card) field: Enter the connection interface on the line side of the MC3810. | Each MC3810 data connection must originate and terminate on a MC3810. If the switch software release does not support the MC3810, NMT designs FastPADs. The minimum speed for synch data is 19.2 kbps. For legacy data like HDLC, use the Bursty Traffic table. | |
Adding MC3810 dedicated voice connections | Voice Traffic table Type field: Enter C32, A32, G729, G729V, G729A, or G729AV. The types refer to compression algorithms; all G types are 8 kbps. BC (Back Card) field: For the MC3810 end of the connection, enter the back card of the FTC/FTM card that links the hub IPX/IGX switch to the MC3810 (T1, E1, V, or X). Fdr BC (Feeder Back Card) field: For each end of the connection having a MC3810, enter V for analog voice, or T1 or E1 for digital voice. | MC3810 dedicated voice connections can have one end at a MC3810 and the other at a CDP, CVM, or UVM card at an IPX or IGX switch. For each feeder back card entry, the NMT establishes a dedicated virtual circuit that connects one voice port on a MC3810 to one voice port on another MC3810 or on an IPX/IGX switch. |
Adding MC3810 bursty data connections | Bursty Traffic table Type field: Enter FR. BC (Back Card) field: On the connection side that uses a MC3810, enter the back card of the FTC card that links the hub IPX/IGX switch to the MC3810 (T1, E1, V, or X). On the other side of the connection, enter the back card of the FRP/FRM (also T1, E1, V, or X). Fdr BC (Feeder Back Card) field: For the connection side with a MC3810, enter the connection interface on the line side of the MC3810. MIR field: Specify the bandwidth requirements on the feeder trunk and the network backbone. PIR field: Specify the port and bus bandwidth requirements | A MC3810 data connection can have one end at a MC3810 and the other at an IPX/IGX FRP/FRM card. At least one end of the connection must have an entry in the Fdr BC field in order for a MC3810 to be designed. If the switch software release does not support the MC3810, NMT designs FastPADs. Remember to set the connection bandwidth by adjusting the MIR and PIR fields. |
Setting up switched voice connections | Voice Traffic table
Create dummy MC3810 connections:
| To add MC3810 switched voice connections, i.e., voice connections between at least one voice port on a MC3810 connected to at least one voice port on many MC3810s, you must perform a two-step process: connect the MC3810s and add dummy MC3810 connections. |
Setting up multiple MC3810s at the same site | Data Traffic table, Voice Traffic table, Bursty Traffic table
| For connections between multiple MC3810s at a site or to associate specific connections with specific MC3810s, use the Hub ID field for all MC3810 connections that originate or terminate at that site. All connections associated with one specific MC3810 should have the same Hub ID throughout the three traffic tables. |
Feeders table
Data Traffic table, Voice Traffic table, Bursty Traffic table
| You can specify the maximum speed of the feeder trunk, for example, If you specify a speed of 0, NMT chooses the best one. |
A FastPAD connection is a connection where at least one end terminates on a FastPAD. FastPADs always connect to the network on a Frame Relay composite link to an FTM or FTC card. FastPAD enables you to concentrate voice and data connection types as a Frame Relay connection joined to an FTC or FRM card.
NMT designs FastPADs automatically when FastPAD connections are added to the Bursty Traffic, Data Traffic, or Voice Traffic table and the model is based on switch software release versions less than 8.2.5, or 8.4.0 to 8.4.9. NMT will also design FastPADs when FastPADs are specifically called for in the Feeders table and connection hub IDs match Feeders table hub IDs.
The FastPAD comes in two sizes, one with eight slots and one with four slots, called the FastPAD micro. By default NMT
Refer to Table 4-6 for information on modeling a network that uses FastPADs.
| Topic | Required Settings | Comments |
|---|---|---|
Setting Switch Software Release | Model Settings table Make sure that the value of Switch Software Release is set to the release that is to be modeled. If that value is one that defaults to FastPAD (817 to 824, or 840 to 849), NMT will design FastPADs for any non-voice feeder connections. All other values default to MC3810 for non-voice feeder connections.
| FastPADs will not be designed for non-voice connections under the default switch software release (920). To force NMT to use FastPADs, the Feeder Table must be used; see Changing Default Parameters below. |
Data Traffic table Type field: Enter the data traffic speed. BC (Back Card) field: For each end of the connection, enter the back card of the FTC/FTM card that links the hub IPX/IGX switch to the FastPAD (T1, E1, V, or X). Fdr BC (Feeder Back Card) field: Enter the connection interface on the line side of the FastPAD (S, R, V, V1, or V6).
| FastPAD data connections must originate and terminate on a FastPAD. If the switch software release supports the MC3810, NMT will design MC3810s, not FastPADs, unless the hub ID fields and the Feeder table are used. For each feeder back card entry, the NMT establishes a dedicated virtual circuit that connects one data port on one FastPAD to one data port on another FastPAD. | |
Adding FastPAD Dedicated Voice Connections | Voice Traffic table Type field: Enter ATC8, ATC12, ATC16, CELP8, or CELP48. The numbers refer to kbps. BC (Back Card) field: For each end of the connection, enter the back card of the FTC/FTM card that links the hub IPX/IGX switch to the FastPAD (T1, E1, V, or X). Fdr BC (Feeder Back Card) field: For each end of the connection, enter V for the VFC-03 card. | FastPAD dedicated voice connections must originate and terminate on a FastPAD. For each back card field entry, the NMT establishes a dedicated virtual circuit that connects one voice card on one FastPAD to one voice card on another FastPAD. |
Adding FastPAD Bursty Data Connections | Bursty Traffic table Type field: Enter FR. BC (Back Card) field: If the end has a FastPAD, enter the back card of the FTC that links the hub IPX/IGX switch to the FastPAD (T1, E1, V, or X). If the end is not a MC3810, enter the back card of the FRP/FRM at that end (also T1, E1, V, or X). Fdr BC (Feeder Back Card) field: If the end has a FastPAD, enter the connection interface on the line side of the FastPAD (S, R, V, V1, or V6). If the end does not have a FastPAD, leave this field blank. | A FastPAD bursty data connection may have one end at a FastPAD and the other at an IPX/IGX FRP/FRM card. At least one end of the connection must have an entry in the Fdr BC. |
Setting Up Switched Voice Connections | Voice Traffic table Connect the FastPADs:
Create dummy FastPAD connections:
| To add FastPAD switched voice connections, i.e., voice connections between at least one voice card on a FastPAD connected to at least one voice card on many FastPADs, you must perform a two-step process: connect the FastPADs and add dummy FastPAD connections.
|
Data Traffic table, Voice Traffic table, Bursty Traffic table
| For connections between multiple FastPADs at a site or to associate specific connections with specific FastPADs, use the Hub ID field for all FastPAD connections that originate or terminate at that site. All connections associated with one specific FastPAD should have the same Hub ID throughout the three traffic tables. | |
Feeders table
Data Traffic table, Voice Traffic table, Bursty Traffic table
| You can specify a FastPAD or FastPAD micro unit and can specify the maximum speed of the composite link, i.e., 64 kbps, 128, kbps, or 256 kbps. If you specify FP (a generic FastPAD), NMT chooses the best one. If you specify 0 as the speed, NMT picks the best one. |
The Port Concentrator provides a method for concentrating voice and data connection types as a Frame Relay connection extending to an FTC or FRM card. The NMT models and provisions Port Concentrators so that they support Frame Relay connections. The card is modeled as a 44-port FRP card, with the PC interface being optional but defaulting to V35.
Refer to Table 4-7 for information on modeling a network that uses port concentrators.
| Topic | Required Settings | Comments |
|---|---|---|
Bursty table Type field: Select FR, ATF, or FTA. BC (back card) field: To specify a PC termination, enter PC in the BC field of the site that has the PC. The NMT rejects PC if the connection type is incorrect. Fdr BC (feeder back card) field: Each PC termination can also specify which PC interface is required. Enter V (for V.35), V1 (for V.11) or V2 (for V.28) in the corresponding Fdr I/F field. If you leave the field blank, the interface defaults to V.35. Hub ID (for Site 1 and Site 2) fields
FdrID (Feeder ID) field: Not used Access Ports table Hub ID field: Slot is the PC slot and port is the virtual port (1 to 44). Do not use feeder slot or feeder port column. Speed field: Enter the port speed. If not supported, it will be rounded up to the nearest supported speed. Speeds 9, 14, 19, and 38 will be respectively interpreted as 9.6, 14.4, 19.2, and 38.4. If you have an Access Port table entry for a PC port, the port speed is determined by the connections assigned to it. | NMT designs port concentrators if, and only if, you enter connections that have port concentrator terminations. Geis bundling format is not supported for FRP-PC.
|
The Least Cost Routing feature introduces the concept of cost based routing into the interface. It was developed to prevent selection of a route which exceeds an acceptable cost.
Refer to Table 4-8 for information on Least Cost Routing.
| Topic | Required Settings | Comments |
|---|---|---|
Specifying a Least Cost Route | Sites table RA (Routing Algorithm) field: Enter C (least cost) or CD (least cost with delay as a cost) | Any site can have a least cost or least hops routing rule. |
| Links table Cost field: Enter a value between 1 and 50. | The weight of the trunk to be used in the routing algorithm. |
| Voice, Data, and Bursty Traffic tables Cost field: Enter a value between 1 and 100. | The maximim allowable cost of the route for this connection. |
Use NMT to customize IMATM trunks and Virtual trunks.
An IMATM trunk is an ATM link of one to eight DS1 lines. Each IMATM trunk card uses a slot of an MGX 8220 edge concentrator and is connected to the BPX switch by means of a T3/E3 port on a BNI card. The trunk can be configured so that it fails only if more than n DS1 lines fail.
The NMT does not model IMATM trunk resiliency during failure analysis. To exclude IMATM trunks from failure analysis, see the section "Fail Analysis" in the chapter "Using the NMT."
Refer to Table 4-9 for information on configuring an IMATM trunk in the NMT.
| Topic | Required Settings | Comments |
|---|---|---|
Specifying an IMATM Trunk | Links table Trunk (type) field: Specify a trunk of T1 or E1. Prepend the number of DS1s for the trunk, for example 5T1 or 8E1. Trunk (capacity) field: For E1 links, specify number of DS0 in the line: 30 for CCS signalling or 32 for Clear Channel signalling. Trunk card field: Specify IMA for both trunk front cards. IMA_RD field: enter the resiliency degree. | Both sites must be BPX. The IMA_RD field is on the second screen of the Links table. |
The virtual trunking feature introduces the concept of defining multiple trunks within a single trunk port interface. It was developed to provide connectivity for a hybrid network consisting of Cisco ATM switches through a public ATM cloud.
NMT models virtual trunks on BNI, BXM, BTM, and AIT ports. To exclude virtual trunks from failure analysis, see the section "Fail Analysis" in the chapter "Using the NMT."
Refer to Table 4-10 for information on virtual trunk configurations.
| Topic | Required Settings | Comments |
|---|---|---|
Specifying a Virtual Trunk | Links table M (Media) field: Enter VT Trnk_Cd field: Both ends must be specified. The ends can be different. VTRate field: Specify the VT rate in cells per second. ...&Type field: Define the ATM type of link (ABR, CBR, UBR, VBR, or leave blank if the links support all types of traffic). | If the back cards are different, the maximum size of VT is the minimum of the two protocols. |
Use NMT to customize these connections:
NMT allows you to model ATM connections in the Bursty Traffic Table. Refer to Table 4-11 for information on modeling ATM connections
| Topic | Required Settings | Comments |
|---|---|---|
Modeling ATM Connections | Bursty Traffic table Site1, Site2 fields: Enter the connection end-point sites. Quantity: Enter the number of connections. Type field: Enter ABR, CBR, VBR, or UBR. MCR fields: Enter minimum cell rate (or Committed Information Rate). PCR fields: Enter peak cell rate |
The ATM sites must must be in the Site Table and must support ATM traffic types (i.e., must be an MGX8850, a BPX, an MGX8820, or an IGX switch with 8.2.5 functionality).
All traffic values (MCR, PCR, QIR, CIR) are given in cells per second for ATM traffic. |
NMT allows you to model ATM to Frame Relay interworking connections. Refer to Table 4-12 for information on modeling ATM to Frame Relay interworking connections.
| Topic | Required Settings | Comments |
|---|---|---|
Modeling ATM to Frame Relay | Bursty Traffic table Type field: Enter ATF or FTA.
| Use ATF when the ATM interface at Site1 interworks to a Frame Relay interface at Site2. Use FTA when a Frame Relay interface at Site1 to interworks to an ATM interface at Site2. The ATM end must support the specified traffic type (i.e., must be a BPX switch or an IGX switch with 8.2.5 functionality). All traffic values (MIR, PIR, QIR, CIR) are given in kbps for ATM traffic. |
NMT allows you to provide any connection with a path through the network, called a preferred route. If the preferred route is available, NMT will follow it for that connection. If the preferred route is not available (common during Failure Analysis), NMT routes the connection any way it can. NMT now also models a directed route - a special case of a preferred route in which a connection must take its preferred route, or not be routed at all.
To enter a preferred route, you enter a route in the Preferred_Route field in the Traffic tables. The route is a series of "cross-connects"(Xcon), separated by equal signs (=), i.e, Xcon1[=Xcon2]...[=XconN].
A "cross-connect" consists of an optional In-trunk HubID (slot/port identifier) followed by a forward slash (/), a mandatory Site Name, and an optional forward slash followed by an Out-trunk HubID. That is, you represent a cross-connect as: [In-trunkHubID/]SiteName[/Out-trunkHubID].
When you specify either of the HubID's in an Xcon, you specify a unique trunk. So if NMT has a choice of trunks between two nodes, you can now specify exactly which one NMT should use. You do not have to specify each Xcon to the same level of detail; one may have no HubID, the next both HubIDs, etc. Some examples should make this clear.
For a connection from Denver to Paris, the following are all valid preferred routes.
Paris 3.1/Paris Denver=Paris Denver/4.1=Paris Denver/4.1=3.1/Paris Boston=Paris 4.1/Boston=Paris 4.1/Boston=4.1/Paris 4.1/Boston/3.1=4.1/Paris Denver/3.1=4.1/Boston/3.1=4.1/Paris
Refer to Table 4-13 for more information on modeling preferred and directed routes.
| Topic | Required Settings | Comments |
|---|---|---|
Modeling Preferred or Directed Routes | Voice, Data, and Bursty Traffic tables DR field: Enter 'Y' if the connection has the directed routing feature, and `N' otherwise. Preferred_Route field: Enter a series of node "cross-connects", separated by equal signs (=). |
If the Preferred_Route field is left blank or is invalid, this field is ignored.
All site names must be in the Site Table, and each consecutive pair of sites must have a trunk in the Link Table. The originating and terminating sites are optional. |
NMT ascii reports are generated with each run of either the Route command or the Optimize command. Some of these reports can be viewed from the Display menu. All can be written to disk from the Report menu. Define Input Screen determines which reports to include in the output file, and Generate creates and names the output file. Most reports are fairly straight forward in the information they present. Two important reports that require some discussion are:
This report displays the load resources on each link in the network, based on the static load model.
In the example below, den-sea is a cell based link where the bandwidth is 92% utilized. This link contains 80000 cells for CBR ATM traffic, 7515 cells of frame relay, and has a statistical reserve of 600, which is not included in the total. There are 55 PVC's on the 1st link. The second link, nyd-pit, uses only 6% of the bandwidth, but has reached the maximum number of PVC's allowed on the link. Note that this is a packet based trunk, as the units are pps. The third link, (lax-pit) is a T3 cell based trunk on a BTM card. The units displayed are packets because the constraint on this link is the number of packets that can be received by the IGX bus. The fourth link, (lax-nyd) is also a cell based trunk. For this link, both the packet load and the cell load are listed because in this case the cell load is the constraint. This is because the combine time outs are set low so most voice and data cells contain only one packet.
------------------------------- Link Load ----------------------------------Trunk Span Load Used Maximum Load MaxSite1 Site2 Type load load units %Ld------------- ------------- ----- -> / <- -> / <- -> / <- ---den sea Total 87515/ 87515 96000/ 96000 cps/cps 92(1.1) (1.1) CBR 80000/ 80000BData 7515/ 7515RES 600/ 600PVC 55/ 55 1771/ 1771 pvc/pvcnyd pit Total 426/ 426 8000/ 8000 pps/pps 6(3.1) (3.1) Voice 426/ 426RES 600/ 600PVC 213/ 213 213/ 213 pvc/pvclax pit Total 2904/ 6824 80000/ 80000 pps/pps 9(5.1) (4.1) NTS 630/ 630Voice 994/ 994BData 1280/ 5200RES 600/ 600PVC 237/ 237 1771/ 1771 pvc/pvclax nyd Total 2824/ 2824 10666/ 10666 pps/pps(3.1) (4.1) NTS 630/ 630Voice 994/ 994BData 1200/ 1200RES 600/ 600Total 2164/ 2164 4830/ 4830 cps/cps 51NTS 630/ 630Voice 994/ 994BData 540/ 540RES 600/ 600PVC 227/ 227 1771/ 1771 pvc/pvc
The resource report displays the card cage for each system unit, and a brief listing of used and available ports. The card statistics report is the second part of the resource report. The new NMT 9.1 release models the UXM card, and has a new card statistics report for tracking the UBU usage of this and other cards. Below is a card statistics report for a two IGX network with 295 ATF interworking connections between the nodes, each MIR=64K, PIR=256K.
------------------------- Card Statistics ----------------------------
Node: ATM_Side Type: IGX-8 Bus Used: 40 UBUs out of 584
Slot Front Back Type PVCs Port UBU/PS Card Specific
Stat Used Allc/Used/Max
1 A NPM 2 2 2
2 S NPM
3 A UXM 3T3 Trunk 295 1 25 13 184 FPL=8%, GWL=2%
4 A UXM 3T3 Line 295 1 13 13 184 FPL=8%, GWL=2%
Legends:
FPL - Fast Packet Load : Percent of FP bus load / Total bus load.
GWL - Gateway Module Load : Percent of FP bus load / Max FP bus load.
====================================================================
Node: FR_Side Type: IGX-8 Bus Used: 118 UBUs out of 584
Slot Front Back Type PVCs Port UBU/PS Card Specific
Stat Used Allc/Used/Max
1 A NPM 2 2 2
2 S NPM
3 A UXM 3T3 Trunk 295 1 60 60 184 FPL=100%, GWL=100%
4 A UFMC T1 192 48 32 32 59
5 A UFMC T1 103 26 24 24 59
Legends:
FPL - Fast Packet Load : Percent of FP bus load / Total bus load.
GWL - Gateway Module Load : Percent of FP bus load / Max FP bus load.
====================================================================
This report tells us that the IGX switch with the ATM end is using 40 of its 584 UBU's, where the IGX switch with the FR end is using 118 UBUs. Looking to the UXM trunk card on slot 3 for both switches, the UXM trunk card at the ATM end is configured to reserve 25 UBUs of the bus, with the current traffic load requiring 13. The maximum setting for this value for a UXM card is 235. The FPL percent means that only 8% of the traffic on this card is in Fast Packets, and the GWL percent means that only 2% of the maximum Fast Packets are being used by the card. Note that the FP traffic here is internal signaling between the card and switch. At the FR end, the FPL is 100% as all traffic on this card is FP. The GWL is also %100 because this card can take no more FP traffic. It can take more ATM traffic.
The table below describes a common NMT problem and what can be done about it.
Symptom | BPX/IGX links are carrying about twice the load expected |
Probable Causes | The combine timeouts are set low (defaults) such that cells contain only one packet |
Solution | Go to CONFIG/MODEL SETTINGS and set the combine timeout values to a higher value. Set it to 255 to force all voice/TS/NTS so each cell contains two packets. |
Posted: Fri Dec 3 18:36:37 PST 1999
Copyright 1989-1999©Cisco Systems Inc.