Deploying EIGRP on a Large-Scale Three-Layer Hierarchical Network

Many networks have been built around the core, distribution, and access layer model, because it provides a well-defined separation of functions into the various portions of the network. It also provides an excellent topology to apply scalability improvement techniques such as summarization.

Using the network described in Figure 3-1, this section describes how you can implement the information hiding technique of summarization at each of the three layers: core, distribution, and access.

Analyzing the Network Core for Summarization

The network core in EIGRP has the same requirements as those presented in Chapter 2, "Applying the Fundamentals." Adequate redundancy and bandwidth must be provided in the core to ensure rapid, reliable delivery of packets presented to it from the distribution layer and destined to common resources or other distribution layer routers. The core should present as little impediment to the delivery of packets as geographic distances and budgets allow. Network designs are much more scalable if it does not matter where a packet enters the core from the distribution layer. The core should appear to be a high-bandwidth service that the distribution layer uses to reach common resources and other distribution layer routers.

If the network has been designed well, including addressing, the edge of the network core will be an ideal place to summarize. The sections that follow discuss the best ways to summarize at the network core to provide maximum stability and resiliency. These methods include the following:

Summarizing from the Core to the Distribution Layer

The "Addressing and Summarization" section in Chapter 2 explained how stability and scalability are best when a network is implemented with good summarization. If your network core topology is robust enough to present a minimum of delay to transit packets and your IP addressing is well designed, you are free to summarize to the fullest from the core to the distribution layer.

In the example network shown in Figure 3-1, you can perform maximum summarization because the network core has adequate bandwidth and redundancy. You can put summarization statements on the serial links that connect the core to the distribution layer, either presenting only the two major network routes (172.16.0.0/16 and 172.17.0.0/16) or just the default route (0.0.0.0/0) to the distribution layer, as shown in Figure 3-2. Refer to the "Summarization Methods" case study later in this chapter for an examination of the various summarization techniques available in an EIGRP network.

Minimizing the updates sent to the distribution layer routers from the core greatly reduces the query range and simplifies the process of bringing up neighbors across these critical links in the network. Refer to the later case study, "Controlling Query Propagation," for details on how important it is to limit the reach of queries in an EIGRP network.

If the destination subnet is closer in the topology to one core router than another, the shortest path from the distribution layer router to the target network might not be the one taken. (The traffic might take a suboptimal route.) If the network core presents minimal delay to traffic, the addition of an extra hop will not be significant when compared to increased stability.

Summarizing into the Core at Its Edge

Summarizing into the core at its edge is only useful if the distribution layer routers along the edge of the core are not also summarizing towards the core. As Figure 3-3 illustrates, the core routers could summarize toward the other core routers so that each core router has full component knowledge of the subnets inside of the regions to which it is connected but only summary knowledge of the other regions.

The following list describes the routing advertisements resulting from the topology and configurations in Figure 3-3:

The advantage of this approach is that the core routers have full knowledge about all remote locations in their region and can choose the optimum route from the core router to the remote site. The disadvantage of this approach is that the core routers for each region are directly involved in the query path for any link failure inside of their region.

Should you summarize within the core of the network? Because this makes the configuration of the core more complicated and moves work from the distribution layer into the network core, you probably should not adopt this solution. In any case, you need to hold off on making a final decision until you have dealt with summarization in the distribution layer.

Analyzing the Network Distribution Layer for Summarization

The distribution layer goals in hierarchical networking are to summarize and aggregate traffic. The following sections on summarizing toward the network core and summarizing toward the remote sites give you a better idea of what you can do with summarization in the distribution layer.

Summarizing Toward the Network Core

You can apply summarization to the inbound links toward the core to limit their advertisements to one or more summary routes representing all the subnets that are reachable through a given distribution router. For example, in Figure 3-4, summarization is configured outbound on Router A and Router B on the serial links toward the core router.

In this network, Routers A and B can advertise the following routes to the core:

However, one problem can occur with this summarization method unless proper steps are taken. If both Router A and Router B advertise summaries representing the same sets of remote networks into the core, you can create a routing black hole if one of the distribution routers loses access to one of the remotes. For example, even if Router A loses its connection to the remote site advertising 172.16.64.0/24, it will continue advertising the 172.16.64.0/19 summary route. In this case, all packets destined to hosts within 172.16.64.0/24 forwarded to Router A will be dropped.

