ISDN Technologies

From the CCNA to the CCIE, ISDN is one of the most important technologies you'll work with. It's also very common in the field; ISDN is frequently used as a backup connection in case an organization's Frame Relay connections go down. Therefore, it's important to know ISDN basics not only for your particular exam, but for job success.

ISDN is used between two Cisco routers that have BRI or PRI interfaces. Basically, with ISDN one of the routers places a phone call to the other router. It is vital to understand not only what causes one router to dial another, but what makes the link go down. Why? Since ISDN is basically a phone call from one router to another, you're getting billed for that phone call -- by the minute. If one of your routers dials another, and never hangs up, the connection can theoretically last for days or weeks. The network manager then receives an astronomical phone bill, which leads to bad things for everyone involved!

Cisco routers use the concept of interesting traffic to decide when one router should call another. By default, there is no interesting traffic, so if you don't define any, the routers will never call each other.

Interesting traffic is defined with the dialer-list command. This command offers many options, so you can tie interesting traffic down not only to what protocols can bring the link up, but what the source, destination, or even port number must be for the line to come up. One common misconception occurs once that link is up. Interesting traffic is required to bring the link up, but by default, any traffic can then cross the ISDN link.

What makes the link come down? Again, the concept of interesting traffic is used. Cisco routers have an idle-timeout setting for their dialup interfaces. If interesting traffic does not cross the link for the amount of time specified by the idle-timeout, the link comes down.

To summarize: Interesting traffic brings the link up; by default, any traffic can cross the link once it's up; a lack of interesting traffic is what brings the link down.

We have looked at how and why one router dials another using ISDN. Just as important is knowing what keeps the link up once it is dialed.

Why? Because ISDN acts as a phone call between two routers, and it’s billed that way to your client. The two routers that are connected by this phone call may be located in different area codes, so now we’re talking about a long distance phone call.

If your ISDN link does not have a reason to disconnect, the connection could theoretically last for days or weeks before someone realizes what’s going on. This is particularly true when the ISDN link is used as a backup for another connection type, as is commonly the case with Frame Relay. When the Frame Relay goes down, the backup ISDN link comes up; when the Frame Relay link comes back not billed for all that time.

To understand why an ISDN link stays up when it’s not needed, we have to understand why it stays up period. Cisco’s ISDN interfaces use the idle-timeout to determine when an ISDN link should be torn down. By default, this value is two minutes, and it also uses the concept of interesting traffic.

Once interesting traffic brings the link up, by default all traffic can cross the link. However, only interesting traffic resets the idle-timeout. If no interesting traffic crosses the link for two minutes, the idle-timer hits zero and the link comes down.

If the protocol running over the ISDN link is RIP version 2 or EIGRP, the most efficient way to prevent the routing updates from keeping the line up is expressly prohibiting their multicast routing update address in the access-list that is defining interesting traffic. Do not prevent them from crossing the link entirely, or the protocol obviously won’t work correctly.

With OSPF, Cisco offers the ip ospf demand-circuit interface-level command. The OSPF adjacency will form over the ISDN link, but once formed, the Hello packets will be suppressed. However, the adjacency will not be lost. A check of the adjacency table with show ip ospf adjacency will show the adjacency remains at Full, even though Hellos are no longer being sent across the link. The ISDN link can drop without the adjacency being lost. When the link is needed, the adjacency is still in place and data can be sent without waiting for OSPF to go through the usual steps of forming an adjacency.

This OSPF command is vital for Cisco certification candidates at every level, but is particularly important for CCNA candidates. Learn this command now, get used to the fact that the adjacency stays up even though Hellos are suppressed, and add this valuable command to your Cisco toolkit.

Now we know how the ISDN link comes up (interesting traffic), and some scenarios that might cause the link to stay up, we need to look at ISDN authentication schemes. The two methods Cisco certification candidates must be familiar with are PAP and CHAP.

Password Authentication Protocol (PAP) sends the username and password over the ISDN link in clear-text. Sending any passwords over any WAN link in clear-text is generally a bad idea, but it’s important to know you have this option.

Regarding both PAP and CHAP, it’s a common misunderstanding that each side must authenticate the other. PAP and CHAP both support bidirectional and unidirectional authentication; that is, R1 can authenticate R2 without R2 necessarily authenticating R1. It’s more common to use unidirectional authentication in a lab environment than a production network, but keep in mind that bidirectional authentication is an option, not a requirement.

The configurations of PAP and CHAP do have their similarities. For both, you’ll configure a username/password combination in global configuration mode. Newcomers to ISDN sometimes put the local router name in for the username; remember that the remote router name is the username.

