In the last few chapters, you've seen the issues that can arise when IP EIGRP networks grow too large (Chapter 5, "Scalability Issues in Large Enterprise Networks,"), and several tools can make these networks scalable. Summarization was discussed in Chapter 6, "EIGRP Route Summarization," route filters in Chapter 7, "Route Filters," default routes in Chapter 8, "Default Routes," and route redistribution in Chapter 9, "Integrating EIGRP with Other Enterprise Routing Protocols."
All EIGRP implementations use the same core route calculation mechanism: Diffused Update Algorithm (DUAL). Therefore, it is not surprising that the same scalability issues you saw in IP EIGRP also appear in IPX networks built on EIGRP. Unfortunately, due to both protocol limitations and EIGRP implementation, network designers cannot use the same scalability toolkit as in the IP world. The most notable differences are as follows:
IPX did not support route summarization (it's called aggregation in the IPX world) for a long time. The IPX route aggregation was defined in the Netware Link State Protocol (NLSP) specification. IPX EIGRP was designed several years before Novell started to think about scalable internetworks and consequently does not support summary IPX routes.
IPX did not support the default route when IPX EIGRP was designed; the IPX default route was also defined later in the NLSP specification. IPX EIGRP can still carry the IPX default route, because the IPX default route is just a special IPX network number. However, it lacks the flexibility from the IP world.
A few more limitations are a consequence of the IOS implementation of IPX routing. There are no IPX route maps and you can't influence IPX administrative distances.
Apart from all these limitations, it's still possible to build large and scalable IPX networks, as you'll see in the case studies at the end of this chapter. The case studies use the tools briefly described in the remainder of the chapter:
IPX Route Filters
IPX Default Route
Controlling Route Redistribution between IPX Routing Protocols
For historical reasons, IPX route filters have different syntaxes for different routing protocols. To configure IPX route filters for RIP, you use the commands from Table 10-1 in interface configuration mode.
Table 10-1. IPX RIP Route Filter Configuration Commands
|
Task |
Command (in Interface Configuration Mode) |
|---|---|
|
Filter inbound IPX RIP updates on the interface |
ipx input-network-filter <ACL> |
|
Filter outbound IPX RIP updates on the interface. |
ipx output-network-filter <ACL> |
To configure IPX route filters for IPX EIGRP or NLSP, you have to use the commands from Table 10-2 in IPX router configuration mode.
Table 10-2. IPX EIGRP Route Filter Configuration Commands
|
Task |
Command (in IPX Router Configuration Mode) |
|---|---|
|
Filter inbound IPX EIGRP update |
distribute-list <ACL> in |
|
Filter inbound IPX EIGRP updates received over the specified interface |
distribute-list <ACL> in <interface> |
|
Filter outbound IPX EIGRP updates |
distribute-list <ACL> out |
|
Filter outbound IPX EIGRP updates sent over the specified interface |
distribute-list <ACL> out <interface> |
|
Filter IPX routes redistributed into IPX EIGRP from another routing process |
distribute-list <ACL> out <protocol> |
Note
In older versions of IOS, the commands from Table 10-1 were also used to filter IPX EIGRP routing updates. In recent IOS versions, these commands no longer work for IPX EIGRP.
Similar differences in commands exist for SAP filters. Filter the services received through IPX SAP protocol using commands from Table 10-3 in interface configuration mode. Filter the services received through the IPX EIGRP SAP mechanism or NLSP using commands from Table 10-4 in IPX router configuration mode.
Table 10-3. IPX SAP Filter Configuration Commands
|
Task |
Command (in Interface Configuration Mode) |
|---|---|
|
Filter inbound IPX SAP updates received through the interface |
ipx input-sap-filter <ACL> |
|
Filter outbound IPX SAP updates received through the interface |
ipx output-sap-filter <ACL> |
Table 10-4. IPX EIGRP SAP Filter Configuration Commands
|
Task |
Command (in IPX Router Configuration Mode) |
|---|---|
|
Filter all SAP services received through IPX EIGRP |
distribute-sap-list <ACL> in |
|
Filter SAP services received in IPX EIGRP SAP packets inbound over the specified interface |
distribute-sap-list <ACL> in <interface> |
|
Filter services in all outbound IPX EIGRP SAP updates |
distribute-sap-list <ACL> out |
|
Filter services announced in IPX EIGRP SAP packets over the specified interface |
distribute-sap-list <ACL> out <interface> |
|
Filter services announced through IPX EIGRP SAP and learned from another SAP source (for example, IPX SAP or NLSP) |
distribute-sap-list <ACL> out <protocol> |
The IPX default route is defined by Novell to be IPX network FFFFFFFE (or –2 if you prefer signed decimal over unsigned hex). The IPX default route was defined in the NLSP specification when Novell needed a way of integrating NLSP (which supports IPX route summarization) with IPX RIP (which doesn't support summarized routes). Novell designers envisioned the IPX default route to be used in the following scenarios:
The network core (or even most of the IPX routers) runs NLSP and carries all the individual and summarized routes.
The remaining routers run RIP and carry the individual routes (which RIP can transport) plus the default route (to give them full connectivity).
The default route is originated by every NLSP-speaking router into the RIP domain to attract the traffic from RIP-only routers to the nearest NLSP entry point.
Note
It's worth noting that some older IPX implementations do not support the default route and thus cannot work in a network that deploys summarized NLSP routes or the IPX default route.
Generating an IPX default route within a network that runs only IPX EIGRP and RIP is much harder than on a network that runs NLSP. The default route must be generated manually (for example, by using a static route) on the core routers and disseminated by IPX EIGRP and RIP to all the other routers. A sample router configuration of a core router is shown in Example 10-1.
Example 10-1. Example 10-1 Generating IPX Default Route on a Core Router
ipx routing ipx internal-network ACE001 ipx route default ACE001.0000.0000.0002
Note
Combining NLSP and EIGRP on the same router does not insert the default route in EIGRP as it would in RIP. The default route must still be declared manually as a static route.
You can use the default route to significantly reduce the size of IPX RIP updates. The interface configuration command ipx advertise-default-route-only causes only the default route to be advertised in the RIP updates sent over the specified interface, resulting in decreased bandwidth requirement and CPU usage.
IPX route redistribution is simpler, but also less flexible than IP route redistribution. The redistribution is configured using the redistribute command, as in the IP world. The re-distribution between RIP and IPX EIGRP, RIP and NLSP, and static routes and all routing protocols is automatic (although it can be turned off if necessary). All the other redistributions (for example, IPX EIGRP to NLSP) must be configured manually.
You can always filter routes redistributed between IPX routing protocols using the distribute-list out command as documented previously in Table 10-2.
IPX routing supports a notion of administrative distances, although it's slightly different from the IP world:
Static IPX routes always take precedence over routes received through dynamic routing protocols.
Routes received through dynamic routing protocols always take precedence over floating static IPX routes.
If the same route is received through several different routing protocols, the IPX RIP part of the metric is compared, and the NLSP or EIGRP metric is ignored. The route with the lower tick/hop value is better.
When several routes with the same IPX RIP metric are received through different routing protocols, IPX EIGRP routes are preferred over NLSP and IPX RIP routes.
For more information on this case study, please visit http://www.ciscopress.com/eigrp.
GreatCoals mining corporation is a multinational corporation with operations in the United States and several foreign countries and with sales offices throughout the world. Its network grew as the company expanded, but no real network design was ever put in place. It's already introduced some hierarchy in the network, mainly to reduce WAN costs. Typical parts of the current network are schematically represented in Figure 10-1.
Although GreatCoals never did a real network design, it none-the-less followed a set of loose rules:
The core of the network is implemented with a 7576 fully redundant router. All international links and all links toward the regional concentration sites terminate on this router.
Sales offices in countries where GreatCoals has only a sales presence link to the central 7576 with low-speed Frame Relay connections with a typical Committed Information Rate (CIR) being 32 kbps.
Central sites in countries where GreatCoals has mining operations link to the central 7576 with high-speed Frame Relay or ATM connections with a typical CIR being over 1 Mbps. All other sites in the country link to the in-country central site, and the international traffic is concentrated there as well.
Regional concentration sites in the United States serve the same purpose as the foreign in-country central sites. All minor sites in the United States connect to the regional concentration sites.
Major U.S. sites connect directly to the core router with high-speed ATM PVCs.
GreatCoals never had a structured IPX addressing scheme although an IPX numbering plan was used and enforced throughout the company.
Note
You'll probably find that all the older IPX networks don't have structured addressing in place. All these networks and their numbering plans were designed well before Novell ever announced the intention to support route aggregation. Proper addressing structure was therefore never an issue when the IPX addressing plan was designed.
The GreatCoals network uses no scalability tools. Therefore, all the routers carry all the IPX routes of the whole GreatCoals global network. It shouldn't come as a surprise that the company started to experience Stuck-in-Active events when the network grew.
Because IPX EIGRP does not support route aggregation, the only scalability solution that could work in GreatCoals' network is the usage of IPX default routes. This solution was already proven in the IP world (see Chapter 8 for the corresponding IP case study) and network designers decided to mirror the IP solution into the IPX world:
The core router (7576) has a static IPX default route pointing toward the null interface, which effectively instructs the router to drop all traffic for unreachable destinations. This default route is redistributed into EIGRP.
The core router announces only the default route to all the other routers. Route filters are used to implement the necessary filtering mechanism.
All the concentration routers announce only the default route to the remote offices. A floating IPX default route is installed in the concentration routers to guarantee default route presence even if the WAN link to the core router fails.
All routers in the network announce all their routes to their upstream neighbors.
The relevant portions of the core router configuration are shown in Example 10-2. Relevant portions of concentration router configuration are shown in Example 10-3.
Example 10-2. Example 10-2 GreatCoals Network—Core Router Configuration
hostname Core-7576 ! ipx routing ipx internal-network FFFFFF01 ! ipx router eigrp 131 network all distribute-list DefaultOnly out ! ! Default route to null 0 ! ipx route default FFFFFF01.0000.0000.0002 ! ip access-list standard DefaultOnly permit -2
Example 10-3. Example 10-3 GreatCoals Network—Concentration Router Configuration
hostname Houston ! ipx routing ipx internal-network FFFFECA3 ! ipx router eigrp 131 network all redistribute floating-static ! ! distribute-list applies only to FR links toward remote offices ! distribute-list DefaultOnly out Serial 0 ! ! Backup default route in case the core default route is gone ipx route default FFFFECA3.0000.0000.0002 floating-static ! ip access-list standard DefaultOnly permit -2
For more information on this case study, please visit http://www.ciscopress.com/eigrp.
The GreatCoals network still experienced SIA events even after the first phase of network redesign because the low-speed international links were terminated on the core router. Whenever there was a route flap anywhere in the network, the core router became involved in the diffusing computation and queried all the international routers over low-speed Frame Relay links.
The only way to eliminate SIA events on the core router is to remove the low-speed links from the core EIGRP process by running a different routing protocol over these links. This can be done in two ways: These links could use IPX RIP or another IPX EIGRP process. The network designers chose to use IPX RIP over these links because it provides better isolation between remote sales offices. IPX RIP carries only the default route from the core router, resulting in very low bandwidth usage.
The core router configuration implementing reduced IPX EIGRP diameter is shown in Example 10-4.
Example 10-4. Example 10-4 GreatCoals Network—Core Router Configuration with Reduced IPX EIGRP Diameter
hostname Core-7576 ! ipx routing ipx internal-network FFFFFF01 ! ! Advertise only default route over RIP on the low-speed links ! interface serial 0 description Frame Relay links to international sales offices ipx network AA0004 ipx advertise-default-route-only AA0004 ! ipx router eigrp 131 ! ! IPX EIGRP cannot be run on all networks, just on the core links ! network AA0001 network AA0002 network AA0003 distribute-list DefaultOnly out ! ! Default route to null 0 ! ipx route default FFFFFF01.0000.0000.0002 ! ip access-list standard DefaultOnly permit -2
For more information on this case study, please visit http://www.ciscopress.com/eigrp.
The arguments used in the previous case study are valid from the routing protocol perspective. IPX RIP carrying only a default route gives the remote offices more isolation than another IPX EIGRP process. The network designers, however, were too IP oriented and tried to transplant good IP designs into the IPX world. As it turns out, the IPX EIGRP performs more than route dissemination; it also provides very efficient SAP transport mechanism. When IPX EIGRP was replaced with IPX RIP on the low-speed serial links, they instantly became overloaded with periodic SAP traffic. It looked like the network design faced a deadlock due to conflicting constraints:
IPX EIGRP cannot be used over low-speed WAN links because the isolation between the remote sales offices would be lost.
IPX EIGRP has to be used over the same links to reduce SAP bandwidth usage.
Fortunately, the IPX EIGRP implementation allows exactly this design. IPX EIGRP could be used only for SAP transport and not as a routing protocol (see Chapter 3, "IPX EIGRP," for details). In this design, IPX EIGRP is configured on all interfaces, but does not carry any routes over the low-speed international links. The improved configuration of the core router is shown in Example 10-5.
Example 10-5. Example 10-5 GreatCoals Network—Core Router Configuration with IPX EIGRP/IPX RIP Combination on Low-Speed WAN Links
hostname Core-7576 ! ipx routing ipx internal-network FFFFFF01 ! ! Advertise only default route over RIP on the low-speed links ! interface serial 0 description Frame Relay links to international sales offices ipx network AA0004 ipx advertise-default-route-only AA0004 ipx sap-incremental eigrp 131 rsup-only ! ipx router eigrp 131 ! ! IPX EIGRP cannot be run on all networks, just on the core links ! network all distribute-list DefaultOnly out ! ! Default route toward the firewall ipx route default FFFFFF01.0000.0000.0002 ! ip access-list standard DefaultOnly permit -2
IPX EIGRP is subject to the same scalability issues as IP EIGRP due to a common design and algorithm. The breadth of scalability tools is somewhat more limited. IPX EIGRP does not support route aggregation and offers only limited support for default routes.
However, several good generic designs give excellent scalability in large IPX networks:
Use IPX EIGRP only in the core network and IPX RIP to transport the routing information in the access layer. This design has to be combined with default routes and route filters to reduce bandwidth usage on the low-speed access links.
Use default route hierarchy and route filters with IPX EIGRP. This design is slightly less scalable than the previous one due to the larger diffused computation diameter.
Use IPX EIGRP and IPX route filters in networks where the any-to-any connectivity is not required. This design is particularly well suited for networks where the users have to access only the central resources. The design can be further improved if you replace IPX EIGRP with IPX RIP on the network periphery.