This problem has two solutions. The first solution is to summarize at the edge of the core into the core rather than between the distribution and core routers, as covered in the previous section, "Summarizing into the Core at Its Edge." This solution defeats the goals of the distribution layer, however, and causes queries for networks in the branches to be propagated into the core.

A second solution is to have another reliable link connecting the distribution layer routers within a region. Routes that are advertised over this link will not be summarized, but both distribution layer routers will contain all of the components from each other. The link between the distribution layer routers should be robust enough to support both any remote-to-remote traffic and traffic passed between the two routers advertising summaries in the case of multiple remote site link failures. On most corporate networks, remote site to remote site traffic is negligible, but there are some situations where the traffic levels can be a major consideration, for instance, when voice over is running between the remote sites.

Another, similar solution is to configure a tunnel between the distribution layer routers and use this link as an alternative path in the event of a distribution-access link failure. This technique is often used if the cost or availability of robust links from distribution router to distribution router precludes the use of a physical link.

Obviously, the preferred solution to the summarization toward the network core problem is to have a relatively high-speed and reliable link connecting the distribution layer routers within a region, given that little remote-to-remote traffic will exist. Figure 3-5 illustrates the new design.

The first thing to note in Figure 3-5 is that no link exists between the two center distribution layer routers. A link here would cause too much route leakage between the distribution sublayers.

Summarizing Toward the Remote Sites

You should perform summarization on the interfaces outbound to the remote sites and toward the core. The purpose of this summarization is to limit the routing updates to the remote routers so that they contain only a default route or major net routes. Without the summarization, all the components in the region are sent to the remote sites. As explained later in this chapter in the case study "Troubleshooting Stuck-in-Active Routes," unnecessarily sending intraregion component routes to remotes causes the remote sites to be included in the query process, which is not good. The easiest way to create convergence problems in a large-scale EIGRP network is to do nothing about restricting the range of queries initiated when a route is marked active by a router. Each hop a query must take to resolve the reachability status of a specific destination increases the chances of a major convergence failure in your network.

In addition, if the routes are not summarized from the distribution routers to the remote routers, significantly more work and traffic are required to start up the distribution-to-remote neighbor relationship. Because smaller bandwidth links tend to be used between remote sites and the distribution layer, decreasing the EIGRP bandwidth requirements at startup is wise. You can use either a summary-address or a distribute-list statement to summarize routing information toward remote sites.

NOTE

For more information on how to implement the summary-address and distribute-list statements, refer to the "Summarization Methods" case study later in this chapter.

In the section "Summarizing into the Core at Its Edge," you discovered that summarization within the network core has some advantages, but it also adds undesirable complexity. Summarizing from the distribution layer into the core decreases the EIGRP query range while reducing complexity within the network. Therefore, it is better to summarize into the core instead of within the core.

After you have decided to summarize from the distribution layer into the core, summarization within the core is unnecessary. Because each distribution layer router is sending only summary information to the core, you should not have much to summarize at the core edge into the core.

Analyzing Routing in the Network Access Layer

Normally, you can classify access layer routers as single-homed or dual-homed. The sections that follow present each type along with alternative methods of supporting them.

Single-Homed Sites

Single-homed sites are those that have only a single path into the rest of the network; single-homed remote sites typically have few routes to advertise upstream. True single-homed sites do not have dial backup or anyother additional path into the distribution layer. As such, true single-homed remote sites tend to be less common.

If EIGRP is running out to the remote router of the single-homed remote site, the remote router can advertise any reachable destinations using EIGRP. In this case, the question becomes this: What should the distribution layer router to which the single-homed remote is connected advertise to the remote site?

By definition, a single-homed remote site really does not have routing decisions to make. That is, if the address is not local, it must be reachable through the link to the distribution layer. For this reason, limiting the routes that are sent from the distribution layer to the remote to the minimum number possible is particularly appropriate. Believe it or not, the minimum can be one or even none.

You can either send a single default route from the distribution layer router to the single-homed remote site, or you can filter out all updates from the distribution layer router to the remote site and define a static default route in the remote site pointing back to the distribution layer router. The latter is more efficient. In this way, the routes from the remote site are learned dynamically for delivery of traffic to the remote site, but a static route is used for the traffic that is inbound from the remote site.

If you do not want to run EIGRP between single-homed remote routers and the distribution layer router, you can use static routes at both routers. Because EIGRP is not running between the remote and the distribution layer routers, the distribution layer router cannot learn dynamically about destinations that are reachable at the remote site.

