Every network designer faces two major design obstacles when designing IP routing in a large network:
Designing a scalable solution tuned to the specifics of the selected routing protocol.
Designing a network that works well over switched WAN networks (X.25, Frame Relay, or ATM).
Switched WAN networks pose additional challenges on top of the usual set of problems found in large-scale network design due to their specific technology. All of these networks present a multi-access subnet to a router but offer no additional features, such as multicasting, usually found on the LAN networks.
The scalability issues of EIGRP were discussed in several chapters in Part II, "Designing Enterprise EIGRP Networks," of this book. Part III, "Running EIGRP over Switched WAN and Dial-Up Networks," focuses on switched WAN issues, starting from generic issues common to all routing protocols in this chapter. EIGRP-specific issues are covered in Chapter 13, "Running EIGRP over WAN Networks," and dial-up related issues in Chapter 14, "EIGRP and Dial-Up Networks."
A case study is presented in the beginning of this chapter to illustrate some of the problems usually found in growing multiprotocol networks built on switched WAN networks. This chapter also discusses several issues specific to switched WAN technologies, from emulated multicasting to special means of resolving Layer 3 to Layer 2 mapping and logical interfaces available over these media types.
For more information on this case study, please visit http://www.ciscopress/com/eigrp.
MetroGas is a large petrochemical conglomerate, covering everything from drilling operations to gas stations throughout the country. The company decided to connect all of its gas stations to the central site through a Frame Relay network with ISDN used as a dial-backup solution. Frame Relay was selected as the main transmission technology for the following reasons:
The overall deployment costs were lower.
The central routers needed only one high-speed port as opposed to a large number of low-speed ports in a leased line implementation.
The Frame Relay service provider performed access concentration. MetroGas would need no concentration routers.
The access speed of the remote gas stations is 64 kbps, and the access speed at the central router is 2 Mbps. Each gas station is connected with the central router with one Permanent Virtual Circuit (PVC) with a Committed Information Rate (CIR) of 16 kbps. The Frame Relay topology of the MetroGas network is displayed in Figure 12-1.
MetroGas's network designers decided to use EIGRP throughout the network to reliably detect Frame Relay outages at the IP layer and to be able to implement load balancing between the Frame Relay PVC and an ISDN dial-up connection. The designers were aware of the scalability issues associated with large-scale EIGRP networks, so they implemented several safeguards, including a hierarchical IP addressing scheme, route filtering, default routes, and so on.
A pilot network linking several gas stations throughout the country with the central site was implemented as the first stage of network deployment. The configuration of access routers (see Example 12-1) and the central router (see Example 12-2) turned out to be extremely straightforward.
Example 12-1. Example 12-1 Access Router Configuration
hostname Access_Wichita ! interface ethernet 0 ip address 10.17.2.1 255.255.255.0 ! interface serial 0 encapsulation frame-relay bandwidth 64 ip address 10.251.17.2 255.255.240.0 ! router eigrp 101 network 10.0.0.0
Example 12-2. Example 12-2 Central Router Configuration
hostname Core_A ! interface FastEthernet 0/0 ip address 10.1.1.1 255.255.255.0 ! interface serial 1/0 encapsulation frame-relay bandwidth 2048 ip address 10.251.16.1 255.255.240.0 ip summary-address eigrp 101 10.0.0.0 255.0.0.0 ! router eigrp 101 network 10.0.0.0 ! ip default-network 10.0.0.0
The pilot was running for a few months and proved easy to install and maintain, so the networking team got the green light to connect the next 200 gas stations. However, as the number of gas stations exceeded a certain limit (it turned out to be somewhere between 35 and 40), they were not able to connect any more stations. EIGRP adjacencies just could not be established. To make matters worse, a new gas station connected to the network might cause a gas station from the pilot network that was running fine for months to become unreachable.
The troubleshooting efforts quickly centered on the Frame Relay network, and the troubleshooting team discovered an interesting phenomenon: Even with no load on the Frame Relay interface, the number of interface output drops were constantly increasing as shown in Example 12-3.
Example 12-3. Example 12-3 show interface Printout on the Central Router
Core_A#show interface serial 1/0
Serial1/0 is up, line protocol is up
Internet address is 10.251.16.1, subnet mask is 255.255.240.0
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 254/255, load 1/255
Encapsulation FRAME-RELAY, loopback not set, keepalive set (10 sec)
LMI enq sent 2, LMI stat recvd 0, LMI upd recvd 0, DTE LMI up
LMI enq recvd 266, LMI stat sent 264, LMI upd sent 0
LMI DLCI 1023 LMI type is CISCO frame relay DTE
Last input 0:00:04, output 0:00:02, output hang never
Last clearing of "show interface" counters 0:10:15
Output queue 0/40, 2468 drops; input queue 0/75, 0 drops
Five minute input rate 375 bits/sec, 2 packets/sec
Five minute output rate 3172 bits/sec, 9 packets/sec
1253 packets input, 55736 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
0 input packets with dribble condition detected
5627 packets output, 264723 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets, 0 restarts
3 carrier transitions
The troubleshooters tried to alleviate the problem by increasing the interface output queue in several ways. They started by increasing the output queue length with the hold-queue out command and then turned on priority queuing and extended the queue lengths with the priority-list queue-limit command. However, every configuration change allowed them to add only a few new neighbors. As soon as more neighbors were added, the symptoms returned.
A call to the Cisco Technical Assistance Center (TAC) proved to be more fruitful. The TAC engineer quickly identified the problem as output queue overload due to a large number of EIGRP neighbors reachable over a single Frame Relay interface. He suggested using the frame-relay broadcast-queue command, and all of the remote locations became reachable in a few seconds—until the MetroGas team added a large number of additional gas stations over the same Frame Relay connection.
The MetroGas engineers faced one of the major obstacles to large-scale Frame Relay deployment: the software emulation of LAN broadcasts over nonbroadcast WAN media done in Cisco IOS (pseudobroadcasting). Multi-access WAN technologies, such as X.25, Frame Relay, ATM, or ISDN, do not support the broadcasting mechanisms usually found in the LAN environment. On the other hand, several different applications, including IP routing protocols, use multicast or broadcast capabilities of the LAN environment to find the peer hosts or routers. For example, EIGRP uses multicast hello packets to find other routers connected to the same subnet. To enable these applications to work unmodified over the multi-access WAN subnets, IOS emulates the multicast capabilities of the LAN environment over a multi-access WAN interface.
Note
A few multi-access WAN networks do support multicasting; for example, some U.S. Frame Relay networks have implemented multicast DLCI capability or private ATM networks that support point-to-multipoint Switched Virtual Circuits (SVC). These implementations have several limitations (for example, you cannot use subinterfaces with multicast DLCI) and are therefore not usable in all environments.
Whenever a multicast packet is routed over a multi-access WAN interface that has no inherent multicasting capability, IOS creates a separate copy of the multicast packet for every neighbor reachable over that interface. Although this is usually the desired behavior, in some situations (for example, on slow-speed X.25 networks) you wouldn't like the multicast packets to be sent to every neighbor. To give the network engineer tighter control over multicast propagation, IOS consults the neighbor maps (see "Layer 2 to Layer 3 Mapping" later in this chapter for more details) when creating multiple copies of the multicast packet. The multicast packet is sent to only those neighbors that have a broadcast option specified in the neighbor map. In environments where the neighbor maps are created dynamically (for example, in most Frame Relay networks), all the dynamic neighbor maps allow the multicast propagation.
All the copies of a single multicast packet are created at one time and sent to the interface output queue in a burst. No shaping or rate limiting is performed on these packets. The results of these traffic bursts are usually output queue overloads, and associated output drops whenever a large number of neighbors are reachable over the same interface.
Note
The output queue overload is never experienced on X.25 interfaces, where each Virtual Circuit (VC) has its own independent output queue. It's also not experienced on dialer interfaces, which are logical interfaces with no associated output queues, and BRI and PRI interfaces where each D channel has its own output queue.
To get rid of the output drops, you can use one of the two possible solutions: Reduce the number of neighbors reachable over the interface (see section "Subinterfaces" later in this chapter for more details) or extend the output queue. You can extend the output queue with various commands depending on the queuing method used on the serial interface as outlined in Table 12-1.
Table 12-1. Extending Interface Output Queue
|
Queuing Method |
Command to Extend the Output Queue |
|---|---|
|
FIFO |
hold-queue <number> out |
|
Priority queuing |
priority-list <list-number> queue-limit <high> <medium> <normal> <low> |
|
Custom queuing |
queue-list <list-number> queue <queue-number> limit <packet-limit> |
|
Weighted fair queuing |
fair-queue <conversation-limit> <dynamic-queues> <reservable-queues> |
The second side effect of emulated multicasting over slower-speed links is a significant amount of jitter introduced by large multicast traffic bursts. To reduce the amount of jitter and solve the output congestion in Frame Relay networks, the frame-relay broadcast-queue command was introduced in IOS 10.3. The command has three parameters for fine-tuning the behavior of emulated broadcasts as detailed in Table 12-2.
Table 12-2. Frame Relay Broadcast-Queue Parameters
|
Parameter |
Meaning |
|---|---|
|
Size |
Number of packets to hold in the broadcast queue. The default is 64 packets. |
|
Byte rate |
Maximum number of bytes to be transmitted per second. The default is 256,000 bytes per second. |
|
Packet rate |
Maximum number of packets to be transmitted per second. The default is 36 packets per second. |
To design the Frame Relay broadcast queue, you should consider the following parameters:
The only multicast packets generated by EIGRP over Frame Relay are the hello packets that are sent every hello-interval seconds and are approximately 40 bytes long unless the Frame Relay network supports Frame Relay level multicasting configured with the frame-relay multicast-dlci command.
The maximum overall byte rate should not exceed one quarter of the local interface speed (or access rate) to prevent local congestion. The per-neighbor byte rate (overall byte rate divided by the number of neighbors) should not exceed one quarter of the slowest remote access rate or one quarter of the smallest CIR to prevent remote congestion.
The number of packets sent per second (packet-rate) should not exceed the output queue size minus some safety margin. A good value in uncongested networks would be three quarters of the output queue.
The overall broadcast queue size must be large enough to prevent multicast packet drops.
With these rules in mind, it's easy to design the broadcast queue for the MetroGas central router that can accommodate 200 neighbors over one Frame Relay interface.
Note
Having 200 neighbors over one Frame Relay interface is not a good design practice. You should limit the number of neighbors off one interface to between 30 and 50. However, in some circumstances, you might be forced to go beyond the usually recommended limit.
The only multicast traffic sent over the Frame Relay interface are EIGRP hello packets, which are sent every five seconds. The overall amount of multicast traffic is 8000 bytes in five seconds or 1600 bytes per second (12,800 bps). The per-neighbor multicast traffic is 40 bytes in five seconds or 64 bps.
The byte-rate of the broadcast queue is limited to 512 kbps (one quarter of 2 Mbps) by the access rate of the central router, and the per-neighbor byte-rate is limited to 4 kbps (one quarter of the 16 kbps CIR). With 200 neighbors, the minimum of the two values is 512 kbps.
Note
You should adjust the parameters of the Frame Relay broadcast queue whenever there is a significant change in the number of neighbors. For example, if you designed the MetroGas broadcast queue for 200 neighbors, but only 50 neighbors were connected in the initial phase, the per-neighbor byte rate would be too high, resulting in Frame Relay PVC overload.
The packet rate of the broadcast queue should be at least 50 packets/second to send 200 packets in less than five seconds. (Otherwise, the hello packets accumulate in the broadcast queue.) The output queue length would therefore have to be extended to approximately 70 packets.
The overall size of the broadcast queue should be around 250 packets. This size easily accommodates the EIGRP hello packets and with some safety margin.
The final configuration of the Frame Relay interface of the MetroGas central router is shown in Example 12-4.
Whenever a Layer 3 device (router or end host) has to send a packet to another Layer 3 device over a multi-access network, it needs to uniquely identify the destination device the packet is sent to on the data link layer. MAC addresses are used on LAN subnets to identify the destination devices, and various forms of virtual channel identifiers are used on switched WAN networks for the same purposes. The identifiers for Permanent Virtual Circuits (PVC) range from the X.25 virtual circuit (VC) number and Frame Relay Data Link Connection Identifier (DLCI) to the Virtual Path/Virtual circuit identifier (VPI/VCI) of ATM. The identifiers for Switched Virtual Circuits (SVC) are the X.121 address for X.25 or Frame Relay, E.164 addresses for Frame Relay and public ATM networks, and NSAP addresses for private ATM networks.
Note
The router uses SVC identifiers to open a virtual circuit to the destination device. The PVC identifier is assigned to the virtual circuit as soon as it is opened. The PVC identifiers are then used to forward the data traffic toward the destination device.
The second prerequisite for successful data traffic propagation over a multi-access subnet is the ability to map logical next-hop addresses (IP addresses, for example) into the physical addresses of the destination devices. Address Resolution Protocol (ARP) is used for dynamic discovery of Layer 3 to Layer 2 mapping in the LAN environment, but ARP cannot be used over multi-access WAN subnets for two reasons:
ARP relies on a broadcast mechanism that is not readily available on WAN interfaces. The emulated broadcast capability provided by IOS doesn't help because it requires the neighbors to be known to operate properly.
LAN environments do not provide on-demand virtual circuits like some WAN environments. Discovering neighbors over on-demand circuits with broadcast mechanisms, such as ARP, is clearly impossible.
Using neighbor maps is the generic mechanism for mapping logical addresses into physical device addresses on all WAN media. The neighbor maps associate logical addresses with Permanent Virtual Circuit (PVC) or Switched Virtual Circuit (SVC) identifiers as outlined in Table 12-3. Only the basic configuration options are shown; detailed descriptions of all configuration options can be found in the IOS documentation.
Table 12-3. IOS Neighbor Map Configuration Commands
|
WAN Media |
IOS Neighbor Map Configuration Command |
|---|---|
|
X.25 PVC |
interface serial 0 x25 pvc <vc > ip <IP-addr> <X.121-addr> [broadcast] |
|
X.25 SVC |
interface serial 0 x25 map ip <IP-addr> <X.121-addr> [broadcast] |
|
Frame Relay PVC |
interface serial 0 frame-relay map ip <IP-addr> <DLCI> [broadcast] |
|
Frame Relay SVC |
map-list <map-name> source-addr E164|X121 <src-addr> dest-addr E164 | X121 <dst-addr>ip <ip-addr> [class <QoS-class>]! interface serial 0 frame-relay svc map-group <map-name> |
|
ATM PVC |
interface atm 0 pvc [<name>] <vpi>/<vci>protocol ip <ip-address> [broadcast] |
|
ATM SVC |
interface atm 0 svc [<name>] <destination-NSAP>protocol ip <ip-address> [broadcast] |
|
ISDN dial-up connection |
interface dialer 0 | bri 0 | serial 0:15 dialer map ip <ip> <E.164> [user <username>][broadcast] |
Note
ATM neighbor configuration has changed in IOS 11.3T and IOS 12.0. For the old command syntax, please refer to the IOS documentation.
Manual configuration of neighbor maps is a tedious process, especially in large-scale environments with a large number of neighbors. Two mechanisms can ease the configuration process: automatic PVC discovery in Frame Relay, and inverse ARP in both Frame Relay and the ATM environment. No such mechanisms exist for X.25 or designs that use switched virtual circuits. In these cases, you must perform all configuration manually.
Frame Relay networks are particularly easy to configure because all the autodiscovery mechanisms are enabled by default. In the ATM world, the inverse ARP mechanism must be configured manually on a per-PVC basis; only the generation of corresponding neighbor maps is automatic.
Neighbor map misconfiguration is a major source of WAN-related problems. The troubleshooting process should proceed along the following lines:
Verify that the neighbor maps are correct by pinging the neighboring routers. If you are able to ping the remote router, both routers have correct entries in their neighbor maps.
Warning
In the case of two parallel links between two routers, the links can be crossed and the ping can still work correctly, but EIGRP doesn't start due to IP subnet mismatch.
Verify that the neighboring routers can exchange hello packets. The neighbor maps must specify broadcast propagation. A missing broadcast option on the neighbor map is usually indicated by the EIGRP neighbor being visible from one end of the WAN link but not from the other. Pinging IP address 224.0.0.10 also generates replies from all EIGRP neighbors.
The easiest way to check the neighbor maps is by using IOS show commands associated with specific WAN technology: show x25 map (see Example 12-5) for X.25 networks, show frame-relay map (see Example 12-6) for Frame Relay networks, and show atm map (see Example 12-7) for ATM networks.
Example 12-5. Example 12-5 show x25 map Output
Router#show x25 map
Serial0: X.121 386611762 <--> ip 172.1.4.2
PERMANENT, BROADCAST, 2 VCS: 64 65*
Example 12-6. Example 12-6 show frame-relay map Output
Router#show frame-relay map
Serial0 (up): ip 172.1.4.2 dlci 101(0x65,0x1850), dynamic,
broadcast,, status defined, active
Serial0.2 (up): point-to-point dlci, dlci 112(0x70,0x1C00), broadcast
status defined, active
Serial0.4 (up): point-to-point dlci, dlci 114(0x72,0x1C20), broadcast
status defined, active
Example 12-7. Example 12-7 show atm map Output
Router#show atm map Map list atm_pri: PERMANENT ip 1.2.3.4 maps to NSAP CD.CDEF.01.234567.890A.BCDE.F012.3456.7890.1234.12, broadcast, aal5mux, multipoint connection up, VC 6 ip 1.2.3.5 maps to NSAP DE.CDEF.01.234567.890A.BCDE.F012.3456.7890.1234.12, broadcast, aal5mux, connection up, VC 15, multipoint connection up, VC 6
A few troubleshooting scenarios are presented in the following paragraphs, together with the corresponding EIGRP debugging outputs. For simplicity reasons, all the scenarios were performed in a small Frame Relay network linking two routers with single PVC, as shown in Figure 12-2. Static Frame Relay maps were used to introduce various configuration errors.
Note
In most designs, dynamic Frame Relay maps should be used on Frame Relay networks to avoid potential configuration problems. Only the networks requiring an increased level of security would use static maps to prevent potential data leakage following a Frame Relay PVC misconfiguration.
In this scenario, one of the routers is missing the broadcast keyword in the neighbor map (see Example 12-8 for router configurations).
Example 12-8. Example 12-8 Scenario 1—Router Configurations
alpha#show running-config
…
interface Serial0
ip address 10.2.7.1 255.255.255.0
no ip directed-broadcast
encapsulation frame-relay
no ip mroute-cache
frame-relay map ip 10.2.7.2 101
…
router eigrp 1
network 10.0.0.0
beta#show running-config
…
interface Serial0
ip address 10.2.7.2 255.255.255.0
no ip directed-broadcast
encapsulation frame-relay
no ip mroute-cache
frame-relay map ip 10.2.7.1 101 broadcast
…
router eigrp 1
network 10.0.0.0
Router Alpha is receiving EIGRP hello packets from router Beta, but is not sending any hello packets back. Router Beta thus cannot detect the presence of router Alpha and rejects all the attempts to initial EIGRP adjacency with router Alpha. The debugging outputs on router Alpha indicate that it tries to establish adjacency with router Beta but eventually drops the adjacency due to excessive retransmissions (see Example 12-9). Router Beta doesn't even try to establish adjacency with router Alpha. Router Alpha is also not seen in the list of EIGRP neighbors on router Beta (see Example 12-10).
Example 12-9. Example 12-9 Scenario 1—Debugging Printouts on Router Alpha
Alpha#show debug
EIGRP:
EIGRP Packets debugging is on
(UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK)
EIGRP Neighbors debugging is on
Alpha#
00:05:03: EIGRP: Received HELLO on Serial0 nbr 10.2.7.2
00:05:03: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0
00:05:03: EIGRP: New peer 10.2.7.2
00:05:03: EIGRP: Enqueueing UPDATE on Serial0 nbr 10.2.7.2 iidbQ un/rely 0/1
00:05:03: EIGRP: Requeued unicast on Serial0
00:05:03: EIGRP: Forcing multicast xmit on Serial0
00:05:03: EIGRP: Sending UPDATE on Serial0 nbr 10.2.7.2
00:05:03: AS 1, Flags 0x1, Seq 2/0 idbQ 0/0 iidbQ un/rely 0/0
00:05:05: EIGRP: Sending UPDATE on Serial0 nbr 10.2.7.2, retry 1, RTO 3000
00:05:05: AS 1, Flags 0x1, Seq 2/0 idbQ 0/0 iidbQ un/rely 0/0
00:05:07: EIGRP: Received HELLO on Serial0 nbr 10.2.7.2
00:05:07: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
00:05:08: EIGRP: Sending UPDATE on Serial0 nbr 10.2.7.2, retry 2, RTO 4500
00:05:08: AS 1, Flags 0x1, Seq 2/0 idbQ 0/0 iidbQ un/rely 0/0
00:05:12: EIGRP: Received HELLO on Serial0 nbr 10.2.7.2
00:05:12: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
00:05:12: EIGRP: Sending UPDATE on Serial0 nbr 10.2.7.2, retry 3, RTO 5000
00:05:12: AS 1, Flags 0x1, Seq 2/0 idbQ 0/0 iidbQ un/rely 0/0
…
00:06:17: EIGRP: Received HELLO on Serial0 nbr 10.2.7.2
00:06:17: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
00:06:17: EIGRP: Sending UPDATE on Serial0 nbr 10.2.7.2, retry 16, RTO 5000
00:06:17: AS 1, Flags 0x1, Seq 2/0 idbQ 0/0 iidbQ un/rely 0/0
00:06:21: EIGRP: Received HELLO on Serial0 nbr 10.2.7.2
00:06:21: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
00:06:22: EIGRP: Retransmission retry limit exceeded
00:06:22: EIGRP: Holdtime expired
00:06:22: EIGRP: Neighbor 10.2.7.2 went down on Serial0
the retry limit has been exceeded, neighbor is declared dead, but it is
immediately "rediscovered" and the whole cycle starts again
00:06:26: EIGRP: Received HELLO on Serial0 nbr 10.2.7.2
00:06:26: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0
00:06:26: EIGRP: New peer 10.2.7.2
00:06:26: EIGRP: Enqueuing UPDATE on Serial0 nbr 10.2.7.2 iidbQ un/rely 0/1
00:06:26: EIGRP: Requeued unicast on Serial0
00:06:26: EIGRP: Forcing multicast xmit on Serial0
00:06:26: EIGRP: Sending UPDATE on Serial0 nbr 10.2.7.2
00:06:26: AS 1, Flags 0x1, Seq 3/0 idbQ 0/0 iidbQ un/rely 0/0
00:06:28: EIGRP: Sending UPDATE on Serial0 nbr 10.2.7.2, retry 1, RTO 3000
00:06:28: AS 1, Flags 0x1, Seq 3/0 idbQ 0/0 iidbQ un/rely 0/0
In the second scenario, both routers have the broadcast option configured in the Frame Relay map, but the remote IP address in the neighbor map is misconfigured on router Alpha (see Example 12-11).
Example 12-11. Example 12-11 Scenario 2—Router Configurations
alpha#show running-config
…
interface Serial0
ip address 10.2.7.1 255.255.255.0
no ip directed-broadcast
encapsulation frame-relay
no ip mroute-cache
frame-relay map ip 10.2.7.3 101 broadcast
…
router eigrp 1
network 10.0.0.0
Both routers can send EIGRP hello packets to the remote router, but the communication cannot proceed beyond the hello packet exchange because the IP packets for router Beta are dropped on router Alpha due to a misconfigured IP address. EIGRP debugging does not indicate the exact source of the problem, but the IP packet debugging clearly shows that the packet is dropped due to an encapsulation failure (see Example 12-12).
Example 12-12. Example 12-12 Scenario 2—Debugging Printouts on Router Alpha
Alpha#show debug EIGRP: EIGRP Packets debugging is on (UPDATE, REQUEST, QUERY, REPLY, IPXSAP, PROBE, ACK) EIGRP Neighbors debugging is on Alpha# 00:11:46: EIGRP: New peer 10.2.7.2 00:11:46: EIGRP: Enqueuing UPDATE on Serial0 nbr 10.2.7.2 iidbQ un/rely 0/1 00:11:46: EIGRP: Requeued unicast on Serial0 00:11:46: EIGRP: Forcing multicast xmit on Serial0 00:11:46: EIGRP: Sending UPDATE on Serial0 nbr 10.2.7.2 00:11:46: AS 1, Flags 0x1, Seq 7/0 idbQ 0/0 iidbQ un/rely 0/0 00:11:47: EIGRP: Received UPDATE on Serial0 nbr 10.2.7.2 00:11:47: AS 1, Flags 0x1, Seq 2/0 idbQ 0/0 iidbQ un/rely 0/0 00:11:48: EIGRP: Sending UPDATE on Serial0 nbr 10.2.7.2, retry 1, RTO 3000 00:11:48: AS 1, Flags 0x1, Seq 7/2 idbQ 0/0 iidbQ un/rely 0/0 00:11:51: EIGRP: Sending UPDATE on Serial0 nbr 10.2.7.2, retry 2, RTO 4500 00:11:51: AS 1, Flags 0x1, Seq 7/2 idbQ 0/0 iidbQ un/rely 0/0 00:11:52: EIGRP: Received UPDATE on Serial0 nbr 10.2.7.2 00:11:52: AS 1, Flags 0x1, Seq 2/0 idbQ 0/0 iidbQ un/rely 0/0 00:11:56: EIGRP: Sending UPDATE on Serial0 nbr 10.2.7.2, retry 3, RTO 5000 00:11:56: AS 1, Flags 0x1, Seq 7/2 idbQ 0/0 iidbQ un/rely 0/0 00:11:57: EIGRP: Received UPDATE on Serial0 nbr 10.2.7.2 00:11:57: AS 1, Flags 0x1, Seq 2/0 idbQ 0/0 iidbQ un/rely 0/0 00:12:01: EIGRP: Sending UPDATE on Serial0 nbr 10.2.7.2, retry 4, RTO 5000 00:12:01: AS 1, Flags 0x1, Seq 7/2 idbQ 0/0 iidbQ un/rely 0/0 00:12:02: EIGRP: Received UPDATE on Serial0 nbr 10.2.7.2 00:12:02: AS 1, Flags 0x1, Seq 2/0 idbQ 0/0 iidbQ un/rely 0/0 initial UPDATE packets are constantly retransmitted, but the EIGRP debugging gives you no clues why that's happening Alpha#undebug all All possible debugging has been turned off Alpha# Alpha#debug ip packet IP packet debugging is on Alpha# 00:12:22: IP: s=10.2.7.2 (Serial0), d=10.2.7.1 (Serial0), len 40, rcvd 3 00:12:23: IP: s=10.2.7.2 (Serial0), d=224.0.0.10, len 60, rcvd 2 00:12:26: IP: s=10.2.7.1 (local), d=10.2.7.2 (Serial0), len 40, sending 00:12:26: IP: s=10.2.7.1 (local), d=10.2.7.2 (Serial0), len 40, encapsulation failed 00:12:27: IP: s=10.2.7.2 (Serial0), d=10.2.7.1 (Serial0), len 40, rcvd 3 00:12:27: IP: s=10.2.7.2 (Serial0), d=224.0.0.10, len 60, rcvd 2 00:12:31: IP: s=10.2.7.1 (local), d=10.2.7.2 (Serial0), len 40, sending 00:12:31: IP: s=10.2.7.1 (local), d=10.2.7.2 (Serial0), len 40, encapsulation failed 00:12:32: IP: s=10.2.7.2 (Serial0), d=10.2.7.1 (Serial0), len 40, rcvd 3 00:12:32: IP: s=10.2.7.2 (Serial0), d=224.0.0.10, len 60, rcvd 2
Contrary to the previous scenario, both routers can see their EIGRP neighbor, but the communication never proceeds beyond the sending of the initial Update packet (see Example 12-13).
Example 12-13. Example 12-13 Scenario 2—EIGRP show Commands on Router Beta
Beta#show ip eigrp neighbors detail
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 10.2.7.1 Se0 124 00:00:55 0 5000 1 0
Last startup serial 2
Version 12.0/1.0, Retrans: 12, Retries: 12, Waiting for Init, Waiting for Init Ack
UPDATE seq 3 ser 2-2 Sent 55292 Init Sequenced
In the third scenario, the IP address in the neighbor map is correct, but the DLCI number is misconfigured, as seen in Example 12-14.
Example 12-14. Example 12-14 Scenario 3—Router Configurations
alpha#show running-config
…
interface Serial0
ip address 10.2.7.1 255.255.255.0
no ip directed-broadcast
encapsulation frame-relay
no ip mroute-cache
frame-relay map ip 10.2.7.2 102 broadcast
…
router eigrp 1
network 10.0.0.0
This scenario is indistinguishable from Scenario 2 both on the EIGRP level—the debugging printouts are identical to those in Example 12-12 and the show command printouts are identical to those in Example 12-13—and on the IP level—IP debugging does not indicate any more than the encapsulation has failed. The only way to diagnose the misconfigured parameter (IP address versus DLCI number) is to use the show frame map (see Example 12-15) and show frame pvc (see Example 12-16) commands. If you misconfigure the IP address, the destination IP address does not appear in the show frame map printout. If you misconfigure the DLCI number, the DLCI displayed in the show frame map printout has PVC status DELETED in the show frame pvc printout.
Example 12-15. Example 12-15 Scenario 3—show frame-relay map Printout
Alpha#show frame-relay map
Serial0 (up): ip 10.2.7.2 dlci 102(0x66,0x1860), static,
broadcast,
CISCO, status deleted
Example 12-16. Example 12-16 Scenario 3—show frame-relay pvc Printout
Alpha#show frame-relay pvc
PVC Statistics for interface Serial0 (Frame Relay DTE)
Active Inactive Deleted Static
Local 0 0 1 0
Switched 0 0 0 0
Unused 1 1 0 0
DLCI = 101, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial0
input pkts 14 output pkts 1 in bytes 862
out bytes 30 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 1 out bcast bytes 30 Num Pkts Switched 0
pvc create time 00:00:59, last time pvc status changed 00:00:59
DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = DELETED, INTERFACE = Serial0
input pkts 0 output pkts 1 in bytes 0
out bytes 64 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 1 out bcast bytes 64
pvc create time 00:01:48, last time pvc status changed 00:01:02
All routers reachable through a single physical interface over a switched WAN network are usually handled in the same manner. For example, all the gas stations connected to the central MetroGas router were handled identically. However, several design scenarios where the routers reachable over a single physical interface have to be handled in entirely different ways do exist. For example, the core and access routers in DUAL-Mart network were in different subnets and running different routing protocols (see "Case Study 1 Solution—Integrating RIP and EIGRP" in Chapter 9, "Integrating EIGRP with Other Enterprise Routing Protocols," for more details).
The designs where you have to handle neighbors reachable over the same physical interface in different ways can be easily implemented using subinterfaces. Subinterfaces are logical interfaces encompassing one (point-to-point subinterfaces) virtual channel or several (multipoint subinterfaces) virtual channels. The subinterface behaves exactly like the physical interfaces from a routing, accounting, and filtering perspective. The subinterfaces differ from the physical interfaces only in the following details:
Subinterfaces don't have their own output queues and interface buffers.
You cannot specify queuing on subinterfaces. You can specify per-DLCI queuing on Frame Relay networks, but the queuing parameters are unique to each DLCI, not to each subinterface.
Some interface SNMP variables are not available for subinterfaces (for example, input and output errors). In older IOS releases, no SNMP counters were available for subinterfaces.
IOS supports two types of subinterfaces: point-to-point subinterfaces that behave exactly like a point-to-point link (PPP or HDLC interface), and multipoint subinterfaces that behave exactly like multi-access WAN interfaces. You can assign only one virtual circuit (PVC or SVC) to a point-to-point subinterface, and you can assign any number of virtual circuits to a multipoint subinterface. (The limits are the same as the interface limits imposed by IOS.)
Use point-to-point subinterfaces in situations where the connection to each neighbor requires a unique set of parameters or where the split-horizon rules of the routing protocol require them. (See Chapter 13 for more details on split horizon and EIGRP.) Some protocols and technologies (for example, IPXWAN) only run over point-to-point links. Deploying these protocols over switched WAN networks, such as Frame Relay, requires point-to-point subinterface definition for every remote router reachable over the WAN network.
In most other cases, you should use multipoint subinterfaces because they give you better scalability:
You don't need to define a new interface for each new neighbor.
Several neighbors can share common configuration parameters, such as routing protocol parameters, packet filters, or accounting options.
Overall router configuration is smaller and easier to manage.
Note
Using point-to-point subinterfaces in networks where the core router has several neighbors can also lead to Interface Descriptor Block (IDB) limit problems; most routers can support only up to 300 physical and logical interfaces when running Cisco IOS prior to version 12.0. The IDB limit is platform-dependent in IOS 11.1CA and IOS 12.0 and has been raised for the high-end routers like 7x00 series routers or AS5800 access servers.
Subinterfaces are created dynamically as soon as you enter the interface command specifying a new subinterface. The subinterface type has to be entered when the subinterface is first referenced; it can be omitted afterwards, but cannot be changed. Individual PVCs or SVCs have to be assigned to subinterfaces using the commands listed in Table 12-4. The table also contains the commands used to create a new subinterface or remove an existing subinterface
Note
The entire subinterface configuration is lost when you remove a subinterface, and it cannot be recovered. The subinterface is never completely removed prior to router reload; it is only marked as deleted and does not appear in the router configuration anymore. You cannot redefine the subinterface type by removing the subinterface and re-creating the same subinterface with a different type: The router refuses your attempt to re-create a subinterface in deleted state.
Table 12-4. Subinterface-Related IOS Configuration Commands
|
Task |
IOS Configuration Commands |
|---|---|
|
Create a new subinterface |
interface serial <x>.<subint> point-to-point | multipoint |
|
Assign an X.25 PVC or SVC to a subinterface |
Enter the x25 map or x25 pvc statement in the subinterface configuration mode |
|
Assign a Frame Relay PVC to a subinterface |
Specify the PVC in the subinterface configuration mode using frame-relay map command (for static Frame Relay maps) or frame-relay interface-dlci command (for dynamic Frame Relay maps) |
|
Assign a Frame Relay SVC to a subinterface |
Assign the Frame Relay map-list describing the SVC to the subinterface using map-group command in subinterface configuration mode |
|
Assign an ATM SVC or PVC to a subinterface |
Use the pvc or svc command in subinterface configuration mode |
|
Remove a subinterface |
no interface serial <x>.<subint> |
You should use subinterfaces in your network design for several reasons, ranging from the need to treat different neighbors in different ways to the cases where the neighbors have to be assigned to different subnets to maintain the uniform subnet mask across the network. Anyway, very few network designs use subinterfaces to reduce the multicast bursts associated with EIGRP hello packets.
Each subinterface behaves exactly like a regular physical interface from the routing perspective and can have its own EIGRP parameters, such as hello-interval and hold-time. Assigning different hello intervals (and associated hold timers) to groups of neighbors can spread the multicast bursts significantly, more so if the hello intervals are relatively prime to each other.
Consider, for example, a core router with 50 neighbors reachable over a 256 kbps X.25 connection. The default hello interval for lower-speed multi-access networks is 60 seconds, which is usually too long, so the network designer has reduced the hello interval to 15 seconds. The broadcast queue cannot be used over X.25 interfaces, so a burst of 50 packets is generated every 15 seconds.
In an alternative design, the 50 neighbors are divided over five subinterfaces with hello intervals of 13,14,15,17, and 19 seconds. The hello intervals were chosen to be prime to each other. (The only common divisor they have is one.) Therefore, a burst of 50 packets is generated only once in 881790 seconds. Smaller bursts are generated more often, as illustrated in Table 12-5. The results in the table were generated using combinatorial theory, which is beyond the scope of this book.
Switched WAN networks present you with several challenges—from output queue overloads caused by emulated multicasts to intricate problems caused by misconfigured neighbor maps. All of these challenges can be overcome or avoided using several tools available in the Cisco IOS, as summarized in Table 12-6.
Table 12-6. Useful Switched WAN-Specific IOS Tools
|
Challenge |
Solution |
Applicable WAN Technology |
|---|---|---|
|
Output drops due to emulated multicasts |
Extend the output queue length |
All |
|
Divide the neighbors across several subinterfaces |
All | |
|
Configure broadcast queue |
Frame Relay | |
|
Neighbor maps are hard to maintain |
Use automatic PVC discovery |
Frame Relay |
|
Build dynamic maps using inverse ARP |
Frame Relay and ATM | |
|
Neighbors reachable over one interface have to handled in different ways |
Use subinterfaces |
All |