[ LiB ]

Scenarios

This section presents examples of ISDN configurations. Each new general command is discussed in detail the first time it is encountered. Each subsequent mention of a command is simply shown. This includes commands and concepts covered in previous chapters.

Scenario 6-1: Configuring a Simple ISDN Call

Here you will learn how to set up a simple ISDN call by using PPP encapsulation, defining interesting traffic, and specifying a carrier switch type and other service provider parameters.

In this scenario, DDR is configured to connect R1 to R2. Routing is achieved via a static route. The type of DDR used is "legacy" DDR, which uses dialer maps. Figure 6-4 shows the network layout.

You will first look at R1's configuration, followed by that of R2.

Step 1: Configuring the Switch Type

The first thing you should do is specify the switch type. Table 6-3 shows a number of switches and their IOS command equivalents. As you can see, there are quite a few. The types of switches vary from country to country. Also, most switches are available in either basic or primary implementations for use with BRI or PRI, accordingly.

Table 6-3. Types of ISDN Switches

Command	Description
basic-1tr6	1TR6 ISDN switches (Germany)
basic-5ess	AT&T basic rate switches (U.S.)
basic-dms100	NT DMS-100 (North America)
basic-ni1	National ISDN-1 (North America)
basic-ni2	National ISDN-2 (North America)
basic-1tr6	1TR6 ISDN switches (Germany)
basic-nwnet3	Net3 switches (Norway)
basic-nznet3	Net3 switches (New Zealand)
basic-ts013	TS013 and TS014 switches (Australia)
basic-net3	NET3, also known as E-DSS1 or DSS1 switches (United Kingdom and Europe)
ntt	NTT ISDN switch (Japan)
primary-4ess	AT&T 4ess switch (U.S.)
primary-5ess	AT&T 5ess switch (U.S.)
primary-dms100	NT DMS-100 switch (U.S.)
primary-net5	NET5 switches (Europe)
vn2 to vn5	VN2, VN3, VN4, and VN5 ISDN switches (France)

Find out which one is used by your service provider. Make sure you are clear on the correct type of switch to avoid numerous problems.

The switch type can be configured in either global or interface configuration mode. Global mode controls the type of switch for all ISDN interfaces. The interface mode command applies it to that interface only. You've probably already guessed that if two different switches are specified for global and interface configuration, the interface takes precedence over the global for that particular interface.

To configure your CO's switch type, use

R1(config)#isdn switch-type switch-identifier

or

R1(config-if)#isdn switch-type switch-identifier

Select the AT&T 5ess switch as the CO ISDN switch type for all ISDN interfaces with

R1(config)#isdn switch-type basic-5ess

After you've specified the type of switch, you can configure the CHAP username and password for the remote router:

R1(config)#username R2 password Cisco

Step 2: Configuring the ISDN Interface

To specify the interface for use by ISDN, choose one of two available commands. The first one applies to routers with the native ISDN interface TE1:

R1(config)#interface bri number

If native TE1 is not a part of your router setup, you need to designate a serial interface for use in ISDN. It becomes TE2 with external TA:

R1(config)#interface serial number

All subsequent commands that govern the interface take place in interface configuration mode. Whether you are using legacy DDR or dialer profiles determines whether most of your interface configuration tasks are applied to a logical or physical interface. Regardless, the ISDN interface is assigned a protocol address, an encapsulation option, a dialer group and, possibly, Service Profile Identifier (SPID) numbers (discussed in the next scenario).

Select the BRI 0 configuration mode:

R1(config)#interface bri 0

Define the BRI 0 IP address and net mask:

R1(config-if)#ip address 192.168.1.1 255.255.255.0

Set the PPP encapsulation for BRI 0:

R1(config-if)#encapsulation ppp

Add CHAP PPP authentication for BRI 0:

R1(config-if)#ppp authentication chap

Step 3: Configuring the Idle Timer

To prevent the link from staying up indefinitely, you can configure an idle timer. If there is no traffic on the link during the idle timer interval, the connection is terminated. The command to configure the idle timer is