To provide the rest of the network with information about destinations that are available at each single-homed remote site, you can configure static routes at the distribution layer router pointing to the appropriate access router for each remote network. This is ideal when links to the remote sites are not robust. Because EIGRP is not running over the link, it is not affected a great deal if the link often fails. Therefore, it cannot create problems for the remainder of the network because of Stuck-in-Actives (SIAs).

The disadvantages of this approach are the administrative overhead of defining a multitude of static routes and then maintaining them when the network topology changes. Typically, you should only use this approach if you are trying to eliminate problem links from the query and update path for EIGRP.

Dual-Homed Remotes

The second category of access layer routers, dual-homed remotes, is much more common than single-homed remotes. Some are permanent dual-homed remotes, like the remotes illustrated in Figure 3-1, with two or more low-speed connections to two different distribution routers from each remote site. Although the purpose of the two connections from the remote could be for load balancing, they are usually for redundancy. These important remote sites are connected in such a way that a Frame Relay permanent virtual circuit (PVC) failure or distribution layer router failure does not cause them to lose access to the core of the network.

Sites with a single permanent link combined with an on-demand backup link, such as a dial-up, ISDN dial-up, or on-demand switched virtual circuit, also need to be treated as if they are dual homed remotes. Even though such sites don't have two permanent connections into the network distribution or core layers, when the permanent link and the backup link are both in operation (which normally happens after a primarily link failure has been corrected, and the backup link has not yet been disconnected) the remote site will present all the same challenges as a dual homed remote.

Distribution layer routers that are attached to these dual-homed remotes see each of the remotes as an alternative path to reach elsewhere in the network. They appear to be transit paths or alternate paths through the network. For an example, look at Figure 3-6.

With a default EIGRP configuration that is running on all the routers shown in Figure 3-6, Router A sees four paths to the 192.168.250.0/24 network:

Router A would normally choose the route directly through Router B to reach 192.168.25.0/24, but if that route fails, Router A chooses between the remaining three routes or, possibly, load shares between them. This might be fine from a traffic standpoint; you can size the links to handle the load, and so forth.

From a network scaling perspective, however, this is more problematic. Router A sees each of these paths as a path through which it must query if the 198.162.250.0/24 network fails, and it holds each of these paths in its topology table, consequently wasting memory.

Summarizing outbound from the distribution layer, as discussed in the section "Summarizing Toward the Remote Sites," effectively limits the number of paths Router A sees to reach the 192.168.250.0/24 network. Because the remote routers will not have routes to this specific network through Router B, they cannot advertise it back to Router A.

This fact is important in the EIGRP network and most common EIGRP network designs because so many remotes are dual-homed. Summarizing to the greatest possible extent from the distribution layer into these remote site routers is important. Configure the distribution layer routers with distribution lists or summary address statements so that the access layer routers receive only a default route whenever possible.

Dual-Homed Remotes and Best Next Hop

Some remote sites might have links into geographically diverse locations with distinct sets of services available at each hub site. For instance, a single remote site might have links to New York City, where a mainframe with all the financial applications resides, and to San Jose, where all the human resources applications reside. In this situation, it may be better to direct traffic towards the hub location closest to the server (and application) the source host is trying to reach, rather than just routing to one of the two hubs based on a load sharing algorithm, or routing to the closest hub.

If a dual-homed remote site needs to select the best next hop to reach certain destinations (typically Data Centers or common services areas), specific routes to those destinations must be propagated to the remote routers so that path selection can take place. Of course, allowing these additional routes increases the work required to bring up the adjacency between the distribution router and the remote router and possibly allow the feedback of routes from distribution router to remote router to distribution router as described previously. How do you deal with this situation?

If a limited number of routes is being allowed from the distribution layer router to the remote router, the additional overhead of bringing up the link should not be severe. Limit the number of routes advertised to the remotes to a bare minimum.

What about those additional paths that the remote routers will be advertising back into the distribution layer? You need to eliminate the possibility of the distribution layer routers seeing the remote routers as transit paths back to other distribution layer routers.

You can prevent those routes from being readvertised from the remote routers back into the distribution layer by configuring distribution lists (filtering the routes advertised by the remote routers toward the distribution layer routers), allowing only the routes at that remote site in routing updates. In other words, the filters permit routes that originate at the remote site, and not routes that are learned via the links to the distribution layer.

