Special Components Needed for ATM Lab Studies

Configuring Dial-on-Demand Routing (DDR)

For ISDN to work properly, dial-on-demand routing (DDR) options must be created on the interface. Often, ISDN links are used to back up point-to-point or Frame Relay circuits. If not configured correctly, the ISDN link can stay up constantly or can continuously connect, hang up, and then connect again. Because ISDN carrier's normally charge usage by the minute, a small configuration error can result in a customer getting ISDN bills of more than $1000 per month. Unless you enjoy long "discussions" with your manager, you probably want to avoid this. DDR works using the concept of user -defined "interesting" traffic. The ISDN link will come up only under the circumstances permitted, or when certain interesting traffic is passed to the ISDN interface. The ISDN call will stay up until no interesting traffic has passed through the ISDN interface for a user-specified period of time, using the dialer idle-timeout command in interface configuration mode. The default idle timeout length is 120 seconds. The length of time that can be configured is as follows :

 ISDN_Router(config-if)#  dialer idle-timeout ?  <1-2147483>  Idle timeout before disconnecting a call 

This time is specified in seconds. An important thing to note here is that all types of traffic will pass over the ISDN link as long as the connection is active, not just the traffic specified as "interesting."

However, only traffic specified as interesting will keep the call up. Think of the dialer idle timeout value as a countdown timer. When traffic specified as interesting initiates an ISDN connection, the timer starts, counting down to 0. When the timer reaches 0, the connection is dropped. This timer is reset only when the traffic specified as interesting (which was defined in the dialer lists) passes through the ISDN link. As you will see, there are a number of ways to accomplish DDR; the trick is to configure the routers so that an ISDN connection is established when needed, while suppressing the connection when it is not needed.

The two options that are discussed with DDR in this chapter are legacy DDR and dialer profiles. Legacy DDR deals with the capability to enable a connection only when there is traffic to send. Here, the dialer parameters are specified on the physical ISDN interface. Dialer profiles include the use of logical dialer interfaces, which are separate from the physical ISDN interface, to issue a DDR call. In this setup, the bulk of the configuration commands are placed on the logical dialer interfaces, and only a few necessary commands actually are placed on the physical ISDN interface. Examples of both legacy and dialer profile configurations are covered in this chapter.

To configure DDR, you must keep in mind that there are two ends to an ISDN call: the calling router and the called router. The calling router is the router that will initiate the ISDN call, and the called router is the destination router where the ISDN link terminates. Note that each router can serve as both a calling and a called router; however, when setting up DDR, you work from one side at a time. One router might have different requirements for placing a call than the other router. Figure 7-3 shows a typical simple ISDN setup.

Figure 7-3. ISDN Backing up a Primary Link

Normally, the remote office will initiate the ISDN connection, therefore becoming the calling router. The headquarters router becomes the called router. Larger networks might have numerous remote offices that use routers with BRI interfaces, with the headquarters router having a PRI interface to handle multiple ISDN calls at once.

In this setup, the Frame Relay link is used as the primary, with the ISDN link backing up the Frame Relay, and is used only when there is a Frame Relay outage . Typically, the remote office is the calling router, and the headquarters location is the called router. As you will see, there are numerous ways in which to accomplish this.

To configure DDR, perform the following steps:

Step 1. Configure the ISDN switch type and SPID information, if necessary.

Step 2. Specify the interesting traffic that will bring up the ISDN call.

Step 3. Configure the dialer information. This includes the number to call to reach the called router, as well as any other parameters associated with the call.

Step 4. Configure any other optional parameters associated with the ISDN interface. These advanced topics include interface encapsulation, dialer idle-timeout, authentication options, callback for billing purposes, and so on. Most of these options are covered later in the chapter.

Step 5. Route traffic over the ISDN line. You can use a number of options here, such as specifying floating static routes, using the backup interface command, or using dynamic routing protocols together with their respective options. These options include the following:

For OSPF: OSPF demand circuit

For EIGRP, IGRP, OSPF: Dialer watch

IGRP, RIP: Snapshot routing

All: Backup interface

These routing topics are covered later in the chapter, and these options are demonstrated through different labs. You will find many parallels in these examples to those found in Chapter 4 for the sake of completeness.

Within the scope of the CCIE lab, you will be provided the switch type and the SPID numbers , so there won't be a lot of guessing. In the real world, ISDN is a huge pain because of service provider issues; however, most typical noncarrier problems are the result of incorrectly entering information (that is, SPIDS or switch type). The other setup for bringing up an ISDN line is to save the router configuration and power-reset the router. Within the scope of the lab exam, if you are highly confident that you have your router configured correctly and that you have the correct working cable plugged into the correct jack, don't hesitate too long to notify the instructor that you are having problems with the line and you are wondering whether there have been problems with the line in the past. As with all other questions to the instructor, ask questions as if the instructor is a customer!

Step 1: Configure the ISDN Switch Type and SPID Information

Referring back to Figure 7-1, you can specify the ISDN switch type in either global or interface configuration mode. Because the routers in this diagram have only one BRI interface, it does not matter where it is applied. For purposes here, specify it in interface mode along with the SPID information, as demonstrated in Example 7-1.

Example 7-1 Setting the SPID Information on a BRI Interface

 ISDN_Router#  config terminal  Enter configuration commands, one per line.  End with CNTL/Z. ISDN_Router(config)#  interface BRI0  ISDN_Router(config-if)#  isdn switch-type basic-dms100  ISDN_Router(config-if)#  isdn spid1 61293198331111 ldn  ISDN_Router(config-if)#  isdn spid2 61293198461111 ldn  

The LDN is the local directory number, which is the seven-digit number assigned by the service provider and used for call routing. The LDN is not necessary for establishing ISDN-based connections, but it must be specified if you want to receive incoming calls on the second B channel. The LDN is required only when two SPIDs are configured (for example, when connecting to a DMS or NI1 switch). Each SPID is associated with an LDN, and configuring the LDN causes incoming calls to B channel 2 to be answered properly. If the LDN is not configured, incoming calls to B channel 2 might fail.

CAUTION

Take caution when entering the SPID information because it can be easy to "fat finger" the numbers. We have done this often and then have wasted time trying to troubleshoot what I thought was an ISDN circuit problem, only to realize that we typed in the wrong SPID.

Step 2: Specify Interesting Traffic

Interesting traffic is defined as the kind of traffic that is allowed to initiate an ISDN connection. When this connection has been established, the link will stay up as long as the type of traffic that is defined as interesting traverses the ISDN link.

This step is performed using the dialer- group interface command, along with a special access list that defines the interesting traffic, called a dialer list, in global configuration mode. The syntax for the dialer-list is as follows:

  dialer-list   dialer-group   protocol   protocol-name  [  permit   deny   list  ]  access-list   number.  

Here, the dialer-group argument is used to define the interesting traffic for the interface. This is the same number that was entered into the dialer-group command. Be sure that the number specified in the dialer-group number matches the dialer-list number. For example, if you want to specify all IP traffic as interesting, use the command dialer list 1 protocol ip permit.

You also can use extended dialer lists to define a more granular set of conditions that will define the interesting traffic, by combining a dialer list with an extended access list. For example, if you want to specify that only traffic originating from 10.1.1.0/24 destined for 10.1.2.0/24 can initiate an ISDN call, you would accomplish this through the following commands:

 ISDN_Router(config)#  dialer-list 1 protocol ip list 101  ISDN_Router(config)#  access-list 101 permit ip 10.1.1.0 0.0.0.255 10.1.2.0 0.0.0.255  

The first command ties the dialer list to an extended access list; this example uses access list 101. By using extended access lists, you can be more specific in what types of traffic you define as interesting.

Step 3: Configure Dialer Information

A few options should be considered when configuring the dialer information. The most basic way to do this is through the dialer-string interface command. Configuring the dialer information in this manner has some limitations ”namely, the dialer string will be used for all outgoing calls, regardless of the actual destination. This works well if the calling router has only one other router to connect to, but not if the ISDN router has the capability to dial into more than one other ISDN router. A more feature-rich way of accomplishing this step is using the dialer-map command. Here, a router can more accurately determine which ISDN router to dial into based on the Layer 3 address. These two options commonly are referred to as legacy DDR. Finally, the last option is to use a set of logical dialer interfaces. A major advantage to using logical dialer interfaces is that an ISDN router has the capability to dial into multiple other ISDN routers simultaneously . We will now demonstrate these three options using the simplified network in Figure 7-4 as a reference.

Figure 7-4. Simplified ISDN Network

Configuring Dialer Information, Method 1: Using Dialer Strings

This is the simplest (and least robust) way to configure ISDN. In Example 7-2, all traffic specified as interesting initiates the call, which will be placed to the number specified in the dialer string. This works well for situations in which there is only one possible destination, but not in networks where there are multiple ISDN sites that need access to each other directly. Note that the BRI interface encapsulation in this example has been set to PPP. In this situation, it is not necessary and could have just as easily been left with the default encapsulation, HDLC.

Example 7-2 Cheech and Chong Router Configurations Using Dialer Strings

 Cheech#  show running-config  version 11.2 no service password-encryption no service udp-small-servers no service tcp-small-servers ! hostname Cheech ! enable password cisco ! isdn switch-type basic-dms100 ! interface Ethernet0  no ip address shutdown ! interface Serial0 no ip address shutdown ! interface Serial1  no ip address  shutdown ! interface BRI0  ip address 175.10.23.1 255.255.255.252  encapsulation ppp  isdn spid1 61293199371111  <SPID associated with the first B channel  isdn spid2 61293199381111  <SPID associated with the second B channel  dialer string 6129319833   <number to dial for all outgoing connections  dialer-group 1 ! ip classless ! dialer-list 1 protocol ip permit  <all ip traffic is interesting ! line con 0  exec-timeout 0 0  privilege level 15  logging synchronous line aux 0 line vty 0 4  password cisco  login ! end ____________________________________________________________________________________ Chong#  show running-config  ! version 11.2 no service password-encryption no service udp-small-servers no service tcp-small-servers ! hostname Chong ! enable password cisco ! isdn switch-type basic-dms100 ! interface Ethernet0 no ip address shutdown ! interface Serial0 no ip address shutdown ! interface Serial1  no ip address  shutdown ! interface BRI0  ip address 175.10.23.2 255.255.255.252 encapsulation ppp isdn spid1 61293198331111   <SPID for the first B channel isdn spid2 61293198461111   <SPID for the second B channel dialer string 6129319937    <number to call for all connections dialer-group 1 ! no ip classless ! dialer-list 1 protocol ip permit  <all ip traffic is interesting ! line con 0  exec-timeout 0 0  privilege level 15  logging synchronous line aux 0 line vty 0 4 no login privilege level 15 ! end 

In this example, both routers can initiate ISDN calls. If you want only Cheech to be capable of calling into Chong, and not vice versa, you could omit the dialer string command in Chong's configuration.

NOTE

Although the configurations in Example 7-2 are fairly straightforward, you might not be familiar with some commands. Both routers have some serious security holes that purposely were done. Under the line con 0, we added the privilege level 15 command. This enables anyone connected to the router to go straight to enable mode without typing in the enable password. We also added the exec-timeout 0 0 command, which means that all console connections will never time out. This was done only to save the time and effort that it takes to go into enable mode and type in a password to get into enable mode. We did something similar under the vty so that when you Telnet to a router, you go automatically into enable mode without a password prompt. Although this is useful in a lab environment, these commands never should be implemented in a live production router. One final command to point out is the logging synchronous parameter under the console heading. This prevents the router from interrupting you while you are in the middle of typing a command. By default, the router logs all events to the console, which can make it easy to lose your place while typing in commands. An alternative to this is the no logging console command, but we prefer the logging synchronous command because it allows you to see the console log entries, which is usually useful, without the bothersome interruptions that occur by default.

Configuring Dialer Information, Method 2: Using Dialer Maps

The problem with using dialer strings occurs when multiple ISDN connections are involved. In the network illustrated in Figure 7-5, the Headquarters router would require two sets of dialer strings to connect to the remote offices, Cheech and Chong. However, because the Headquarters router has no way of associating IP addresses with dialer strings, it might dial the Cheech router when it needs to connect to the Chong router.