R1(config-if)#dialer idle-timeout seconds

Here's an example:

R1(config-if)#dialer idle-timeout 3600

Step 4: Configuring Dialer Maps

To place a call to a destination, a router needs some way of identifying it. The "DDR" section mentioned the existence of legacy DDR and its more advanced successor, dialer profiles. Here you will become familiar with the legacy DDR configuration through dialer maps.

In short, dialer maps associate the destination router's protocol address with a specific telephone number called the dial string. The command lets other options be specified as well. It's important to understand that it is applied to the physical interfacein this case, BRI 0.

R1(config-if)#dialer map protocol next-hop-address [name hostname] [speed speed]
  [broadcast] dial-string

This syntax does not include all the options available for this command. The options shown here translate as follows:

• protocol is the Layer 3 protocol to which the phone number is mapped.

• next-hop-address is the Layer 3 protocol address.

• hostname is the name of the remote router used for authentication.

• speed is used for rate adaptation to request a lower speed than the standard DS0 64 kbps.

• With broadcast, broadcasts, such as routing updates, are forwarded to this address.

• dial-string is the destination's telephone number.

Multiple dialer map statements identifying different destinations may be used on the same physical interface.

Create the dialer map command to specify IP as the name of the protocol, 192.168.1.2 as the IP address for the BRI interface of the next-hop router, R2 as the CHAP identification name for the remote router, and 2125552222 as the telephone number used to reach the BRI interface on the remote router:

R1(config-if)#dialer map ip 192.168.1.2 name R2 speed 56 2125552222

Step 5: Specifying Interesting Traffic

You might recall the definition of interesting traffic from the "DDR" section. The dialer-list command is used to identify interesting traffic. dialer-list has two versions: the so-called basic version and one that refers to an access list. The basic version allows or drops only packets belonging to an entire protocol:

R1(config)#dialer-list dialer-group-number protocol protocol-name {permit | deny}

The access-list version adds the richness of all the options that can be defined by the extended access list:

R1(config)#dialer-list dialer-group-number protocol protocol-name list
  access-list-number

Let's look at what each element of this command represents. dialer-group-number is the dialer-list identifier that will be used in the next step of DDR configuration to assign this list to an interface. protocol-name specifies the Layer 3 protocol to be used.

The access-list-number argument matches an extended access list that is defined separately for the purposes of being used with the dialer-list command. The use of access lists to define interesting traffic is covered in the next scenario.

To define interesting traffic for R1, you need to exit interface configuration mode. Associate permitted IP traffic with dialer group 1. This means that the router initiates an ISDN call only for IP traffic.

R1(config)#dialer-list 1 protocol ip permit

Step 6: Assigning the Dialer List to an Interface

We've already mentioned that the dialer-group-number used in the previous command needs to match another command's argument that applies it to an actual interface. By referencing the same number in the dialer-group interface command, the dialer-list command set up in global configuration mode controls which packets are to initiate a call through that interface.

R1(config-if)#dialer-group dialer-group-number

Enter interface configuration mode again, and associate the BRI 0 interface with dialer list 1:

R1(config-if)#dialer-group 1

Step 7: Configuring Routing

You were previously warned that if you choose to advertise routing updates and inadvertently don't prevent those updates from bringing up the link, you might be unpleasantly surprised when you receive a bill from your provider.

Do not despair. ISDN technology offers numerous options to successfully accomplish what you need while keeping charges in check:

• Static routes and default routes

• Floating static routes

• Dynamic routing with passive interfaces

• OSPF demand circuit

• Dialer watch

• Snapshot routing

Here you will examine the static route option; the rest are discussed in later scenarios.

Whenever you have a stub network, as is the case with this scenario, there is no real need to use dynamic routing, because all connections come from and go to the same point.

Set up a static route to R2's 192.168.100.0/24 network using this command:

R1(config)#ip route 192.168.100.0 255.255.255.0 192.168.1.2

Example 6-1 demonstrates R1's complete ISDN configuration that includes all previous steps.

Example 6-1. R1 ISDN Configuration