Configuring route filters at the remote site's routers can prevent information learned through one hub from being forwarded to the other hub, and can also act as an insurance policy against remote site router misconfiguration disasters. A missing summary address statement or distribution list on a distribution router causes the remote site to learn more routes than it should, possibly causing havoc.

In some situations, a route that inadvertently leaks from the distribution layer toward a remote router might be the best route at the other distribution layer router, causing all the traffic to be routed through the remote site. This could be a disaster because it is not likely that the links to the remotes are provisioned to support the traffic that is transmitted through the site if this occurs. It could cause failed neighbors and network instability.

In the sample network shown in Figure 3-6, the distribution lists in the remotes are not necessary because every distribution router has the same level of summarization. To be safe, however, you should configure distribution lists.

Analyzing Use of the Stub Feature in Access Routers

Configuring a remote router as a stub, when used in conjunction with the summarization techniques described in the previous sections, can dramatically improve scaling in dual-homed remote routers. Because many networks are composed of large numbers of small access routers, which are either single- or dual-homed to the distribution layer, the stub feature is extremely valuable in many EIGRP networks. What does configuring a router as a stub actually do? Stubs limit the query scope and simplify the network topology, improving EIGRP network convergence.

NOTE

Throughout this section, you will see discussion of controlling query propagation as an important part of configuring a remote router as a stub. Discussion of the importance of controlling query propagation occurs in the "Controlling Query Propagation" case study later in this chapter. In summary, queries are always propagated one hop past a summarization point. If you configure summarization on the distribution routers toward the remote routers (as recommended in the previous sections), queries are propagated one hop beyond the distribution layer routers, to the remote site routers in the access layer, even though the answer to the query is never found there. This is not much more work on the remote site routers, but it causes a great deal more work on the distribution layer routers, because they need to generate and track one query per remote router. Therefore, summarization succeeds at limiting updates to the remotes, but it still allows queries to reach the remote routers.

The active process is designed to find unknown loop free paths through the network. Why not take a short cut in the active process, and simply not search in places where you know an alternate path could not exist? You could cut down on the query range, and improve network convergence time, dramatically. In fact, there are routers a network designer knows, just by examining the network design itself, will never be used as an alternate path, or a transit path, no matter how many links in the network fail. In EIGRP terms, these are stub routers.

A stub router is a router on the edge of the network, or, in other words, a router with no routers farther from the core attached to it. If you view the network topology as a tree (the same way a link-state protocol would build a tree of the topology within a flooding domain), edge routers are always nodes at the farthest point possible from the center of the tree, and through which no traffic should (or would) ever pass. EIGRP allows the network designer to explicitly mark stub routers as stub routers. EIGRP will never search for an alternate path through a router marked as a stub.

How does configuring a router as a stub stop the router from receiving queries? When a router is configured as a stub, it flags itself as a stub by setting bits in its hello packet. Each neighbor of a stub router notes these flags and sets corresponding flags in the neighbor's data structure.

When the EIGRP process on a router loses all the successors and feasible successors for a route, it begins a diffusing update by marking the route active and sending queries to each of its neighbors (except, possibly, those attached to the same interface as the old successor). Before sending these queries, however, it looks at the peer information to determine if a peer is a stub router. If a peer is a stub router, it is removed from the list of neighbors to send queries to. Figure 3-7 illustrates the impact of declaring the remote routers as stubs. As illustrated in Figure 3-7, declaring your remote routers as stubs dramatically reduces the number of queries on the network. In that diagram, only one query is sent instead of many.

Another important aspect of the stub feature is how it decreases the apparent complexity of the topology by limiting the types of routes that a router advertises. In Figure 3-8, Router A finds four alternate paths to 192.168.250.0/24, one through each remote router, and one directly to Router B.

The stub feature significantly alters this behavior, simplifying the convergence process. When a router is defined as a stub, it must be configured with the types of routes that the stub router will advertise. By definition, an EIGRP stub router does not advertise dynamically derived routes (routes learned from other EIGRP neighbors). In Figure 3-8, this means that Routers C, D, and E will not advertise any route they learned from Router B. If Routers C, D, and E are configured as stub routers, Router A is left with one path to 192.168.250.0/24, through Router B.

You can define more than one operand on the eigrp stub command. For example, you can define the following command:

This command causes EIGRP to advertise all connected, summary, and redistributed routes. If you do not define operands (you configure just eigrp stub), both connected and summary routes are advertised.