The only real advantage of PAP over CHAP comes in the password configuration. Since PAP actually sends the password as a whole over the link, the two routers can send different passwords during authentication. The operation of CHAP requires that both routers use the same password, and we’ll see why in tomorrow’s article.

Under the BRI interface, you’ll enter encapsulation ppp and ppp authentication pap.

So far, your authentication scheme looks like this:

username R2 password CCNA

Int bri0
encapsulation ppp
ppp authentication pap

PAP requires an extra command at this point. The ppp pap sent-username command is required under the interface, indicating the username and password this router will be sending to the remote router.

Int bri0
encapsulation ppp
ppp authentication pap
ppp pap sent-username R1 password CISCO

I always encourage CCNA and CCNP candidates to use as many debugs as possible when working in their lab, since these commands show us how things work. For any PPP authentication, always run debug ppp negotiation before sending interesting traffic to trigger the call. Watching exactly how PAP and CHAP work give you a much better understanding of what’s going on “behind the command”, and makes you a stronger candidate and a stronger networking engineer.

We have learned that PPP has two main methods of authentication that Cisco certification candidates need to know how to configure: PAP and CHAP.

PAP has very few advantages over CHAP. PAP passwords are carried over the line in clear-text, which in today’s world is a very bad idea. PAP configuration also requires additional configuration with the “ppp pap sent-username” command, so anyone who can see your running configuration can also see the PAP password.

The only advantage PAP has over CHAP is a slim one. With PAP, a different password can be used by the each of the routers involved in the authentication. CHAP requires that the password be the same. Why? We’ll see as we examine CHAP authentication.

The First Step to Configuring CHAP

CHAP requires you to configure a username / password combination for any remote device that will be involved in authentication. (We’re assuming that the routers have already been configured with their names via the global hostname command.) Both routers will use the password CISCO.

R1:

username R2 password CISCO

int bri0
encapsulation ppp
ppp authentication chap

R2:

username R1 password CISCO

int bri0
encapsulation ppp
ppp authentication chap

Why CHAP Authentication Requires The Same Password On Both Routers

Remember how PAP sends the password over the line in clear-text? CHAP does not actually send the password over the line at all. Instead, CHAP runs a hash algorithm using the password and a random number. It is the result of this hash that is passed over the link. The remote router receives the hash result, and runs the exact same algorithm. If the result is the same, the authentication attempt will be successful. If the result is different, the authentication will fail. For this reason, the passwords must be the same.

Debug The Connection If Authentication Fails

Since two passwords are involved, the chances of one of the passwords being mistyped doubles. If you configure CHAP and the link dials but drops almost immediately, there’s an authentication problem. Run debug ppp negotiation and attempt to dial the line again. The output of this particular debug will show you where the problem is.

The major reason I recommend getting your hands on real Cisco equipment rather than a simulator is that real Cisco routers give you the chance to practice and learn show and debug commands.

The knowledge you acquire from debugs is invaluable. Frankly, it’s this knowledge that puts you above the “average” CCNA who doesn’t have that hands-on experience. Watching debugs in action also gives you a head start on the CCNP. Since 90 – 95% of CCNAs go on to pursue the CCNP, it’s a great idea to get started with debugs now.

Don’t make the mistake of waiting until you’re studying for your CCNP and CCIE to start learning debugs and shows. The work you do for the CCNA is the foundation for everything you’ll do in the future.

Never, ever, ever practice debugs on a production network. There are debugs that will give you so much information that the router actually becomes overloaded and then locks up. Never practice debugs on a production network.

It’s important to know the proper show and debug commands for ISDN for several reasons. First, by watching ISDN in operation, you can see its processes and better understand what’s going on. Secondly, it’s difficult if not impossible to properly troubleshoot ISDN without knowing the proper show and debug commands. (It’s easy to overlook an ISDN authentication error just by looking at the configuration, but running debug ppp negotiation will quickly show you where the problem lies.)

Let’s take a look at the ISDN show and debug commands that every CCNA and CCNP should know.

Show ISDN Status

If you only know one ISDN show command, it’s got to be this one. Always use this command after configuring your ISDN switch type and any necessary SPIDs. The command will show you the switch type (and will also show you if you did not configure a switch type), and whether the SPIDs you entered are valid:

