Previous | Table of Contents | Next |
Table 6.2 describes the various types of switching and load balancing in Cisco routers.
Switching Type | Similar to IP | Load Balancing |
---|---|---|
Process switching | Yes | Packet by packet |
Fast switching | No | Packet by packet |
Autonomous/silicon | Yes | Destination by destination |
Designers can modify the default IPX RIP metrics by using the ipx delay command.
Do not infer from Table 6.2 that IPX cannot be fast-switchedit can. Its behavior is different from the characteristics of IP fast switching. Also note that some versions of the IOS, including 11.2(12), have problems with IPX fast switching, and administrators should upgrade their routers as applicable. |
Controlling IPX SAP Traffic
The Service Advertising Protocol, or SAP, is responsible for the distribution of information regarding file, print, and other services provided by the network.
For the network designer, the SAP process can be both a help and a hindrance. The most significant problem with SAPs is their reliance on broadcasts, which in turn limits scalability.
However, it is not the broadcast update mechanism that hinders scalability with SAP. The issue is the method used to create the updates. Each router and server in the network recalculates SAP traffic. This information is then retransmitted as a complete SAP table, which should be consistent throughout the network. Rather than sending information about just the services that that server provides, the device sends information about all services that all devices provide. Also, separate SAP entries are created for each service, so a NetWare server with three printers, file sharing, and four database entries would create eight SAP entriesrequiring two SAP packets.
Each SAP update is transmitted at 60-second intervals, and each update packet contains up to seven services. The designer can readily see how the addition of a single service on the network would add to the SAP traffic when repeated by 1,000 routers and servers, for example.
It is important for the network designer to consider filtering IPX SAP traffic even when the network is quite smallpossibly as small as 20 networks. The use of IPX SAP access lists can provide security and scalability features to the network. As with most network policies, SAP access lists are best deployed at the distribution layer of the hierarchical model.
Table 6.3 shows the three different locations where administrators may employ SAP access lists.
Location | Command |
---|---|
Input | input-sap-filter |
Output | output-sap-filter |
Source | router-sap-filter |
The IPX SAP access lists are numbered from 1000 to 1099 and are configured in a similar fashion to IP access lists. The syntax is as follows:
Access-list {number} [deny | permit] network[.node]
[service-type[server-name]]
A network number of 1 will match any network, and a service type of 0 will match all services. Like other access lists, SAP access lists are parsed in sequence and with an implicit deny at the end.
SAP update timers can also be controlled without filtering the contents. You accomplish this with the ipx sap-incremental command, which was introduced with Cisco IOS 10.0. This option is available to administrators without the IPX EIGRP protocol as well. The argument rsup-only is added to the command.
For use with non-Cisco equipment, it is possible to adjust the default update increment for SAP broadcasts; however, you must deploy this option with caution and consistency. The benefit of this option is the reduction of bandwidth consumed by SAP broadcasts. However, as with most options, the designer and administrator must accept a compromise. As the time between updates increases, the time for notification of a failed service also increases. This may not be a significant concern in most networks, but it is worth considering before selecting this SAP control option.
It is recommended that no nodes be placed on a segment that has a modified SAP timer; however, it is permitted so long as all nodes on the segment are modified to reflect the new configuration. |
IPXWAN
While it is uncommon, there may be an instance when the designer or administrator would wish to connect a Novell server to a Cisco router via the Point-to-Point Protocol (PPP). Such installations are occasionally used for disaster recovery.
The IPXWAN protocol operates over PPP to provide accurate routing metrics on dial-up connections, which is accomplished via a handshake process. IPXWAN is an established standard, which permits interoperability between non-Cisco devices. Cisco has supported the protocol since IOS 10.0.
It was noted previously that IPXWAN links incorporate a cost of six ticks. This is automatically resolved when using IPXWAN over PPP. The command ipx link-delay is used to adjust the cost of each link. Table 6.4 provides suggested delay values based on formulas from Cisco and Novell. Note that these values were developed for IPXWAN 2.0.
Bandwidth | Ticks |
---|---|
9600 bps | 108 |
19.2Kbps | 60 |
38.4Kbps | 24 |
56Kbps | 18 |
128Kbps | 12 |
256Kbps | 6 |
1.544Mbps | 6 |
Previous | Table of Contents | Next |