Figure 7-5. Dialer Map Configuration

A way to map IP addresses to dialed numbers is to use dialer maps. Using dialer maps tells the router which dial string to call when it wants to connect to a specific IP address. Example 7-3 demonstrates the router configuration using dialer maps.

Example 7-3 Example Dial String Configuration for the Headquarters Router

  interface BRI0   ip address 175.10.23.3 255.255.255.248   encapsulation ppp   isdn spid1 61293193601111   isdn spid2 61293197761111   dialer map ip 175.10.23.1 name Cheech 6129319937   dialer map ip 175.10.23.2 name Chong 6129319833   dialer-group 1  

The IP address space is set up so that when the Headquarters router calls either Cheech or Chong, they are in the same subnet.

You should be aware of a couple of other options when using dialer maps. One is that the connection speed for each B channel can be manually set to either 56 kbps or 64 kbps, using the speed keyword. Another useful command is the name keyword, which can be placed at the end of the dialer map statement. With CHAP and the name keyword included in the dialer map command, both the telephone number and the name for a given next -hop address are compared to the names of the routers already connected. In this way, calls to destinations to which connections already are established can be avoided.

More important is the broadcast keyword option. If you want to pass routing updates across the ISDN connection, (routing protocols use broadcast packets to advertise their routes), you must use the broadcast keyword in the dialer map statement, as demonstrated in Example 7-4. This is much like Frame Relay, in that the broadcast statement must be configured in all frame-relay map statements if you want to pass routing updates.

Example 7-4 Using the broadcast Statement: Headquarters Router Configuration

  interface BRI0   ip address 175.10.23.3 255.255.255.248   encapsulation ppp   isdn spid1 61293193601111   isdn spid2 61293197761111    dialer map ip 175.10.23.1 name Cheech broadcast 6129319937     dialer map ip 175.10.23.2 name Chong broadcast 6129319833    dialer-group 1  

The configuration in Example 7-4 enables the passing of routing updates and other broadcast traffic. However, if you don't want this traffic to actually trigger calls, you need to specify restrictive dialer lists or make the ISDN interface passive under the routing process.

Configuring Dialer Information, Method 3: Using Logical Dialer Interfaces

Dialer profiles were introduced in Cisco IOS Software Release 11.2, and they offer the capability to separate the configuration parameters used in legacy DDR from the physical interfaces. It is perhaps the most complex method of configuring DDR, but it offers the greatest amount of flexibility and design options. It works through the creation of logical dialer interfaces, where the configuration options are placed. These dialer interfaces are bound to a physical interface only when a connection is made, through the use of dialer pools.

To configure dialer profiles, first you must remove all legacy DDR commands under the BRI 0 interface. Then you create a logical interface, dialer 1, and place all configuration options and Layer 3 information on that interface. The steps for configuring dialer profiles are as follows:

Step 1. Remove all legacy DDR commands from the BRI 0 interface. IOS will not allow you to map a dialer interface to a physical interface until this is done.

Step 2. Configure a logical interface using the interface dialer X command, where X can be any value between 0 and 255.

Step 3. Configure a dialer remote-name on the dialer interface. Only one remote name can be specified, and this should be the name of the router with which you want to make an ISDN connection.

Step 4. Map the logical interface to the physical interface. This is done by associating a dialer pool on the logical interface to the dialer pool-member on the physical interface. This is done with the dialer pool-member x command on the physical interface and the dialer pool x command on the logical dialer interface, where x can be any integer from 1 to 255. The number specified must be the same for both interfaces, and there can be only one dialer pool per dialer interface.

Step 5. Define the interesting traffic. This is needed only for routers that initiate calls (calling routers), and it is done the same way as legacy DDR, except that the commands are now placed on the logical interface.

Step 6. Provide a dialer string to call on the logical interface. This is the number to call to connect to another ISDN router. Note here that dialer maps cannot be configured on dialer interfaces. When a connection is made to another router, dialer maps are generated dynamically.

Step 7. Configure the optional parameters on the dialer interface. This is where things like dialer idle timeouts and network addressing are placed.

Example 7-5 illustrates an example configuration that incorporates these seven steps. The important thing to notice in this example is the introduction of the logical dialer interface.

Example 7-5 Example Dialer Profile Configuration

 Remote_Site#  show running-config  Building configuration... Current configuration: ! version 12.0 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname Remote_Site ! ! username Headquarters password 0 cisco ip subnet-zero isdn switch-type basic-dms100 ! interface Loopback0  ip address 175.10.101.1 255.255.255.255  no ip directed-broadcast ! interface Ethernet0  ip address 175.10.2.1 255.255.255.0  no ip directed-broadcast  no keepalive ! interface Serial0  no ip address  no ip directed-broadcast  shutdown  no fair-queue  clockrate 125000 ! interface Serial1  description PRIMARY LINK TO HQ  bandwidth 64  ip address 175.10.200.1 255.255.255.252  no ip directed-broadcast ! interface BRI0  no ip address  no ip directed-broadcast  encapsulation ppp  dialer pool-member 1  isdn switch-type basic-dms100  isdn spid1 61293199371111  isdn spid2 61293199381111 !  interface Dialer1   ip address 175.10.23.1 255.255.255.252   no ip directed-broadcast   encapsulation ppp   dialer remote-name Headquarters   dialer string 6129319833   dialer pool 1   dialer-group 1  ! no ip classless ! dialer-list 1 protocol ip permit ! ! line con 0  privilege level 15  logging synchronous  transport input none line aux 0 line vty 0 4  login ! end ! We can verify our configuration by using the show dialer command.  Notice here that the BRI 0 interface is now bound to the logical dialer interface, dialer 1. Remote_Site#  show dialer  BRI0 - dialer type = ISDN Dial String      Successes   Failures    Last called   Last status 0 incoming call(s) have been screened. 0 incoming call(s) rejected for callback. BRI0:1 - dialer type = ISDN Idle timer (120 secs), Fast idle timer (20 secs) Wait for carrier (30 secs), Re-enable (15 secs) Dialer state is data link layer up Dial reason: ip (s=175.10.23.1, d=175.10.23.2)  Interface bound to profile Di1  Time until disconnect 111 secs Current call connected 00:00:10 Connected to 6129319833 (6129319833) BRI0:2 - dialer type = ISDN Idle timer (120 secs), Fast idle timer (20 secs) Wait for carrier (30 secs), Re-enable (15 secs) Dialer state is idle  Di1 - dialer type = DIALER PROFILE   Idle timer (120 secs), Fast idle timer (20 secs)  Wait for carrier (30 secs), Re-enable (15 secs)  Dialer state is data link layer up   Dial String      Successes   Failures    Last called   Last status  6129319833               2          0    00:00:11       successful   Default 

Step 4: Configuring Advanced Optional Parameters

A number of advanced features can be specified using ISDN, including ISDN callback, call screening, and PPP authentication. Most of these options apply only to a PPP encapsulated interface. To demonstrate this, simply look at the number of PPP options available to us on the BRI interface in Example 7-6.

Example 7-6 Calling Up the Available PPP Options

 R2(config-if)#  ppp ?  authentication          Set PPP link authentication method   bap                     Set BAP bandwidth allocation parameters   bridge                Enable PPP bridge translation   callbac    k               Set PPP link callback option   chap                    Set CHAP authentication parameters   compression             Enable PPP Compression control negotiation   ipcp                   Set IPCP negotiation options   lcp                     PPP LCP configuration   max-bad-auth            Allow multiple authentication failures   multilink               Make interface multilink capable   pap                     Set PAP authentication parameters   quality                 Set minimum Link Quality before link is down   reliable-link           Use LAPB with PPP to provide a reliable link   timeout                 Set PPP timeout parameters   use-tacacs              Use TACACS to verify PPP authentications 

For example, if you want to use authentication to verify the validity of an incoming ISDN call, you must use PPP encapsulation. PPP also can be used to configure dialer callback and multilink, among others. Because of the feature available using PPP, and because nearly all real-world ISDN configurations use PPP-encapsulated interfaces, you will be using PPP encapsulated BRI interfaces in all of the labs.

The most commonly configured optional parameter involves the use of authentication, which means using either PAP or CHAP, as discussed in the sections that follow.

Example: Authentication Using the Password Authentication Protocol (PAP)

PAP is a simple method for a remote router to verify the validity of a remote node. The primary drawback is that it is not a secure method, meaning that the username and password are sent across the ISDN network in plain text and can be seen easily using a protocol analyzer. Because the PAP process is sent across the link without encryption, anyone with a protocol analyzer easily can obtain this information. PAP also offers no protection against playback and trial-and-error (dictionary or brute force) attacks. Because of this, CHAP is the preferred method of authentication. Still, it supplies a rudimentary authentication method supported by Cisco.

To configure PAP, you need to configure four things:

Step 1. Configure the remote router's username and password in global configuration mode, using the username name password password command. The username must match the host name that is configured on the remote router exactly, and it is case-sensitive.

Step 2. Under interface configuration mode, you need to set up PPP encapsulation on the ISDN interface using the encapsulation ppp command.

Step 3. Specify that you are using PAP authentication using the ppp authentication pap command.

Step 4. Specify the local username and password combination that you want to send to the remote ISDN router with the ppp pap sent-username username password password command. This must match what the remote router has specified in Step 1 for your router.

Example 7-7 shows the PAP authentication configuration for the calling router, and Example 7-8 shows the PAP authentication configuration for the called router.

Example 7-7 Example PAP Authentication Configuration: Router 1 (Calling Router)

 ISDN-1#  show running-config  Building configuration... Current configuration: ! version 12.0 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname ISDN-1 ! ! username ISDN-2 password 0 CISCO ip subnet-zero isdn switch-type basic-dms100 ! ! ! interface Loopback0  ip address 175.10.101.1 255.255.255.255  no ip directed-broadcast ! interface Ethernet0  ip address 175.10.2.1 255.255.255.0  no ip directed-broadcast  no keepalive ! interface Serial0  no ip address  no ip directed-broadcast  encapsulation frame-relay  logging event subif-link-status  logging event dlci-status-change  no fair-queue  clockrate 125000 ! interface Serial1  description PRIMARY LINK TO HQ  bandwidth 64  ip address 175.10.200.1 255.255.255.252  no ip directed-broadcast ! interface BRI0  ip address 175.10.23.1 255.255.255.252  no ip directed-broadcast  encapsulation ppp  dialer map ip 175.10.23.2 name ISDN-2 broadcast 6129319833  dialer-group 1  isdn switch-type basic-dms100  isdn spid1 61293199371111  isdn spid2 61293199381111  ppp authentication pap  ppp pap sent-username ISDN-1 password 7 0802657D2A36 ! router eigrp 1  passive-interface BRI0  network 175.10.0.0  no auto-summary ! no ip classless ! dialer-list 1 protocol ip permit ! ! line con 0  privilege level 15  logging synchronous  transport input none line aux 0 line vty 0 4  login ! end 

Example 7-8 Example PAP Authentication Configuration: Router 2 (Called Router)

 ISDN-2#  show running-config  Building configuration... Current configuration: ! version 12.0 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname ISDN-2 ! logging buffered 9096 debugging ! username ISDN-1 password 0 CISCO ip subnet-zero isdn switch-type basic-dms100 ! ! ! interface Loopback0  ip address 175.10.102.1 255.255.255.255  no ip directed-broadcast ! interface Ethernet0  ip address 175.10.1.1 255.255.255.0  no ip directed-broadcast  no keepalive ! interface Serial0  no ip address  no ip directed-broadcast  encapsulation frame-relay  logging event subif-link-status  logging event dlci-status-change ! interface Serial1  description PRIMARY LINK TO REMOTE SITE  bandwidth 64  ip address 175.10.200.2 255.255.255.252  no ip directed-broadcast  clockrate 125000 ! interface BRI0  ip address 175.10.23.2 255.255.255.252  no ip directed-broadcast  encapsulation ppp  dialer-group 1  isdn switch-type basic-dms100  isdn spid1 61293198331111  isdn spid2 61293198461111  ppp authentication pap  ppp pap sent-username ISDN-2 password 7 01302F377824 ! no ip classless ! dialer-list 1 protocol ip permit ! ! line con 0  privilege level 15  logging synchronous  transport input none line aux 0 line vty 0 4  login ! end 