R1#show isdn status
Global ISDN Switchtype = basic-ni < ISDN switch type is correctly configured.>
ISDN BRI0 interface
dsl 0, interface ISDN Switchtype = basic-ni
Layer 1 Status:
ACTIVE
Layer 2 Status:
TEI = 91, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
TEI = 92, Ces = 2, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
Spid Status:
TEI 91, ces = 1, state = 5(init)
spid1 configured, no LDN, spid1 sent, spid1 valid < SPID 1 is good.>
Endpoint ID Info: epsf = 0, usid = 1, tid = 1
TEI 92, ces = 2, state = 5(init)
spid2 configured, no LDN, spid2 sent, spid2 valid < SPID 2 is good.>
Endpoint ID Info: epsf = 0, usid = 3, tid = 1
Layer 3 Status:
0 Active Layer 3 Call(s)
Activated dsl 0 CCBs = 0
The Free Channel Mask: 0x80000003

Once in a while, you’ll get this output from show isdn status:

R2#show isdn status
The current ISDN Switchtype = basic-ni1
ISDN BRI0 interface
Layer 1 Status:
ACTIVE
Layer 2 Status:
Layer 2 NOT Activated
Spid Status:
TEI Not Assigned, ces = 1, state = 3(await establishment)
spid1 configured, no LDN, spid1 NOT sent, spid1 NOT valid
TEI Not Assigned, ces = 2, state = 1(terminal down)
spid2 configured, no LDN, spid2 NOT sent, spid2 NOT valid

Check your running configuration, and if the SPIDs look good, simply close the BRI interface and open it again. Then run show ISDN status again. If you then see “spids are valid”, you’re ready to proceed. If you still see a message that the spids are invalid, you’ve most likely mistyped the SPID.

Show Access-List < ACL number>

What’s this command got to do with ISDN? Everything.

Remember how the ISDN link comes up in the first place? Interesting traffic. By default, there is no interesting traffic. You define interesting traffic with the dialer-list and dialer-group commands, AND the access-list command. If you have a problem with your link never coming up or with it coming up and staying up, use this command to see what traffic has been defined as interesting.

Show Dialer

Another helpful command to determine why an ISDN link is coming up and staying up. This command shows you how many successful calls and failed calls have taken place, what the current idle-timer value is (by default, it’s 120 seconds), and most importantly, what the source and destination was for the current interesting traffic:

R1#show dialer
BRI0 - dialer type = ISDN

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=172.12.21.1, d=172.12.21.2) < s=Source, d=Destination
>
Time until disconnect 62 secs
< Idle timer, reset by interesting traffic only >
Connected to 8358662 (R2)

Here, you can see that the idle-timer value is at its default, that there are 62 seconds left until the link comes down (unless interesting traffic resets the timer), and that the source of the interesting traffic was 172.12.21.1 and the destination is 172.12.21.2. If that destination is the multicast address of a routing protocol – say, 224.0.0.5 for OSPF – you know what traffic is keeping the line up.

Show ISDN History

Want to see what calls have been made in the last 15 minutes? Just run this command. It’s helpful if you’re walking in to an ISDN troubleshooting situation and want to see what calls have been made.

Debug PPP Negotiation

Not only do you need to know this command for your CCNA and CCNP exams, you MUST know it to be an effective ISDN troubleshooter.

When PPP authentication is first configured, it’s simple to mistype a password, or forget to configure a “username / password” combination. Instead of continually reading your running configuration to see what the problem is, run debug ppp negotiation and send a ping to bring the line up. You’ll quickly see where the problem is.

R2#debug ppp negotiation
PPP protocol negotiation debugging is on
R2#ping 172.12.21.1

BR0:1 PPP: Phase is AUTHENTICATING, by both
< Both routers are authenticating the other with CHAP.>
BR0:1 CHAP: O CHALLENGE id 1 len 23 from "R2"
< R2 is sending a challenge to the remote router. O = “outgoing”.>
BR0:1 CHAP: I CHALLENGE id 1 len 23 from "R1"
< A CHAP challenge has come in from R1. I = “incoming”>
BR0:1 CHAP: O RESPONSE id 1 len 23 from "R2"
< R2 is sending a response to the challenge.>
BR0:1 CHAP: I SUCCESS id 1 len 4
< A success message has come in , indicating the challenge was successfully met.>
BR0:1 CHAP: I RESPONSE id 1 len 23 from "R1"
< A response to the challenge sent to R1 is now coming in.>
BR0:1 CHAP: O SUCCESS id 1 len 4
< The challenge was successfully met by R1, and a success message is sent.>

By mastering these simple ISDN show and debug commands, you increase your chances of passing the CCNA and CCNP exams greatly, and vastly improve your on-the- job skills.

This article was contributed by Chris Bryant, CCIE #12933, who is the owner of The Bryant Advantage. You can visit his site at www.thebryantadvantage.com