Analyzing Routes to External Connections

Another area to be concerned with is injecting information learned from other routing protocols into EIGRP. Typically, you would inject this information along the edge of the network, or from networks not originally planned to be a part of the EIGRP routing domain, such as the network of an aquired or partnering company. You can classify these external sites in two ways:

This section describes several methods to propagate information about these external destinations. First, if the external routing domain has a limited number of IP networks, you can redistribute the routes into EIGRP from the other routing domain.

NOTE

Carefully consider the security of the routing system when redistributing routes from an external routing domain. See Chapter 8, "Routing Protocols Security," for more information on this topic.

Redistributing routes into EIGRP can be a reasonable choice if done correctly. If done poorly, however, redistribution can create a disaster. Refer to the "Redistribution" case study later in this chapter for techniques on preventing problems when redistributing routes from EIGRP into and from other routing protocols. The "Case Study: Redistribution" section focuses more exclusively on redistribution between Interior Gateway Routing Protocol (IGRP) and EIGRP for combining networks and for transitioning from IGRP to EIGRP.

NOTE

If you have not already transitioned from IGRP to EIGRP in your network, you should. IGRP is being removed from Cisco IOS Software Release 12.3, so now is the perfect time to make the switch.

If the external connection is to the Internet, redistributing the routes into EIGRP is probably not a good idea, unless you enjoy cleaning up after complete network failures. The Internet has entirely too many routes; you would overpopulate the routing tables. Generally, from within a routing domain, you should use a default route to reach the nearest border with the Internet, and then use the more specific routing information on the border router to route correctly toward the Internet.

You can propagate information about the default route into EIGRP in two ways. First, you could define a static route to 0.0.0.0/0 and redistribute this route into EIGRP from a border router. One problem with this approach is routers configured with ip summary-address eigrp AS 0.0.0.0 0.0.0.0 will not forward traffic to a default route (0.0.0.0/0) learned from a neighboring router. Why not?

A local summary route has a default administrative distance of 5, whereas the external default route has an administrative distance of 170. Therefore, a redistributed static route will never be installed if a competing locally generated summary default route exists. Either the local router must have a static route with a better administrative distance than the summary, or the summary must be configured with an administrative distance higher than 170.

The second way to propagate information about the default route into EIGRP is to mark a route as a candidate default using the command ip default-network. However, this is not the preferred method of providing a default route into an EIGRP network.

NOTE

The capability to distribute a default route through the command default-information originate is planned for a future release of Cisco IOS Software.

NOTE

Cisco is planning to remove support for the command ip default-network in a future Cisco IOS release.

Analyzing Routes to the Common Services Area

In the network illustrated in Figure 3-9, common services are connected to the core through two distribution routers and via multiple, parallel Fast Ethernet links. Whether these are truly separate physical links or VLANs that are connected through switches, to EIGRP they present the appearance of multiple parallel paths interconnecting the two distribution routers. One of the more typical errors that network designers make is to include all of these parallel paths as alternative paths for routes to reach much of the rest of the network.

Ideally, the servers on these segments point their default gateway to a Hot Standby Router Protocol (HSRP) address shared by the two distribution routers. This design allows the servers on these segments to adapt to a router or link failure almost immediately.

The networks that connect the servers to the routers are not designed for transit traffic; traffic is not expected to enter the common services distribution router from the core, go through one of the Fast Ethernet links used by the common services, and then exit through the other distribution router back to the core. EIGRP, however, does not know this, because every link between the two distribution routers appears as a possible path to every destination in the network. EIGRP treats each of these links as an alternate path, stores information about them in the topology table, and propagates queries through them. These alternate paths complicate the EIGRP convergence.

To eliminate the possibility of these networks being used for transit traffic, the network manager should run EIGRP on as few of these links as possible. Configuring passive-interface interface for an interface or subinterface removes EIGRP from these interfaces. Although EIGRP will continue to advertise the IP addresses for the interfaces that are declared passive, EIGRP Hellos will not be sent and neighbors will not be formed on them. This eliminates their use as transit paths for traffic.

To prevent the rest of the routers in the network from going active on individual segments that support these servers, you should use the same strategy that is used everywhere else in the network. Summarize the subnets that reside on the common service Ethernet connections in both distribution layer routers so that they send only a single summary route to the core. If a single Ethernet connection goes down in the common services area, the remainder of the network does not start the query process to find an alternative path. The query stops at the first router that does not have knowledge of the specific subnet that has failed, which is a core router.

