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

To pass the BSCI exam and move one step closer to CCNP certification success, you’ve got to know how and when to use debug commands to troubleshoot and verify network operations. While you should never practice debug commands on a production network, it’s important to get some hands-on experience with them and not rely on “router simulators” and books to learn about them.

When it comes to RIP, “debug ip rip” is the primary debug to use. This debug will show you the contents of the routing update packets, and is vital in diagnosing RIP version mismatches and routing update authentication issues.

You know how to use the variance command to configure unequal-cost load-sharing with IGRP, but IGRP has no topology table that will give you the feasible successor metrics you need. With IGRP, you need to use the “debug ip igrp transactions” command to get these vital metrics.
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

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

Earning your Cisco CCNA and CCNP is a tough proposition, and part of that is the fact that you quickly learn that there’s usually more than one way to do things with Cisco routers – and while that’s generally a good thing, you better know the ins and outs of all options when it comes to test day and working on production networks. Working with Frame Relay subinterfaces and split horizon is just one such situation.

One reason for the use of subinterfaces is to circumvent the rule of split horizon. You recall from your CCNA studies that split horizon dictates that a route cannot be advertised out the same interface upon which it was learned in the first place. In the following example, R1 is the hub and R2 and R3 are the spokes. All three routers are using their physical interfaces for frame relay connectivity, and they are also running RIPv2 172.12.123.0 /24. Each router is also advertising a loopback interface, using the router number for each octet.

R1(config)#int s0

R1(config-if)#ip address 172.12.123.1 255.255.255.0

R1(config-if)#no frame inverse

R1(config-if)#frame map ip 172.12.123.2 122 broadcast

R1(config-if)#frame map ip 172.12.123.3 123 broadcast

R1(config-if)#no shut

R2(config)#int s0

R2(config-if)#encap frame

R2(config-if)#no frame inver

R2(config-if)#frame map ip 172.12.123.1 221 broadcast

R2(config-if)#frame map ip 172.12.123.3 221 broadcast

R2(config-if)#ip address 172.12.123.2 255.255.255.0

R3(config)#int s0

R3(config-if)#encap frame

R3(config-if)#no frame inver

R3(config-if)#frame map ip 172.12.123.1 321 broadcast

R3(config-if)#frame map ip 172.12.123.2 321 broadcast

R3(config-if)#ip address 172.12.123.3 255.255.255.0

R1#show ip route rip

2.0.0.0/32 is subnetted, 1 subnets

R 2.2.2.2 [120/1] via 172.12.123.2, 00:00:20, Serial0

3.0.0.0/32 is subnetted, 1 subnets

R 3.3.3.3 [120/1] via 172.12.123.3, 00:00:22, Serial0

R2#show ip route rip

1.0.0.0/32 is subnetted, 1 subnets

R 1.1.1.1 [120/1] via 172.12.123.1, 00:00:06, Serial0

R3#show ip route rip

1.0.0.0/32 is subnetted, 1 subnets

R 1.1.1.1 [120/1] via 172.12.123.1, 00:00:04, Serial0

The hub router R1 has a route to both loopbacks, but neither spoke has a route to the other spoke’s loopback. That’s because split horizon prevents R1 from advertising a network via Serial0 if the route was learned on Serial0 to begin with.

We’ve got two options here, one of which is to disable spilt horizon on the interface. While doing so will have the desired effect in our little network, disabling split horizon is not a good idea and should be avoided whenever possible. We’re not going to do it in this lab, but here is the syntax to do so:

R1(config)#interface serial0

R1(config-if)#no ip split-horizon

A better solution is to configure subinterfaces on R1. The IP addressing will have to be revisited, but that’s no problem here. R1 and R2 will use 172.12.123.0 /24 to communicate, while R1 and R3 will use 172.12.13.0 /24. R3’s serial0 interface will need to be renumbered, so let’s look at all three router configurations:

R1(config)#interface serial0

R1(config-if)#encap frame

R1(config-if)#no frame inverse-arp

R1(config-if)#no ip address

R1(config-if)#interface serial0.12 multipoint

R1(config-subif)#ip address 172.12.123.1 255.255.255.0

R1(config-subif)#frame map ip 172.12.123.2 122 broadcast

R1(config-subif)#interface serial0.31 point-to-point

R1(config-subif)#ip address 172.12.13.1 255.255.255.0

R1(config-subif)#frame interface-dlci 123

R2(config)#int s0

R2(config-if)#ip address 172.12.123.2 255.255.255.0

R2(config-if)#encap frame

R2(config-if)#frame map ip 172.12.13.3 221 broadcast

R2(config-if)#frame map ip 172.12.123.1 221 broadcast

R3(config)#int s0

R3(config-if)#ip address 172.12.13.3 255.255.255.0

R3(config-if)#encap frame

R3(config-if)#frame map ip 172.12.13.1 321 broadcast

R3(config-if)#frame map ip 172.12.123.2 321 broadcast

A frame map statement always names the REMOTE IP address and the LOCAL DLCI. Don’t forget the broadcast option!

Show frame map shows us that all the static mappings on R1 are up and running. Note the “static” output, which indicates these mappings are a result of using the frame map command. Pings are not shown, but all three routers can ping each other at this point.

R1#show frame map

Serial0 (up): ip 172.12.123.2 dlci 122(0×7A,0×1CA0), static,

broadcast, CISCO, status defined, active