In the configuration, the password is encrypted under the BRI0 interface. This is done by Cisco IOS Software so that anyone passing by your desk cannot obtain the password simply by looking at the configuration. This password is encrypted only in the configuration file, and the actual password (CISCO) is sent in plain text across the link.

Example: Authentication Using the Challenge Handshake Authentication Protocol (CHAP)

CHAP is used in nearly every real-world PPP authentication scheme because it offers better security than PAP. CHAP periodically verifies the identity of the remote node and uses the MD5 hash algorithm to encrypt the CHAP process. Therefore, Joe Hacker who has put a sniffer on the line will be unable to decipher what the password is. CHAP uses a three-way handshake occurring in the following sequence:

1. The central rite router issues a challenge to the remote router.

2. The remote router responds to the challenge.

3. The central site router accepts or rejects the connection.

Only three configuration steps are required to configure PPP CHAP authentication:

Step 1. Set the encapsulation type to PPP by on the ISDN interface.

Step 2. Configure CHAP on the interface using the ppp authentication chap command in interface configuration mode.

Step 3. Configure the username and password of the remote ISDN router(s), using the username name password secret in global configuration mode, where name is the host name of the remote router and secret is the secret password. The name is case-sensitive and must match the remote router's host name exactly (and it is case-sensitive). The secret password also must be the same on both routers. If you find that CHAP is failing, one of the first things that you should verify is that the username is specified correctly and that both routers are using the exact same password.

Example 7-9 shows the PPP CHAP configuration for Router 1, and Example 7-10 shows the PPP CHAP configuration for Router 2.

Example 7-9 Example PPP CHAP Configuration: Router 1

 ISDN-1#  show running-config  ! version 12.0 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname ISDN-1 ! !  username ISDN-2 password cisco  ip subnet-zero isdn switch-type basic-dms100 ! ! ! interface Ethernet0  ip address 175.10.2.1 255.255.255.0  no ip directed-broadcast ! interface Serial0  no ip address  no ip directed-broadcast  shutdown  no fair-queue ! interface Serial1  no ip address  no ip directed-broadcast  shutdown ! interface BRI0  ip address 175.10.23.1 255.255.255.248  no ip directed-broadcast  encapsulation ppp   dialer map ip 175.10.23.2 name ISDN-2 broadcast 6129319833  dialer-group 1  isdn switch-type basic-dms100  isdn spid1 61293199371111  isdn spid2 61293199381111  ppp authentication chap  ! no ip classless ! dialer-list 1 protocol ip permit ! ! line con 0  privilege level 15  logging synchronous  transport input none line aux 0 line vty 0 4  login ! end 

Example 7-10 Example PPP CHAP Configuration: Router 2

 ISDN-2#  show running-config  ! version 12.0 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname ISDN-2 ! !  username ISDN-1 password cisco  ip subnet-zero isdn switch-type basic-dms100 ! ! ! interface Ethernet0  ip address 172.16.1.1 255.255.255.0  no ip directed-broadcast ! interface Serial0  no ip address  no ip directed-broadcast  shutdown ! interface Serial1  no ip address  no ip directed-broadcast  shutdown ! interface BRI0  ip address 175.10.23.2 255.255.255.248  no ip directed-broadcast  encapsulation ppp   dialer map ip 175.10.23.1 name ISDN-1 broadcast 6129319937  dialer-group 1  isdn switch-type basic-dms100  isdn spid1 61293198331111  isdn spid2 61293198461111  ppp authentication chap  ! no ip classless ! dialer-list 1 protocol ip permit ! ! line con 0  privilege level 15  logging synchronous  transport input none line aux 0 line vty 0 4  login ! end 

The important configuration commands for CHAP authentication have been highlighted.

Example: Authentication Using an Alternative Host Name

Cisco IOS Software allows you to configure CHAP using a different host name than what the calling router's actual host name is.

When a remote Cisco router connects to either a Cisco or a non-Cisco central router of a different administrative control, an Internet service provider (ISP), or a rotary of central routers, it is necessary to configure an authentication username that is different from the host name. In this situation, the host name of the router is not provided or is different at different times ( rotary ). Also, the username and password that are allocated by the ISP might not be the remote router's host name. In such a situation, the ppp chap hostname command is used to specify an alternate username that will be used for authentication.

For example, consider a situation in which multiple remote devices are dialing into a central site. Using normal CHAP authentication, the username (which would be the host name) of each remote device and a shared secret must be configured on the central router. In this scenario, the configuration of the central router can get lengthy and cumbersome to manage; however, if the remote devices use a username that is different from their host name, this can be avoided. The central site can be configured with a single username and shared secret that can be used to authenticate multiple dial-in clients .

This is done using the ppp chap hostname "alternate-host-name " command:

 ISDN-1(config-if)#  ppp chap  hostname ?  WORD  Alternate CHAP hostname 

On the called router, you need to configure the username/password combination using the alternate host name of the calling router, not the actual host name. Example 7-11 shows the configuration for the calling router, and Example 7-12 shows the configuration for the called router.

Example 7-11 CHAP Alternate Host Name Configuration: Calling Router

 ISDN-1#  show running-config  Building configuration... Current configuration: ! version 12.0 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname ISDN-1 ! username ISDN-2 password cisco ip subnet-zero isdn switch-type basic-dms100 ! interface Ethernet0  ip address 172.16.1.1 255.255.255.0  no ip directed-broadcast ! interface Serial0  no ip address  no ip directed-broadcast  shutdown  no fair-queue ! interface Serial1  no ip address  no ip directed-broadcast  shutdown ! interface BRI0  ip address 175.10.23.1 255.255.255.248  no ip directed-broadcast  encapsulation ppp  dialer map ip 175.10.23.2 name ISDN-2 broadcast 6129319833  dialer-group 1  isdn switch-type basic-dms100  isdn spid1 61293199371111  isdn spid2 61293199381111  ppp authentication chap   ppp chap hostname FAKE_NAME  ! no ip classless ! dialer-list 1 protocol ip permit ! ! line con 0  privilege level 15  logging synchronous  transport input none line aux 0 line vty 0 4  login ! end 

Example 7-12 CHAP Alternate Host Name Configuration: Called Router

 ISDN-2#  show running-config  Building configuration... Current configuration: ! version 12.0 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname ISDN-2 ! !  username FAKE_NAME password cisco  ip subnet-zero isdn switch-type basic-dms100 ! ! ! interface Ethernet0  ip address 172.16.1.1 255.255.255.0  no ip directed-broadcast ! interface Serial0  no ip address  no ip directed-broadcast  shutdown ! interface Serial1  no ip address  no ip directed-broadcast  shutdown ! interface BRI0  ip address 175.10.23.2 255.255.255.248  no ip directed-broadcast  encapsulation ppp  dialer map ip 175.10.23.1 name ISDN-1 broadcast 6129319937  dialer-group 1  isdn switch-type basic-dms100  isdn spid1 61293198331111  isdn spid2 61293198461111  ppp authentication chap  ! no ip classless ! dialer-list 1 protocol ip permit ! ! line con 0  privilege level 15  logging synchronous  transport input none line aux 0 line vty 0 4  login ! end 

In this example, the calling router has been authenticated by the called router with a host name of FAKENAME, even though the router's actual host name is ISDN-1. You can see this process with the debug ppp authentication command in Example 7-13.

Example 7-13 Calling Router Authentication Verification

 ISDN-1#  debug  ppp authentication  PPP authentication debugging is on ISDN-1#  ping 175.10.23.2  Type escape sequence to abort.  Sending 5, 100-byte ICMP Echos to 175.10.23.2, timeout is 2 seconds:  .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 40/41/44 ms ISDN-1# 08:38:29: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up 08:38:29: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 6129319833 08:38:29: BR0:1 PPP: Treating connection as a callout 08:38:30: BR0:1 PPP: Phase is AUTHENTICATING, by both 08:38:30: BR0:1 CHAP: Using alternate hostname FAKE_NAME 08:38:30: BR0:1 CHAP: O CHALLENGE id 8 len 30 from "FAKE_NAME" 08:38:30: BR0:1 CHAP: I CHALLENGE id 8 len 27 from "ISDN-2" 08:38:30: BR0:1 CHAP: Using alternate hostname FAKE_NAME 08:38:30: BR0:1 CHAP: O RESPONSE id 8 len 30 from "FAKE_NAME" 08:38:30: BR0:1 CHAP: I SUCCESS id 8 len 4 08:38:30: BR0:1 CHAP: I RESPONSE id 8 len 27 from "ISDN-2" 08:38:30: BR0:1 CHAP: O SUCCESS id 8 len 4 08:38:31: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to up ISDN-1# 

Note the timeout of the first ICMP ping packet. This was because of the time it took for the ISDN call negotiation and connection process.

Example: Using PPP to Authenticate on Incoming Calls Only ”Configuring Unidirectional CHAP Authentication

When two devices normally use CHAP authentication, each side sends out a challenge, to which the other side responds and is authenticated by the challenger. Each side authenticates one another independently. If you want to operate with non-Cisco routers that do not support authentication by the calling router or device, you must use the ppp authentication chap callin command. When using the ppp authentication command with the callin keyword, the access server authenticates the remote device only if the remote device initiated the call (for example, if the remote device "called in"). In this case, authentication is specified on incoming (received) calls only.

As depicted in Table 7-2, if Router 1 initiates a call to Router 2, Router 2 would challenge Router 1, but Router 1 would not challenge Router 2. This occurs because the ppp authentication chap callin command is configured on Router 1. This is an example of a unidirectional authentication.

Table 7-2. Unidirectional Authentication

Router 1		Router 2
	Router 1 calls Router 2 --->
	<--- Router 2 challenges Router 1
Router 1 does not challenge Router 2 because it is configured for one-way authentication.

Example: Using PPP Link Quality

PPP link quality was covered in Chapter 4. It is important to note that this feature also applies to ISDN interfaces, as long as they are configured with PPP encapsulation.

Additional Optional Parameters: Link Quality Monitoring (LQM)

Link Quality Monitoring (LQM) is available on all serial interfaces running PPP. LQM monitors the link quality. If the quality drops below a configured percentage, the router shuts down the link. The percentages are calculated for both the incoming and the outgoing directions. The outgoing quality is calculated by comparing the total number of packets and bytes sent with the total number of packets and bytes received by the destination node. The incoming quality is calculated by comparing the total number of packets and bytes received with the total number of packets and bytes sent by the destination peer.

When LQM is enabled, Link Quality Reports (LQRs) are sent in place of keepalives every keepalive period. All incoming keepalives are responded to properly. If LQM is not configured, keepalives are sent every keepalive period and all incoming LQRs are responded to with an LQR. LQR is specified in RFC 1989, "PPP Link Quality Monitoring," by William A. Simpson of Computer Systems Consulting Services. To enable LQM on the interface, use the ppp quality percentage command in interface configuration mode.

The percentage argument specifies the link quality threshold. That percentage must be maintained , or the link is deemed to be of poor quality and is taken down. The percentages are calculated for both incoming and outgoing directions. The outgoing quality is calculated by comparing the total number of packets and bytes sent to the total number of packets and bytes received by the peer. The incoming quality is calculated by comparing the total number of packets and bytes received to the total number of packets and bytes sent by the peer.

If the link quality percentage is not maintained, the link is deemed to be of poor quality and is taken down. The policy implements a time lag so that the link does not bounce up and down.

Additional Optional Parameters: ISDN Call Screening

Besides CHAP and PAP authentication, there are alternate ways to authenticate incoming ISDN calls. Authentication based on caller ID provides even greater security than the methods described before by authenticating remote clients based not only on user ID and password, but also on dialing location. Caller ID allows the initial incoming call from the client to the server to be accepted or rejected based on the caller ID message contained in the ISDN setup message. Caller ID is not available everywhere, so be sure to check with the ISDN provider if you want to implement this feature in your network.