R1#show run
hostname R1
isdn switch-type basic-5ess
username R2 password Cisco
interface bri 0
 ip address 192.168.1.1 255.255.255.0
 encapsulation ppp
 dialer idle-timeout 360
 dialer map ip 192.168.1.2 name R2 speed 56 2125552222
 dialer-group 1
 ppp authentication chap
!
ip route 192.168.100.0 255.255.255.0 192.168.1.2
dialer-list 1 protocol ip permit

Let's now look at the configuration of R2. It needs to mirror R1.

Establish the CHAP username and password for the remote router:

R2(config)#username R1 password Cisco

Identify the BRI 0 IP address and net mask:

R2(config-if)#ip address 192.168.1.2 255.255.255.0

Specify R1 as the CHAP identification name for the remote router and 2125551111 as the telephone number used to dial up the remote router:

R2(config-if)#dialer map ip 192.168.1.1 name R1 speed 56 2125551111

Example 6-2 shows the ISDN configuration of R2.

Example 6-2. R2 ISDN Configuration

R1#show run
hostname R2
isdn switch-type basic-5ess
username R1 password Cisco
interface bri 0
 ip address 192.168.1.2 255.255.255.0
 encapsulation ppp
 dialer idle-timeout 360
 dialer map ip 192.168.1.1 name R1 speed 56 2125551111
 dialer-group 1
 ppp authentication chap
!
ip route 192.168.200.0 255.255.255.0 192.168.1.1
dialer-list 1 protocol ip permit

Scenario 6-2: Configuring DDR with Access Lists

In this scenario, you will look at how DDR commands can be used to define an extended access list to initiate ISDN calls. The topology used in the preceding scenario applies to this one as well. Some changes have been requested, however, so your configuration needs to be adjusted accordingly. The service provider switch is changed to a Northern Telecom DMS-100 model, and DDR must be configured on router R1 to connect to R2 for all IP traffic except Telnet and FTP.

Specify a Northern Telecom DMS-100 switch as the one used by the ISDN service provider:

R1(config)#isdn switch-type basic-dms100

Configuring SPIDs

After you've specified the switch type, you might need to specify a SPID number. Not all switches require a SPID value, especially outside the U.S. Whenever the SPID number is required, you can find out the exact SPID information from your ISDN service provider.

SPIDS are dial-in numbers used by some service providers with certain types of switches, such as National ISDN1 and DMS-100. These numbers, which are similar to regular phone numbers, verify the services provided by your contract. SPIDs are available in spid1 and spid2 categories, one for each B channel.

Sometimes the keyword ldn might have to be placed at the end of the command line. ldn (local directory number) is assigned by the service provider and is used to make sure that calls are properly routed to both B channels.

The syntax for the spid commands is as follows:

R1(config-if)#isdn spid1 spid-number [ldn]
R1(config-if)#isdn spid2 spid-number [ldn]

Because you are using a DMS-100 switch, you need to configure SPID numbers:

R1(config-if)#isdn spid1 5551212
R1(config-if)#isdn spid2 5551213

PPP Authentication with a Different Host Name

In the last scenario, you set up CHAP authentication on each participating router to match the calling router's host name. You might run into a situation in which a username you set up for a calling router does not match its host name. For instance, not knowing a router's host name, dealing with a rotational host name, or simply shortening the task of storing a multitude of host names with their respective passwords would prompt you to skip the real host name and opt for an alternate. Cisco offers such an option for CHAP in its IOS.

To achieve this, perform a combination of actions. On the called router, such as R2, configure the username password command using an alternate host name:

R2(config)#username caller password Cisco

At the same time, match this alternate host name on the calling router, R1, with the following command:

R1(config-if)#ppp chap hostname alternate-host-name

Replace the alternate-host-name argument in the real configuration with the word "caller."

Configuring DDR

Because you will configure the new dialer group number 2 for this scenario, first remove the dialer group 1 configured in the previous scenario.

Then associate the BRI 0 interface with dialer list 2 using the dialer-group command:

