|
||
CCNA exam success depends on mastering many technologies that are new to you, and few exam topics have more details than ISDN. ISDN isn't just for your CCNA exam studies, though. While ISDN is dismissed by many, the fact is that there are many small and mid-size networks out there that use ISDN as their backup to frame relay. Some of these companies have spoke networks that use ISDN to connect to their hub as well, so it's a great idea to know ISDN configuration and troubleshooting for your real-world career as well as passing the CCNA. With that in mind, let's take a look at five common ISDN errors and how to avoid them.
With dialer map statements, remember that the phone number you put in the dialer map is the phone number of the remote router, not the local one. Look at it this way - if you want to call a friend on your cell, you don't pick up your cell and dial your own number!
Speaking of dialer map statements, don't forget the all-important broadcast option at the end of the command:
R1(config-if)#dialer map ip 172.12.21.1 name R2 broadcast 5555555
The router will accept that command without the "broadcast" option, but routing protocol updates and hellos would not be able to travel across the line. (This command is also needed in frame relay map statements to allow broadcasts and multicasts to be transmitted.)
PAP is PPP's clear-text authentication scheme, and clear text is a really bad idea. But if you do have to configure it, don't forget that PAP requires additional configuration -the ppp pap sent-username command.
R1(config-if)#ppp pap sent-username R1 password CISCO
Must set encapsulation to PPP before using PPP subcommands
R1(config-if)#
The error message we got while configuring the sent-username command is another important reminder - by default, a BRI line is running HDLC, not PPP. Since HDLC doesn't allow us to use either PAP or CHAP, we'll need to set the link to PPP with the encapsulation ppp command.
R1(config-if)#encapsulation ppp
R1(config-if)#ppp authentication pap
R1(config-if)#ppp pap sent-username R1 password CISCO
But before we configure any of this information, we should configure the ISDN switch-type. Why? Because without the switch-type configuration, it doesn't matter that we avoid the other four errors - the line will not come up. Configure the switch-type with the "isdn switch-type" command, and then verify it with "show isdn status".
R1(config)#isdn switch-type basic-ni
R1#show isdn status
Global ISDN Switchtype = basic-ni (output of this command cut here for clarity)
If you forget this part of the configuration, the output of show isdn status wastes no time in reminding you!
R1#show isdn status
**** No Global ISDN Switchtype currently defined ****
ISDN is an important part of your CCNA studies, and this knowledge still comes in handy in production networks as well. Keep studying, notice the details, run those debugs, and you'll be a CCNA before you know it!
CCNA exam success depends greatly on knowing the details, and if there's one protocol that has a lot of details, it's OSPF! This is true particularly of hub-and-spoke networks, so in this CCNA OSPF tutorial we'll take a look at some of the more important hub-and-spoke OSPF details. This will help you in working with real-world networks as well, since this OSPF network type is one of the more typical network topologies.
In OSPF, the hub must become the designated router (DR). The DR election's deciding value is the OSPF interface priority, and the default value is 1. It's not enough to set the hub's OSPF interface to 2, however, since the spoke routers must not become the DR or BDR. You must set the spoke interfaces to an OSPF priority of zero.
R2(config)#int s0
R2(config-if)#ip ospf priority 0
This ensures that the spokes will not become the DR or BDR if the hub goes down.
The hub does require a bit more configuration, though. The neighbor command must be used on the hub to indicate the IP address of the potential neighbors.
R1(config)#router ospf 1
R1(config-router)#neighbor 172.12.123.2
R1(config-router)#neighbor 172.12.123.3
It's common to have an ISDN link as a backup in an OSPF network, and when that ISDN link comes up the hello packets must be able to cross the link. What you don't want is to have the hellos keep the link up! By configuring the ISDN link as an OSPF demand circuit, the link will drop in the absence of interesting traffic, but the OSPF adjacency that formed across the ISDN link will be assumed by the router to still be up. (You usually see this command configured on both sides of the ISDN link, but it's only needed on one side. It doesn't hurt anything to put it on both sides, though.)
R2(config)#int bri0
R2(config-if)#ip ospf demand-circuit
A final detail of OSPF hub-and-spoke and demand circuits actually takes place at Layer 2. For the OSPF hello packets to successfully be transmitted across an ISDN link or a frame relay network, the broadcast option must be enabled in the appropriate frame and dialer map statements. Failure to enable this option can lead to a situation where pings will be successful, but OSPF adjacencies will not form.
R2(config-if)#dialer map ip 172.12.21.1 name R1 broadcast 5551111
R2(config-if)#frame map ip 172.12.123.1 221 broadcast
When you're troubleshooting OSPF in a production network or your CCNA / CCNP home lab, don't just look at Layer 3 - because everything's got to be right at the physical and data link layers in order for the network layer to function correctly!