This strategy has one problem, though: It can create routing black holes in the same way that dual-homed remotes can. To understand why, examine Figure 3-10, which has all but two of the common services networks removed.

Router A and Router B both advertise a summary of 172.16.16.0/22, which covers the entire address range but does not overlap with other addresses in the network. If the Router A interface on the 172.16.18.192/26 network fails, Router A continues advertising the 172.16.16.0/22 summary toward the core. If, however, one of the core routers forwards a packet that is destined to the 172.16.18.192/26 network toward Router A, Router A drops it because it has no route for this destination. Even worse, it might send the packet back toward the core along its default route.

To resolve this situation, Router A must know that 172.16.18.192/26 is reachable through Router B. This is why you should run EIGRP over at least one of these parallel Ethernet links. To do this, do not put a passive-interface statement into the configuration for at least one Ethernet link. A better solution is to have one or two links between these routers for dedicated redundancy (with no servers or other devices on them) to account for just this situation.

Analyzing Routes to Dial-In Clients

Dial-in access creates several issues and complications. This section discusses host routes created by the dial process and EIGRP bandwidth concerns.

Host Routes

Typically, dial in is handled through PPP. When a PPP session is initiated, a host route (/32) is created on the access server for the remote site, and the host route is removed when the call is dropped. If the number of dial-in clients is large, this can create a significant amount of network activity because the network reacts to these host routes appearing and disappearing.

You can eliminate this influx of network activity in EIGRP in two ways. First, you can define the command no ip peer host-route on the interface(s) of the access server, which stops the host route from being created in the first place.

Second, you can summarize the host routes learned via the dial interfaces, allowing only this summary route to be advertised toward the core. You can do this summarization either by con-figuring ip summary-address autonomous system eigrp on the links toward the core, or by configuring a distribute-list out on the links toward the core, as discussed in the "Summarization Methods" case study later in this chapter.

If the routes advertised by a router dialing into the network are normally summarized someplace other than the router accepting the dial-in connection, you can wind up with some major problems in your network. There are several problems with routers advertising routes towards the core of the network beyond the point where those routes are normally summarized.

As long as the dial-up link is up, the path through the dial-up link will be preferred towards the remote site. Once the primary link is fixed, it's common for the dial-up link to remain up for some time. In this situation, it's not desirable for the traffic to the remote site to continue to be routed over the dial-up link.

To make matters worse, once the primary link is repaired, the dialing router may actually leak more specific routes into the core of the network through the dial-up link, drawing all the traffic for every possible destination behind the summary onto the dial-up link. If you configure your dial-up links so a remote router will dial in to a destination between the summarization point for the routes advertised by that remote router and the core of the network, you need to make certain you take these possible problems into consideration in the network design.

Figure 3-11 illustrates the technique of making certain the dial-up links are terminated behind the summarization point, in relation to the network core.

Bandwidth Issues

Bandwidth can be an issue when routers, rather than individual hosts, are dialing into an access server. EIGRP uses the bandwidth that is configured on the interface (using the bandwidth command) to determine the rate to pace EIGRP packets. EIGRP paces its packets so that it will not overwhelm the link by using 50 percent of the defined bandwidth by default. Because EIGRP relies on the bandwidth that is configured on the interface for packet pacing, it is important for the interface to be configured correctly. The interface should reflect the real bandwidth that is available on the link.

If EIGRP believes that the interface has more bandwidth than what is actually available, it can dominate the link, not allowing other traffic to flow. If EIGRP believes the interface has much less bandwidth than it actually does, it might not be able to successfully send all the updates, queries, or replies across the link because of the extended pacing interval.

To make things more complicated, the bandwidth that is used to determine the pacing interval is divided by the total number of remote peers on Integrated Services Digital Network (ISDN)

PRI and dialer interfaces in an attempt to fairly distribute the available bandwidth between the neighbors that are reachable through that interface.

With Frame Relay multipoint interfaces, this works fine. With ISDN or dialer interfaces, however, you never know how many neighbors will be dialed in. If only one Basic Rate Interface (BRI) is dialed in, the bandwidth should be defined as 64 kbps. If 23 BRIs are dialed in, the bandwidth should be 1.544 Mbps. Because the defined bandwidth does not change with the number of neighbors dialed in, you should set the bandwidth to make it work for both extremes by doing the following: