Whether you're just getting ideas for your Cisco home lab or adding to your existing lab, ebay is a great place to get ideas for your lab as well as pick up some great bargains.
Of course, the internet being what it is, there are always going to be a few people looking to take your money while shipping you inferior merchandise, or worse, no merchandise at all. While these "dealers" are in the minority, you still need to be careful when purchasing Cisco equipment on ebay. In this article, I'll give you several tips on browsing ebay ads for home lab ideas, and a few things to look out for when purchasing equipment on ebay.
For those of you just starting your Cisco certification pursuit, the idea of purchasing a home lab kit -- a set of routers, switches, and perhaps some cables and study guides -- seems like a good idea. Instead of putting your lab together one piece at a time, these kits allow you to get a head start on your studies.
One thing to watch out for in these kits is outdated equipment, or the inclusion of outdated study guides. Often, vendors will use these kits as a way to get rid of unwanted inventory.
The Cisco 1900 family of switches falls into this category. A recent search on ebay for "ccna lab" showed seven different CCNA lab kits that contained 1900 switches. The problem here is that the current CCNA exams do not test on the 1900 switches, which are menu-driven and do not have an IOS. You'll need to be well-versed with switches that do have an IOS, such as the 2950s.
The plus side here is that you will probably save money by using 1900 switches. If you're on a tight budget, having a 1900 switch is better than no switch at all. If at all possible, though, get a Cisco switch with an IOS.
The cables and transceivers included with these kits are generally exactly what you need to set up that particular kit, and this can be very helpful to those CCNA candidates who are new to the various cables needed to physically configure a home lab. Just make sure you're not buying a kit with 10 transceivers (used on AUI ports) when you've only got two routers with Ethernet ports.
Watch out for kits that include outdated study guides. I've seen four-year-old CCNA books included with some kits. If you already have your study guides, feel free to ask the vendor how much the kit costs without the books.
That leads me to the most important point. Get to know the vendor before buying anything. Visit their website and check their ebay feedback. If buying from an individual as opposed to a reseller, find out what conditions the router or switch has been kept in, and make sure to define the terms under which they will accept returns.
There's nothing wrong with buying equipment from someone who's selling their CCNA/CCNP/CCIE home lab, but just make sure you ask the right questions first. Professional resellers generally have their return policy right in their ebay ad; if they don't, ask for a copy.
Building your own CCNA and/or CCNP home lab is a little intimidating at first, but speaking as someone who has climbed the Cisco certification ladder from the CCNA to the CCIE, I can tell you that it is the best investment you can make in your career. Use a little caution, ask the right question, and soon you'll be leaving the world of "router simulators" behind - and you'll be developing your skills as a true professional should: On real Cisco routers and switches!
Showing posts with label isdn. Show all posts
Showing posts with label isdn. Show all posts
Friday, December 26, 2008
Cisco Certification: Introduction To ISDN
From the CCNA to the CCIE, ISDN is one of the most important technolgies 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.
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.
One myth about ISDN is that Cisco Discovery Packets keep an ISDN link up. CDP is a Cisco-proprietary protocol that runs between directly connected Cisco devices. There is a school of thought that CDP packets have to be disabled on a BRI interface in order to prevent the link from staying up or dialing when it's not really needed. I've worked with ISDN for years in the field and in the lab, and I've never seen CDP bring up an ISDN link. Try it yourself the next time you're working on a practice rack!
Chris Bryant
CCIE #12933
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.
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.
One myth about ISDN is that Cisco Discovery Packets keep an ISDN link up. CDP is a Cisco-proprietary protocol that runs between directly connected Cisco devices. There is a school of thought that CDP packets have to be disabled on a BRI interface in order to prevent the link from staying up or dialing when it's not really needed. I've worked with ISDN for years in the field and in the lab, and I've never seen CDP bring up an ISDN link. Try it yourself the next time you're working on a practice rack!
Chris Bryant
CCIE #12933
Thursday, December 25, 2008
Cisco CCNA Exam Tutorial: Five OSPF Hub-And-Spoke Details You Must Know!
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!
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!
Cisco CCNA Exam Tutorial: Five ISDN Details To Remember
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!
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!
Wednesday, December 24, 2008
Cisco CCNA Certification Exam Tutorial: ISDN Details You Must Know
CCNA exam success depends partially on knowing the details of ISDN, and there are plenty of them! To help you review for your CCNA exam, here are a few ISDN details that you must know on exam day. (They help in the real world, too – and there are still plenty of ISDN networks out there!
The Cisco-proprietary version of HDLC is the default encapsulation type for serial and ISDN interfaces.
R2#show interface serial0
Serial0 is up, line protocol is up
Hardware is HD64570
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
Encapsulation HDLC, loopback not set, keepalive set (10 sec)
While there’s only one D-channel in BRI, PRI (US) and PRI (EU), the bandwidth of that D-channel does vary from BRI to PRI. It’s 16 kbps in BRI and 64 kbps in both PRI versions.
The global command isdn switch-type must be configured before you can even begin to have ISDN work. show isdn status will tell you whether or not you’ve done this correctly.
R2#show isdn status
**** No Global ISDN Switchtype currently defined ****
ISDN BRI0 interface
dsl 0, interface ISDN Switchtype = none
Layer 1 Status:
DEACTIVATED
Layer 2 Status:
Layer 2 NOT Activated
Layer 3 Status:
0 Active Layer 3 Call(s)
PAP allows passwords to be different; CHAP requires that they be the same.
PAP requires the “ppp pap sent-username” interface-level command. CHAP has no equivalent command.
Define interesting traffic with dialer-list and link that list to the interface with dialer-group.
R2#conf t
R2(config)#dialer-list 1 proto ip permit
R2(config)#int bri0
R2(config-if)#dialer-group 1
The dialer idle-timeout value is expressed in seconds, not minutes. (Even IOS Help isn’t totally clear on this.)
R2(config)#int bri0
R2(config-if)#dialer-group 1
R2(config-if)#dialer idle-timeout ?
<1-2147483> Idle timeout before disconnecting a call
R2(config-if)#dialer idle-timeout 120
Dialer map maps a remote IP address to a remote phone number. You never dial the local router’s phone number.
dialer load-threshold requires the ppp multilink command to be configured, and the value of dialer load-threshold is expressed as a ratio of 255, NOT 100. For example, if you want the second b-channel to come up when the first reaches 50% of capacity, the value to express with dialer load-threshold would be 50% of 255 – which equals 127.
R2(config)#int bri0
R2(config-if)#encap ppp
R2(config-if)#ppp multilink
R2(config-if)#dialer load-threshold ?
<1-255> Load threshold to place another call
Success on the CCNA exam depends on knowing the details. Keep studying, keep practicing on real Cisco routers and switches, keep a positive attitude, and you're on your way to CCNA exam success!
The Cisco-proprietary version of HDLC is the default encapsulation type for serial and ISDN interfaces.
R2#show interface serial0
Serial0 is up, line protocol is up
Hardware is HD64570
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
Encapsulation HDLC, loopback not set, keepalive set (10 sec)
While there’s only one D-channel in BRI, PRI (US) and PRI (EU), the bandwidth of that D-channel does vary from BRI to PRI. It’s 16 kbps in BRI and 64 kbps in both PRI versions.
The global command isdn switch-type must be configured before you can even begin to have ISDN work. show isdn status will tell you whether or not you’ve done this correctly.
R2#show isdn status
**** No Global ISDN Switchtype currently defined ****
ISDN BRI0 interface
dsl 0, interface ISDN Switchtype = none
Layer 1 Status:
DEACTIVATED
Layer 2 Status:
Layer 2 NOT Activated
Layer 3 Status:
0 Active Layer 3 Call(s)
PAP allows passwords to be different; CHAP requires that they be the same.
PAP requires the “ppp pap sent-username” interface-level command. CHAP has no equivalent command.
Define interesting traffic with dialer-list and link that list to the interface with dialer-group.
R2#conf t
R2(config)#dialer-list 1 proto ip permit
R2(config)#int bri0
R2(config-if)#dialer-group 1
The dialer idle-timeout value is expressed in seconds, not minutes. (Even IOS Help isn’t totally clear on this.)
R2(config)#int bri0
R2(config-if)#dialer-group 1
R2(config-if)#dialer idle-timeout ?
<1-2147483> Idle timeout before disconnecting a call
R2(config-if)#dialer idle-timeout 120
Dialer map maps a remote IP address to a remote phone number. You never dial the local router’s phone number.
dialer load-threshold requires the ppp multilink command to be configured, and the value of dialer load-threshold is expressed as a ratio of 255, NOT 100. For example, if you want the second b-channel to come up when the first reaches 50% of capacity, the value to express with dialer load-threshold would be 50% of 255 – which equals 127.
R2(config)#int bri0
R2(config-if)#encap ppp
R2(config-if)#ppp multilink
R2(config-if)#dialer load-threshold ?
<1-255> Load threshold to place another call
Success on the CCNA exam depends on knowing the details. Keep studying, keep practicing on real Cisco routers and switches, keep a positive attitude, and you're on your way to CCNA exam success!
Cisco CCNA Certification Exam Tutorial: Configuring Dialer Profiles
The most common method of configuring ISDN is with dialer maps, but dial information can also be configured on a logical interface. To pass the CCNA exam, you must know how to configure and troubleshoot both dialer maps and dialer profiles.
Dialer Profiles allow different dialing information to be configured onto logical interfaces. The logical interfaces may have different dialing destinations, different remote router names, etc., but they’ll be using the same physical interface.
Dialer strings are used on dialer profiles. Note that each logical interface has a different IP address, a different remote router to dial, and a different dialer string, but they will be using the same physical interface to dial out. The commands dialer pool and dialer pool-member are used to link the logical and physical interfaces. The number following each command must match for the logical interface to correctly bind to the physical interface.
R1(config)#interface dialer0
R1(config-if)#ip address 172.16.1.1 255.255.255.0
R1(config-if)#encapsulation ppp
<. The encapsulation type is placed on both the logical and physical interfaces. >
R1(config-if)#dialer remote-name Remote0
R1(config-if)#dialer pool 1
< places logical interface into dialer pool >
R1(config-if)#dialer string 5551212
< number dialed to contact router Remote0 >
R1(config-if)#dialer-group 1
< links logical interface to dialer-list 1 >
R1(config)#interface dialer1
R1(config-if)#ip address 172.16.1.2 255.255.255.0
R1(config-if)#encapsulation ppp
R1(config-if)#dialer remote-name Remote1
R1(config-if)#dialer pool 1
R1(config-if)#dialer string 5551234
R1(config-if)#dialer-group 1
R1(config)#interface bri0
R1(config-if)#no ip address
< With dialer profiles, IP addresses are assigned to logical interfaces. >
R1(config-if)#encapsulation ppp
< The encapsulation type is place on both the logical and physical interfaces.>
R1(config-if)#dialer pool-member 1
< The number associated with this command should match the number configured with the dialer pool number on the logical dialer interfaces. >
R1(config-if)#isdn spid1 0835866101
R1(config-if)#isdn spid2 0835866301
When configuring dialer profiles, the encapsulation type should be placed on both the physical BRI interface and the logical dialer interfaces. The SPIDs are configured on the physical interface as well.
Configuring dialer profiles can be a little tricky at first, and the best way to master this skill is to get real hands-on practice in your own CCNA / CCNP home lab or a rack rental service. Either way, hands-on is the best practice. Best of luck in your CCNA studies!
Dialer Profiles allow different dialing information to be configured onto logical interfaces. The logical interfaces may have different dialing destinations, different remote router names, etc., but they’ll be using the same physical interface.
Dialer strings are used on dialer profiles. Note that each logical interface has a different IP address, a different remote router to dial, and a different dialer string, but they will be using the same physical interface to dial out. The commands dialer pool and dialer pool-member are used to link the logical and physical interfaces. The number following each command must match for the logical interface to correctly bind to the physical interface.
R1(config)#interface dialer0
R1(config-if)#ip address 172.16.1.1 255.255.255.0
R1(config-if)#encapsulation ppp
<. The encapsulation type is placed on both the logical and physical interfaces. >
R1(config-if)#dialer remote-name Remote0
R1(config-if)#dialer pool 1
< places logical interface into dialer pool >
R1(config-if)#dialer string 5551212
< number dialed to contact router Remote0 >
R1(config-if)#dialer-group 1
< links logical interface to dialer-list 1 >
R1(config)#interface dialer1
R1(config-if)#ip address 172.16.1.2 255.255.255.0
R1(config-if)#encapsulation ppp
R1(config-if)#dialer remote-name Remote1
R1(config-if)#dialer pool 1
R1(config-if)#dialer string 5551234
R1(config-if)#dialer-group 1
R1(config)#interface bri0
R1(config-if)#no ip address
< With dialer profiles, IP addresses are assigned to logical interfaces. >
R1(config-if)#encapsulation ppp
< The encapsulation type is place on both the logical and physical interfaces.>
R1(config-if)#dialer pool-member 1
< The number associated with this command should match the number configured with the dialer pool number on the logical dialer interfaces. >
R1(config-if)#isdn spid1 0835866101
R1(config-if)#isdn spid2 0835866301
When configuring dialer profiles, the encapsulation type should be placed on both the physical BRI interface and the logical dialer interfaces. The SPIDs are configured on the physical interface as well.
Configuring dialer profiles can be a little tricky at first, and the best way to master this skill is to get real hands-on practice in your own CCNA / CCNP home lab or a rack rental service. Either way, hands-on is the best practice. Best of luck in your CCNA studies!
Cisco CCNA Certification: The (Many) Different Kinds Of Switching
When you're studying for your CCNA exam, whether you're taking the Intro-ICND path or the single-exam path, you're quickly introduced to the fact that switching occurs at Layer 2 of the OSI model. No problem there, but then other terms involving switching are thrown in, and some of them can be more than a little confusing. What is "cell switching"? What is "circuit switching"? Most confusing of all, how can you have "packet switching"? Packets are found at Layer 3, but switching occurs at Layer 2. How can packets be switched?
Relax! As you'll see in this article, the terms aren't that hard to keep straight. Packet switching, for example, describes a protocol that divides a message into packets before they're sent. The packets are then sent individually, and may take different paths to the same destination. Once the packets arrive at the final destination, they are reassembled.
Frame switching follows the same process, but at a different layer of the OSI model. When the protocol runs at Layer 2 rather than Layer 3, the process is referred to as frame switching.
Cell switching also does much the same thing, but as the name implies, the device in use is a cell switch. Cell-switched packets are fixed in length. ATM is a popular cell-switching technology.
The process of circuit switching is just a bit different, in that the process of setting up the circuit itself is part of the process. The channel is set up between two parties, data is transmitted, and the channel is then torn down. The circuit-switching technology most familiar to CCNA candidates is ISDN.
Don't let these terms confuse you. The four different terms are describing much the same process. The main difference is that they are occurring at different levels of the OSI model, and using a different transport method to get the data where it needs to go.
Relax! As you'll see in this article, the terms aren't that hard to keep straight. Packet switching, for example, describes a protocol that divides a message into packets before they're sent. The packets are then sent individually, and may take different paths to the same destination. Once the packets arrive at the final destination, they are reassembled.
Frame switching follows the same process, but at a different layer of the OSI model. When the protocol runs at Layer 2 rather than Layer 3, the process is referred to as frame switching.
Cell switching also does much the same thing, but as the name implies, the device in use is a cell switch. Cell-switched packets are fixed in length. ATM is a popular cell-switching technology.
The process of circuit switching is just a bit different, in that the process of setting up the circuit itself is part of the process. The channel is set up between two parties, data is transmitted, and the channel is then torn down. The circuit-switching technology most familiar to CCNA candidates is ISDN.
Don't let these terms confuse you. The four different terms are describing much the same process. The main difference is that they are occurring at different levels of the OSI model, and using a different transport method to get the data where it needs to go.
Cisco CCNA / CCNP Home Lab Tutorial: Using 2520 Routers
I know from experience that part of the excitement and anxiety of putting together your own CCNA / CCNP home lab is deciding what to buy! While you can make a workable home lab out of almost any combination of Cisco routers and switches, some routers are better suited for home lab work than others because they can fill multiple roles.
My personal favorite is the Cisco 2520. This router has four serial interfaces, making it an ideal frame relay switch. Don't forget that just because you're using a router as a frame switch, you can still use its routing capabilities. One setup I use is to use three of the four serial interfaces for frame switching and the fourth interface as a point-to-point network with another router. All you need is some DTE/DCE cables and you're all set.
The 2520 also comes with one ethernet interface and an ISDN interface, so that gives you even more options. Even if you're not planning to run ISDN in your home lab right now, you may choose to do so in the future - and with a 2520, you've already got the right router to do so. Keep in mind that if you are going to run ISDN in your home lab, you’ll need an ISDN device such as an ISDN simulator in your lab. (ISDN simulators are physical devices and are plentiful on ebay – they’re no relation to “router simulators”.)
Again, I want to reiterate that you can work any Cisco router into a CCNA / CCNP home lab - there's no "right" or "wrong" combination of equipment. But as with anything else, some combinations are better than others, so consider adding some 2520s to your home lab! This router gives you a great combination of interfaces and capabilities, plus the most important factor of all - real hands-on experience during your CCNA and CCNP exam preparation!
My personal favorite is the Cisco 2520. This router has four serial interfaces, making it an ideal frame relay switch. Don't forget that just because you're using a router as a frame switch, you can still use its routing capabilities. One setup I use is to use three of the four serial interfaces for frame switching and the fourth interface as a point-to-point network with another router. All you need is some DTE/DCE cables and you're all set.
The 2520 also comes with one ethernet interface and an ISDN interface, so that gives you even more options. Even if you're not planning to run ISDN in your home lab right now, you may choose to do so in the future - and with a 2520, you've already got the right router to do so. Keep in mind that if you are going to run ISDN in your home lab, you’ll need an ISDN device such as an ISDN simulator in your lab. (ISDN simulators are physical devices and are plentiful on ebay – they’re no relation to “router simulators”.)
Again, I want to reiterate that you can work any Cisco router into a CCNA / CCNP home lab - there's no "right" or "wrong" combination of equipment. But as with anything else, some combinations are better than others, so consider adding some 2520s to your home lab! This router gives you a great combination of interfaces and capabilities, plus the most important factor of all - real hands-on experience during your CCNA and CCNP exam preparation!
Cisco CCNA / CCNP Home Lab: Why You Need An ISDN Simulator
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.
In years past, this was a major problem for 640-801, 811, and 821 studies, because the simulators used to be so expensive. New ones can still be pricey ($600 and up), but with the sudden influx of used ISDN simulators on ebay and Cisco resellers, you can get a used one that will do the job for you.
Why are there suddenly so many ISDN simulators on the market? Cisco recently removed ISDN from the CCIE R&S exam, so a lot of CCIE rack resellers as well as private individuals are selling their simulators. There's never been a better time to add ISDN to your home lab. If taken care of (kept out of extreme heat), they can last for quite a few years. The one I purchased for my IE home lab is still working well.
If you choose to purchase a new simulator, you can run a Google search to find vendors. I've made two purchases from www.vconsole.com over the last few years and both of those simulators have worked beautifully.
As I said earlier, there's never been a better time to add ISDN to your home lab. Don't just settle for trying to memorize theory - get your hands on the real deal, practice and fix your configurations, and you'll be amazed at what you learn and how well you do on your CCNA and CCNP exams!
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.
In years past, this was a major problem for 640-801, 811, and 821 studies, because the simulators used to be so expensive. New ones can still be pricey ($600 and up), but with the sudden influx of used ISDN simulators on ebay and Cisco resellers, you can get a used one that will do the job for you.
Why are there suddenly so many ISDN simulators on the market? Cisco recently removed ISDN from the CCIE R&S exam, so a lot of CCIE rack resellers as well as private individuals are selling their simulators. There's never been a better time to add ISDN to your home lab. If taken care of (kept out of extreme heat), they can last for quite a few years. The one I purchased for my IE home lab is still working well.
If you choose to purchase a new simulator, you can run a Google search to find vendors. I've made two purchases from www.vconsole.com over the last few years and both of those simulators have worked beautifully.
As I said earlier, there's never been a better time to add ISDN to your home lab. Don't just settle for trying to memorize theory - get your hands on the real deal, practice and fix your configurations, and you'll be amazed at what you learn and how well you do on your CCNA and CCNP exams!
Cisco CCNA / CCNP Exam Tutorial: Testing ISDN Links Without Pings
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.
R1#isdn call interface bri0 8358662
R1#
03:54:43: BR0 DDR: Attempting to dial 8358662
03:54:43: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
03:54:44: BR0:1 DDR: dialer protocol up
03:54:45: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to up
03:54:49: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 8358662 R2
To tear the test call down correctly, use isdn disconnect interface. IOS Help displays the options with this command.
R1#isdn disconnect interface bri 0 ?
all Disconnect the data call(s) on all b channels
b1 Disconnect the data call on b1 channel
b2 Disconnect the data call on b2 channel
R1#isdn disconnect interface bri 0 all
03:58:36: BR0:1 DDR: disconnecting call
03:58:36: BR0:2 DDR: disconnecting call
03:58:36: %ISDN-6-DISCONNECT: Interface BRI0:1 disconnected from 8358662
R2, call lasted 20 seconds
03:58:36: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
03:58:36: BR0:1 DDR: disconnecting call
03:58:37: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to down
I say "correctly" because the one thing you don't want to do to end an ISDN call, test or otherwise, is just shut the interface. Telcos don't like it, and ISDN lab devices like it even less. Always let the d-channel do its work and tear the call down in an orderly fashion - don't just cut it off by shutting the interface down.
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.
R1#isdn call interface bri0 8358662
R1#
03:54:43: BR0 DDR: Attempting to dial 8358662
03:54:43: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
03:54:44: BR0:1 DDR: dialer protocol up
03:54:45: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to up
03:54:49: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 8358662 R2
To tear the test call down correctly, use isdn disconnect interface. IOS Help displays the options with this command.
R1#isdn disconnect interface bri 0 ?
all Disconnect the data call(s) on all b channels
b1 Disconnect the data call on b1 channel
b2 Disconnect the data call on b2 channel
R1#isdn disconnect interface bri 0 all
03:58:36: BR0:1 DDR: disconnecting call
03:58:36: BR0:2 DDR: disconnecting call
03:58:36: %ISDN-6-DISCONNECT: Interface BRI0:1 disconnected from 8358662
R2, call lasted 20 seconds
03:58:36: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
03:58:36: BR0:1 DDR: disconnecting call
03:58:37: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to down
I say "correctly" because the one thing you don't want to do to end an ISDN call, test or otherwise, is just shut the interface. Telcos don't like it, and ISDN lab devices like it even less. Always let the d-channel do its work and tear the call down in an orderly fashion - don't just cut it off by shutting the interface down.
Tuesday, December 23, 2008
Cisco CCNA / CCNP Certification Exam Tutorial: Dialer Watch
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.
Be careful with this command. The entries here need to match exactly the routes and masks being watched. Dialer watch-lists use subnet masks, not wildcard masks.
R2(config)#dialer watch-list 5 ip 10.1.1.0 255.255.255.0
R2(config)#dialer watch-list 5 ip 1.1.1.1 255.255.255.255
Configure the dialer watch-group command on the BRI interface, AND frame map statements for the watched routes. As with dialer-list and dialer-group, the group number referenced in the dialer watch-group command must match the number assigned to the dialer watch-list.
The Dialer Watch configuration will not work without frame map statements for each watched route. I repeat this because this is the step a lot of people leave out.
R2(config)#interface bri0
R2(config-if)#dialer watch-group 5
R2(config-if)# dialer map ip 1.1.1.1 255.255.255.255. name R1 5557777 broadcast
R2(config-if)# dialer map ip 10.1.1.0 255.255.255.0 name R1 5557777 broadcast
To test Dialer Watch, the Serial0 interface on R2 will be shut down. Since we're running OSPF, the route table will be updated almost immediately and the ISDN link should come up right after that.
R2(config)#int s0
R2(config-if)#shut
01:12:47: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on Serial0 from FULL to DOWN, N
eighbor Down: Interface down or detached
01:12:47: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
01:12:48: %SYS-5-CONFIG_I: Configured from console by console
01:12:48: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state
to up
01:12:49: %LINK-5-CHANGED: Interface Serial0, changed state to administratively
down
01:12:50: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, changed state
to down
01:12:53: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 5557777 R1
Within five seconds, the ISDN link is up. show dialer verifies that Dialer Watch is the reason the line was brought up.
R2#show dialer
BRI0 - dialer type = ISDN
Dial String Successes Failures Last DNIS Last status
5557777 2 0 00:00:11 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: Dialing on watched route loss
Time until disconnect 108 secs
Connected to 5557777 (R1)
A final note regarding Dialer Watch ... it will not work with RIP, but will with all our other dynamic IGPs (IGRP, EIGRP, OSPF).
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.
Be careful with this command. The entries here need to match exactly the routes and masks being watched. Dialer watch-lists use subnet masks, not wildcard masks.
R2(config)#dialer watch-list 5 ip 10.1.1.0 255.255.255.0
R2(config)#dialer watch-list 5 ip 1.1.1.1 255.255.255.255
Configure the dialer watch-group command on the BRI interface, AND frame map statements for the watched routes. As with dialer-list and dialer-group, the group number referenced in the dialer watch-group command must match the number assigned to the dialer watch-list.
The Dialer Watch configuration will not work without frame map statements for each watched route. I repeat this because this is the step a lot of people leave out.
R2(config)#interface bri0
R2(config-if)#dialer watch-group 5
R2(config-if)# dialer map ip 1.1.1.1 255.255.255.255. name R1 5557777 broadcast
R2(config-if)# dialer map ip 10.1.1.0 255.255.255.0 name R1 5557777 broadcast
To test Dialer Watch, the Serial0 interface on R2 will be shut down. Since we're running OSPF, the route table will be updated almost immediately and the ISDN link should come up right after that.
R2(config)#int s0
R2(config-if)#shut
01:12:47: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on Serial0 from FULL to DOWN, N
eighbor Down: Interface down or detached
01:12:47: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
01:12:48: %SYS-5-CONFIG_I: Configured from console by console
01:12:48: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state
to up
01:12:49: %LINK-5-CHANGED: Interface Serial0, changed state to administratively
down
01:12:50: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, changed state
to down
01:12:53: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 5557777 R1
Within five seconds, the ISDN link is up. show dialer verifies that Dialer Watch is the reason the line was brought up.
R2#show dialer
BRI0 - dialer type = ISDN
Dial String Successes Failures Last DNIS Last status
5557777 2 0 00:00:11 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: Dialing on watched route loss
Time until disconnect 108 secs
Connected to 5557777 (R1)
A final note regarding Dialer Watch ... it will not work with RIP, but will with all our other dynamic IGPs (IGRP, EIGRP, OSPF).
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!
Monday, December 22, 2008
Cisco CCNA / CCNP Certification Exam Tutorial: Floating Static Routes
To pass the Cisco CCNA and CCNP certification exams, as well as becoming a world-class networker, you've got to know how and when to use floating static routes. And if you're wondering what makes them "float" -- read on!
In this example, R1 and R2 are running OSPF over a Frame Relay network, 172.12.123.0 /24. They're also connected by a BRI ISDN link, 172.12.12.0 /24. R1 is advertising a loopback network, 1.1.1.1 /32, via OSPF. We want R2 to have a route to that loopback even if the frame goes down - and here, we'll use a floating static route to make that happen.
R2 sees the route to the loopback interface via OSPF, and can ping that interface successfully.
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:02, Serial0
R2#ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 68/68/68 ms
This is when it's important to know your administrative distances.... or at least know where to look to see them! The AD of OSPF is 110, which means we can configure a static route to 1.1.1.1 /32, and as long as the AD of the static route is higher than 110, it won't be used unless the OSPF route leaves the routing table. That's why this kind of route is called a "floating" static route - the route "floats" in the routing table and isn't seen unless the primary route leaves the table.
You learned how to write a static route in your CCNA studies, but you also remember that the default AD of a static route is either 1 or 0... and both of those values are less than 110! To change the AD of a static route, configure the desired distance at the end of the ip route command.
R2(config)#ip route 1.1.1.1 255.255.255.255 bri0 ?
<1-255> Distance metric for this route
A.B.C.D Forwarding router's address
name Specify name of the next hop
permanent permanent route
tag Set tag for this route
R2(config)#ip route 1.1.1.1 255.255.255.255 bri0 111
The static route has an AD that's only one higher than that of the OSPF route, but that's enough to make the route "float" and not yet be seen in the routing table.
R2#show ip route
1.0.0.0/32 is subnetted, 1 subnets
O 1.1.1.1 [110/65] via 172.12.123.1, 00:06:44, Serial0
172.12.0.0/24 is subnetted, 2 subnets
C 172.12.12.0 is directly connected, BRI0
C 172.12.123.0 is directly connected, Serial0
Let's see the effect on the routing table when the Serial0 interface is closed.
R2(config)#int s0
R2(config-if)#shutdown
12:04:53: %OSPF-5-ADJCHG: Process 1, Nbr 172.12.123.1 on Serial0 from FULL to DOWN, Neighbor Down: Interface down or detached
12:04:55: %SYS-5-CONFIG_I: Configured from console by console
12:04:55: %LINK-5-CHANGED: Interface Serial0, changed state to administratively down
12:04:56: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, changed state to down
R2#show ip route
1.0.0.0/32 is subnetted, 1 subnets
S 1.1.1.1 is directly connected, BRI0
172.12.0.0/24 is subnetted, 1 subnets
C 172.12.12.0 is directly connected, BRI0
The floating static route appears in the table, but the ISDN link will not come up until the BRI interface has traffic to send. Let's ping 1.1.1.1 and see what happens. debug dialer was configured on R2 before sending the ping.
R2#ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
12:16:01: BR0 DDR: Dialing cause ip (s=172.12.12.2, d=1.1.1.1)
12:16:01: BR0 DDR: Attempting to dial 8358661
12:16:01: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up.!!
12:16:01: BR0:1 DDR: dialer protocol up!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 36/37/40 ms
The link comes up and traffic can still reach 1.1.1.1. Once R2 becomes an OSPF neighbor of R1 again, the OSPF route will again become the primary path and the floating static route leaves the routing table.
R2(config)#int s0
R2(config-if)#no shut
R2#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
172.12.123.1 1 FULL/DR 00:01:57 172.12.123.1 Serial0
R2#show ip route
1.0.0.0/32 is subnetted, 1 subnets
O 1.1.1.1 [110/65] via 172.12.123.1, 00:00:16, Serial0
172.12.0.0/24 is subnetted, 2 subnets
C 172.12.12.0 is directly connected, BRI0
C 172.12.123.0 is directly connected, Serial0
A floating static route is an excellent "back door" that will keep the ISDN link down while allowing that link to serve as a backup route. Just make sure the ISDN link comes down when you expect it to - always check that with show isdn status!
In this example, R1 and R2 are running OSPF over a Frame Relay network, 172.12.123.0 /24. They're also connected by a BRI ISDN link, 172.12.12.0 /24. R1 is advertising a loopback network, 1.1.1.1 /32, via OSPF. We want R2 to have a route to that loopback even if the frame goes down - and here, we'll use a floating static route to make that happen.
R2 sees the route to the loopback interface via OSPF, and can ping that interface successfully.
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:02, Serial0
R2#ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 68/68/68 ms
This is when it's important to know your administrative distances.... or at least know where to look to see them! The AD of OSPF is 110, which means we can configure a static route to 1.1.1.1 /32, and as long as the AD of the static route is higher than 110, it won't be used unless the OSPF route leaves the routing table. That's why this kind of route is called a "floating" static route - the route "floats" in the routing table and isn't seen unless the primary route leaves the table.
You learned how to write a static route in your CCNA studies, but you also remember that the default AD of a static route is either 1 or 0... and both of those values are less than 110! To change the AD of a static route, configure the desired distance at the end of the ip route command.
R2(config)#ip route 1.1.1.1 255.255.255.255 bri0 ?
<1-255> Distance metric for this route
A.B.C.D Forwarding router's address
name Specify name of the next hop
permanent permanent route
tag Set tag for this route
R2(config)#ip route 1.1.1.1 255.255.255.255 bri0 111
The static route has an AD that's only one higher than that of the OSPF route, but that's enough to make the route "float" and not yet be seen in the routing table.
R2#show ip route
1.0.0.0/32 is subnetted, 1 subnets
O 1.1.1.1 [110/65] via 172.12.123.1, 00:06:44, Serial0
172.12.0.0/24 is subnetted, 2 subnets
C 172.12.12.0 is directly connected, BRI0
C 172.12.123.0 is directly connected, Serial0
Let's see the effect on the routing table when the Serial0 interface is closed.
R2(config)#int s0
R2(config-if)#shutdown
12:04:53: %OSPF-5-ADJCHG: Process 1, Nbr 172.12.123.1 on Serial0 from FULL to DOWN, Neighbor Down: Interface down or detached
12:04:55: %SYS-5-CONFIG_I: Configured from console by console
12:04:55: %LINK-5-CHANGED: Interface Serial0, changed state to administratively down
12:04:56: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, changed state to down
R2#show ip route
1.0.0.0/32 is subnetted, 1 subnets
S 1.1.1.1 is directly connected, BRI0
172.12.0.0/24 is subnetted, 1 subnets
C 172.12.12.0 is directly connected, BRI0
The floating static route appears in the table, but the ISDN link will not come up until the BRI interface has traffic to send. Let's ping 1.1.1.1 and see what happens. debug dialer was configured on R2 before sending the ping.
R2#ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
12:16:01: BR0 DDR: Dialing cause ip (s=172.12.12.2, d=1.1.1.1)
12:16:01: BR0 DDR: Attempting to dial 8358661
12:16:01: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up.!!
12:16:01: BR0:1 DDR: dialer protocol up!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 36/37/40 ms
The link comes up and traffic can still reach 1.1.1.1. Once R2 becomes an OSPF neighbor of R1 again, the OSPF route will again become the primary path and the floating static route leaves the routing table.
R2(config)#int s0
R2(config-if)#no shut
R2#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
172.12.123.1 1 FULL/DR 00:01:57 172.12.123.1 Serial0
R2#show ip route
1.0.0.0/32 is subnetted, 1 subnets
O 1.1.1.1 [110/65] via 172.12.123.1, 00:00:16, Serial0
172.12.0.0/24 is subnetted, 2 subnets
C 172.12.12.0 is directly connected, BRI0
C 172.12.123.0 is directly connected, Serial0
A floating static route is an excellent "back door" that will keep the ISDN link down while allowing that link to serve as a backup route. Just make sure the ISDN link comes down when you expect it to - always check that with show isdn status!
Subscribe to:
Posts (Atom)