R1(config-if)#dialer-group 2

You can apply access lists to a dialer group to initiate dialing. The use of extended access lists when configuring ISDN is more common than specifying conditions in the dialer list itself.

Extended TCP access list entries are defined in the access-list 111 deny commands. They prevent FTP and Telnet packets from triggering calls.

R1(config)#access-list 111 deny tcp any any eq ftp
R1(config)#access-list 111 deny tcp any any eq telnet

The command access-list 111 permit allows all other IP traffic to start ISDN calls:

R1(config)#access-list 111 permit ip any any

The next command enables automatic DDR calling. It assigns access list 111 to dialer list 2, which in turn is applied to the BRI 0 interface by the dialer-group command already configured:

R1(config)#dialer-list 2 protocol ip list 111

Example 6-3 shows R1's new configuration.

Example 6-3. R1 Running Configuration

R1#show run
hostname R1
isdn switch-type basic-dms100
isdn spid1 5551212
isdn spid2 5551213
username R2 password Cisco
interface bri 0
 ip address 192.168.1.1 255.255.255.0
 encapsulation ppp
 dialer idle-timeout 360
 dialer map ip 192.168.1.2 name R2 speed 56 2125552222
 dialer-group 2
 ppp authentication chap
 ppp chap hostname caller
ip route 192.168.100.0 255.255.255.0 192.168.1.2
access-list 111 deny tcp any any eq ftp
access-list 111 deny tcp any any eq telnet
access-list 111 permit ip any any
dialer-list 2 protocol ip list 101

Scenario 6-3: Configuring PRI

Figure 6-5 shows the topology for this scenario. R3 possesses a PRI interface. You need to configure the router to allow R4 to access its Ethernet side via ISDN.

You can begin your configuration by enabling the Ethernet interface on R3. This includes setting an IP address for the Ethernet interface. Here, it is 10.30.30.1/24.

The next step is to configure the ISDN switch type specified by the telephone company for your PRI connection. In this case, it is primary-5ess:

R3(config)#isdn switch-type primary-5ess

Now configure a username and password to be used for authentication when R4 tries to connect to R3. Let's say that the username is "R4" and the password is "Cisco":

R3(config)#username R4 password Cisco

You can now configure a dialer list to specify IP as the type of interesting traffic that initiates a call to R4:

R3(config)#dialer-list 1 protocol ip permit

Next, create the static route to R4's Ethernet network via its BRI address:

R3(config)#ip route 10.40.40.0 255.255.255.0 192.168.1.4

It's time to configure the T1 interface.

Configuring PRI

Configuring PRI interfaces involves the PRI-specific tasks discussed next, as well as the DDR-based commands you used in BRI configurations.

You start by configuring the ISDN PRI controller:

R3(config)#controller {t1 | e1} {slot/port | unit-number}

The t1 part of the command is used for North America and Japan. e1 is used for European facilities and much of the rest of the world. The slot/port or unit-number specifies the controller's physical slot, port location, or unit number.

You can use the following controller configuration command to select the frame type used by the PRI service provider:

R3(config-controller)#framing {sf | esf | crc4 | no-crc4}

Older T1 configurations use the sf (superframe) keyword. esf (extended superframe) is used for T1 PRI configurations. The crc4 | no-crc4 (cyclic redundancy check) options are for E1 PRI configurations.

The next command identifies the physical-layer signaling method. You need to satisfy the density requirement of 1s on the provider's digital facility. If there aren't enough 1s in the digital bitstream, the network switches and multiplexers can lose their synchronization for transmitting signals.

R3(config-controller)#linecode {ami | b8zs | hdb3}

ami means alternate mark inversion. hdb3 (high-density bipolar 3) is used for E1 PRI configurations.

The linecode and framing controller commands must match the framing and line-code types that are used at the T1/E1 WAN provider's CO switch.

Choose the clock source for the T1 with the following command:

R3(config-controller)#clock source {line [primary | secondary] | internal}

primary or secondary keywords are used for AS5000 to select either the primary or secondary TDM as the clock source.