Serial0 (up): ip 172.12.13.3 dlci 123(0×7B,0×1CB0), static,

broadcast, CISCO, status defined, active

After the 172.12.13.0 /24 network is added to R1 and R3’s RIP configuration, R2 and R3 now have each other’s loopback network in their RIP routing tables.

R2#show ip route rip

1.0.0.0/32 is subnetted, 1 subnets

R 1.1.1.1 [120/1] via 172.12.123.1, 00:00:20, Serial0

3.0.0.0/32 is subnetted, 1 subnets

R 3.3.3.3 [120/1] via 172.12.123.1, 00:00:22, Serial0

R3#show ip route rip

1.0.0.0/32 is subnetted, 1 subnets

R 1.1.1.1 [120/1] via 172.12.13.1, 00:00:20, Serial0

2.0.0.0/32 is subnetted, 1 subnets

R 2.2.2.2 [120/1] via 172.12.13.1, 00:00:22, Serial0

While turning split horizon off is one way to achieve total IP connectivity, doing so can have other unintended results. The use of subinterfaces is a more effective way of allowing the spokes to see the hub’s loopback network.

BECNs and FECNs aren’t just important to know for your Cisco CCNA and CCNP certification exams – they’re an important part of detecting congestion on a Frame Relay network and allowing the network to dynamically adjust its transmission rate when congestion is encountered.

The Forward Explicit Congestion Notification (FECN, pronounced “feckon”) bit is set to zero by default, and will be set to 1 if congestion was experienced by the frame in the direction in which the frame was traveling. A DCE (frame relay switch) will set this bit, and a DTE (router) will receive it, and see that congestion was encountered along the frame’s path.

If network congestion exists in the opposite direction in which the frame was traveling, the Backward Explicit Congestion Notification (BECN, pronounced “beckon”) will be set to 1 by a DCE.

If this is your first time working with BECNs and FECNs, you might wonder why the BECN even exists – after all, why send a “backwards” notification? The BECN is actually the most important part of this entire process, since it’s the BECN bit that indicates to the sender that it needs to slow down!

For example, frames sent from Kansas City to Green Bay encounter congestion in the FR cloud. A Frame Switch sets the FECN bit to 1. In order to alert KC that it’s sending data too fast, GB will send return frames with the BECN bit set. When KC sees the BECN bit is set to 1, the KC router knows that the congestion occurred when frames were sent from KC to GB.

Frame Relay BECN Adaptive Shaping allows a router to dynamically throttle back on its transmission rate if it receives frames from the remote host with the BECN bit set. In this case, KC sees that the traffic it’s sending to GB is encountering congestion, because the traffic coming back from GB has the BECN bit set. If BECN Adaptive Shaping is running on KC, that router will adjust to this congestion by slowing its transmission rate. When the BECNs stop coming in from GB, KC will begin to send at a faster rate.

BECN Adaptive Shaping is configured as follows:

KC(config)#int s0

KC(config-if)#frame-relay adaptive-shaping becn

To see how many frames are coming in and going out with the BECN and FECN bits set, run show frame pvc.

R3#show frame pvc

< some output removed for clarity >

input pkts 306 output pkts 609 in bytes 45566

out bytes 79364 dropped pkts 0 in FECN pkts 0

in BECN pkts 0 out FECN pkts 0 out BECN pkts 0

in DE pkts 0 out DE pkts 0

out bcast pkts 568 out bcast bytes 75128

pvc create time 01:26:27, last time pvc status changed 01:26:27

Just watch the “in”s and “out”s of BECN, FECN, and DE in both the exam room and your production networks!

Whether you’re just starting to think about passing the CCNA or CCNP exams, or you’ve been on the certification track for a while, you’ve got to have a plan for success. If you wanted to drive your car from Florida to California, you’d create a plan to get there. You’d get a map and decide how far you wanted to drive per day, and maybe even make some hotel reservations in advance. You certainly wouldn’t get in your car, just drive it randomly down the nearest highway, and hope you ended up in California, would you?

Certainly not. Earning your CCNA certification is the same way. It’s not enough to just study a few minutes “when you feel like it”, or tell yourself that you’ll start studying for the exams “when I get such-and-such done”. The perfect time to start on the road to Cisco certification is not tomorrow, and it’s not next week. It’s today.

You’re much better off with one hour of solid study than three hours of interrupted, unfocused study. Here are a few ways to go about getting the kind of quality study time that will get you to the CCNA or CCNP (or any Cisco certification, for that matter!).

Schedule your study time, and regard this study time as you would an appointment with a client. If you were to meet a customer at 10:00 to discuss a network install, would you just decide not to show up and watch television instead? Not if you wanted the job. The same goes for your study time. That’s an appointment with the most important customer of all – YOU.

Turn your cell, iPod, TV, instant messenger, and all other electronic collars off for the duration of your study time. I know those of us in information technology don’t like to say this, but we can actually exist without being in touch with the world for a little while. You may even get to like it! Having uninterrupted study time is key to CCNA and CCNP exam success.

Finally, schedule your exam before you start studying. Contrary to what many people think, “deadline” is not a dirty word. We do our best work when we have a deadline and a schedule to keep. Make out your study schedule, schedule your exam, and get to work just as you would a network project for a customer. The project you’re working on is your career and your life, and by following these simple steps you can make it a highly successful project – by passing your CCNA and CCNP exam!