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!
Showing posts with label ppp. Show all posts
Showing posts with label ppp. Show all posts
Thursday, December 25, 2008
Tuesday, December 23, 2008
Cisco CCNA / CCNP Exam Tutorial: Five Debugs You Must Know
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.
Several factors are considered by OSPF-enabled routers when it comes to forming adjacencies, including hello and dead timer settings. If an adjacency doesn't form when you think it should, run "debug ip ospf adj". The reason the adjacency isn't forming is usually seen quickly with this command's output.
Let's not ignore Layer Two! If frame relay mappings are not forming according to your configuration, run "debug frame lmi". This debug will allow you to quickly diagnose and correct any LMI mismatches.
When it comes to PPP, it can be very frustrating to try to spot a problem with a password or username. Instead of staring at the configuration for 10 minutes, run "debug ppp negotiation" and send a ping over the link. This command will help you spot the router with the misconfigured username or password, not to mention saving you a lot of time!
Effectively using debugs during your CCNA and CCNP exam study will help you truly understand what's going on "behind the command" - and it will really come in handy on that day when your production network just isn't doing what you (think) you told it to do!
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.
Several factors are considered by OSPF-enabled routers when it comes to forming adjacencies, including hello and dead timer settings. If an adjacency doesn't form when you think it should, run "debug ip ospf adj". The reason the adjacency isn't forming is usually seen quickly with this command's output.
Let's not ignore Layer Two! If frame relay mappings are not forming according to your configuration, run "debug frame lmi". This debug will allow you to quickly diagnose and correct any LMI mismatches.
When it comes to PPP, it can be very frustrating to try to spot a problem with a password or username. Instead of staring at the configuration for 10 minutes, run "debug ppp negotiation" and send a ping over the link. This command will help you spot the router with the misconfigured username or password, not to mention saving you a lot of time!
Effectively using debugs during your CCNA and CCNP exam study will help you truly understand what's going on "behind the command" - and it will really come in handy on that day when your production network just isn't doing what you (think) you told it to do!
Cisco CCNA / CCNP Certification Exam Tutorial: Configuring PPP Callback
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.
Client:
username R1 password CCIE
interface BRI0
ip address 172.12.12.2 255.255.255.0
encapsulation ppp
dialer map ip 172.12.12.1 name R1 broadcast 5557777
dialer-group 1
isdn switch-type basic-ni
ppp callback request
ppp authentication chap
Most of that configuration will look familiar to you, but the ppp callback request command might not. This command enables the BRI interface to request the callback.
Simple enough, right? The PPP Callback Server config requires more configuration and an additional map-class as well.
Server:
username R2 password CCIE
interface BRI0
ip address 172.12.12.1 255.255.255.0
encapsulation ppp
dialer callback-secure
dialer map ip 172.12.12.2 name R2 class CALL_R2_BACK broadcast 5558888
dialer-group 1
isdn switch-type basic-ni
ppp callback accept
ppp authentication chap
map-class dialer CALL_R2_BACK
dialer callback-server username
Examining the PPP Callback Server command from the top down...
dialer callback-secure enables security on the callback. If the remote router cannot be authenticated for callback, the incoming call will be disconnected.
The dialer map statement now calls the class CALL_R2_BACK, shown at the bottom of the config excerpt.
ppp callback accept enables PPP callback on this router.
dialer callback-server username tells the callback server that the device referenced in the dialer map statement is a callback client.
The only way to find out if the config works is to test it, so let's send a ping from R2 to R1 and see if the callback takes place.
R2#ping 172.12.12.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.12.12.1, timeout is 2 seconds:
02:45:42: BR0 DDR: Dialing cause ip (s=172.12.12.2, d=172.12.12.1)
02:45:42: BR0 DDR: Attempting to dial 5557777
02:45:42: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
02:45:42: BR0:1 DDR: Callback negotiated - Disconnecting now
02:45:42: BR0:1 DDR: disconnecting call
02:45:42: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 5557777 R1
02:45:42: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
02:45:42: DDR: Callback client for R1 5557777 created
02:45:42: BR0:1 DDR: disconnecting call.....
Success rate is 0 percent (0/5)
R2#
02:45:57: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
R2#
02:45:57: BR0:1 DDR: Callback received from R1 5557777
02:45:57: DDR: Freeing callback to R1 5557777
02:45:57: BR0:1 DDR: dialer protocol up
02:45:58: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to up
The callback was successfully negotiated, and the call then disconnected. R1 then called R2 back, and show dialer on R1 confirms the purpose of the call.
R1#show dialer
BRI0 - dialer type = ISDN
Dial String Successes Failures Last DNIS Last status
5558888 2 4 00:00:20 successful
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: Callback return call
Time until disconnect 99 secs
Connected to 5558888 (R2)
Pretty cool! PPP Callback isn’t just important for passing your CCNA and CCNP exams – in circumstances such as shown in this example, it can save your organization quite a bit of money!
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.
Client:
username R1 password CCIE
interface BRI0
ip address 172.12.12.2 255.255.255.0
encapsulation ppp
dialer map ip 172.12.12.1 name R1 broadcast 5557777
dialer-group 1
isdn switch-type basic-ni
ppp callback request
ppp authentication chap
Most of that configuration will look familiar to you, but the ppp callback request command might not. This command enables the BRI interface to request the callback.
Simple enough, right? The PPP Callback Server config requires more configuration and an additional map-class as well.
Server:
username R2 password CCIE
interface BRI0
ip address 172.12.12.1 255.255.255.0
encapsulation ppp
dialer callback-secure
dialer map ip 172.12.12.2 name R2 class CALL_R2_BACK broadcast 5558888
dialer-group 1
isdn switch-type basic-ni
ppp callback accept
ppp authentication chap
map-class dialer CALL_R2_BACK
dialer callback-server username
Examining the PPP Callback Server command from the top down...
dialer callback-secure enables security on the callback. If the remote router cannot be authenticated for callback, the incoming call will be disconnected.
The dialer map statement now calls the class CALL_R2_BACK, shown at the bottom of the config excerpt.
ppp callback accept enables PPP callback on this router.
dialer callback-server username tells the callback server that the device referenced in the dialer map statement is a callback client.
The only way to find out if the config works is to test it, so let's send a ping from R2 to R1 and see if the callback takes place.
R2#ping 172.12.12.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.12.12.1, timeout is 2 seconds:
02:45:42: BR0 DDR: Dialing cause ip (s=172.12.12.2, d=172.12.12.1)
02:45:42: BR0 DDR: Attempting to dial 5557777
02:45:42: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
02:45:42: BR0:1 DDR: Callback negotiated - Disconnecting now
02:45:42: BR0:1 DDR: disconnecting call
02:45:42: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 5557777 R1
02:45:42: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
02:45:42: DDR: Callback client for R1 5557777 created
02:45:42: BR0:1 DDR: disconnecting call.....
Success rate is 0 percent (0/5)
R2#
02:45:57: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
R2#
02:45:57: BR0:1 DDR: Callback received from R1 5557777
02:45:57: DDR: Freeing callback to R1 5557777
02:45:57: BR0:1 DDR: dialer protocol up
02:45:58: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to up
The callback was successfully negotiated, and the call then disconnected. R1 then called R2 back, and show dialer on R1 confirms the purpose of the call.
R1#show dialer
BRI0 - dialer type = ISDN
Dial String Successes Failures Last DNIS Last status
5558888 2 4 00:00:20 successful
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: Callback return call
Time until disconnect 99 secs
Connected to 5558888 (R2)
Pretty cool! PPP Callback isn’t just important for passing your CCNA and CCNP exams – in circumstances such as shown in this example, it can save your organization quite a bit of money!
Cisco CCNA / CCNP Certification Exam Tutorial: ISDN And Multilink PPP
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.
Enabling MLP is a three-step process:
Enable PPP on the link
Enable MLP with the command ppp multilink
Define the threshold at which the second b-channel should start carrying data with the dialer load-threshold command.
Let's say you wanted the second b-channel to start carrying data when the first channel reaches 75% of capacity. It would make sense that the command to do so would be dialer load-threshold 75... but it's not.
R1(config)#int bri0
R1(config-if)#ppp multilink
R1(config-if)#dialer load-threshold ?
<1-255> Load threshold to place another call
The dialer load-threshold value is based on 255, not 100. To have this command bring the line up at a certain percentage, multiply that percentage in decimal format by 255. Below, I multiplied 255 by .75 (75%) to arrive at 191.
R1(config-if)#dialer load-threshold 191 ?
either Threshold decision based on max of inbound and outbound traffic
inbound Threshold decision based on inbound traffic only
outbound Threshold decision based on outbound traffic only
R1(config-if)#dialer load-threshold 191 either
As illustrated by IOS Help in the above configuration, dialer load-threshold has additional options as well. You can configure the interface to consider only incoming, outgoing, or all traffic when calculating when to bring the next channel up.
Configuring Multilink PPP is just one of the skills you’ll need to earn your CCNA and pass the CCNP BCRAN exam. Don’t underestimate ISDN on Cisco’s certification 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.
Enabling MLP is a three-step process:
Enable PPP on the link
Enable MLP with the command ppp multilink
Define the threshold at which the second b-channel should start carrying data with the dialer load-threshold command.
Let's say you wanted the second b-channel to start carrying data when the first channel reaches 75% of capacity. It would make sense that the command to do so would be dialer load-threshold 75... but it's not.
R1(config)#int bri0
R1(config-if)#ppp multilink
R1(config-if)#dialer load-threshold ?
<1-255> Load threshold to place another call
The dialer load-threshold value is based on 255, not 100. To have this command bring the line up at a certain percentage, multiply that percentage in decimal format by 255. Below, I multiplied 255 by .75 (75%) to arrive at 191.
R1(config-if)#dialer load-threshold 191 ?
either Threshold decision based on max of inbound and outbound traffic
inbound Threshold decision based on inbound traffic only
outbound Threshold decision based on outbound traffic only
R1(config-if)#dialer load-threshold 191 either
As illustrated by IOS Help in the above configuration, dialer load-threshold has additional options as well. You can configure the interface to consider only incoming, outgoing, or all traffic when calculating when to bring the next channel up.
Configuring Multilink PPP is just one of the skills you’ll need to earn your CCNA and pass the CCNP BCRAN exam. Don’t underestimate ISDN on Cisco’s certification exams!
Cisco CCNA / CCNP Certification Exam: Caller ID Screening And Callback
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=0x8023
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!
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=0x8023
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!
Subscribe to:
Posts (Atom)
