ISDN is a vital topic for today’s CCNA and CCNP candidates, especially for the ICND and Intro exams – you’ve got to know ISDN inside and out to pass those exams. Naturally you want to include it in your home lab. What many candidates don’t realize is that you can’t connect two Cisco routers directly via their Basic Rate Interface (BRI) interfaces you’ve got to have another device between them called an ISDN simulator.

An ISDN simulator is not one of those software programs pretending to be routers (”router simulators”) this is a piece of hardware that acts as the telephone company in your home lab. Older simulators come with preprogrammed phone numbers and SPIDs, where newer ones let you program the phone numbers you want to use. Either way, an ISDN simulator is great for your CCNA/CCNP home lab, because you can practice dial scenarios that actually work. And you get to troubleshoot the ones that don’t, which is also important to learn! )

You don’t need any special cables or connectors you just connect both of your routers’ BRI interfaces to the ISDN simulator with a straight-through cable and you’re ready to go.
Read the full story

To earn your Cisco CCNA and CCNP certifications, you’ve got to master ISDN – and despite what some people say, there’s still a lot of ISDN out there that needs to be supported. And when it comes to troubleshooting ISDN, there’s a lot to look at. Is the correct ISDN switchtype configured? Are the dialer map statements correct? What about the dialer-group and dialer-list commands? And that’s just the start.

I always say that all troubleshooting starts at Layer 1, the Physical layer of the OSI model. The usual method of troubleshooting ISDN is sending pings across the link, but the connection can be tested without using pings or even before assigning IP addresses to the BRI interfaces!

It’s a good idea to place these test calls before configuring the interfaces – that way, you know you’ve got a valid connection before beginning the configuration (and there’s a lot of config to go along with ISDN!)

To place a test call without using pings, use the isdn call interface command.
Read the full story

Dialer Watch is a vital part of your CCNA and CCNP studies, particularly for the BCRAN exam, but it’s one of the most misunderstood technologies as well. To help you pass the CCNA and CCNP certification exams, here’s a detailed look at Dialer Watch.

Dialer Watch allows you to configure a route or routes as “watched” when the watched route leaves the routing table and there is no other valid route to that specific destination, the ISDN link will come up. In the following example, R1 and R2 are connected by both a Frame Relay cloud over the 172.12.123.0 /24 network and an ISDN cloud using the 172.12.12.0 /24 network. The routers are running OSPF over the Frame cloud, and R1 is advertising its loopback of 1.1.1.1/32 as well as an Ethernet segment, 10.1.1.0/24, via OSPF. R2 has both of these routes in its OSPF table, as shown below.

R2#show ip route ospf

1.0.0.0/32 is subnetted, 1 subnets

O 1.1.1.1 [110/65] via 172.12.123.1, 00:00:07, Serial0

10.0.0.0/24 is subnetted, 1 subnets

O 10.1.1.0 [110/128] via 172.12.123.1, 00:00:08, Serial0

We want R2 to place a call to R1 if either the loopback or Ethernet networks leave R2’s routing table, but we don’t want to have to depend on interesting traffic. That dictates the use of Dialer Watch.

First, configure the list of watched routes with dialer watch-list. Only one of the watched routes needs to leave the routing table for the ISDN link to come up. In this example, R2 will watch both routes from its OSPF routing table.
Read the full story

You may run into situations where a router in a remote location needs to dial in to a central router, but the toll charges are much higher if the remote router makes the call. This scenario is perfect for PPP Callback, where the callback client places a call to a callback server, authentication takes place, and the server then hangs up on the client! This ensures that the client isn’t charged for the call. The server then calls the client back.

In the following example, R2 has been configured as the client and R1 is the callback server. Let’s look at both configurations and the unique commands PPP Callback requires.
Read the full story

ISDN is a huge topic on both your Cisco CCNA and BCRAN CCNP exams. While many ISDN topics seem straightforward, it’s the details that make the difference in the exam room and working with ISDN in production networks. Configuring and troubleshooting multilink PPP is just one of the skills you’ll need to pass both of these demanding exams.