Only one command is needed to configure ISDN call screening. For Legacy DDR,

  isdn caller   remote-number  [  callback  ] 

For dialer profil es,

  dialer-caller   remote-number  [  callback  ] 

The callback option tells the router to terminate the incoming call and call back the router that originally placed the call. Callback is covered in the next section.

Example 7-14 shows how to configure caller screening.

Example 7-14 Call Screening

  interface BRI 0   isdn caller 6129319937  

This command can be repeated for each number that will be allowed to dial in. The Cisco IOS software also allows you to configure "don't care" digits in the remote number, using the letter x. For example, to allow all incoming calls from the 952 area code, you would use the isdn caller 952xxxxxxx command. You must use one x for each digit that you don't care about. The command isdn caller 952x is not the same as isdn caller 952xxxxxxx. The first command allows only four-digit numbers starting with 952, whereas the second command allows all seven-digit numbers starting with 952.

Use the debug ISDN event to troubleshoot ISDN call screening.

Additional Optional Parameters: ISDN Callback

Callback is a useful feature for networks that want to maintain a central location for all outgoing ISDN calls for billing or other business purposes. The callback feature (introduced in Cisco IOS Software Release 11.0) allows a remote router to place a call to the central site router requesting that the central site router call back the remote router. Then, the central site router disconnects the call and places a return call to the remote location. With callback configured, the ISDN bill is reduced at the remote sites because actual data transfers occur when the central office router calls back. Example 7-15 and 7-16 show the configuration for ISDN callback for the Remote Site and Headquarter routers, respectively.

NOTE

Callback relies on PPP authentication, so PAP or CHAP authentication must be configured for callback to work.

Example 7-15 ISDN Callback Configuration: Remote Site Router

 Remote_Site#  show running-config  Building configuration... Current configuration: ! version 12.0 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname Remote_Site ! ! username Headquarters password 0 cisco ip subnet-zero isdn switch-type basic-dms100 ! ! ! interface Ethernet0  ip address 172.16.1.1 255.255.255.0  no ip directed-broadcast ! interface Serial0  ip address 175.10.50.1 255.255.255.252  no ip directed-broadcast  no fair-queue  clockrate 125000 ! interface Serial1  ip address 175.10.1.1 255.255.255.252  no ip directed-broadcast ! interface BRI0  ip address 175.10.23.1 255.255.255.248  no ip directed-broadcast  encapsulation ppp  dialer wait-for-carrier-time 10  dialer map ip 175.10.23.2 name Headquarters broadcast 6129319833  dialer hold-queue 100 timeout 10  dialer-group 1  isdn switch-type basic-dms100  isdn spid1 61293199371111  isdn spid2 61293199381111  ppp callback request   ppp authentication chap  ! no ip classless ! dialer-list 1 protocol ip permit ! ! line con 0  privilege level 15  logging synchronous  transport input none line aux 0 line vty 0 4  login ! end ________________________________________________________________________ 

Example 7-16 ISDN Callback Configuration: Headquarters Router

 Headquarters#  show running-config  Building configuration... Current configuration: ! version 12.0 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname Headquarters ! ! username Remote_Site password 0 cisco ip subnet-zero isdn switch-type basic-dms100 ! ! ! interface Ethernet0  ip address 172.16.1.1 255.255.255.0  no ip directed-broadcast ! interface Serial0  ip address 175.10.50.2 255.255.255.252  no ip directed-broadcast ! interface Serial1  ip address 175.10.1.2 255.255.255.252  no ip directed-broadcast  clockrate 125000 ! interface BRI0  ip address 175.10.23.2 255.255.255.248  no ip directed-broadcast  encapsulation ppp  dialer callback-secure   dialer enable-timeout 5   dialer map ip 175.10.23.1 name Remote_Site class callback 6129319937  dialer hold-queue 100  dialer-group 1  isdn switch-type basic-dms100  isdn spid1 61293198331111  isdn spid2 61293198461111  ppp callback accept   ppp authentication chap  ! no ip classless ! !  map-class dialer callback   dialer callback-server username  dialer-list 1 protocol ip permit ! ! line con 0  privilege level 15  logging synchronous  transport input none line aux 0 line vty 0 4  login ! end 

When an incoming call arrives and the callback router finds a best match configured for callback, the router uses the value configured by the dialer enable-timeout command to determine the length of time to wait before making the callback.

The minimum value of the timer is 1 second; the default value of the timer is 15 seconds. The interval set for this feature on this router must be much less than that set for DDR fast call rerouting for ISDN (that interval is set by the dialer wait-for-carrier command) on the calling (remote) side. Cisco recommends setting the dialer wait-for-carrier timer on the calling side to twice the length of the dialer enable-timeout timer on the callback side. In the example, we have set the dialer enable-timeout to 5 seconds on the Headquarters router, and the dialer wait-for-carrier timer to 10 seconds on the Remote_Site router.

The dialer callback-server map class configuration command allows the interface to return calls when callback successfully is negotiated. The username keyword specifies that the interface is to locate the dial string for making the return call by looking up the authenticated host name in a dialer map command.

The dialer map interface configuration command has been modified to include the class keyword and the name of the class, as specified in the map-class command. The name keyword is required so that when the Remote_Site router dials in, the interface can locate this dialer map statement and obtain the dial string for calling back the Remote_Site's router. Example 7-17 illustrates how to utilize dialer debugging to verify the callback configuration.

Example 7-17 Verifying the Callback Configuration

 Remote_Site#  debug dialer  Dial on demand events debugging is on Remote_Site#  ping 175.10.23.2  Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 175.10.23.2, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) Remote_Site# 00:30:08: BR0 DDR: Dialing cause ip (s=175.10.23.1, d=175.10.23.2) 00:30:08: BR0 DDR: Attempting to dial 6129319833 00:30:08: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up 00:30:08: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 6129319833  00:30:08: BR0:1 DDR: Callback negotiated - waiting for server disconnect  00:30:09: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down  00:30:09: DDR: Callback client for Headquarters 9529319833 created   00:30:09: BR0:1 DDR: disconnecting call   00:30:09: BR0:1 DDR: disconnecting call  00:30:14: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up 00:30:14: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 6129319833 00:30:16: BR0:1 DDR: No callback negotiated 00:30:16: BR0:1 DDR: dialer protocol up  00:30:16:  BR0:1 DDR: Callback received from Headquarters 6129319833  00:30:16: DDR: Freeing callback to Headquarters 6129319833 00:30:16: BR0:1 DDR: Call connected, 4 packets unqueued, 4 transmitted, 0 discar ded 00:30:17: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to up 00:30:20: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 6129319833 Headquarters Remote_Site#  ping 175.10.23.2  Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 175.10.23.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 44/44/44 ms _________________________________________________________________________________ Headquarters#  show dialer  BRI0 - dialer type = ISDN Dial String      Successes   Failures    Last called   Last status 6129319937               4          0    00:00:10       successful 0 incoming call(s) have been screened. 0 incoming call(s) rejected for callback. BRI0:1 - dialer type = ISDN Idle timer (120 secs), Fast idle timer (20 secs) Wait for carrier (30 secs), Re-enable (5 secs) Dialer state is data link layer up  Dial reason: Callback return call  Time until disconnect 111 secs Connected to 6129319937 (Remote_Site) 

Here, you can see that the first five ping s were unsuccessful . This is because of the amount of time that it took for the Headquarters router to disconnect the incoming call and then call back the Remote_Site router. After this process was completed, the ping s were successful. The callback process can be seen when issuing the debug dialer command. The show dialer command on the Headquarters router clearly shows that the reason for its call was "Callback return call." The debug dialer and show dialer commands are useful methods of verifying that the routers are properly configured for ISDN callback.

Additional Optional Parameters: Using PPP Multilink

Multilink PPP is a feature that allows traffic to be load balanced over multiple WAN links. When enabled, the multiple physical links are bonded together and are seen as one logical link . In the case of ISDN, you can configure multiple B channels to come up to act as one large traffic pipe. The multiple links come up in response to a user-defined threshold using the dialer load-threshold command. This threshold can be defined based on inbound or outbound traffic, or either. It is a value from 1 to 255, where 1 means that the second BRI channel should come up almost immediately when the ISDN link is up, and 255 means that the second BRI channel should come up only when the first channel is completely saturated . For example, if you want to have the second B channel bond to the first when the load is 50 percent utilized, you would use the command dialer load-threshold 127 (255 x .50 = 127, after rounding up). Configuring multilink PPP requires the following commands used under interface mode:

  encapsulation ppp   dialer load-threshold   load   ppp multilink  

Example 7-18 shows an example configuration using PPP multilink.

Example 7-18 PPP Multilink Configuration:

 Remote_Site#  show running-config  Building configuration... Current configuration: ! version 12.0 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname Remote_Site ! ! username Headquarters password 0 cisco ip subnet-zero isdn switch-type basic-dms100 ! ! ! interface Loopback0  ip address 175.10.101.1 255.255.255.255  no ip directed-broadcast ! interface Ethernet0  ip address 175.10.2.1 255.255.255.0  no ip directed-broadcast  no keepalive ! interface Serial0  no ip address  no ip directed-broadcast  shutdown  no fair-queue  clockrate 125000 ! interface Serial1  description PRIMARY LINK TO HQ  ip address 175.10.200.1 255.255.255.252  no ip directed-broadcast ! interface BRI0  ip address 175.10.23.1 255.255.255.248  no ip directed-broadcast  encapsulation ppp  dialer map ip 175.10.23.2 name Headquarters broadcast 6129319833  dialer load-threshold 25 either  dialer-group 1  isdn switch-type basic-dms100  isdn spid1 61293199371111  isdn spid2 61293199381111  ppp multilink  ! router eigrp 1  network 175.10.0.0  no auto-summary ! no ip classless ! access-list 101 deny   eigrp any any access-list 101 permit ip any any dialer-list 1 protocol ip list 101 ! ! line con 0  privilege level 15  logging synchronous  transport input none line aux 0 line vty 0 4  login ! end 

Here, it is specified that both B channels should be used after the first B channel has exceeded a threshold of approximately 10 percent in either outbound or inbound traffic (255 [ts\x .10 is close to 25), not 25 percent.

You can verify the multilink PPP configuration by issuing the show dialer command. In Example 7-19, the router is made to initiate an ISDN connection by simply ping ing the other side of the link.

Example 7-19 Verifying the Multilink PPP Configuration

 Remote_Site#  ping 175.10.23.2  Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 175.10.23.2, timeout is 2 seconds: .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 44/45/48 ms Remote_Site#  show dialer  BRI0 - dialer type = ISDN Dial String      Successes   Failures    Last called   Last status 6129319833              29         62    00:00:06       successful 0 incoming call(s) have been screened. 0 incoming call(s) rejected for callback. BRI0:1 - dialer type = ISDN Idle timer (120 secs), Fast idle timer (20 secs) Wait for carrier (30 secs), Re-enable (15 secs)  Dialer state is multilink member   Dial reason: ip (s=175.10.23.1, d=175.10.23.2)  Connected to 6129319833 (Headquarters) BRI0:2 - dialer type = ISDN Idle timer (120 secs), Fast idle timer (20 secs) Wait for carrier (30 secs), Re-enable (15 secs)  Dialer state is idle  

You can see that the ISDN connection was made successfully and that the first B channel is indeed a multilink member. However, the second B channel still shows that it is idle and was not bonded to the first B channel. The reason for this is that the simple ping s that traversed the link were not sufficient to exceed the 10 percent load that is required in this case.

To see what the load is for the first B channel, issue the show interface bri0 1 command, as demonstrated in Example 7-20.

Example 7-20 Displaying the Load for the First B Channel

 Remote_Site#  show interface bri 0 1  BRI0:1 is up, line protocol is up   Hardware is BRI  MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 3/255  Encapsulation PPP, loopback not set, keepalive set (10 sec)   LCP Open, multilink Open   Last input 00:00:05, output 00:00:05, output hang never   Last clearing of "show interface" counters never   Queueing strategy: fifo   Output queue 0/40, 0 drops; input queue 0/75, 0 drops   5 minute input rate 1000 bits/sec, 1 packets/sec   5 minute output rate 1000 bits/sec, 1 packets/sec      4183 packets input, 2365973 bytes, 0 no buffer      Received 0 broadcasts, 0 runts, 0 giants, 0 throttles      0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort      4342 packets output, 2396289 bytes, 0 underruns      0 output errors, 0 collisions, 33 interface resets      0 output buffer failures, 0 output buffers swapped out      210 carrier transitions 

You can plainly see that the load on this B channel is only at 3/255. In this configuration, the second B channel will come up only after the first B channel has exceeded a load of 25/255, or approximately 10 percent.

You will need to create some more traffic to actually bring up both B channels in this configuration. You can do this by using the extended ping command, as demonstrated in Example 7-21.

Example 7-21 Creating Additional Traffic to Bring Up Both B Channels

 Remote_Site#  ping  Protocol [ip]: Target IP address: 175.10.23.2 Repeat count [5]: 100 Datagram size [100]: 1500 Timeout in seconds [2]: Extended commands [n]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 100, 1500-byte ICMP Echos to 175.10.23.2, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!! Success rate is 100 percent (100/100), round-trip min/avg/max = 212/359/428 ms 

Now, issue the same show int bri0 1 command to check the load on the interface, as done in Example 7-22.

Example 7-22 Displaying the Load for Both B Channels

 Remote_Site#  show int bri0 1  BRI0:1 is up, line protocol is up   Hardware is BRI  MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 27/255  Encapsulation PPP, loopback not set, keepalive set (10 sec)   LCP Open, multilink Open   Last input 00:00:04, output 00:00:04, output hang never   Last clearing of "show interface" counters never   Queueing strategy: fifo   Output queue 0/40, 0 drops; input queue 0/75, 0 drops   5 minute input rate 8000 bits/sec, 5 packets/sec   5 minute output rate 7000 bits/sec, 4 packets/sec      4452 packets input, 2579061 bytes, 0 no buffer      Received 0 broadcasts, 0 runts, 0 giants, 0 throttles      0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort      4611 packets output, 2611177 bytes, 0 underruns      0 output errors, 0 collisions, 33 interface resets      0 output buffer failures, 0 output buffers swapped out      212 carrier transitions 

You can see that the load has reached 27/255, so the second B channel should have been brought up to bond with the first B channel. There are a couple of ways to verify that this has indeed happened : using the show dialer and the show ppp multilink commands, as demonstrated in Example 7-23.

Example 7-23 Verifying a Second B Channel with the show dialer command

 Remote_Site#  show dialer  BRI0 - dialer type = ISDN Dial String      Successes   Failures    Last called   Last status 6129319833              32         62    00:00:55       successful 0 incoming call(s) have been screened. 0 incoming call(s) rejected for callback. BRI0:1 - dialer type = ISDN Idle timer (120 secs), Fast idle timer (20 secs) Wait for carrier (30 secs), Re-enable (15 secs)  Dialer state is multilink member   Dial reason: ip (s=175.10.23.1, d=175.10.23.2)  Connected to 6129319833 (Headquarters) BRI0:2 - dialer type = ISDN Idle timer (120 secs), Fast idle timer (20 secs) Wait for carrier (30 secs), Re-enable (15 secs)  Dialer state is multilink member   Dial reason: Multilink bundle overloaded  Connected to 6129319833 (Headquarters) 

Both channels are indeed in use, and the second B channel shows that the dial reason was because of a PPP multilink overload.

Example 7-24 shows how to verify the PPP multilink configuration.

Example 7-24 Verifying a Second B Channel with the show ppp multilink Command

 ISDN-1#  show ppp multilink  Bundle ISDN-2, 2 members, Master link is Virtual-Access1 Dialer Interface is BRI0   0 lost fragments, 0 reordered, 0 unassigned, sequence 0xF8/0xF8 rcvd/sent   0 discarded, 0 lost received, 1/255 load  Member Links: 2 (max not set, min not set)   BRI0:1   BRI0:2  

Here, both B channels are listed as PPP multilink members.

In this case, we sent 100 1500-byte ICMP packets across the link. This was enough to bring up the secondary B channel. Both B channels were bonded to form one large virtual circuit.

Step 5: Routing Traffic over ISDN

As stated previously, there are a number of ways to ensure that traffic is routed over the ISDN interface. You want to be able to route traffic over the ISDN link when it is up, but you normally do not want this routing traffic to cause it to stay up indefinitely. One important configuration option that you should be aware of is the passive-interface routing command. Passive interfaces listen to incoming routing updates but will not advertise any routing information out that interface. This is particularly effective for dial-on-demand interfaces because you can suppress the routing information from causing unnecessary connections. This command is done under the routing process and is valid for nearly every routing protocol. Example 7-25 shows an example using EIGRP.

Example 7-25 Defining a Passive Interface

  router eigrp 1   passive-interface BRI0   network 175.10.0.0   no auto-summary  

If the passive-interface BRI0 command is not used, the ISDN link continuously would connect as routing updates are passed. This assumes that the broadcast keyword is on the dialer map statement. The broadcast keyword also will pass any multicast traffic that is often used by routing protocols.

The majority of real-world applications use floating static routes for routing over ISDN so that when the primary link fails, the ISDN interface comes up. However, numerous other equally successful methods enable you to control routing information over an ISDN network, including the following:

• Floating static routes

• OSPF demand circuit

• Dialer watch

• Backup interface

• Backup load

• Snapshot routing

Example: Floating Static Routes

A floating static route is simply a static route with a higher administrative distance than that of the routing protocols, which is tagged at the end of the ip route command. Each routing protocol has a different administrative distance associated with it. An administrative distance is simply the degree of reliability, or cost, of the route. The lower the distance is, the more reliable the routing information is for the specified routes. If a router knows about a route from more than one means, the route with the lowest administrative distance wins out. Table 7-3 shows the default administrative distances for connected interfaces, static routes, and routing protocols.

Table 7-3. Default Administrative Distances

Protocol	Default Administrative Distance
Connected interface
Static route	1
Enhanced Interior Gateway Routing Protocol (EIGRP) summary route	5
External Border Gateway Protocol (BGP)	20
Internal EIGRP	90
IGRP	100
OSPF	110
Intermediate System-to-Intermediate System (IS-IS)	115
Routing Information Protocol (RIP)	120
Exterior Gateway Protocol (EGP)	140
External EIGRP	170
Internal BGP	200
Unknown	255

A static route becomes floating when it is assigned a higher AD than that of the routing protocols. It is called "floating" because when a route known through some other means goes away, the floating static route "floats" to the top and is used by the router. For example, if you use the command ip route 10.1.1.0 255.255.255.0 BRI 0 200, you have manually assigned an AD of 200 to this route. The router routes packets to 10.1.1.0/24 through the BRI 0 interface only if it knows of no other way to reach this subnet. This is useful when you want to use the ISDN network to route traffic only if the primary link has failed. This is the most common real-world method used to configure ISDN to back up a primary link failure. Figure 7-6 shows a simple network between the two routers Cheech and Chong. In this case, Frame Relay is used as the primary communication link between the two routers, with the ISDN link being used as a backup method only.

Figure 7-6. Floating Static Route Example

In this scenario, you want to maintain connectivity between users on the Ethernet segments between the two locations. Example 7-26 shows the configuration for the proper use of floating static routes in this scenario.

Example 7-26 Floating Static Route Configuration

 Cheech#  show running-config  Building configuration... Current configuration: ! version 11.2 no service password-encryption no service udp-small-servers no service tcp-small-servers ! hostname Cheech ! enable password cisco ! username Chong password 0 cisco isdn switch-type basic-dms100 ! interface Loopback0  ip address 175.10.2.2 255.255.255.0 ! interface Ethernet0  ip address 175.10.22.1 255.255.255.0  no keepalive  no mop enabled ! interface Serial0  ip address 175.10.123.1 255.255.255.0  encapsulation frame-relay  frame-relay map ip 175.10.123.2 300 broadcast ! interface Serial1  no ip address  shutdown ! interface BRI0  ip address 175.10.23.1 255.255.255.0  encapsulation ppp  isdn spid1 61293199371111  isdn spid2 61293199381111  dialer map ip 175.10.23.2 broadcast 6129319833  dialer-group 1  no fair-queue  ppp authentication chap ! router eigrp 1  passive-interface BRI0  network 175.10.0.0  no auto-summary ! ip classless  ip route 175.10.35.0 255.255.255.0 175.10.23.2 200  ! dialer-list 1 protocol ip permit ! line con 0  exec-timeout 0 0  privilege level 15  logging synchronous line aux 0 line vty 0 4  password cisco  login ! end _______________________________________________________________________ Chong#  show running-config  Building configuration... Current configuration: ! version 11.2 no service password-encryption no service udp-small-servers no service tcp-small-servers ! hostname Chong ! enable password cisco ! username Cheech password 0 cisco isdn switch-type basic-dms100 ! interface Loopback0  ip address 175.10.3.3 255.255.255.0 ! interface Ethernet0  ip address 175.10.35.3 255.255.255.0 ! interface Serial0  no ip address  encapsulation frame-relay  no fair-queue ! interface Serial0.1 point-to-point  ip address 175.10.123.2 255.255.255.0  frame-relay interface-dlci 200 ! interface Serial0.2 point-to-point  ip address 175.10.134.2 255.255.255.252  shutdown  frame-relay interface-dlci 400 ! interface Serial1  no ip address  shutdown ! interface BRI0  ip address 175.10.23.2 255.255.255.0  encapsulation ppp  isdn spid1 61293198331111  isdn spid2 61293198461111 dialer map ip 175.10.23.1 broadcast 6129319937 dialer-group 1  no fair-queue  ppp authentication chap ! router eigrp 1  passive-interface BRI0  network 175.10.0.0  no auto-summary ! no ip classless  ip route 175.10.22.0 255.255.255.224 175.10.23.1 200  ! dialer-list 1 protocol ip permit ! line con 0  exec-timeout 0 0  privilege level 15  logging synchronous line aux 0 line vty 0 4  password cisco  login ! end 

You have made the BRI0 interfaces passive under the EIGRP processes. This was needed to keep the routing updates from initiating calls and keeping up the link indefinitely. Because the dialer list specifies all IP packets as interesting, EIGRP multicast updates would have brought the ISDN link up. An alternative to using the passive-interface command is to use a more restrictive dialer list that denies EIGRP packets.

Example: OSPF Demand Circuit

As the name implies, an OSPF demand circuit enables the ISDN link to work through the OSPF protocol. This topic was introduced in Chapter 12, demand circuits suppress the OSPF hello packets from traversing the ISDN link, and ISDN calls initiate only after a logical topology change. Without this feature, these hello packets can keep the link up indefinitely. This feature is enabled through the following single interface command:

 ISDN_Router#  config term  ISDN_Router(config)#  int bri0  ISDN_Router(config-if)#  ip ospf demand-circuit  

This seems simple enough, right? In most situations, it is. However, keep in mind that when a change in the OSPF link-state database occurs, an ISDN call is made. Therefore, in certain situations, such as when you are redistributing other protocols into OSPF, you must be careful in how you implement the redistribution, to avoid routing loops that will cause these link-state changes to occur constantly. You will see an example of this soon in the advanced practice labs when you need to do more than simply add the ip ospf demand-circuit command to make this work properly. Figure 7-7 shows the reference network that we will use to illustrate the proper configuration for setting up the OSPF demand circuit.

Figure 7-7. Example OSPF Demand Circuit Configuration

Example 7-27 shows the configuration for both the Headquarters and Remote Site routers.

Example 7-27 OSPF Demand Circuit Configuration

 Remote_Site#  show running-config  Building configuration... Current configuration: ! version 12.0 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname Remote_Site ! ! username Headquarters password 0 cisco ip subnet-zero isdn switch-type basic-dms100 ! ! ! interface Loopback0  ip address 175.10.101.1 255.255.255.255  no ip directed-broadcast ! interface Ethernet0  ip address 175.10.2.1 255.255.255.0  no ip directed-broadcast  no keepalive ! interface Serial0  no ip address  no ip directed-broadcast  shutdown  no fair-queue ! interface Serial1  description PRIMARY LINK TO HQ  ip address 175.10.200.1 255.255.255.252  no ip directed-broadcast  bandwidth 64  ! interface BRI0  ip address 175.10.23.1 255.255.255.248  no ip directed-broadcast  encapsulation ppp  ip ospf demand-circuit   ip ospf cost 9999  dialer map ip 175.10.23.2 name Headquarters broadcast 6129319833  dialer-group 1  isdn switch-type basic-dms100  isdn spid1 61293199371111  isdn spid2 61293199381111 !  router ospf 1   network 175.10.0.0 0.0.255.255 area 0  ! no ip classless ! dialer-list 1 protocol ip permit ! ! line con 0  privilege level 15  logging synchronous  transport input none line aux 0 line vty 0 4  login ! end _______________________________________________________________________ Headquarters#  show running-config  Building configuration... Current configuration: ! version 12.0 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname Headquarters ! logging buffered 9096 debugging ! username Remote_Site password 0 cisco ip subnet-zero isdn switch-type basic-dms100 ! ! ! interface Loopback0  ip address 175.10.102.1 255.255.255.255  no ip directed-broadcast ! interface Ethernet0  ip address 175.10.1.1 255.255.255.0  no ip directed-broadcast  no keepalive ! interface Serial0  no ip address  no ip directed-broadcast  shutdown ! interface Serial1  description PRIMARY LINK TO REMOTE SITE  ip address 175.10.200.2 255.255.255.252  no ip directed-broadcast  clockrate 64000  bandwidth 64  ! interface BRI0  ip address 175.10.23.2 255.255.255.248  no ip directed-broadcast  encapsulation ppp  dialer-group 1  isdn switch-type basic-dms100  isdn spid1 61293198331111  isdn spid2 61293198461111 ! router ospf 1  network 175.10.0.0 0.0.255.255 area 0 ! no ip classless ! dialer-list 1 protocol ip permit ! ! line con 0  privilege level 15  logging synchronous  transport input none line aux 0 line vty 0 4  login ! end 

The ip ospf demand circuit configuration command in interface mode tells the router to not send hello packets out that interface. Without it, the OSPF hellos will keep the link up. Example 7-28 shows the output from the show ip ospf interface bri0 command.

Example 7-28 Using the show ip ospf interface Command

 Remote_Site#  show ip ospf interface bri0  BRI0 is up, line protocol is up (spoofing)   Internet Address 175.10.23.1/29, Area 0   Process ID 1, Router ID 175.10.101.1, Network Type POINT_TO_POINT, Cost: 9999   Configured as demand circuit.   Run as demand circuit.   DoNotAge LSA allowed.   Transmit Delay is 1 sec, State POINT_TO_POINT,   Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5     Hello due in 00:00:01  Neighbor Count is 1, Adjacent neighbor count is 1   Adjacent with neighbor 175.10.102.1  (Hello suppressed)   Suppress hello for 1 neighbor(s)  

You can see that OSPF has formed a neighbor adjacency with the Headquarters router and is suppressing the hello packets for the BRI 0 interface.

In this network, the primary link is a 64-kbps point-to-point circuit. As you will learn in the OSPF section of this book, it is generally a good idea to explicitly state the actual bandwidth of each interface that OSPF has been enabled on, which is why you used the bandwidth 64 command on the Serial 1 interface of each router. This is because the metric used in OSPF is cost, which is calculated as 100,000,000/bandwidth.

Unless you actually state what the bandwidth is for the serial interface, OSPF assumes that it is a full T1 and incorrectly gives the interface an OSPF cost of 64. For ISDN interfaces, OSPF assumes that the link is 64 kbps and assigns it a cost of 1562. This can be seen with the show ip ospf interface bri0 command, as demonstrated in Example 7-29.

Example 7-29 Assigning a Cost to an ISDN Interface in an OSPF Environment

 Remote_Site#  show ip ospf int bri0  BRI0 is up, line protocol is up (spoofing)   Internet Address 175.10.23.1/29, Area 0  Process ID 1, Router ID 175.10.101.1, Network Type POINT_TO_POINT, Cost: 1562  Configured as demand circuit.   Run as demand circuit.   DoNotAge LSA allowed.   Transmit Delay is 1 sec, State POINT_TO_POINT,   Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5     Hello due in 00:00:03   Neighbor Count is 1, Adjacent neighbor count is 1  Adjacent with neighbor 175.10.102.1  (Hello suppressed)   Suppress hello for 1 neighbor(s)  

Notice that the OSPF hello packets are being suppressed and will not be sent over the ISDN network.

The problem here is that now OSPF has assigned a cost of 1562 to both the Serial 1 and BRI interfaces. It now sees these links as equal-cost path , and traffic is load balanced across both links. This causes the ISDN link to stay up indefinitely. To remedy this, it is usually a good idea to assign an artificially high OSPF cost to the BRI interfaces, ensuring that traffic is routed over this link only after the alternate paths are down.

In this example, a cost of 9999 has been assigned to the ISDN link by issuing the ip ospf cost 9999 command. This actual cost that you implement doesn't really matter, but it needs to be high enough that OSPF will not prefer the backup ISDN link.

Under normal circumstances, the routing table should look like Example 7-30.

Example 7-30 Testing the OSPF Demand Circuit Configuration

 Remote_Site#  show ip route  Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP        D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area        N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2        E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP        i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default        U - per-user static route, o - ODR Gateway of last resort is not set      175.10.0.0/16 is variably subnetted, 6 subnets, 4 masks C       175.10.200.0/30 is directly connected, Serial1 O       175.10.1.0/24 [110/1572] via 175.10.200.2, 00:00:39, Serial1 C       175.10.2.0/24 is directly connected, Ethernet0 C       175.10.23.0/29 is directly connected, BRI0 C       175.10.101.1/32 is directly connected, Loopback0 O       175.10.102.1/32 [110/1563] via 175.10.200.2, 00:00:39, Serial1 Remote_Site#ping 175.10.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 175.10.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 16/18/20 ms 

Now, you will administratively shut down the Serial 1 interface and verify that you still have connectivity to the Headquarters router, as demonstrated in Example 7-31.

Example 7-31 Testing the ISDN Backup with the Primary Link Shut Down

 Remote_Site#  conf t  Enter configuration commands, one per line.  End with CNTL/Z. Remote_Site(config)#int s1 Remote_Site(config-if)#shut Remote_Site(config-if)# 3d03h: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up Remote_Site(config-if)#end Remote_Site# 3d03h: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 6129319833 3d03h: %LINK-5-CHANGED: Interface Serial1, changed state to administratively down n 3d03h: %SYS-5-CONFIG_I: Configured from console by console 3d03h: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to up 3d03h: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to  down Remote_Site# 3d03h: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 6129319833 Headquarters Remote_Site#sho ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP        D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area        N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2        E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP        i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default        U - per-user static route, o - ODR Gateway of last resort is not set      175.10.0.0/16 is variably subnetted, 6 subnets, 3 masks O       175.10.1.0/24 [110/10009] via 175.10.23.2, 00:00:06, BRI0 C       175.10.2.0/24 is directly connected, Ethernet0 C       175.10.23.2/32 is directly connected, BRI0 C       175.10.23.0/29 is directly connected, BRI0 C       175.10.101.1/32 is directly connected, Loopback0 O       175.10.102.1/32 [110/10000] via 175.10.23.2, 00:00:06, BRI0 Remote_Site#ping 175.10.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 175.10.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 40/43/44 ms 

Because OSPF detected a topology change in the network, it initiated a connection. If you issue the show dialer command as demonstrated in Example 7-32, you can see that the reason for the ISDN call was IP traffic to the destination of 224.0.0.5. This is the multicast address used in OSPF.

Example 7-32 show dialer Command Reveals the Reason for an ISDN Call

 Remote_Site#  show dialer  BRI0 - dialer type = ISDN Dial String      Successes   Failures    Last called   Last status 6129319833              44         62    00:01:55       successful 0 incoming call(s) have been screened. 0 incoming call(s) rejected for callback. BRI0:1 - dialer type = ISDN Idle timer (120 secs), Fast idle timer (20 secs) Wait for carrier (30 secs), Re-enable (15 secs) Dialer state is data link layer up  Dial reason: ip (s=175.10.23.1, d=224.0.0.5)  Time until disconnect 49 secs Connected to 6129319833 (Headquarters) BRI0:2 - dialer type = ISDN Idle timer (120 secs), Fast idle timer (20 secs) Wait for carrier (30 secs), Re-enable (15 secs) Dialer state is idle 

When the primary link is restored, the ISDN connection tears down after the dialer idle timeout period has occurred. It can be easy to create routing loops in your network, especially when multiple routes are being redistributed. It is important to use filtering to ensure that these loops do not cause unnecessary ISDN connections.

Example: Dialer Watch

Dialer watch became a feature with Cisco IOS Software Release 11.3(2)T. It works by having the IOS "watch" the routing table to keep track of a number of user-defined routes. When one or more of the routes in the dialer watch list are removed from the routing table, an ISDN connection is initiated. The speed and effectiveness of implementing dialer watch depends on the convergence times and characteristics of the routing protocol used. EIGRP works best and normally is implemented with dialer watch, although dialer watch also is supported using OSPF and IGRP.

Dialer watch uses the ISDN network as a backup means to provide reliable connectivity between remote locations. Dialer watch monitors the routing table and initiates calls when the primary link fails and one of the routes defined in the dialer watch list is removed from the routing table. It does this in the following sequence:

1. When a watched route is deleted, dialer watch checks for at least one valid route for any of the watched IP addresses defined.

2. If there is no valid route, the primary line is considered down and unusable.

3. If there is a valid route for at least one of the defined watched IP addresses and the route is pointing to an interface other than the backup interface configured for dialer watch, the primary link is considered up. For example, if a site remote site has two Frame Relay PVCs to its headquarters, and one of the PVC's goes down, traffic still can be routed over the secondary PVC rather than over the ISDN link.

4. If the primary link goes down, the routing protocol immediately notifies the dialer watch process, and the secondary link (in this case, the ISDN line) is brought up.

5. After the secondary link is up, the primary link is checked again at the expiration of each idle timeout.

6. If the primary link remains down, the idle timer is reset.

If the primary link comes back up, the secondary link is disconnected. A disable timer can be set to delay the disconnection of the secondary link.

For the network in Figure 7-8, you will back up the connection to network 175.10.1.0/24 and to the Headquarters loopback address, ensuring connectivity despite a Frame Relay outage.

Figure 7-8. Network Topology for Dialer Watch Configuration Example

Example 7-33 shows the configuration for using dialer watch.

Example 7-33 Dialer Watch Configuration

 Remote_Site#  show running-config  Building configuration... Current configuration: ! version 12.0 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname Remote_Site ! ! username Headquarters password 0 cisco ip subnet-zero isdn switch-type basic-dms100 ! ! ! interface Loopback0  ip address 175.10.101.1 255.255.255.255  no ip directed-broadcast ! interface Ethernet0  ip address 175.10.2.1 255.255.255.0  no ip directed-broadcast  no keepalive ! interface Serial0  no ip address  no ip directed-broadcast  shutdown  no fair-queue  clockrate 125000 ! interface Serial1  description PRIMARY LINK TO HQ  ip address 175.10.200.1 255.255.255.252  no ip directed-broadcast ! interface BRI0  ip address 175.10.23.1 255.255.255.248  no ip directed-broadcast  encapsulation ppp  dialer map ip 175.10.23.2 name Headquarters broadcast 6129319833  dialer map ip 175.10.102.1 name Headquarters broadcast 6129319833  dialer map ip 175.10.1.0 name Headquarters broadcast 6129319833  dialer watch-group 1  dialer-group 1  isdn switch-type basic-dms100  isdn spid1 61293199371111  isdn spid2 61293199381111 ! router eigrp 1  network 175.10.0.0  no auto-summary ! no ip classless ! access-list 101 deny   eigrp any any access-list 101 permit ip any any dialer watch-list 1 ip 175.10.102.1 255.255.255.255 dialer watch-list 1 ip 175.10.1.0 255.255.255.0 dialer-list 1 protocol ip list 101 ! ! line con 0  privilege level 15  logging synchronous  transport input none line aux 0 line vty 0 4  login ! end _______________________________________________________________________ Headquarters#  show running-config  Building configuration... Current configuration: ! version 12.0 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname Headquarters ! ! username Remote_Site password 0 cisco ip subnet-zero isdn switch-type basic-dms100 ! ! ! interface Loopback0  ip address 175.10.102.1 255.255.255.255  no ip directed-broadcast ! interface Ethernet0  ip address 175.10.1.1 255.255.255.0  no ip directed-broadcast  no keepalive ! interface Serial0  no ip address  no ip directed-broadcast  shutdown ! interface Serial1  description PRIMARY LINK TO REMOTE SITE  ip address 175.10.200.2 255.255.255.252  no ip directed-broadcast  clockrate 125000 ! interface BRI0  ip address 175.10.23.2 255.255.255.248  no ip directed-broadcast  encapsulation ppp  dialer-group 1  isdn switch-type basic-dms100  isdn spid1 61293198331111  isdn spid2 61293198461111 ! router eigrp 1  network 175.10.0.0  no auto-summary ! no ip classless ! dialer-list 1 protocol ip permit ! ! line con 0  privilege level 15  logging synchronous  transport input none line aux 0 line vty 0 4  login ! end 

If any of the routes defined in the dialer-watch list still exists in the routing table, the primary interface is considered to be up, and the ISDN call will not initiate. In this example, both the routes to the Headquarters Ethernet segment and the loopback address must disappear from the routing table before dialer watch will cause the router to make a call. Using a loopback address is an effective way to use dialer watch because this interface is always up. If you specified only the Ethernet network in the dialer watch list, ISDN calls would be made whenever the Ethernet interface went down. This is not a desired result because the primary link might still be up; if the Ethernet is down, it will be just as unreachable through the backup link as it would be through the primary connection. In this example, you could have just as easily chosen only the Headquarters loopback network in the dialer watch list. Instead, both the Ethernet and loopback networks were used in the dialer watch list to illustrate that all routes being watched must no longer be in the routing table for dialing to occur.

CAUTION

The networks defined in the dialer watch list must match the network and subnet masks in the routing table exactly. For example, if the routing table shows 175.10.0.0/16 and your configuration lists dialer watch-list 1 ip 175.10.0.0 255.255.255.0, the dialer watch process will be incapable of detecting that 175.10.0.0/16 is no longer in the routing table.

Example: Backup Interface

Using the backup interface command is another effective way of using ISDN to back up a primary link failure. This command works by keeping track of the link status of the primary interface and initiating an ISDN connection only when the interface status of the primary interface changes from up to down.

NOTE

Some documentation states that the backup interface will come up when only the line protocol of the primary interface goes from up to down. This is not the case. The actual interface must be down, and the line protocol must be down also. You will see an example of where it will not work when the interface is administratively down and the line protocol is down.

Using the backup interface method is not as common as using floating static routes because the only way to test that the ISDN link is working is by actually taking down the primary link physically.

Configuring the backup interface requires only one command:

 Router(config-if)#  backup interface bri 0  

This is performed under the primary link's interface, not under the ISDN interface. An optional parameter that you should be aware of is the backup delay command. This configuration command allows you to determine the time that the ISDN link should wait after detecting a primary link outage before initiating a call, as well as the amount of time that the backup link should wait before tearing down this call after the primary link has been restored. This is useful when the primary link experiences frequent, short outages, and you do not want the ISDN router to initiate a call every time this happens. This is done with the command sequence in Example 7-34, again done under the primary link's interface configuration mode.

Example 7-34 Example Backup Configuration

  interface Serial0    backup delay 5 60     backup interface BRI0    ip address 175.10.123.1 255.255.255.0   encapsulation frame-relay   frame-relay map ip 175.10.123.2 300 broadcast  

Here, the primary link is the Frame Relay connection on Serial 0, and the backup link is the ISDN link on BRI 0. The ISDN link will wait 5 seconds after before calling, after the Serial 0 interface goes from up to down, and it will wait 60 seconds before ending the call after the Serial 0 interface goes from down to up. The backup delay is configured in seconds and can be a value from 0 to 4,294,967,294 seconds for both delay times. Configuring the delays is an optional parameter; if omitted, the ISDN link will come up instantly upon the primary links failure, and the call will terminate instantly upon restoration of the primary link.

Set the delays to ensure that fast bouncing circuits do not start the ISDN call. Bouncing circuits will create havoc with link-state routing protocols, especially OSPF.

When configuring the ISDN link as backup interface, the BRI 0 interface status changes from up, line protocol up (spoofing), to standby mode, line protocol down, as demonstrated in Example 7-35.

Example 7-35 ISDN Interface Status When Using the Backup Interface Configuration

 Cheech#  show int bri0  BRI0 is standby mode, line protocol is down   Hardware is BRI   Internet address is 175.10.23.1/24   MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255   Encapsulation PPP, loopback not set   Last input 00:19:42, output 00:19:42, output hang never   Last clearing of "show interface" counters 1d04h   Queueing strategy: fifo   Output queue 0/40, 0 drops; input queue 0/75, 0 drops   5 minute input rate 0 bits/sec, 0 packets/sec   5 minute output rate 0 bits/sec, 0 packets/sec      21175 packets input, 88385 bytes, 0 no buffer      Received 4 broadcasts, 0 runts, 0 giants, 0 throttles      0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort      21175 packets output, 89187 bytes, 0 underruns      0 output errors, 0 collisions, 2 interface resets      0 output buffer failures, 0 output buffers swapped out      3 carrier transitions 

This interface remains in standby mode and will be unusable until the primary link fails.

Figure 7-9 shows the example network to reference for your backup interface configuration.

Figure 7-9. Network Topology for Backup Interface Configuration Example

Example 7-36 shows an example backup interface configuration.

Example 7-36 Backup Interface Configuration

 Cheech#  show running-config  Building configuration... Current configuration: ! version 11.2 no service password-encryption no service udp-small-servers no service tcp-small-servers ! hostname Cheech ! enable password cisco ! username Chong password 0 cisco isdn switch-type basic-dms100 ! interface Loopback0  ip address 175.10.2.2 255.255.255.0 ! interface Ethernet0  ip address 175.10.22.1 255.255.255.0  no keepalive  no mop enabled ! interface Serial0  backup delay 5 60  backup interface BRI0  ip address 175.10.123.1 255.255.255.0  encapsulation frame-relay  frame-relay map ip 175.10.123.2 300 broadcast ! interface Serial1  no ip address  shutdown ! interface BRI0  ip address 175.10.23.1 255.255.255.0  encapsulation ppp  isdn spid1 61293199371111  isdn spid2 61293199381111  dialer map ip 175.10.23.2 broadcast 6129319833  dialer-group 1  no fair-queue  ppp authentication chap ! router eigrp 1  network 175.10.0.0  no auto-summary ! ip classless ! dialer-list 1 protocol ip permit ! line con 0  exec-timeout 0 0  privilege level 15  logging synchronous line aux 0 line vty 0 4  password cisco  login ! end _______________________________________________________________________ Chong#  show running-config  Building configuration... Current configuration: ! version 11.2 no service password-encryption no service udp-small-servers no service tcp-small-servers ! hostname Chong ! enable password cisco ! username Cheech password 0 cisco isdn switch-type basic-dms100 ! interface Loopback0  ip address 175.10.3.3 255.255.255.0 ! interface Ethernet0  ip address 175.10.35.3 255.255.255.0 ! interface Serial0  no ip address  encapsulation frame-relay  no fair-queue ! interface Serial0.1 point-to-point  ip address 175.10.123.2 255.255.255.0  frame-relay interface-dlci 200 ! interface Serial1  no ip address  shutdown ! interface BRI0  ip address 175.10.23.2 255.255.255.0  encapsulation ppp  isdn spid1 61293198331111  isdn spid2 61293198461111  dialer idle-timeout 9999  dialer-group 1  no fair-queue  ppp authentication chap ! router eigrp 1  network 175.10.0.0  no auto-summary ! no ip classless ! dialer-list 1 protocol ip permit ! line con 0  exec-timeout 0 0  privilege level 15  logging synchronous line aux 0 line vty 0 4  password cisco  login ! end 

No special configuration command was needed in the Chong router, and the BRI0 interface was not made passive under the EIGRP routing process. Normally, when you fail to do this, the EIGRP process keeps the ISDN link up indefinitely, but because it is configured as a backup interface, it will not call unless the Serial 0 interface goes down.

When testing the backup interface scenario, it is important to realize that it will not work simply by administratively shutting down the serial interface on the Cheech router. A backup interface connection will be made only when the primary link's interface is down, not administratively down. However, if you had implemented logical subinterfaces in the Cheech router, using Serial 0.1 for the Frame Relay connection to Chong, you could have configured the backup interface commands on the Serial 0.1 interface. In this case, you could have shut down the physical Serial 0 interface, and the ISDN backup connection would have worked because the Serial 0.1 interface would have gone from up to down (not administratively down). But because you configured the physical serial interface with the backup command in the previous case, you need to actually unplug the Frame Relay connection from the router (or power down the Frame Relay switch in the lab) to initiate the ISDN call.

Example 7-37 shows Cheech's routing table before the Frame Relay outage. Example 7-38 shows the same routing table after the Frame Relay outage.

Example 7-37 Cheech's Routing Table Before Frame Relay Outage

 Cheech#  show ip route  Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP        D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area        N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2        E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP        i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default        U - per-user static route, o - ODR Gateway of last resort is not set      175.10.0.0/24 is subnetted, 7 subnets D       175.10.35.0 [90/2195456] via 175.10.123.2, 00:05:07, Serial0 D       175.10.5.0 [90/2323456] via 175.10.123.2, 00:05:07, Serial0 D       175.10.3.0 [90/2297856] via 175.10.123.2, 00:05:07, Serial0 C       175.10.2.0 is directly connected, Loopback0 D       175.10.23.0 [90/41024000] via 175.10.123.2, 00:04:41, Serial0 C       175.10.22.0 is directly connected, Ethernet0 C       175.10.123.0 is directly connected, Serial0 Cheech#  ping 175.10.35.3  Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 175.10.35.3, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms 

Example 7-38 Cheech's Routing Table After Frame Relay Outage

 Cheech#  show ip route  Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP        D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area        N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2        E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP        i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default        U - per-user static route, o - ODR Gateway of last resort is not set      175.10.0.0/16 is variably subnetted, 7 subnets, 2 masks D       175.10.35.0/24 [90/40537600] via 175.10.23.2, 00:00:12, BRI0 D       175.10.5.0/24 [90/40665600] via 175.10.23.2, 00:00:12, BRI0 D       175.10.3.0/24 [90/40640000] via 175.10.23.2, 00:00:12, BRI0 C       175.10.2.0/24 is directly connected, Loopback0 C       175.10.23.2/32 is directly connected, BRI0 C       175.10.23.0/24 is directly connected, BRI0 C       175.10.22.0/24 is directly connected, Ethernet0 Cheech#  ping 175.10.35.3  Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 175.10.35.3, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 40/41/44 ms Cheech# 

After the Frame Relay connection was unplugged from the Cheech router, it dialed into Chong after waiting 5 seconds. After restoring the connection, the ISDN call ended after 60 seconds. Again, these timers are user-configurable.

Example: Using the backup load Command

Using the backup interface command is also helpful in that, when the primary link becomes overly utilized, an ISDN call can be initiated to provide more bandwidth using the backup load command on the primary link's interface. It also provides a way to configure the routers to make an ISDN connection to back up a failed primary link. A major advantage to using this method to initiate ISDN calls is that it works over any routed or routing protocol. This is bandwidth on demand, not backup. But backup load does work in conjunction with backup interface, as follows:

A Cisco IOS interface is placed into backup mode by applying the backup interface command:

• The backup interface interface configuration command specifies the interface that is to act as the backup.

• The backup load command specifies the traffic threshold at which the backup interface is to be activated and deactivated.

• The backup delay command specifies the amount of time that is to elapse before the backup interface is activated or deactivated after a transition on the primary interface.

Backup interfaces traditionally lock the backup interface into backup state so that it is unavailable for other use. Dialer profiles eliminates this lock and allows the physical interface to be used for multiple purposes. Floating static route DDR design also eliminates this lock on the dialer interface.

Using the configuration in Example 7-39, BRI 0 is activated only when serial interface 1/0 (the primary line) goes down. The backup delay command configures the backup connection to activate 30 seconds after serial interface 0 goes down and to remain activated for 60 seconds after the serial interface 1/0 comes up.

Example 7-39 Configuration Options Using Backup Delay

  interface serial 1/0   ip address 172.20.1.4 255.255.255.0   backup interface bri 2/0   backup delay 30 60  

Using the configuration in Example 7-40, BRI 2/0 is activated only when the load on Serial 0 (the primary line) exceeds 75 percent of its bandwidth. The backup line is deactivated when the aggregate load between the primary and backup lines is within 5 percent of the primary line's bandwidth.

Example 7-40 Configuration Options Using Backup Load

  interface serial 1/0   ip address 172.20.1.4 255.255.255.0   backup interface bri 2/0   backup load 75 5  

Using the configuration in Example 7-41, BRI 2/0 is activated only when serial interface 1/00 goes down or when traffic exceeds 25 percent. If serial interface 1/0 goes down, 10 seconds will elapse before BRI 0 becomes active. When serial interface 1/0 comes up, BRI 2/0 remains active for 60 seconds. If BRI 2/0 is activated by the load threshold on serial interface 1/0, BRI 2/0 is deactivated when the aggregate load of serial interface 1/0 and BRI 2/0 returns to within 5 percent of the bandwidth of serial interface 1/0.

Example 7-41 Using the Backup Load Configuration

  interface serial 1/0   ip address 172.20.1.4 255.255.255.0   backup interface bri 2/0   backup load 25 5   backup delay 10 60  

Note the difference between PPP multilink and backup load. In PPP multilink, the dialer-load threshold value was specified as a value from 1 to 255. In backup load, the number specified to bring up the backup connection is given as a true percentage (0 to 100).

Example: Snapshot Routing

Snapshot routing works on the client/server principle in which one router (usually the headquarters router) is designated as the snapshot server, and one or more routers (remote sites) are the snapshot clients. The clients connect to the server at specific times, called the active period, to obtain their routing information from the server. The term snapshot gets its name from the fact that when the clients' active time expires , the ISDN call disconnects but the clients retain a "snapshot" of the routing entries. During the time that the ISDN line is idle, termed the quiet period, these routing entries remain frozen into the clients' routing tables. When the quiet period ends, the clients dial into the snapshot server to obtain the latest routing information. The quiet and active periods are configurable (5 to 1000 minutes for the active time, and 8 to 100,000 minutes for the quiet period).

Because link-state protocols rely on the use of periodic hellos to retain neighbor adjacency, snapshot routing can be used only with link-state protocols, such as IGRP and RIP for IP, RIP for IPX, and RTMP for AppleTalk.

Snapshot Client Configuration

Configuring snapshot routing is relatively simple. For the client router, only two commands are needed in interface config mode. The first one is as follows:

 router(config-if)#  snapshot client   active-time quiet-time  [  suppress-statechange-updates  ]   [  dialer  ] 

This command sets the active and quiet periods, in minutes. The suppress-statechange-updates command option disables the exchange of routing updates each time that the link comes up because of any additional traffic. The default is that routing information is exchanged whenever the ISDN link is up for any reason. The dialer option is used to tell the client router to go ahead and dial into the snapshot server in the absence of regular traffic, and to point to the appropriate dialer map specified in Step 2.

The second required command is as follows:

 router(config-if)#  dialer map snapshot   sequence-number   name   name dial-string  

This command defines the dialer map that includes the snapshot server router to call for routing updates.

A common point of confusion occurs when using the help (the ? ) the feature in this command, when a protocol address is asked for when the sequence number is really needed. Consider the configuration in Example 7-42.

Example 7-42 dialer map snapshot Confusion Illustration

 Cheech#  conf t  Cheech(config)#  int bri0  Cheech(config-if)#  dialer map snapshot ?  N  Protocol specific address 

It appears here that IOS is looking for a specific protocol address, when, in fact, only a sequence number is required. Sequence numbers are used to identify a dialer map and prioritize the sequence (a number from 1 to 254) in which the client calls the server routers, if there are multiple server routers. If only one server router exists, any sequence number will do. The point here is to remember to input only a number from 1 to 254, not to try to put in any kind of Layer 3 address.

Snapshot Server Configuration

This one is easy because only one command is needed:

 Router(config-if)#s  napshot server   active-timer  [  dialer  ] 

The active-timer specified in this command must match the same value that was placed on the client router.

Example Snapshot Configuration

In the simple network in Figure 7-10, Frame Relay is used as the primary communication link between the two sites, and snapshot routing is used to exchange routing information between the two locations so that connectivity will remain through the ISDN link in the case of a Frame Relay outage. We made the BRI interfaces passive to eliminate the routing updates from triggering a call.

Figure 7-10. Snapshot Network Reference

Example 7-43 illustrates the proper snapshot configuration.

Table 7-4. Snapshot Client Router Configuration

 Cheech#  show running-configuration  no service password-encryption no service udp-small-servers no service tcp-small-servers ! hostname Cheech ! enable password cisco ! username Chong password 0 cisco isdn switch-type basic-dms100 ! interface Loopback0  ip address 175.10.2.2 255.255.255.0 ! interface Ethernet0  ip address 175.10.22.1 255.255.255.0  no keepalive  no mop enabled ! interface Serial0  ip address 175.10.123.1 255.255.255.0  encapsulation frame-relay  frame-relay map ip 175.10.123.2 300 broadcast ! interface Serial1  no ip address  shutdown ! interface BRI0  ip address 175.10.23.1 255.255.255.0  encapsulation ppp  isdn spid1 61293199371111  isdn spid2 61293199381111  dialer map snapshot 1 name Chong 6129319833  dialer map ip 175.10.23.2 broadcast 6129319833  dialer-group 1  snapshot client 10 20 dialer  no fair-queue  ppp authentication chap ! router igrp 1  network 175.10.0.0 ! ip classless ! dialer-list 1 protocol ip permit ! line con 0  exec-timeout 0 0  privilege level 15  logging synchronous line aux 0 line vty 0 4  password cisco  login ! end ______________________________________________________________________________________ Chong#  show running-configuration  no service password-encryption no service udp-small-servers no service tcp-small-servers ! hostname Chong ! enable password cisco ! username Cheech password 0 cisco isdn switch-type basic-dms100 ! interface Loopback0  ip address 175.10.3.3 255.255.255.0 ! interface Ethernet0  ip address 175.10.35.3 255.255.255.0 ! interface Serial0  no ip address  encapsulation frame-relay  no fair-queue ! interface Serial0.1 point-to-point  ip address 175.10.123.2 255.255.255.0  frame-relay interface-dlci 200 ! interface Serial1  no ip address  shutdown ! interface BRI0  ip address 175.10.23.2 255.255.255.0  encapsulation ppp  isdn spid1 61293198331111  isdn spid2 61293198461111  dialer-group 1  snapshot server 10  no fair-queue  ppp authentication chap ! router igrp 1  network 175.10.0.0 ! no ip classless ! dialer-list 1 protocol ip permit ! line con 0  exec-timeout 0 0  privilege level 15  logging synchronous line aux 0 line vty 0 4  password cisco  login ! end 

An important note here is that we have not made the BRI0 interfaces passive under the IGRP process. This is needed so that routing traffic will pass over the ISDN link and the snapshot routing process will keep this line from coming up needlessly. To verify that the routers do connect during the active period and that routing traffic is being passed, you can issue the show dialer and show snapshot commands, as demonstrated in Example 7-44.

Example 7-43 Verifying Router Connections During Active Periods and Passing of Routing Traffic

 Cheech#  show dialer  BRI0 - dialer type = ISDN Dial String      Successes   Failures    Last called   Last status 6129319833              85          0    00:10:22       successful 0 incoming call(s) have been screened. BRI0:1 - dialer type = ISDN Idle timer (120 secs), Fast idle timer (20 secs) Wait for carrier (30 secs), Re-enable (15 secs) Dialer state is data link layer up Dial reason: snapshot Time until disconnect 6 secs Connected to 6129319833 (Chong) BRI0:2 - dialer type = ISDN Idle timer (120 secs), Fast idle timer (20 secs) Wait for carrier (30 secs), Re-enable (15 secs) Dialer state is idle Cheech#  show dialer  BRI0 - dialer type = ISDN Dial String      Successes   Failures    Last called   Last status 6129319833              85          0    00:10:26       successful 0 incoming call(s) have been screened. BRI0:1 - dialer type = ISDN Idle timer (120 secs), Fast idle timer (20 secs) Wait for carrier (30 secs), Re-enable (15 secs) Dialer state is data link layer up  Dial reason: snapshot  Time until disconnect 

The reason for this ISDN connection was to exchange snapshot routing information. Based on the previous example, these exchanges should take place every 20 minutes, for a length of 10 minutes each. In real-world applications, you might want to increase the quiet time period because causing the link to come up every 20 minutes might seem a bit excessive and costly.

The show snapshot command can be used to verify that the snapshot processes are working properly and to show which snapshot options are being applied, as demonstrated in Example 7-45.

Example 7-44 Verifying Snapshot Processes and Applied Options

 Cheech#  show snapshot  BRI0 is up, line protocol is up Snapshot client   Options: dialer support   Length of active period:          10 minutes   Length of quiet period:           20 minutes   Length of retry period:           13 minutes    For dialer address 1     Current state: active, remaining/exchange time: 8/2 minutes     Connected dialer interface:        BRI0:1     Updates received this cycle: ip 

Only IP routes are being passed, and you can verify that this router has been configured as a client using dialer information, with the configured active and quiet periods, along with the retry period. The retry period defaults to the configured active period plus 3 minutes.

To test that routing over the ISDN link works in the event of a Frame Relay outage, unplug the Frame Relay connection from the Cheech router. Example 7-46 and 7-47 show the routing table before and after the Frame Relay connection was unplugged.

Example 7-45 Routing Table Before Frame Relay Outage

 Cheech#  show ip route  Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP        D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area        N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2        E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP        i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default        U - per-user static route, o - ODR Gateway of last resort is not set      175.10.0.0/24 is subnetted, 6 subnets I       175.10.35.0 [100/8576] via 175.10.123.2, 00:00:04, Serial0 I       175.10.3.0 [100/8976] via 175.10.123.2, 00:00:04, Serial0 C       175.10.2.0 is directly connected, Loopback0 C       175.10.23.0 is directly connected, BRI0 C       175.10.22.0 is directly connected, Ethernet0 C       175.10.123.0 is directly connected, Serial0 Cheech# ping 175.10.35.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 175.10.35.3, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/7/8 ms 

Example 7-46 Routing Table After a Frame Relay Outage

 Cheech#  show ip route  Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP        D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area        N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2        E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP        i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default        U - per-user static route, o - ODR Gateway of last resort is not set      175.10.0.0/16 is variably subnetted, 6 subnets, 2 masks I       175.10.35.0/24 [100/158350] via 175.10.23.2, 00:00:00, BRI0 I       175.10.3.0/24 [100/158750] via 175.10.23.2, 00:00:00, BRI0 C       175.10.2.0/24 is directly connected, Loopback0 C       175.10.23.2/32 is directly connected, BRI0 C       175.10.23.0/24 is directly connected, BRI0 C       175.10.22.0/24 is directly connected, Ethernet0 Cheech#ping 175.10.35.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 175.10.35.3, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 40/43/44 ms 

It took only a couple seconds for the routing to converge to the ISDN link. When the Frame Relay link was restored, traffic again was routed over this link quickly.