Now that you've configured the controller, you can specify it for the PRI operation:

R3(config-controller)#pri-group timeslots range

This command identifies how many fixed timeslots the provider allocates. T1 uses values from 1 to 24, and E1 can range from 1 to 31.

The next command sets up an interface for PRI D channel operation:

R3(config-controller)#interface serial {slot/port: | unit :}{23 | 15}

This creates a serial subinterface to a T1/E1. The 23 argument refers to a T1 interface and designates channels 0 to 22 as the B channels and DS0 23 as the D channel. Alternatively, the 15 parameter is for an E1 interface and designates 30 B channels and timeslot 16 as the D channel.

On R3, configure your PRI as shown in Example 6-4.

Example 6-4. PRI Configuration

R3(config)#controller t1 1/0
R3(config-controller)#linecode b8zs
R3(config-controller)#clock source line
R3(config-controller)#framing esf
R3(config-controller)#pri-group timeslots 1-24
R3(config-controller)#interface serial 1/0:23

At this point you can continue with the DDR portion of the PRI configuration. The tasks you configure here are already familiar to you, such as PPP encapsulation, authentication, interface IP address, dialer group, and dialer map to the destination. This portion of the configuration is presented in Example 6-5.

Example 6-5. R3 Interface Configuration

R3(config-if)#encapsulation PPP
R3(config-if)#ppp authentication chap
R3(config-if)#ip address 192.168.1.3 255.255.255.0
R3(config-if)#dialer-group 1
R3(config-if)#dialer idle-timeout 90
R3(config-if)#dialer map ip 192.168.1.4 name R4 2125554444

Next, you will configure dynamic routing via EIGRP.

Configuring Routing

In the previous scenario, you learned how to set up routing via a static route. In most instances, however, this solution is not sufficient to satisfy the routing requirement. In larger environments, the scalability issue introduces the need for dynamic routing.

In this example, you can set up EIGRP routing with the following command:

R3(config)#router eigrp 100

This creates a new problem. If you introduce your network into the dynamic protocol, your links will constantly be brought up by the routing updates, right? Well, not if you configure passive interfaces. A passive interface listens to routing updates but doesn't forward them.

R3(config-router)#passive-interface interface

The following command adapts this syntax for the current scenario:

R3(config-router)#passive-interface serial 1/0:23

Sometimes a situation occurs in which other networks need to be informed of the stub network existence. So, you need to configure the router to redistribute the static route to other routers in the network. Therefore, the static route will be redistributed into a dynamic protocol of your choice. For this purpose, apply the following:

R3(config-router)#redistribute static

Verification

You can verify your ISDN configuration by using several commands. For instance, you can check the status of the ISDN link by entering show isdn status, as shown in Example 6-6.

Example 6-6. Verifying ISDN Status

R3#show isdn status
The current ISDN Switchtype = primary-5ess
ISDN Serial1/0:23 interface
    Layer 1 Status:
        ACTIVE
    Layer 2 Status:
        TEI = 0, State = MULTIPLE_FRAME_ESTABLISHED
    Layer 3 Status:
        0 Active Layer 3 Call(s)
    Activated dsl 0 CCBs = 0
    Total Allocated ISDN CCBs = 0

You can check the D channel configuration by issuing the show interface serial 1/0:23 command, as shown in Example 6-7.

Example 6-7. Verifying the D Channel Subinterface

R3#show interface serial 1/0:23
Serial1/0:23 is up, line protocol is up (spoofing)
  Hardware is DSX1
  Internet address is 192.168.1.3/24
  MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255
  Encapsulation PPP, loopback not set
  Last input 00:00:04, output 00:00:04, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0 (size/max/drops); Total output drops: 0
  Queueing strategy: weighted fair
  Output queue: 0/1000/64/0 (size/max total/threshold/drops)
     Conversations  0/1/256 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     102 packets input, 618 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     102 packets output, 571 bytes, 0 underruns
     0 output errors, 0 collisions, 6 interface resets
     0 output buffer failures, 0 output buffers swapped out
     1 carrier transitions
  Timeslot(s) Used:24, Transmitter delay is 0 flags