With BRI, we’ve got two B-channels to carry data, and both of them have a 64-kbps capacity. You might think it would be a good idea to have both channels in operation before one reaches capacity, and it is a great idea Problem is, it’s not a default behavior of ISDN. The second b-channel will not begin to carry traffic until the first one reaches capacity.

With Multilink PPP (MLP), a bandwidth capacity can be set that will allow the second b-channel to bear data before the first channel reaches capacity. The configuration for MLP is simple, but often misconfigured. We’ll use our good friend IOS Help to verify the measurement this command uses.
Read the full story

As a CCNA and/or CCNP candidate, you’ve got to be able to spot situations where Cisco router features can save your client money and time. For example, if a spoke router is calling a hub router and the toll charges at the spoke site are higher than that of the hub router, having the hub router hang up initially and then call the spoke router back can save the client money (and make you look good!)

A popular method of doing this is using PPP callback, but as we all know, it’s a good idea to know more than one way to do things in Cisco World! A lesser-known but still effective method of callback is Caller ID Screening & Callback. Before we look at the callback feature, though, we need to know what Caller ID Screening is in the first place!

This feature is often referred to simply as “Caller ID”, which can be a little misleading if you’ve never seen this service in operation before. To most of us, Caller ID is a phone service that displays the source phone number of an incoming call. Caller ID Screening has a different meaning, though. Caller ID Screening on a Cisco router is really another kind of password – it defines the phone numbers that are allowed to call the router.

The list of acceptable source phone numbers is created with the isdn caller command. Luckily for us, this command allows the use of x to specify a wildcard number. The command isdn caller 555xxxx results in calls being accepted from any 7-digit phone number beginning with 555, and rejected in all other cases. We’ll configure R2 to do just that and then send a ping from R1 to R2. To see the results of the Caller ID Screening, debug dialer will be run on R1 before sending the ping. I’ve edited this output, since the output you see here will be repeated fire times – once for each ping packet.

R2(config-if)#isdn caller 555xxxx

R1#debug dialer

Dial on demand events debugging is on

R1#ping 172.12.12.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 172.12.12.2, timeout is 2 seconds:

03:30:25: BR0 DDR: Dialing cause ip (s=172.12.12.1, d=172.12.12.2)

03:30:25: BR0 DDR: Attempting to dial 8358662.

Success rate is 0 percent (0/5)

R1 doesn’t give us any hints as to what the problem is, but we can see that the pings definitely aren’t going through. On R2, show dialer displays the number of screened calls.

R2#show dialer

BRI0 – dialer type = ISDN

Dial String Successes Failures Last DNIS Last status

8358661 1 0 00:03:16 successful

7 incoming call(s) have been screened.

0 incoming call(s) rejected for callback.

The callback option mentioned in the last line shown above enables the router to reject a phone call, and then call that router back seconds later.

R2 will now be configured to initially hang up on R1, and then call R1 back.

R2(config-if)#isdn caller 8358661 callback

R1 will now ping R2. The pings aren’t returned, but seconds later R2 calls R1 back.

R1#ping 172.12.12.2

Success rate is 0 percent (0/5)

R1#

03:48:12: BRI0: wait for isdn carrier timeout, call id=0×8023

R1#

03:48:18: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up

R1#

03:48:18: BR0:1 DDR: dialer protocol up

R1#

03:48:19: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to up

R1#

03:48:24: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 8358662 R2

show dialer on R2 shows the reason for the call to R1 is a callback return call.

R2#show dialer

BRI0 – dialer type = ISDN

Dial String Successes Failures Last DNIS Last status

8358661 3 0 00:00:48 successful

7 incoming call(s) have been screened.

10 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: Callback return call

Time until disconnect 71 secs

Connected to 8358661 (R1)

The drawback to Caller ID Callback is that not all telco switches support it, so if you have the choice between this and PPP Callback, you’re probably better off with PPP Callback. However, it’s always a good idea to know more than one way to get things done with Cisco!