Enhanced Interior Gateway Routing Protocol (EIGRP) supports three protocol families: IP, IPX, and AppleTalk. You saw all the details of IP EIGRP in Chapter 1, "EIGRP Concepts and Technology," and Chapter 2, "Advanced EIGRP Concepts, Data Structures, and Protocols," and you will get the same level of details on IPX EIGRP implementation in this chapter. All three EIGRP implementations share common algorithms, protocols, and packet formats. They also share a user interface (IOS show commands) and configuration commands as far as possible, making it easy for any network engineer familiar with one protocol family (for example, TCP/IP) to design and implement EIGRP networks for other protocol families (for example, IPX).
Because there are significant differences between various protocol families, for example, in layer-3 addressing, naming, and directory services supported by the protocol family, and so on, it's not surprising that EIGRP implementations differ slightly between various protocol families. This chapter focuses mainly on differences between the IP and IPX implementation of EIGRP, which are as follows:
Automatic route redistribution between various IPX routing protocols—. IP redistribution must always be configured manually. The only exception is the redistribution between IGRP and EIGRP with the same Autonomous System number.
Metric integration of various IPX routing protocols—. IP routing protocols usually have completely inconsistent and incomparable metrics. The exception is redistribution between (E)IGRP processes.
Naming and directory services—. These services are implemented by Service Advertisement Protocol (SAP) in the IPX world and have to be tightly integrated with IPX EIGRP. No similar integration of naming/directory services and routing protocols exists in the IP protocol suite.
All the other features of IP EIGRP are retained in the IPX implementation. The most notable features are as follows:
The vector and composite metrics and route selection rules.
The DUAL algorithm is exactly the same.
The hello and transport protocols are the same.
Topology database contents and associated show commands are basically the same. The only difference is the external metric part of an external EIGRP route.
Due to protocol differences between IP and IPX as well as differing customer requirements, slight adaptations of IP EIGRP mechanisms appear in the IPX implementation:
You cannot specify the K-values in the IPX implementation. K-values are fixed in IPX EIGRP, leading to the formula for vector-to-composite metric conversion shown in Equation 3-1.
IPX EIGRP information is exchanged in IPX packets on IPX socket 85BE. The internal packet format is the same as for IP EIGRP.
IPX EIGRP cannot use multicast addresses because IPX does not support multicasting (or at least didn't support it when IPX EIGRP was designed). All the multicast routing information exchange is performed using the IPX broadcast address.
The last introductory remark to be made about IPX EIGRP concerns its position in the evolution of IPX protocol suite and associated routing protocols. When the IP EIGRP was designed, IP classless routing was a well-established concept, and alternate routing protocols such as OSPF and IS-IS were already in existence. It's not surprising that the IP EIGRP implementation contains all the modern concepts like classless prefixes, route aggregation, complex route redistribution, and so on.
At the same time, the IPX protocol suite didn't even support the default routes, let alone route aggregation, or longest prefix-based routing. It didn't make sense to include these features into the new routing protocol because Novell didn't even consider them at that time. The IPX implementation of EIGRP is consequently quite rudimentary when compared with the IP implementation; it was meant only as a bandwidth-efficient and scalable replacement for IPX's Routing Information Protocol (RIP). Modern routing concepts, such as route aggregation and default routes, were introduced into IPX protocol at a much later time with the introduction of Novell Link State Protocol (NLSP), and IPX EIGRP was never adapted to support them.
IPX EIGRP is configured in approximately the same way as IP EIGRP; a router process is started with a unique Autonomous System number, and the networks over which the IPX EIGRP run are specified. Even the command syntax is almost the same as for IP EIGRP, as specified in Table 3-1.
Table 3-1. Basic IPX EIGRP Configuration Commands
|
Task |
Command |
|---|---|
|
Start IPX EIGRP routing process |
ipx router eigrp <as-number> |
|
Start running IPX EIGRP over an interface |
network <ipx-network-number> |
|
Start running IPX EIGRP on all numbered IPX interfaces |
network all |
IPX EIGRP runs only on the interfaces that you specified with the network statements. Moreover, the IPX network number that you specify in the IPX EIGRP router definition must be specified on the interface itself with the ipx network command or it won't appear in the router configuration. This limitation precludes IPX EIGRP usage on IPXWAN links.
Note
IPXWAN is a more modern IPX encapsulation method used on point-to-point WAN links. It enables IPX routers to dynamically negotiate the IPX network number or use unnumbered IPX links. IPXWAN also measures round-trip delays when the WAN link is initialized.
You cannot run IPX EIGRP over unnumbered IPXWAN links because you cannot specify IPX network number 0 in the network statement. On the other hand, IPX EIGRP seems to work on the numbered IPXWAN links, but only until the router reloads.
Consider, for example, the following scenario: You've configured IPX EIGRP on a numbered IPXWAN link with the configuration commands in Example 3-1.
Example 3-1. Example 3-1 IPX EIGRP Configuration over IPXWAN Interface
ipx internal-network ABCD ! interface serial 0 encapsulation ppp ipx ipxwan 0 1234 ! ipx router eigrp network 1234
IPX EIGRP runs correctly over the IPXWAN link. It locates the neighboring router and exchanges the routing information. However, the network 1234 statement does not appear in the configuration because the IPX network specified in the IPX EIGRP process is not specified with the ipx network statement on the interface. The fact that the IPX EIGRP ran over network 1234 is lost after the router reloads.
IPX RIP runs by default on any interface with an IPX network number defined, even though this often results in RIP running in parallel with IPX EIGRP. Because every NetWare file server also acts as an IPX router and normally uses IPX RIP to build its routing table, you cannot remove IPX RIP from the LAN networks or you risk losing IPX connectivity with your file servers. However, concurrent operation of IPX RIP and EIGRP on the WAN interfaces definitely doesn't make sense. It's therefore recommended that you turn off IPX RIP on all WAN links as soon as you configure IPX EIGRP. To do that, you have to use the command sequence specified in Example 3-2.
Example 3-2. Example 3-2 Command Sequence Used to Turn Off IPX RIP on WAN Interfaces
ipx router rip no network <WAN-ipx-network-number>
Route redistribution between IPX EIGRP and IPX RIP is automatic. Under most circumstances, there is no need to turn the redistribution off or to fine-tune it because the tight integration of IPX RIP metrics into IPX EIGRP assures optimum route selection. If you encounter a scenario where the automatic redistribution proves harmful, you can use the commands in Table 3-2 to turn it off or to filter the routes being redistributed between the two routing protocols.
Table 3-2. Configuration Commands to Control IPX Route Redistribution
|
Task |
Command |
|---|---|
|
Stop IPX RIP routes from being redistributed into IPX EIGRP |
ipx router eigrp <as-number> no redistribute rip |
|
Stop IPX EIGRP routes from being redistributed into IPX RIP |
ipx router rip no redistribute eigrp <as-number> |
|
Filter routes being redistributed from IPX RIP into IPX EIGRP |
ipx router eigrp <as-number> distribute-list out <ACL> rip |
|
Filter routes being redistributed from IPX EIGRP into IPX RIP |
ipx router rip distribute-list out <ACL> eigrp <as> |
Note
The IOS implementation of the IPX routing protocols lacks most of the advanced features found in the IP routing protocol implementations; it has no route maps, administrative distances, or default metrics.
Using several concurrent routing protocols with incompatible metrics and automatic redistribution between them is usually a direct path to disaster due to the complexity and unexpected side effects of such a design. The designers of IPX EIGRP thus had to take every possible precaution to avoid all the side effects of running IPX RIP and IPX EIGRP concurrently in an IPX network. They deployed several techniques that deviate slightly from what you'd expect to see in an IP environment, but the end result is a stable implementation that enables you to deploy IPX RIP and IPX EIGRP in any combination without worrying about the complexity of the design. To understand these techniques and their results, you have to understand the details of IPX RIP routing.
IPX RIP is a traditional distance-vector protocol modeled after IP RIP. All the routes known to a router are advertised to all its neighbors every 60 seconds and the best routes received are stored in the local routing table. IPX RIP deviates from IP RIP in its route selection rules; the hop count used in IP RIP has been augmented by delays (also called ticks), which take precedence over the hop count. Routes with lower cumulative delays are considered better, and the hop count is used only as a tiebreaker when the delay of two routes is the same.
The default value of the IPX delay is computed from the value specified in the interface delay configuration command (the same value is also used by EIGRP), using the formula in Equation 3-2.
If you don't specify the interface delay using the delay command, the IPX delay takes a default value as outlined in Table 3-3.
Table 3-3. Default Values of an IPX Delay
Interface Type | Default Value of IPX Delay |
|---|---|
LAN interface | 1 |
WAN interface (regardless of interface type and speed) | 6 |
You can also specify the IPX delay manually by using the ipx delay interface configuration command or you can use the IPXWAN protocol to measure the delay dynamically before the link is put into operation.
Whenever an IPX router receives an IPX RIP update through one of its interfaces, it adjusts the metrics in the incoming update with the interface values following the formulas in Equation 3-3.
Any Cisco router running both IPX RIP and IPX EIGRP performs automatic redistribution between these two protocols unless you disable the redistribution with one of the commands from Table 3-2. IPX RIP routes are redistributed into IPX EIGRP as external EIGRP routes, and the IPX RIP metric is copied into the external data portion of the EIGRP route. The detailed IPX EIGRP and IPX RIP metrics of a route can be displayed with the show ipx eigrp topology <network> command, as shown in Example 3-3.
Example 3-3. Example 3-3 Detailed Display of an External IPX EIGRP Route
Router>show ipx eigrp topology 12345
IPX-EIGRP topology entry for 12345
State is Passive, Query origin flag is 1, 1 Successor(s)
Routing Descriptor Blocks:
Next hop is
FFF40001.0000.0003.0000 (Serial1), from FF40001.0000.0003.0000
Composite metric is (291456000/290944000), Send flag is 0×0,
Route is External
Vector metric:
Minimum bandwidth is 9 Kbit
Total delay is 975000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2
External data:
Originating router is 0060.7015.5daa
External protocol is RIP, metric is 2, delay 49
Administrator tag is 0 (0×00000000)
Flag is 0×00000000
As you can see from Example 3-3, an IPX EIGRP route contains almost exactly the same parameters as an IP EIGRP route; the only difference is in the External data portion. The external data parameters have the meanings explained in Table 3-4.
Table 3-4. External Data Parameters of an IPX EIGRP Route
|
Parameter |
Meaning |
|---|---|
|
Originating router |
MAC address of the router that redistributed external route into EIGRP. This address can also be set with the ipx routing command. |
|
External protocol |
External route type—RIP, EIGRP, static, or NLSP. |
|
External protocol metric |
RIP hop count and delay of the redistributed route |
|
Administrator tag |
The field cannot be set or used. |
|
Flag |
The field cannot be set or used. |
When an external IPX EIGRP route derived from IPX RIP is propagated through the IPX EIGRP network, its vector metric is adjusted according to EIGRP vector metric adjustment rules and the delay part of the External protocol metric is adjusted as well, as shown in Equation 3-4.
The net result of the rules in Equation 3-4 is that an IPX EIGRP route always contains the same IPX delay as an IPX RIP route propagated along the same path would have. This property is extremely important because the IPX delay is used within IPX hosts (file servers and workstations) to calculate transport layer timeouts.
Finally, as the IPX EIGRP route is redistributed back into IPX RIP, the IPX delay field of the RIP route is set to the IPX delay value in the External protocol metric field, and the RIP hop count is set to the RIP hop count in the original redistribution point incremented by one. These transformations are summarized in Equation 3-5.
To ensure optimum routing and prevent routing loops in the mixed IPX EIGRP/IPX RIP network, two additional rules are enforced:
In this section, you learn how the rules from the previous two sections ensure that all the routers in a mixed IPX RIP/IPX EIGRP network always select the optimum routes. The following scenarios are evaluated:
IPX RIP and IPX EIGRP running concurrently over all links
IPX RIP running only on the LAN interfaces and IPX EIGRP on all links
A misconfigured network where the IPX EIGRP is running on high-speed WAN interfaces and IPX RIP is running on a backdoor, low-speed WAN link
A misconfigured network where the IPX EIGRP domain is discontinuous
Each scenario is evaluated in a network that hasn't been tuned for optimal IPX operation; the IPX interface delay is the default (1 for LAN interfaces, 6 for WAN interfaces), and only the bandwidths on the WAN links have been set.
Scenario 1—Concurrent IPX RIP and IPX EIGRP Operation
All routers in the network run IPX RIP and IPX EIGRP on all interfaces as displayed in Figure 3-1.
The internal network of file server Fred is propagated to file server Barney and the remote PC in several steps:
Fred announces network ACE01 to Alpha via IPX RIP broadcast; RIP hop count = 1.
Alpha propagates information about network ACE01 via IPX RIP to Bravo and Delta; RIP hop count = 2.
Alpha redistributes the received RIP information into EIGRP and propagates network ACE01 to Bravo and Delta via EIGRP.
Bravo receives the RIP and EIGRP routes for network ACE01. The hop count in the RIP route is 2, whereas the hop count in the EIGRP route is 1, so it uses the EIGRP route. Similar processing happens on Charlie.
Delta receives RIP routes from Alpha (with hop count of 2) and Charlie (with hop count of 4). EIGRP routes are also received from Alpha and Charlie, and the route through Charlie has better composite metric. Charlie becomes the IPX EIGRP successor. The IPX hop count in the EIGRP route through Charlie is 1 and the IPX hop count of the best IPX RIP route is 2. Delta therefore selects the EIGRP route through Charlie as the best route, leading to optimum IPX routing.
Delta redistributes the IPX EIGRP route received through Charlie to IPX RIP. The delay of the IPX RIP route is the cumulative IPX delay of the path Delta—Charlie—Bravo—Alpha—Fred (leading to proper IPX retransmission timeout), and the IPX hop count of the route is 2. (The original IPX hop count in the redistribution point Alpha was 1, and it always increases by one when the redistribution into IPX RIP is performed.)
Scenario 2—IPX RIP Running on LAN Interfaces Only
In the second scenario, where IPX RIP is running only on LAN interfaces (see Figure 3-2), the route selection process is even simpler because no IPX RIP and IPX EIGRP routes are competing. Alpha redistributes the IPX RIP routes received from Fred into IPX EIGRP, and Delta selects the best IPX EIGRP route going through Charlie and Bravo. Delta then redistributes that route back into IPX RIP. The IPX delay and IPX hop count are the same as in the previous scenario.
Scenario 3—Running IPX RIP on Some WAN Links
The third scenario represents a misconfigured network that still selects the optimum route. The IPX EIGRP domain is contiguous, but only IPX RIP runs over slow-speed link between Alpha and Delta (see Figure 3-3).
In this scenario, the propagation of network ACE01 from Fred to Barney is performed in the following steps:
Alpha receives the IPX RIP update from Fred (IPX hop count = 1). Alpha redistributes it into IPX EIGRP and forwards it to Delta (IPX hop count = 2).
Delta receives the IPX EIGRP route through Bravo and Charlie (IPX hop count = 1) and directs the RIP route from Alpha (IPX hop count = 2). The EIGRP route is preferred because it has a lower IPX hop count.
Delta redistributes the IPX EIGRP route into IPX RIP. Barney receives the IPX RIP route with an IPX hop count of 2 and an IPX delay of 19 (cumulative delay of LAN interface between Fred and Alpha and three IPX EIGRP WAN links).
Scenario 4—Discontinuous IPX EIGRP Domains
In the last scenario, IPX EIGRP runs only between Alpha and Bravo, and another IPX EIGRP process runs between Charlie and Delta (see Figure 3-4).
The propagation of network ACE01 advertised by Fred between Alpha and Delta is more complex:
Alpha receives the IPX RIP update from Fred (IPX hop count = 1).
Alpha redistributes the IPX RIP information into IPX EIGRP and also propagates the IPX RIP information to Delta (hop count = 2).
Alpha sends the IPX EIGRP information to Bravo (IPX hop count = 1).
Bravo redistributes the IPX EIGRP information received from Alpha into IPX RIP and increases the IPX hop count. The IPX RIP information is sent to Charlie (IPX hop count = 2).
Charlie redistributes the received IPX RIP information into IPX EIGRP and propagates the IPX EIGRP information to Delta.
Delta received the IPX RIP update with an IPX hop count = 2 and the IPX EIGRP update with the same hop count. The IPX RIP information is considered better, and the IPX EIGRP information is discarded. The IPX RIP information received from Alpha is propagated to Barney.
The IPX data flow between PC and Fred goes over the low-speed 64 kbps link.
To ensure optimum IPX routing, the IPX EIGRP processes should always be contiguous. Multiple, sequential redistribution between IPX EIGRP and IPX RIP never leads to routing loops, but it can lead to suboptimal IPX routing.
Service Advertisement Protocol (SAP) is an integral and important part of the IPX protocol stack. It enables the end-hosts to locate the services and servers they need to access. The protocol itself was designed for small networks with a small number of services and was never meant to scale to large networks.
The SAP protocol is similar to IPX RIP in its design and uses a distance-vector approach to service information dissemination:
Every server announces its services using periodic SAP updates every 60 seconds. If a service is not announced for a prolonged period of time (by default, 180 seconds), it's considered unreachable.
Every router announces all services known to it using periodic SAP updates sent every 60 seconds.
All the changes in the network—the appearance of new services or disappearance of existing services—are announced immediately using flash updates.
Other messages in the SAP protocol are used to exchange information between workstations and routers or servers, but these are exchanged only on the LAN media and are thus irrelevant to IPX SAP integration into IPX EIGRP.
Note
IPX SAP contains no loop prevention mechanism by itself; it doesn't even perform split-horizon checks. All loop prevention is based on IPX routing tables using several sanity checks:
The periodic SAP updates place a large burden on WAN links in any IPX network. By default, every SAP packet, which is 480 bytes long, can carry up to seven service advertisements. Considering that every Novell file server advertises 3 to 5 services and that every printer and fax server on a LAN also advertises at least one service, the number of services advertised by remote office in a network can approach 10 services per remote LAN. In a network with 200 remote offices, the total number of services that have to be advertised is above 2000. The bandwidth used by periodic SAP packets on every link in a network of that size is calculated in Equation 3-6 and represents nearly 30 percent of the bandwidth of a 64 kbps link. It's evident that a better mechanism for transporting service information is needed in large IPX networks.
The need for periodic SAP packets arises only from the inherent unreliability of the SAP protocol. If the SAP information exchange were reliable, there would be no need for periodic IPX SAP packets, and the SAP protocol would consume significantly less bandwidth on the WAN links. IPX EIGRP guarantees IPX SAP packet delivery; the IPX SAP protocol itself remains unmodified, but the periodic SAP messages can be suppressed due to the reliability of the underlying transport protocol. The interaction of IPX SAP and IPX EIGRP is best illustrated with the debugging outputs, as demonstrated in Example 3-4.
Example 3-4. Example 3-4 Sample IPX SAP Transaction Using IPX EIGRP as the Transport Protocol
router#debug eigrp packet ipxsap ack router#debug ipx sap activity … IPX SAP packet received over Serial 1 announcing that service FileServer became unreachable … EIGRP: Received IPXSAP on Serial1 nbr FFF40001.0000.0003.0000 AS 11, Flags 0x0, Seq 408/478 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0 EIGRP: Enqueuing ACK on Serial1 nbr FFF40001.0000.0003.0000 Ack seq 408 iidbQ un/rely 0/0 peerQ un/rely 1/0 IPXEIGRP: Received EIGRP SAP from FFF40001.0000.0003.0000 IPXSAP: Response (in) type 0x2 len 96 src:FFF40001.0000.0003.0000 dest:FFF40001.0000.0000.0004(85BE) type 0x4, "FileServer", 22.0000.0000.0002(437), 16 hops IPXSAP: type 4 server "FileServer" poison received from FFF40001.0000.0003.0000 EIGRP: Sending ACK on Serial1 nbr FFF40001.0000.0003.0000 AS 11, Flags 0x0, Seq 0/408 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 1/0 … Alternate path was found, new information sent over all interfaces in a flash update. IPX EIGRP runs only over Serial 1, Serial 0 uses IPX SAP protocol … IPXSAP: positing update to FFF40000.ffff.ffff.ffff via Serial0 (flash) IPXSAP: positing update to FFF40001.ffff.ffff.ffff via Serial1 (flash) IPXSAP: Update type 0x2 len 96 src:ABCD.0000.0c46.d9ec dest:ABCD.ffff.ffff.ffff(452) type 0x4, "FileServer", 22.0000.0000.0002(437), 16 hops EIGRP: Enqueuing IPXSAP on Serial1 AS 0, Flags 0x0, Seq 479/0 idbQ 0/0 iidbQ un/rely 0/1 serno 98-98 EIGRP: Enqueuing IPXSAP on Serial1 nbr FFF40001.0000.0003.0000 AS 0, Flags 0x0, Seq 479/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0 serno 98-98 EIGRP: Sending IPXSAP on Serial1 nbr FFF40001.0000.0003.0000 AS 11, Flags 0x0, Seq 479/408 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 98-98 EIGRP: Received ACK on Serial1 nbr FFF40001.0000.0003.0000 AS 11, Flags 0x0, Seq 0/479 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
The periodic SAP messages were primarily designed to overcome the unreliable transport mechanism, but they also serve two additional purposes:
They initially populate the SAP tables of newly started routers.
Under some conditions, they enable the discovery of alternate paths toward services that became inaccessible.
IPX EIGRP has a special table, called the backup SAP table, to emulate the behavior of the periodic SAP protocol. Whenever an incoming SAP update is received, the information in the update is always stored in the backup SAP table. Sanity checks are performed on the received information; the network specified in the SAP advertisement has to be reachable through the neighbor that sent the SAP update. Only the information that passes the sanity checks is considered for import into the main SAP table. The main SAP table contains only the best service advertisements that have passed the sanity checks. The whole process is illustrated in Figure 3-5.
You can display the per-neighbor backup SAP table with the show ipx eigrp neighbor server command as illustrated in Example 3-5.
Example 3-5. Example 3-5 SAP Backup Table Display
Router>show ipx eigrp neighbor server
IPX EIGRP Neighbors for process 11
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
1 FFF40000.0000.0000.0002 Se0 11 00:01:22 879 5000 0 219
Server table for this peer:
Type Name Address Port Hops
4 FileServer 22.0000.0000.0002:0437 4
4 Top2600 1.0000.0000.0001:0837 3
0 FFF40001.0000.0003.0000 Se1 13 00:52:52 31 200 0 423
Server table for this peer:
Type Name Address Port Hops
4 FileServer 22.0000.0000.0002:0437 2
4 Top2600 1.0000.0000.0001:0837 2
Whenever the primary path to a service in the main SAP table is lost, the EIGRP neighbor is lost due to topology changes, and so on, and the backup table is scanned to find alternate information about the lost services. This process is illustrated in Figure 3-6.
The IPX SAP protocol distributes service reachability information between the servers and the routers, but it's also used by the workstations to find the desired services. Novell dedicated several special IPX SAP packet types to service information search purposes; however, several custom applications do not use these packets but rely on listening to IPX SAP updates to find the services they need. These applications rely on IPX SAP protocol being present on the LAN where the workstations are to find the servers they need.
It's therefore necessary to retain the original IPX SAP protocol on the LAN networks, and it's also desirable to avoid periodic IPX SAP messages on the WAN networks to minimize bandwidth usage. IPX EIGRP defaults were thus chosen as follows:
Periodic IPX SAP messages are always sent over LAN media regardless of whether EIGRP neighbors are reachable over the LAN.
Periodic IPX SAP messages are suppressed on the WAN links as soon as an EIGRP neighbor is discovered over that WAN interface.
Although these defaults satisfy most design scenarios, you might find a few exceptions where you want to disable periodic SAP messages on LAN media or enable periodic SAP messages on WAN media. The commands you use to fine-tune the protocols used to deliver SAP information are specified in Table 3-5.
Table 3-5. Commands to Fine-Tune SAP Information Delivery
|
Command |
Purpose |
|---|---|
|
interface ethernet 0 ipx sap-incremental eigrp <as> |
Stop periodic IPX SAP messages on LAN media as soon as an EIGRP neighbor in EIGRP process <as> is discovered |
|
interface serial 0 no ipx sap-incremental eigrp <as> |
Send periodic IPX SAP messages on WAN media even though there are EIGRP neighbors in EIGRP process <as> reachable over the specified WAN interface |
|
interface serial 0 ipx sap-incremental eigrp <as> rsup-only |
Use EIGRP only for incremental SAP transport. Suppress periodic SAP messages as soon as there is an EIGRP neighbor in EIGRP process <as> reachable through a specified interface, but do not accept any EIGRP routing updates through the specified interface |
In several scenarios, the IPX EIGRP SAP processing needs fine-tuning.
Scenario 1—Transit-Only IPX LAN
In a network where several routers are connected to a common transit-only LAN (a LAN segment which has no servers or hosts connected to it), suppression of periodic IPX SAP updates on the transit LAN might reduce the CPU load on the routers connected to that LAN. All the routers connected to the transit LAN should run EIGRP. You should configure periodic IPX SAP suppression on all routers with the ipx sap-incremental eigrp configuration command.
Scenario 2—Mixed WAN Environment
When you run IPX over a multipoint Frame-Relay connection, and some of the remote routers do not support IPX EIGRP, you have to enable periodic IPX SAP propagation manually using the no ipx sap-incremental eigrp command. Typically such situations include Frame Relay networks where the remote routers do not support IPX EIGRP (for example, very old Cisco IOS releases or third-party routers) or do not have IPX EIGRP configured.
Scenario 3—Using IPX EIGRP only to Suppress Periodic IPX SAP Update
In very rare scenarios, you might want to use IPX EIGRP to suppress periodic IPX SAP updates, but you want to retain the IPX routing structure as computed by IPX RIP. In these cases, IPX EIGRP should not be used for route selection because it might select different paths than IPX RIP, but only for IPX SAP transport. The command to use on the WAN interfaces is ipx sap-incremental eigrp rsup-only.
IPX EIGRP's implementation is very similar to IP EIGRP; the user interface, core algorithms, and protocols are the same, giving you a consistent configuration and management interface. However, several differences related to IPX-specific details do exist:
Redistribution between IPX EIGRP and IPX RIP is automatic.
External protocol metric in IPX EIGRP route is adjusted when the route is propagated between IPX EIGRP neighbors.
IPX routes received from various IPX routing protocols are compared based on their IPX hop count, not on the administrative distance as in IP.
IPX SAP is tightly integrated into IPX EIGRP to suppress periodic IPX SAP updates and reduce WAN bandwidth utilization.
The IOS implementation of IPX routing protocols is also less flexible than the IP routing implementation. It has no route maps, administrative distances, or routing protocol tags that you can use to control redistribution. Anyhow, the tools available in the IPX world are flexible enough to provide you with a comprehensive toolbox for scalable internetwork design, as you will see in the following chapters.