Next, you can verify the configuration of the T1 controller. Enter show controller t1 1/0 to do this, as shown in Example 6-8.

Example 6-8. Verifying the Controller Configuration

R3#show controller t1 1/0
T1 1/0 is up.
  Applique type is Channelized T1 - unbalanced
  No alarms detected.
  Framing is ESF, Line Code is B8zs, Clock Source is Line.

  Data in current interval (580 seconds elapsed):
     0 Line Code Violations, 0 Path Code Violations
     0 Slip Secs, 3 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
     0 Errored Secs, 0 Bursty Err Secs, 3 Severely Err Secs, 0 Unavail Secs

If you want to monitor the ISDN connection in real time so that you can see the Layer 2 communication process, you can turn on Q.921 debugging by entering debug isdn q921.

Then you ping R4's Ethernet port. Assume that it is configured with the IP address 10.40.40.1. When the ping returns successful results, you can view the rest of the connection process, because Q.921 debugging has been turned on, as shown in Example 6-9.

Example 6-9. Monitoring the ISDN Connection in Real Time

ISDN Q921 packets debugging is on
R3#
ISDN Se1/0:23: RX <-  RRp sapi = 0  tei = 0 nr = 20
ISDN Se1/0:23: TX ->  RRf sapi = 0  tei = 0  nr = 15
ISDN Se1/0:23: TX ->  RRp sapi = 0  tei = 0 nr = 15
ISDN Se1/0:23: RX <-  RRf sapi = 0  tei = 0  nr = 20
ISDN Se1/0:23: RX <-  RRp sapi = 0  tei = 0 nr = 20
ISDN Se1/0:23: TX ->  RRf sapi = 0  tei = 0  nr = 15
ISDN Se1/0:23: TX ->  RRp sapi = 0  tei = 0 nr = 15
ISDN Se1/0:23: RX <-  RRp sapi = 0  tei = 0 nr = 20
ISDN Se1/0:23: TX ->  RRf sapi = 0  tei = 0  nr = 15
ISDN Se1/0:23: RX <-  RRf sapi = 0  tei = 0  nr = 20

Scenario 6-4: Alternative Identification Techniques

You already know how to configure identification through PPP authentication options PAP and CHAP. You also encountered the alternate-host-name parameter that can be used with CHAP. In this scenario, you will be introduced to two more identification options that can be used alongside or instead of those you've previously learned.

Caller ID

The caller identification feature allows for screening of incoming ISDN calls. When the call is requested, the number supplied in the message is checked against a preexisting table of permitted numbers. This way, the call is not accepted until it is verified.

The syntax for the ISDN caller ID command is as follows:

Router(config-if)#isdn caller number [callback] [exact]

This statement is applied to a called router. The number argument can be up to 25 characters long and can specify a range of numbers or partially known numbers. If you supply an X for any position in the number, it is treated as a "don't-care" digit, where the router accepts any number that matches the same position. Also, you can assign several numbers to an interface.

The callback keyword is used in the callback setups. The optional exact keyword demands the exact match to the configured number. In other words, if you don't have the exact option enabled, your router accepts any number of digits supplied by a caller as long as the same sequence of numbers appears in the configured telephone number.

When configuring caller identification, take care that your switch or access router supports this feature; otherwise, no calls will get through.

Unidirectional PPP Authentication

As mentioned in the previous chapter, the PPP authentication option, along with many other PPP options, must be bidirectional. This means that both routers participating in the connection setup have to authenticate one another.

There is a way to bend this rule if you add an optional callin keyword at the end of the ppp authentication [pap | chap] command. This keyword specifies that authentication is to be used only if the router is on the receiving end of the call.

This issue comes up when one of the routers does not support authentication. Take a look at Figure 6-6. In this scenario, if R6 places a call to R2, it allows R2 to challenge R6, but it does not challenge R2 in return. However, if R2 places a call to R6 (a call in), R6 makes an authentication request from R2. The full syntax for the command is

