Standard analog telephone lines with asynchronous modems are a reasonably effective dial backup technology, and they have the great advantage of being nearly ubiquitous: in regions where you can get no other network services, you can often get an analog telephone line. Further, most Cisco routers have an AUX port that supports an analog modem connection.

But this option has some important drawbacks. The first is that there are no guarantees about how much bandwidth you will get. Many analog modems are rated to speeds up to 56Kbps, but in practice you will rarely get this much throughput. It is more typical to see a practical bandwidth of between 9.6 and 44Kbps with asynchronous modems.

The second important problem with voice grade telephone lines is that they are susceptible to electrical noise, which can cause dropped packets and sometimes even dropped calls.

Switched 56Kbps digital service, which also goes by the brand name Centrex in some areas, is a synchronous digital dialup technology. We recommend using this in regions that don’t offer ISDN because it offers greater bandwidth and reliability than voice grade analog service. However, the number of local telephone companies that can offer switched 56Kbps but not ISDN is rapidly decreasing.

To use this technology, you need a synchronous serial port on your router, and an external Data Unit (DU), or synchronous modem.

ISDN (Integrated Services Digital Network) is usually the best way to go for dialup networking. It has the highest bandwidth and the greatest reliability. And, when using ISDN with Cisco routers, you have the distinct advantage of being able to use built-in ISDN terminal adapters and Network Termination Type 1 (NT1) units, which reduces both the complexity and the costs of implementation and maintenance.

ISDN circuits come in two basic varieties called Basic Rate Interface (BRI) and Primary Rate Interface (PRI). A BRI circuit supports two 64Kbps B-channels and a 16Kbps D-channel that handles the signaling for the two B-channels. A PRI circuit, on the other hand, uses a single 64Kbps D-channel to support the signaling for 23 (if delivered through a T1 circuit) or 30 (for an E1 circuit) B-channels. Many network vendors will also sell PRI services on fraction T1 or E1 circuits, allowing smaller numbers of B-channels.

The D-channel is not usually used for user data, but Cisco routers allow you to bind the two B-channels together for a net 128Kbps link using the PPP multilink feature. Unlike analog modems, each of these channels operates at full-duplex, so you can send and receive simultaneously at the full channel speed.

It is possible to use the D-channel of a PRI circuit for user data, but only if the carrier has not configured this channel to manage the B-channels. In situations where you have multiple PRI circuits, it is possible to control all of the B-channels from the D-channel of the first PRI circuit, leaving the D-channels of the other circuits available for data. The advantages of doing this are slight, however.

Many organizations use BRI interfaces for remote branch devices, and PRI interfaces for central dialup circuits. This way you can save on physical ports by having many branches dial into a single central PRI circuit. By default, a PRI circuit can accept calls from remote ISDN circuits. ISDN circuits can also terminate calls from Centrex or switched 56Kbps type circuits without requiring any special hardware. Further, Cisco has analog modem cards for several routers such as the AS5x00 and 3600 series. These allow you to terminate analog calls from remote devices on the same PRI circuit. This is an extremely useful option because you can then configure all of your remote devices to dial to the same central ISDN PRI telephone number.

BRI interfaces come in two main varieties, called “S/T” and “U.” Usually a BRI circuit is delivered and terminated on a U interface, which is a two-wire digital telephone line. The U interface connects to an NT1, which converts the U interface signaling to S/T interface signaling. The S/T interface then connects to a Terminal Adapter device, which allows you to connect the ISDN circuit to your equipment. Both S/T and U interfaces use standard RJ-45 cables.

Cisco allows you to eliminate some or all of these pieces of equipment, though, by offering a variety of ISDN hardware options. Many access routers come with an optional on-board Terminal Adapter, or can take an ISDN module with this functionality. The BRI interface is labeled “S/T” to indicate when the router has an on-board terminal adapter. You can connect this port to an external NT1 device, which in turn connects to the telephone company’s circuit.

Cisco also has a variety of BRI modules that include an on-board NT1. These also use an RJ-45 connector, but they are labeled “U” to indicate that you should connect directly to the ISDN circuit. We generally prefer to implement ISDN on routers with on-board NT1 units because it simplifies implementation.

If you want to take full advantage of ISDN features, the router must at least have an on-board Terminal Adapter.

Many network engineers make the mistake of either under or overestimating how many dial backup lines they need to provide at their central site. In a hub-and-spoke WAN, you can easily estimate how many dialup lines you will need at the central site based on the probability failure for a branch’s primary circuit.

The most common failure mode in any WAN is the so-called “last mile” failure, which means that the local loop circuit between the remote site and the WAN provider’s Central Office (CO) breaks for some reason. The break could be due to a fiber cut, cross-connection problem, or (more common than anybody would like) human error. The provider will usually keep statistics on these problems, which they will use to define their Service Level Agreement (SLA) for each type of circuit.

The SLA effectively reflects a probability of a circuit failure. If, for example, your remote sites have a 99.9% SLA, this means that there is a 0.1% probability of failure. So, if you have a network with N circuits, each of which has the same probability of failure, P, you can use the following formula to calculate the probability of k simultaneous failures:

P(k,N) = N! P^k (1-P)^(N-k) / (k! (N-k)!)

The symbol “!” is a standard shorthand notation for the factorial function:

N! = N x (N – 1) x (N–2) x … x 2 x 1

So, for a WAN SLA of 99.9%, which is on the poor side (but typical), P is 0.1% (100% – 99.9%). If you have a hub-and-spoke WAN with N=100 circuits, the probability of there being a single circuit down is:

P(1,100) ~ 0.1 = 10%

So roughly 10% of the time, you can expect to have one circuit down. Similarly, the probabilities of there being two or more simultaneous failures are given by:

P(2,100) ~ .5%

P(3,100) ~ .02%

P(4,100) ~ 0.00038%

P(10,100) ~ 1.7 x10^-15%

It’s clear from this that the probability of 10 simultaneous failures is very small indeed. But just looking at probabilities can be deceptive because all of the numbers look small. We recommend multiplying these probabilities by the number of minutes in a year to get a better idea of how likely these failure scenarios actually are.

The probability of there being a single circuit failure is 10%, or 36.5 days per year. The probability of two simultaneous failures is 0.5%, which is roughly 44 hours per year. The probability of three simultaneous failure is .02%, or 105 minutes per year. And the probability of four simultaneous failures is .00038%, which is about two minutes per year.

So these are all things that you can expect to see happen at least once in the expected several year life span of this WAN. But the probability of 10 simultaneous failures is so small that you would expect it to happen roughly 5 x 10^-10 seconds per year. Looking at this another way, if this failure condition lasted for one second, you would expect it to happen about once every billion years. Those are odds that most of us could live with.

By doing this sort of analysis, you can tell that having three dial backup circuits would probably come in handy at least once a year, and you might even need as many as four. But you’re not likely to ever need 10.

However, it’s important to bear in mind that this analysis assumes that these failures are not correlated. Depending on how your WAN provider implements your circuits, a single failure could affect several branches. So it is usually a good idea to apply a safety rule and double the number of circuits that this analysis suggests you will need. In this case, you probably need 4 circuits—but if you have 8 or 10, you should be more than safe.

You want automatic dial recovery in case a WAN link fails.

One of the most reliable ways of implementing dial backup on a Cisco router is to use a floating static default route, as follows:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#interface BRI0/0
Router1(config-if)#ip address 10.1.99.55 255.255.255.0
Router1(config-if)#encapsulation ppp
Router1(config-if)#dialer idle-timeout 300
Router1(config-if)#dialer map ip 10.1.99.1 name dialhost broadcast 95551212
Router1(config-if)#dialer load-threshold 50 either
Router1(config-if)#dialer-group 1
Router1(config-if)#isdn switch-type basic-ni
Router1(config-if)#isdn spid1 800555123400 5551234
Router1(config-if)#isdn spid2 800555123500 5551235
Router1(config-if)#ppp authentication chap
Router1(config-if)#ppp multilink
Router1(config-if)#exit
Router1(config)#username dialhost password dialpassword
Router1(config)#ip route 0.0.0.0 0.0.0.0 10.1.99.1 180
Router1(config)#dialer-list 1 protocol ip list 101
Router1(config)#access-list 101 deny eigrp any any
Router1(config)#access-list 101 permit ip any any
Router1(config)#router eigrp 55
Router1(config-router)#network 10.0.0.0
Router1(config-router)#end
Router1#

The matching configuration of the other end is shown in Recipe 13.2.

This recipe includes several important features. First, note that we have configured dial backup using an ISDN BRI interface on this router. So, we have to set up the ISDN configuration:

Router1(config)#interface BRI0/0
Router1(config-if)#isdn switch-type basic-ni
Router1(config-if)#isdn spid1 800555123400 5551234
Router1(config-if)#isdn spid2 800555123500 5551235

This site is connected to a National ISDN switch. So we have defined the switch type to be basic-ni. If this had been a PRI rather than a BRI, we would have used primary-ni. And, because it is a National ISDN switch, we also have to include the ISDN Service Profile Identifier (SPID) values. These define the telephone numbers associated with each of the two B-channels in the BRI. Note that the syntax includes essentially the same number twice:

Router1(config-if)#isdn spid1 800555123400 5551234

The first argument is the whole telephone number, including area code, with 00 tacked on the end. These extra two digits vary between different telephone companies. Sometimes this needs to be a different code such as 0101. The telephone company can tell you the correct value to include.

The second number is not always required. This is essentially the phone number that you would need to call this B-channel from the other B-channel. In this example, the telephone company uses 7-digit local dialing, so we can eliminate the area code.

There are several different kinds of ISDN switches, and it’s important to find out what your carrier uses to ensure that you configure the router properly.

For telephone companies that use AT&T switches:

Router1(config-if)#isdn switch-type basic-5ess

For telephone companies that use Nortel DMS100 switches:

Router1(config-if)#isdn switch-type basic-dms100

Telephone companies outside of North America often use different kinds of ISDN switches. In France you would use the following command:

Router1(config-if)#isdn switch-type vn3

In Australia, the telephone company uses TS013 ISDN switches:

Router1(config-if)#isdn switch-type basic-ts013

In Norway and New Zealand:

Router1(config-if)#isdn switch-type basic-net3

In Germany:

Router1(config-if)#isdn switch-type basic-1tr6

And, in Japan:

Router1(config-if)#isdn switch-type ntt

Please contact the local telephone company supplying the BRI circuit to ensure that you have the right switch type. And be sure to ask them whether you need to configure SPIDs on your router. Some switches require them, while others don’t.

You can verify that you have your ISDN configuration working correctly with the show isdn status command:

Router1#show isdn status
Global ISDN Switchtype = basic-ni
ISDN BRI1/0 interface
     dsl 8, interface ISDN Switchtype = basic-ni
     Layer 1 Status:
     ACTIVE
     Layer 2 Status:
     TEI = 85, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
     TEI = 86, Ces = 2, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
     TEI 85, ces = 1, state = 8(established)
         spid1 configured, spid1 sent, spid1 valid
     TEI 86, ces = 2, state = 8(established)
         spid2 configured, spid2 sent, spid2 valid
     Layer 3 Status:
     0 Active Layer 3 Call(s)
     Activated dsl 8 CCBs = 0
     The Free Channel Mask:  0x80000003
Total Allocated ISDN CCBs = 2
Router1#

In this case, you can see that you have an “active” status at Layer 1, and both of the Terminal Endpoint Identifiers (TEI) are in a “MULTIPLE_FRAME_ESTABLISHED” state. This means that the router is talking with the telephone company’s ISDN switch and both of the B-channels are ready to go. This display also says that there are currently no active calls at Layer 3. As an aside, we should point out that this refers to the ISDN circuit’s Layer 3, and not the IP network layer. When the router places a call, it will establish a PPP connection, which will support IP.

The actual dialing is done by the dialer map command:

Router1(config)#dialer-list 1 protocol ip list 101
Router1(config)#access-list 101 deny eigrp any any
Router1(config)#access-list 101 permit ip any any
Router1(config)#interface BRI0/0
Router1(config-if)#dialer map ip 10.1.99.1 name dialhost broadcast 95551212
Router1(config-if)#dialer-group 1

In this case, the dialer map says that, to reach the IP address 10.1.99.1, which is a router called dialhost, it should dial the phone number 95551212. Note that we have included a “9” at the start of this phone number. Again, you will need to ask your local telephone company whether there is a special code digit. We have seen places where we needed a 9, an 8, or nothing at all.

The broadcast keyword in this command allows both multicast and broadcast traffic to use this dialup link. This is extremely important for routing protocols such as EIGRP, RIPv2, and OSPF, which use multicasts for sending their updates between routers. This example uses EIGRP, so we need to include this keyword.

With this type of dialer configuration, you also need to define a dialer group. In this case, we have assigned this interface to dialer group number 1. You configure the behavior of this dialer group with the dialer-list statement, which defines what an interesting packet is for this network.

An interesting packet is one that will bring up the dialer, or keep it active if it is already up. If the circuit is up, the router will reset the idle timer every time it sees an interesting packet. The result is that as long as there are interesting packets to send, the router will keep the dial session active. Otherwise, it will disconnect the call when the idle timer expires. This is particularly important when you are calling long-distance numbers. If the wrong packets are considered interesting, it could mean long call and an expensive phone bill.

So we have associated the dialer list with an access list that specifies what is interesting. In this case, all IP packets except EIGRP are interesting. It’s important to remember that EIGRP packets will still pass through the dial link normally. But if the link is not active, an EIGRP packet is not sufficient to bring it up. And, if the link is active, the presence of EIGRP packets alone won’t prevent the router from dropping it.

This is extremely important, because, as we discussed in Chapter 7, the router will send an EIGRP HELLO packet every few seconds by default. But we don’t want the link to remain active unless there is real user traffic to send. If you are using a different routing protocol, you should specify its update packets here instead.

Sometimes you do want the link to remain active all the time. For example, the administrators of some small WANs like to keep ISDN sessions nailed up all the time (usually because they only pay an access charge, and not a usage or long-distance charge). So, if the session drops for any reason, they want it to immediately dial up again. In this case, you could replace the access list with a new one that finds all traffic interesting:

Router1(config)#access-list 101 permit ip any any

It’s easier still if you modify the dialer-list command to make all IP traffic interesting:

Router1(config)#dialer-list 1 protocol ip permit

When the router dials, it will use Point-to-Point Protocol (PPP) to carry Layer 3 protocols such as IP. So you need to define several PPP parameters:

Router1(config)#interface BRI0/0
Router1(config-if)#encapsulation ppp
Router1(config-if)#ppp authentication chap
Router1(config-if)#exit
Router1(config)#username dialhost password dialpassword

The encapsulation command simply tells the router to use PPP as its Layer 2 protocol. But, because you don’t want just anybody dialing into this dialhost router, it’s a good idea to include some authentication. In this case we have configured the router to use Challenge Handshake Authentication Protocol (CHAP) for authenticating PPP sessions. This basically means that both this router and the router it dials to will exchange usernames and passwords when they connect. The username for this router is the router’s name. We define the username and password for the other router with the username command.

Cisco also supports PPP authentication scheme called Password Authentication Protocol (PAP). CHAP is much more secure because it only passes passwords in encrypted form rather than clear-text, as PAP does. CHAP is no more complex to set up, and presents no appreciable extra load on the router’s resources. So we strongly recommend using CHAP rather than PAP.

Because this is an ISDN BRI interface, we would like to be able to use both of the B-channels to increase the available bandwidth:

Router1(config)#interface BRI0/0
Router1(config-if)#dialer load-threshold 50 either
Router1(config-if)#ppp multilink

The command ppp multilink means that this PPP session can be split across several physical connections. This feature allows full load balancing and packet sequencing across all of the connections in the multilink bundle. In this case, we want to bond the two ISDN B-channels into a single 128Kbps PPP link. By default, the router will only use one of these channels, whichever one is available. The dialer load-threshold command specifies the rule that the router will use to bring up the second link. In this case, we have specified that, if the traffic utilization in either direction (input or output) reaches ~20% (50/255 link utilization), then the router should bring up the second channel.

We have also modified the default idle timeout:

Router1(config)#interface BRI0/0
Router1(config-if)#dialer idle-timeout 300

By default, the router will drop the dial session if there have been no interesting packets for 120 seconds. We have increased this value to 300 seconds. Because ISDN dials so quickly, this is not vital. But with asynchronous modem dialup, it can take up to a full minute to establish a new session. You often need to increase the idle timer is to make sure that the primary connection is up and stable before disconnecting the backup circuit. It is a good idea to wait for the routing protocol to converge, and to ensure that the primary circuit isn’t simply bouncing up and down. You also have to trade off between the time required to establish a new session and the cost of any long-distance charges on this line. We generally recommend using an idle timeout period of five minutes, as shown in the example.

Finally, we come to one of the most important features of this configuration, the trigger condition. This router will dial whenever it has traffic to send to the IP address 10.1.99.1, which is the IP address of the dialhost router itself. User traffic will be directed to end devices such as servers, not to routers. The only way to bring up this dial interface is if this router needs to send an interesting packet to the dial router’s IP address. This is where the floating static route comes in.

In Chapter 5 we discussed floating static routes. These are routes whose administrative distances are so high that any dynamically learned route to the same destination will be better. The router will only install this static route if the dynamic routing protocol can’t offer anything better:

Router1(config)#ip route 0.0.0.0 0.0.0.0 10.1.99.1 180

In this particular case, the routing protocol is EIGRP, which has default administrative distance of 90 for all internal routes and 170 for external routes. So, by creating this static default route with a metric of 180, we ensure that the router will never use it if it has anything better.

The net result is that, if the primary link fails, EIGRP will lose all of its routes. So the router will install the floating static route to handle any user data packets that it needs to transmit. Since this route points to the far end of the dial link, the router must bring up the dial connection.

The nice thing about this way of triggering dial backup is that it is extremely robust. Anything that causes you to lose connectivity for any reason will trigger the dial backup. This is better than the backup interface solution described in Recipe 13.4, for example, because it doesn’t require loss of physical connectivity to trigger the backup.

Also, as we discuss in Recipe 13.4 (which uses the backup interface method for triggering dial backup), the floating static configuration allows you to have the interface remain up but not connected when the primary circuit is working. In the case of ISDN, this means that you can use the show isdn commands that we discuss in Recipe 13.7 to ensure that your circuit is still working.

One of the most useful features of this type of trigger mechanism is that you can test the dial backup easily. If you look at the dialer list, you will see that all the router needs to initiate a dial session is to have a packet to send to the far end that matches the dialer list. So, in this particular example, you could easily bring up a dial session for testing by just logging into the remote router and pinging the IP address of the dial backup router:

Router1#ping 10.1.99.1

Recipe 13.2; Recipe 13.4; Chapter 5; Chapter 7

You want to treat several physical interfaces as a single dialer.

If you have several physical interfaces on your router that you want to treat as a single dialer, particularly for PPP multilink channel bonding, you can create a logical dialer interface:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#interface BRI0/0
Router1(config-if)#encapsulation ppp
Router1(config-if)#dialer pool-member 1
Router1(config-if)#isdn switch-type basic-ni
Router1(config-if)#isdn spid1 800555123400 5551234
Router1(config-if)#isdn spid2 800555123500 5551235
Router1(config-if)#ppp authentication chap
Router1(config-if)#exit
Router1(config)#interface BRI0/1
Router1(config-if)#encapsulation ppp
Router1(config-if)#dialer pool-member 1
Router1(config-if)#isdn switch-type basic-ni
Router1(config-if)#isdn spid1 800555123600 5551236
Router1(config-if)#isdn spid2 800555123700 5551237
Router1(config-if)#ppp authentication chap
Router1(config-if)#exit
Router1(config)#interface Dialer1
Router1(config-if)#ip address 10.1.99.55 255.255.255.0
Router1(config-if)#encapsulation ppp
Router1(config-if)#dialer remote-name dialhost
Router1(config-if)#dialer pool 1
Router1(config-if)#dialer idle-timeout 300
Router1(config-if)#dialer string 95551212
Router1(config-if)#dialer load-threshold 50 either
Router1(config-if)#dialer-group 1
Router1(config-if)#ppp authentication chap
Router1(config-if)#ppp multilink
Router1(config-if)#exit
Router1(config)#username dialhost password dialpassword
Router1(config)#ip route 0.0.0.0 0.0.0.0 10.1.99.1 180
Router1(config)#dialer-list 1 protocol ip list 101
Router1(config)#access-list 101 deny eigrp any any
Router1(config)#access-list 101 permit ip any any
Router1(config)#router eigrp 55
Router1(config-router)#network 10.0.0.0
Router1(config-router)#end
Router1#

Dialer interfaces are particularly useful for the server side, where you can use them to bond together several ISDN BRI or PRI circuits:

dialhost#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
dialhost(config)#username Router1 password dialpassword
dialhost(config)#controller T1
dialhost(config-controller)#framing esf
dialhost(config-controller)#clock source line primary
dialhost(config-controller)#linecode b8zs
dialhost(config-controller)#pri-group timeslots 1-24
dialhost(config-controller)#exit
dialhost(config)#interface Serial0:23
dialhost(config-if)#encapsulation ppp
dialhost(config-if)#dialer rotary-group 1
dialhost(config-if)#dialer-group 1
dialhost(config-if)#isdn switch-type primary-dms100
dialhost(config-if)#isdn not-end-to-end 56
dialhost(config-if)#exit
dialhost(config)#interface Dialer1
dialhost(config-if)#ip address 10.1.99.1 255.255.255.0
dialhost(config-if)#encapsulation ppp
dialhost(config-if)#dialer in-band
dialhost(config-if)#dialer idle-timeout 300
dialhost(config-if)#dialer-group 1
dialhost(config-if)#no peer default ip address
dialhost(config-if)#ppp authentication chap
dialhost(config-if)#ppp multilink
dialhost(config-if)#exit
dialhost(config)#access-list 101 deny eigrp any any
dialhost(config)#access-list 101 permit ip any any
dialhost(config)#dialer-list 1 protocol ip list 101
dialhost(config)#router eigrp 55
dialhost(config-router)#network 10.0.0.0
dialhost(config-router)#end
dialhost#

This example is similar to Recipe 13.1, but this time we have created a logical Dialer1 interface instead of using a dialer map command. The effect is the same, but with dialer interfaces you have the advantage of being able to bond together several different physical links into a single PPP multilink bundle.

In the first example, we have included two ISDN BRI interfaces, giving us an effective total bandwidth of 256Kbps for the backup link. However, as in Recipe 13.1, we have included a dialer load-threshold command so the router will bring up these additional B channels only if it requires them.

There are a couple of important differences between the first example in this recipe and the one in Recipe 13.1. First, notice that we have not included any IP addresses or dialer configuration information on the physical interfaces. Instead, we put all of this information in the configuration of the logical dialer interface.

Then, to associate these physical interfaces with this particular logical interface, we use the dialer pool-member command on the physical interfaces and the dialer pool command on the dialer interface. In this example, we have created dialer pool number 1 on the Dialer1 interface and assigned the two BRI interfaces to this pool. The dialer interface number is arbitrary. The only thing that matters is that the dialer pool numbers match the dialer pool member numbers.

Because there is no dialer map command to define the telephone number to call, the destination hostname, and the destination IP address, we have to configure these separately. First we set up the remote hostname and the dialer string (which defines the destination phone number) as follows:

Router1(config)#interface Dialer1
Router1(config-if)#dialer remote-name dialhost
Router1(config-if)#dialer string 95551212

And, as in Recipe 13.1, we include a floating static route to trigger the dial backup:

Router1(config)#ip route 0.0.0.0 0.0.0.0 10.1.99.1 180

The rest of the configuration is essentially the same as in Recipe 13.1.

The second example in this recipe shows a sample server side configuration. In many ways it is similar to the branch, but there are also a few key differences. The first difference is that the server is configured to use a PRI rather than a BRI circuit. In this case, the router uses a built-in T1 CSU, so we need to define the framing, line coding, and how the T1 time slices work:

dialhost(config)#controller T1
dialhost(config-controller)#framing esf
dialhost(config-controller)#clock source line primary
dialhost(config-controller)#linecode b8zs
dialhost(config-controller)#pri-group timeslots 1-24
dialhost(config-controller)#exit

This represents the most common options, Extended Super Frame (ESF) framing with Binary 8-Zero Substitution (B8ZS) line coding. And we will draw the clock from the circuit, rather than generating it in the router. The most important part of this is the definition of the T1 time slots. In this case, we have grouped all 23 B-channels and the D-channel into a single PRI group. This reflects the fact that we purchased this circuit as a whole T1. However, you could just as easily work with a fractional T1 PRI circuit that includes only some of the available time slots. Please see Chapter 16 for more information on the controller command.

Once we have defined the T1 time slots for the PRI circuit, we can configure the circuit for dialup:

dialhost(config)#interface Serial0:23
dialhost(config-if)#encapsulation ppp
dialhost(config-if)#dialer rotary-group 1
dialhost(config-if)#dialer-group 1
dialhost(config-if)#isdn switch-type primary-dms100
dialhost(config-if)#isdn not-end-to-end 56
dialhost(config-if)#exit

The name of this interface, Serial0:23, means that we are working with the circuit attached to interface Serial0, and that it includes 23 time slices. In this example, the telephone company’s ISDN switch is a Nortel DMS100, so we have to configure this with the isdn switch-type command. The encapsulation ppp and the dialer-group commands are familiar from previous examples, but there are a couple of other options here.

The first new feature is the dialer rotary-group command. This is a useful variation on some of the dialer commands that we discussed earlier. Because the argument of this command is the number 1, this physical interface is assigned to a rotary group that is associated with the virtual interface, Dialer1. A rotary group is similar to any other dialer group, but it allows multiple simultaneous connections to different remote routers. This wasn’t necessary for the branch routers, because they dial only to the one central router. But the host router must be able to accept calls from many branches at once.

The primary router doesn’t require dialer map statements to accept inbound calls. These are only necessary for outbound calls. When the router receives a new inbound connection, it will create a dynamic map to associate the IP address with the dial connection.

The last command in this configuration is often required when using ISDN calls between different telephone companies, particularly for long-distance calls:

dialhost(config-if)#isdn not-end-to-end 56

By default, the router will assume that all calls use 64Kbps ISDN B-channels. But some regions use 56Kbps instead of 64. And, worse still, sometimes you have a long distance call that starts and ends at 64Kbps but has a hidden leg of 56Kbps in the middle of the carrier’s network. In all of these cases, the router will drop the call by default, because of the speed mismatch. This command manually forces the router to use 56Kbps for all calls to prevent these speed mismatch problems.

Recipe 13.1; Chapter 16

You want to connect a standard asynchronous modem to the router’s AUX port and use it for dial backup.

Many Cisco routers include an AUX port that is a low-speed asynchronous serial interface that can connect to a standard modem and support PPP:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router2(config)#interface Async65
Router2(config-if)#encapsulation ppp
Router2(config-if)#dialer in-band
Router2(config-if)#dialer pool-member 1
Router2(config-if)#ppp authentication chap
Router2(config-if)#async default routing
Router2(config-if)#exit
Router2(config)#interface Dialer1
Router2(config-if)#ip address 10.1.99.56 255.255.255.0
Router2(config-if)#encapsulation ppp
Router2(config-if)#dialer remote-name dialhost
Router2(config-if)#dialer pool 1
Router2(config-if)#dialer idle-timeout 300
Router2(config-if)#dialer string 95551212
Router2(config-if)#dialer-group 1
Router2(config-if)#ppp authentication chap
Router2(config-if)#exit
Router2(config)#line aux 0
Router2(config-line)#modem inout
Router2(config-line)#transport input all
Router2(config-line)#no exec
Router2(config-line)#speed 115200
Router2(config-line)#exit
Router2(config)#username dialhost password dialpassword
Router2(config)#ip route 0.0.0.0 0.0.0.0 10.1.99.1 180
Router2(config)#dialer-list 1 protocol ip list 101
Router2(config)#access-list 101 deny eigrp any any
Router2(config)#access-list 101 permit ip any any
Router2(config)#router eigrp 55
Router2(config-router)#network 10.0.0.0
Router2(config-router)#end
Router2#

Much of this configuration is similar to the ISDN configuration shown in Recipe 13.2. It uses a dialer interface in exactly the same way. But here, because there is only one async modem in this example, we can’t benefit from PPP multilink.

The first part of this configuration example sets up the AUX port to run PPP and associates it with a dialer pool:

Router2(config)#interface Async65
Router2(config-if)#encapsulation ppp
Router2(config-if)#dialer in-band
Router2(config-if)#dialer pool-member 1
Router2(config-if)#ppp authentication chap
Router2(config-if)#async default routing

The only thing here that hasn’t appeared in a previous example is the async default routing command. This command allows the async interface to support a routing protocol such as EIGRP. By default, routing protocols are disabled on async interfaces, so you need to enable it.

The number of this particular interface, Async65, wasn’t selected at random. The router automatically assigns a line number to every interface that can be used for terminal access (including VTY lines, AUX lines, and console lines), and the line number varies from router to router, depending on the hardware configuration. So we used the show line command to see which line number corresponded to the AUX port on this router:

Router1#show line
   Tty Typ     Tx/Rx    A Modem  Roty AccO AccI   Uses   Noise  Overruns   Int
     0 CTY              -    -      -    -    -      0       0     0/0       -
    65 AUX   9600/9600  -    -      -    -    -      0       0     0/0       -
*   66 VTY              -    -      -    -    -     10       0     0/0       -
*   67 VTY              -    -      -    -    -     19       0     0/0       -
    68 VTY              -    -      -    -    -      3       0     0/0       -
    69 VTY              -    -      -    -    -      0       0     0/0       -
    70 VTY              -    -      -    -    -      0       0     0/0       -
    71 VTY              -    -      -    -    -      0       0     0/0       -
    72 VTY              -    -      -    -    -      0       0     0/0       -
    73 VTY              -    -      -    -    -      0       0     0/0       -
    74 VTY              -    -      -    -    -      0       0     0/0       -
    75 VTY              -    -      -    -    -      0       0     0/0       -

Line(s) not in async mode -or- with no hardware support:
1-64

Router1#

As you can see, the AUX port is on line 65 on this router. It’s important to do this before you attempt any of the rest of the configuration, so you know what to configure. When you use the AUX port for dial backup, you also need to configure the terminal line information for this physical port:

Router2(config)#line aux 0
Router2(config-line)#modem inout
Router2(config-line)#transport input all
Router2(config-line)#no exec
Router2(config-line)#speed 115200

The first command here is modem inout, which configures the router to allow access to the modem, and vice versa. Then we added the command transport input all so that there are no restrictions on the protocols that may use this port.

The no exec command is extremely important when using async dial, and almost universally ignored in Cisco references. By default, the router will start an EXEC session on your AUX port. So, if you plug a terminal into this port, you will get a login prompt. Unfortunately, your modem doesn’t know what to do with a login prompt. At best, it will just ignore it, so disabling the EXEC session is simply good form. But, at worst, we have seen problems where the modem attempts to respond to the login prompt, the EXEC session interprets this as a bad login attempt and puts up a new prompt, and the modem again attempts to respond. The result can be high CPU utilization and, more importantly, this activity will prevent the router from dialing. We strongly recommend disabling the EXEC session on any async dial ports, as we have done here.

The last command in this section sets the line speed. It’s important to remember that this is the speed between the router and the modem. The actual dial session will have a much lower net speed, likely less than 56Kbps. However, it’s a good idea to make the line speed as fast as the modem can support. This will ensure that you get the best possible speed. Note that the default speed here is only 9.6Kbps—if you don’t increase this value, you will not be able to get the full advantage of the compression capabilities of modern modems.

Recipe 13.1; Recipe 13.2

You want to configure a router to dial only if it sees a physical failure on the primary WAN interface.

Cisco routers can watch the physical signals on an interface and trigger a backup interface if the primary fails. The router will automatically drop the call after the primary circuit comes back up:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#interface Serial0/0
Router1(config-if)#backup delay 0 300
Router1(config-if)#backup interface BRI0/0
Router1(config-if)#encapsulation frame-relay
Router1(config-if)#down-when-looped
Router1(config-if)#exit
Router1(config)#interface Serial0/0.1 point-to-point
Router1(config-subif)#ip address 10.1.1.10 255.255.255.252
Router1(config-subif)#frame-relay interface-dlci 50
Router1(config-subif)#exit
Router1(config)#interface BRI0/0
Router1(config-if)#ip address 10.1.99.55 255.255.255.0
Router1(config-if)#encapsulation ppp
Router1(config-if)#dialer idle-timeout 300
Router1(config-if)#dialer map ip 10.1.99.1 name dialhost broadcast 95551212
Router1(config-if)#dialer load-threshold 50 either
Router1(config-if)#dialer-group 1
Router1(config-if)#isdn switch-type basic-ni
Router1(config-if)#isdn spid1 800555123400 5551234
Router1(config-if)#isdn spid2 800555123500 5551235
Router1(config-if)#ppp authentication chap
Router1(config-if)#ppp multilink
Router1(config-if)#exit
Router1(config)#dialer-list 1 protocol ip permit
Router1(config)#end
Router1#

In this example, the primary WAN interface is a Frame Relay connection. Please see Chapter 10 for more information about Frame Relay configuration. However, this would work as well on just about any kind of interface. The main reason we used Frame Relay is to show that you have to put the backup commands on the physical interface, not on any subinterfaces or virtual interfaces. If this router loses physical signaling on the serial interface, it will automatically bring up the dial backup. The key to this configuration method is the backup command, which you associate with the primary interface:

Router1(config)#interface Serial0/0
Router1(config-if)#backup delay 0 300
Router1(config-if)#backup interface BRI0/0

In this case you can see that the backup interface for this serial port is the ISDN interface, BRI0/0. We also included a backup delay command, which specifies two times. The first parameter tells the router how long it should wait before bringing up the backup after it loses signals on this primary interface. In this case, we don’t want to wait. If there is a failure, we want the backup to activate immediately. However, in some cases, you might want to delay slightly to save money on backup charges in case the primary comes back again right away. So, if you wanted to wait 15 seconds before dialing, you could configure it like this:

Router1(config-if)#backup delay 15 300

The second number tells the router how long to wait after the primary recovers before dropping the dial connection. If you’re using Frame Relay, it can take a minute or more after you see physical signals before there is end-to-end connectivity. So it is important to keep the backup link active until everything has stabilized. Also, a link will sometimes bounce up and down if there are electrical problems. Specifying a sensible delay before dropping the backup link ensures helps with link stability.

We have also included the down-when-looped command on the primary interface:

Router1(config)#interface Serial0/0
Router1(config-if)#down-when-looped

The dial backup will trigger only if this interface line protocol is in a “down” state. Normally, when you put a circuit into a loopback state for testing, the router considers the interface to be in an “up” state, but looped. However, when it’s in this diagnostic state, the circuit will not pass any data. So, by configuring down-when-looped, we ensure that the backup will trigger if somebody runs a loopback test (perhaps unintentionally) on the primary circuit.

In general, we don’t recommend using the backup interface method for dial backup. There are many types of WAN problems in which you will lose connectivity, but you don’t lose physical signaling on the interface. For example, in the Frame Relay case again, there could be a problem in the cloud that causes you to lose your virtual circuit. Or you might be connected to a faulty network termination device that keeps signals active even though it doesn’t have a real connection. The floating static method given in Recipe 13.1 and Recipe 13.2 is much more robust than the backup interface method.

There is another important disadvantage to using the backup interface method. The router will keep backup interfaces disabled until it needs to dial. This causes two problems.

First, it means that you have to wait longer to dial because the router has to first establish physical connectivity with the backup network. In the case of ISDN, this can take 10–15 seconds.

The second problem is that, with ISDN interfaces, you lose the ability to see the state of the ISDN connection. Normally, if an ISDN interface is connected but not dialed, you can use the show isdn status command to verify that it is talking to the carrier’s switch correctly, as we discussed in Recipe 13.1. However, since the backup interface is disabled with the method shown in the current recipe, you can’t easily verify that your backup circuit is working without failing the primary circuit.

There is actually an interesting way to get around this last problem, though. Instead of using a physical interface (such as an ISDN port as we did in this example), you could make the backup interface be a dialer interface, as we discussed in Recipe 13.2. In this case, the dialer interface will remain down when the primary is working, but the ISDN interface will still be up. This means that you will be able to use the various show isdn commands as you can with the other methods.

We do not recommend using the backup interface method for dial backup, but there is one interesting extra option to the backup interface configuration that can be useful in some situations. In addition to triggering the backup circuit when the primary circuit fails, you can configure the router to trigger the backup circuit when the load on the primary circuit gets heavy. This is a form of bandwidth on demand:

Router1(config)#interface Serial0/0
Router1(config-if)#backup load 75 25

This command triggers the dial backup when the load on the primary interface rises to about 75%, and deactivates it when the load drops below 25%. Note, however, that to be really useful as additional bandwidth, you have to make sure that the routing over this new connection makes sense. In particular, it doesn’t help much unless the routing protocol sees the two paths as equal and shares the load between them. This will generally require some careful metric tuning in your routing protocol, and it will almost certainly require that the dial backup circuit terminates on the same router as the primary circuit. Otherwise two-way load sharing will be very difficult to arrange.

Recipe 13.1; Chapter 10

You want to use Cisco’s dialer watch feature to trigger dial backup.

The dialer watch feature allows the router to track a particular destination IP address in its routing table. If all of the tracked IP addresses disappear from the routing table, the router automatically triggers the dial backup connection:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#interface BRI0/0
Router1(config-if)#ip address 10.1.99.55 255.255.255.0
Router1(config-if)#encapsulation ppp
Router1(config-if)#dialer map ip 10.1.1.0 name dialhost broadcast 95551212
Router1(config-if)#dialer map ip 10.2.0.0 name dialhost broadcast 95551212
Router1(config-if)#dialer map ip 10.1.99.1 name dialhost broadcast 95551212
Router1(config-if)#dialer load-threshold 50 either
Router1(config-if)#dialer-group 1
Router1(config-if)#dialer watch-group 1
Router1(config-if)#dialer watch-disable 300
Router1(config-if)#isdn switch-type basic-ni
Router1(config-if)#isdn spid1 800555123400 5551234
Router1(config-if)#isdn spid2 800555123500 5551235
Router1(config-if)#ppp authentication chap
Router1(config-if)#ppp multilink
Router1(config-if)#exit
Router1(config)#username dialhost password dialpassword
Router1(config)#dialer-list 1 protocol ip list 101
Router1(config)#access-list 101 deny eigrp any any
Router1(config)#access-list 101 permit ip any any
Router1(config)#router eigrp 55
Router1(config-router)#network 10.0.0.0
Router1(config-router)#exit
Router1(config)#dialer watch-list 1 ip 10.1.1.0 255.255.255.0
Router1(config)#dialer watch-list 1 ip 10.2.0.0 255.255.0.0
Router1#

This configuration is similar to that of Recipe 13.1, but this time the router uses the dialer watch feature to trigger the dial backup. The dialer watch-group command configures the backup interface to belong to a particular group. Usually you would configure only one such group on a router, but there is nothing to prevent you from having several different watch groups, each with different dial interfaces.

The watch group in this example looks for two prefixes in the routing tables, 10.1.1. 0/24 and 10.2.0.0/16. If both of these routes drop out of the routing table, the router will automatically bring up the dial interface. Note that all of the watched routes must disappear before the router will dial.

We have configured several dialer map statements for this example. The same dialer map statement that we used in Recipe 13.1 defines the basic IP routing of the interface. We have also included two watch lists, one for each of the watched IP addresses.

We used the same dialer list configuration here as we did in Recipe 13.1. This is because we still don’t want routine EIGRP packets to bring up the dial interface.

After it triggers the dial backup, the dialer watch configuration will keep track of the primary interface by periodically looking for the watched IP addresses in its routing table. The dialer watch feature will consider the primary circuit active only if the watched routes exist in the routing table, and do not point through the dial interface. We have configured a delay of 300 seconds before the router drops the dial backup after deciding (based on the routing tables) that the primary interface has recovered:

Router1(config-if)#dialer watch-disable 300

In general, we still prefer to use floating static routes to trigger dial backup, as in Recipe 13.1 and Recipe 13.2. This is because they offer greater control and flexibility.

Recipe 13.1; Recipe 13.2

You want to ensure that the dial backup line disconnects properly when the primary link recovers.

Sometimes funny things happen when the primary link comes back and the backup link has not yet disconnected. These problems are usually due to poor routing metrics, which can cause at least one of the routers to prefer the dial path, even if the primary is available. The easiest way to handle these problems is to use bandwidth commands to ensure that the primary is the better path:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#interface Serial0/0.1 point-to-point
Router1(config-subif)#bandwidth 56
Router1(config-subif)#exit
Router1(config)#interface BRI0/0
Router1(config-subif)#bandwidth 54
Router1(config-subif)#end
Router1#

This example assumes that you have a Frame Relay connection using a 56Kbps primary link, and an ISDN dial backup connection. The problem is that the default ISDN interface bandwidth is 64Kbps. So, if both the primary and the backup are active at the same time, the routing protocol will see the backup link as the preferred path. As a result, there will always be interesting traffic flowing through the backup link, and the router will fail to disconnect the dialup session properly.

To address this problem, we have configured a bogus bandwidth on the BRI interface. This will ensure that if both primary and backup are active simultaneously, the primary will be the better path. The only stipulation is that the value must be lower for the backup path.

Actually, this change affects only the routing decisions for traffic going from this router to the dial router. It is not difficult to get a situation where traffic from the branch to the hub site takes the primary path, while outbound packets to the branch take the backup path. So you have to be careful to adjust the values on both ends.

Dial backup situations can get more complicated in some networks. Perhaps the most insidious problems happen when the router responsible for the primary WAN link summarizes a large number of branch IP address ranges. This summarization is normally a good thing because it simplifies the global routing tables and improves overall performance.

However, suppose the branch has a LAN segment that uses 10.11.100.0/24. And suppose the primary WAN router connects to many branches, offering the network core only a summary route that describes all of the branches as 10.11.0.0/16. When the primary WAN link for this branch breaks, the branch router dials to a dedicated dial backup router. The dynamic routing works because, although the primary WAN router advertises a summary route that includes this branch’s LAN address, the backup router advertises a more specific route. So other devices in the network core can route to the branch using the more specific route from the backup router.

The problem appears when the primary link recovers. There are now two paths available. By adjusting bandwidths as shown in this recipe, the branch router knows that it should switch to using the primary link. But the rest of the network doesn’t see any change. The primary router continues to present only a summary route for all of its branches, and the dial backup host still presents the more specific route for this particular branch. So all outbound traffic to the branch still uses the backup link.

We know of no simple solution to this problem, except to ensure that the branch router is responsible for dropping the dial connection with an appropriate timeout. The alternatives are to avoid summarization or to have the dial backup router be the same physical device as the primary WAN router. You can help the branch router to switch to the primary, though, by ensuring that the dial host router sends only a default route, rather than a full routing table. This way, when the primary circuit recovers, the branch router will use the more specific routes that it learns through the primary circuit, thus quickly removing any interesting packets from the backup link. Then the branch router can take the responsibility for dropping the dial connection.

You want to check on the dialer status of a router.

Here are some useful commands for looking at the status of a dial backup link. For dial backup that uses the floating static or dialer watch type configurations, you can use the show dialer command:

Router1#show dialer

For dial configurations that use the backup interface configuration, you can use the show backup command:

Router1#show backup

And, for backup configurations that use ISDN, you can get some additional information from the show isdn status, show isdn active, and show isdn history commands:

Router1#show isdn status
Router1#show isdn active
Router1#show isdn history

The show dialer command provides a lot of useful information about existing dial sessions as well as some historical statistics:

Router1#show dialer
BRI0 - dialer type = ISDN

Dial String      Successes   Failures     Last DNIS    Last status
0 incoming call(s) have been screened.
0 incoming call(s) rejected for callback.

BRI0:1 - dialer type = ISDN
Idle timer (300 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=10.1.99.55, d=224.0.0.10)
Interface bound to profile Dialer1
Current call connected 00:03:18
Connected to 95551212 (dialhost)
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

Dialer1 - dialer type = DIALER PROFILE
Load threshold for dialing additional calls is 100
Idle timer (300 secs), Fast idle timer (20 secs)
Wait for carrier (30 secs), Re-enable (15 secs)
Dialer state is data link layer up
Number of active calls = 1
Number of active circuit switched calls = 0

Dial String      Successes   Failures    Last DNIS   Last status
95551212               2          0    00:03:19       successful   Default
Router1#

There is a lot of useful information in this output. First, notice that there is an active dial session on the first B-channel of this ISDN BRI interface, BRI0:1. It has been connected for a little more than three minutes, and you can see the dial string that represents the remote telephone number. The second ISDN B-channel, BRI0:2, is not connected, presumably because the router has yet not seen the minimum traffic threshold that we specified for bringing up the second channel, or perhaps because it isn’t configured for PPP multilink.

But there is another extremely important piece of information here. Note the line marked “Dial reason,” which shows the source and destination IP addresses of the packet that originally caused the router to start the dial session. In this case, the source IP address is 10.1.99.55, which is the IP address of the dial interface itself. The destination IP address is 224.0.0.10, which is extremely interesting because this is the multicast IP address that EIGRP uses to talk between routers. This is fine if we intended for this dial connection to remain up all the time. However, if this router was supposed to only dial when a primary link failed, looking at this output should tell you that the dialer list configuration is wrong.

The bottom of the display includes some historical information about each of the configured dial strings, and lists how often the router has been able to connect successfully using each string. In this case there is only one dial string, but if there were several, they would all appear with their respective totals.

The show backup command is only useful when you use the backup interface configuration, which is discussed in Recipe 13.4:

Router1#show backup


Primary Interface  Secondary Interface   Status
-----------------  -------------------   ------
Serial0/0          BRI0/0                active backup

In this case the interface BRI0/0 is operating as an active backup for the primary interface, Serial0/0. If the primary interface is working properly, the Status column will say “normal operation.” In this case, the backup interface will go into a standby mode:

Router1#show int bri0/0
BRI0 is standby mode, line protocol is down
  Hardware is BRI
  Internet address is 10.1.99.55/24
  MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation PPP, loopback not set
  Last input never, output never, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: weighted fair
  Output queue: 0/1000/64/0 (size/max total/threshold/drops)
     Conversations  0/0/16 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 48 kilobits/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     0 packets input, 0 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
     0 packets output, 0 bytes, 0 underruns
     0 output errors, 0 collisions, 7 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
Router1#

If you are using ISDN for dial backup in any of the configurations discussed, you can get other useful information through the various show isdn commands:

Router1#show isdn status
Global ISDN Switchtype = basic-ni
ISDN BRI0/0 interface
     dsl 0, interface ISDN Switchtype = basic-ni
    Layer 1 Status:
     ACTIVE
    Layer 2 Status:
     TEI = 89, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
     TEI = 90, Ces = 2, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
     TEI 89, ces = 1, state = 8(established)
         spid1 configured, spid1 sent, spid1 valid
         Endpoint ID Info: epsf = 0, usid = 70, tid = 1
     TEI 90, ces = 2, state = 8(established)
         spid2 configured, spid2 sent, spid2 valid
         Endpoint ID Info: epsf = 0, usid = 71, tid = 2
    Layer 3 Status:
     1 Active Layer 3 Call(s)
    Activated dsl 0 CCBs = 1
     CCB:callid=801A, sapi=0, ces=1, B-chan=1, calltype=DATA
    The Free Channel Mask:  0x80000002
Total Allocated ISDN CCBs = 2
Router1#

This example shows a single active call on one of the ISDN B-channels. Another useful piece of information is provided by the lines that say that each SPID was configured, sent, and considered “valid” by the switch. In this case, we were connected to a basic-ni type switch, which requires us to manually configure SPIDs. So it is important to check that the switch accepted these values.

If there are active calls, the output of show isdn active can also be useful:

Router1#show isdn active
--------------------------------------------------------------------------------
                                ISDN ACTIVE CALLS
--------------------------------------------------------------------------------
History table has a maximum of 100 entries.
History table data is retained for a maximum of 15 Minutes.
--------------------------------------------------------------------------------
Call    Calling      Called       Remote  Seconds Seconds Seconds Charges
Type    Number       Number       Name    Used    Left    Idle    Units/Currency
--------------------------------------------------------------------------------
Out             +95551212       dialhost      207               0      0
--------------------------------------------------------------------------------

Router1#

Here you can see that there is a single active call. This output also tells you exactly how long the call has been connected, and whether it was an in or outbound connection. You can also get some potentially useful historical information about previous calls from the show isdn history command:

Router1#show isdn history
--------------------------------------------------------------------------------
                                ISDN CALL HISTORY
--------------------------------------------------------------------------------
History table has a maximum of 100 entries.
History table data is retained for a maximum of 15 Minutes.
--------------------------------------------------------------------------------
Call    Calling      Called       Remote  Seconds Seconds Seconds Charges
Type    Number       Number       Name    Used    Left    Idle    Units/Currency
--------------------------------------------------------------------------------
Out                                         Failed
Out             +95551212       dialhost       20                      0
Out             +95551212       dialhost      219               0      0
--------------------------------------------------------------------------------

Router1#

This router has attempted to make three outbound calls. The first call failed, the second lasted 20 seconds before disconnecting, and the third lasted 219 seconds. This output can be particularly useful if you think that your router might be dialing too often, or that it might be frequently dialing and dropping calls. You can also look in the router’s logging buffer for log messages. By default, every time the router dials, it will generate at least one log message. Please refer to Chapter 18 for more information on logging.

Your dial backup is not behaving properly and you want to debug it to isolate and resolve the problem.

The most common reasons for failed dial backup calls are incorrect dial strings and PPP authentication problems. You can easily diagnose both of these problems with this command:

Router1#debug ppp authentication

Here is another useful command for diagnosing problems with dialer configurations:

Router1#debug dialer

When you use CHAP authentication with PPP, as we have done throughout this chapter, it is relatively easy to debug most common problems. We like to use the debug ppp authentication command because it pinpoints the most frequent problems:

Jun 28 14:04:05.211: BR0/0:1 PPP: Phase is AUTHENTICATING, by both
Jun 28 14:04:05.211: BR0/0:1 CHAP: O CHALLENGE id 1 len 33 from "Router1"
Jun 28 14:04:05.211: BR0/0:1 AUTH: Started process 0 pid 60
Jun 28 14:04:05.235: BR0/0:1 CHAP: I CHALLENGE id 35 len 33 from "dialhost"
Jun 28 14:04:05.235: BR0/0:1 CHAP: O RESPONSE id 35 len 33 from "Router1"
Jun 28 14:04:05.267: BR0/0:1 CHAP: I SUCCESS id 35 len 4
Jun 28 14:04:05.271: BR0/0:1 CHAP: I RESPONSE id 1 len 33 from "dialhost"
Jun 28 14:04:05.271: BR0/0:1 CHAP: O SUCCESS id 1 len 4

This shows the PPP authentication challenge and response handshake between two routers. This is one of the first places to look when you have dialup sessions that refuse to connect. In this particular trace, the router Router1 has dialed to dialhost. Upon connection, both routers present a password challenge. In this case, you can see that both routers responded correctly, and authentication was successful. You should see a similar trace on both routers if everything is working properly.

If you enable this debug command and see nothing, then you know that the routers are not reaching this point, indicating that there is a problem at a lower layer. It would then be a good idea to start by making sure that you have the correct dial string, which you can verify by simply looking at the state of the dial interface on the receiving end to see if it picks up the phone when you call from the other end.

Another useful command to see if your router is dialing appropriately is debug dialer:

Jun 28 14:04:02.691: BR0/0 DDR: rotor dialout [priority]
Jun 28 14:04:02.691: BR0/0 DDR: Dialing cause ip (s=10.1.99.55, d=10.1.99.1)
Jun 28 14:04:02.691: BR0/0 DDR: Attempting to dial 95551212
Jun 28 14:04:05.311: Di1 DDR: dialer protocol up

Here you can see that the router is dialing because of an IP packet, and the output shows the source and destination IP addresses of this packet. It also shows the dial string, the interface, and the fact that it connected successfully.