R6(config-if)#ppp authentication [pap | chap] callin

Figure 6-6. One-Way PPP Authentication

[View full size image]

Scenario 6-5: Alternative Routing Methods

Previously, you learned how to configure static routing and dynamic routing via EIGRP. Here you will see how you can effectively implement OSPF as your dynamic routing method and use static routing as a backup method.

OSPF Demand Circuit

OSPF Demand Circuit (DC) is another feature that enables routing over ISDN without keeping the link constantly open. Perhaps you already know that to maintain neighbor relationships and ensure the accuracy of its link-state databases, OSPF sends Hello packets every 10 seconds and link-state advertisements (LSAs) every 30 minutes. Normally, it would keep the link up indefinitely.

The OSPF DC option was created to stifle periodic Hellos and LSAs. When DC is configured on a router, its Hello packets have a DC bit set, and its LSAs have a DoNotAge (DNA) bit set that suppresses those periodic refreshers. The way this works is at first OSPF creates adjacencies and synchronizes LSA databases in the usual manner. After this is done, OSPF keeps those adjacencies so that the routing updates can initiate an ISDN call only after a topological change has taken place.

To configure the OSPF DC, use the following command on your ISDN interface:

R1(config-if)#ip ospf demand-circuit

It has been argued by some that this command should be placed on routers at both ends of the call. However, it needs to reside only on the calling router. It is of no use to the receiving router. In instances where both routers can call one another, the use of OSPF DC is not recommended. Otherwise, you might run into a situation where both routers initiate a call simultaneously after the topological change, and the call will never get through.

A number of issues are associated with OSPF DC. If you are not careful while redistributing protocols into OSPF, you might cause routing loops and link flapping that keep the line up indefinitely because of constant "change" in topology.

Also, you might encounter a scenario where the ISDN interface's bandwidth, which figures into the OSPF metric of cost, equals that of the primary link. OSPF cost is based on a formula: cost = 100,100,000/bandwidth (bps). To keep the ISDN interface as a backup, you would have to manually assign it a very high cost to keep it from load balancing:

R1(config-if)#ip ospf cost cost

Floating Static Routes

There are situations where you want your static routes to take the back burner to dynamic routing and be used only if other routes are unavailable. You would have to configure floating static routes. Normally, static routes have a default administrative distance of 1. This means that under ordinary circumstances they are preferred over dynamic routing protocols.

To switch this order manually, assign an administrative distance to the static route that is higher than the one of a dynamic route. We recommend using something above 200. Employ the familiar ip route command, but this time, add an administrative-distance argument at the end:

R1(config)#ip route destination-network destination-subnet-mask {local-interface |
  next-hop} administrative-distance

Scenario 6-6: Configuring the Interface and the Backup Interface

The backup interface is used as an alternative to floating static routes. When an ISDN interface is configured as a backup, its status changes to standby, and its line protocol state changes to down. They remain that way until something happens to the main link. The command for the backup interface is configured under the principal interface (not the ISDN interface!). The syntax for the command is as follows:

R1(config-if)#backup interface interface number

A number of optional parameters can be configured under a backup interface setup. The backup delay command specifies the amount of time (in seconds) that will lapse after the main interface fails and before the ISDN backup link is brought up. It also identifies how long after the principal link is repaired the ISDN interface stays up until it becomes inactive again. This command is used in conjunction with the backup interface command under the chief interface configuration. If backup delay is omitted, the ISDN interface kicks in instantaneously after the primary link failure and deactivates after the primary link is back. This isn't a good idea when you're dealing with a flapping connection.

R1(config-if)#backup delay activation-time deactivation-time

The backup load command is used in a bandwidth-on-demand scenario. It controls the percentage of the main link saturation before activating the ISDN interface as well as the percentage in the decrease of traffic before bringing the ISDN link down. It is also used together with the backup interface command.

R1(config-if)#backup load activation-percentage deactivation-percentage

backup load can be configured alongside the backup delay command. Then, each one is responsible for its own sphere of influence.

[ LiB ]