Tài liệu DDR Lab Scenario 1 - Legacy DDR Walk Through doc

Configure PPP CHAP authentication SOLUTION REVEALED Router 1's Final Configuration Router 2's Final Configuration Introduction This lab is designed to walk you through a basic ISDN DDR

Trang 1

Date of Issue: 03-01-2001

Lab Scenario 1 - Legacy DDR Walk

Through

by David Wolsefer

Introduction

Network Specifications

The Starting Configurations

Configuration Tasks

1 Configure the ISDN switch type

2 "No shut" the BRI interfaces

3 Configure SPIDs

4 Use a dialer-list

5 Check our work

6 Configure a Floating Static Route

7 Encapsulation PPP

8 Configure Dialer Maps

9 Configure PPP CHAP authentication

SOLUTION REVEALED

Router 1's Final Configuration

Router 2's Final Configuration

Introduction

This lab is designed to walk you through a basic ISDN DDR configuration This lab will show you what commands to type in and how to check that you have configured things correctly step-by-step

Network Specifications

When you are finished building this network, it should meet the following specifications:

1 Each router should be able to dial the other

2 Dialing should occur any time you ping the other router, but should not dial to send any routing updates

3 You should use only static routes but the administrative distance should be something other than 0 or 1

4 You should only be able to see the neighboring router with Cisco Discovery Protocol if the ISDN link is already up

The Starting Configurations

The actual equipment used in developing this lab included a Cisco

1604 router and a Cisco 2610 router The ISDN simulator was a

Teltone ISDN Demonstrator with two U interfaces You can use any

router with suitable ISDN interfaces Some good recommendations

might include Cisco 2503s, 2504s, or 2522s Here is the basic

starting point for cabling your equipment:

ISDN Information for Router1:

isdn switch-type basic-ni

isdn spid1 0835866101 8358661

isdn spid2 0835866301 8358663

ISDN Information for Router2:

You will need to adjust the lab contents to fit your ISDN simulator and/or routers as necessary You MUST use an ISDN simulator

or actual ISDN lines There is no way to configure ISDN using crossover cables or something similar

Trang 2

isdn spid1 0835866201 8358662

isdn spid2 0835866401 8358664

Figure 1.

Configuration Tasks

1 Configure the ISDN switch type on each router.

Before we begin, perform a write erase on each router to make sure that we are starting from scratch After you enter the write erase command, reload the router When you receive a prompt to configure the router, enter ctrl-c and the router will continue to boot up Once this is done, enter exec mode by typing enable You will see the following:

Router>

Router>enable

Router#

Once this is complete, check that no configuration exists by entering the write command followed by show

configuration (Note: you can use show configuration instead of show run because you just saved the

configuration This displays the current configuration faster than show run would.) You should not see any configured

IP addresses, routing statements, or ISDN configurations of any kind You can check this by using the show isdn status command to see that no ISDN switchtype is defined Here is an example:

router#sh isdn stat

**** No ISDN Switchtype currently defined ****

ISDN BRI0 interface

Layer 1 Status:

DEACTIVATED

Layer 2 Status:

Layer 2 NOT Activated

Layer 3 Status:

0 Active Layer 3 Call(s)

Activated dsl 0 CCBs = 0

The Free Channel Mask: 0x80000003

Total Allocated ISDN CCBs = 0

Since we have no ISDN switch type configured, our first step should be to configure one We can use the ? to help us

find the correct syntax for our switch type, basic-ni1 We will need to use the isdn switch-type global command on

each router as follows:

Router#

Router#configure terminal (you can use conf t for short)

Router(config)#

r1(config)#isdn switch-type ?

basic-1tr6 1TR6 switch type for Germany

basic-5ess AT&T 5ESS switch type for the U.S

basic-dms100 Northern DMS-100 switch type

basic-net3 NET3 switch type for UK and Europe

basic-ni1 National ISDN-1 switch type

basic-nwnet3 NET3 switch type for Norway

basic-nznet3 NET3 switch type for New Zealand

basic-ts013 TS013 switch type for Australia

ntt NTT switch type for Japan

vn2 VN2 switch type for France

Trang 3

vn3 VN3 and VN4 switch types for France

router(config)#isdn switch-type basic-ni1

router(config)#^Z

router#

00:23:38: %SYS-5-CONFIG_I: Configured from console by console

Now that we have configured the ISDN switch type, let's check it by using the show isdn status command If you

configured your routers correctly, you should see the following:

The current ISDN Switchtype = basic-ni1

ISDN BRI0 interface

Layer 1 Status:

DEACTIVATED

Layer 2 Status:

Layer 3 Status:

The Free Channel Mask: 0x80000003

2 "No shut" the BRI interfaces to make sure that the router is talking to the ISDN switch.

router(config)#int bri 0

router(config-if)#no shut

router(config-if)#^z

00:23:54: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down

00:23:54: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down

00:23:54: %LINK-3-UPDOWN: Interface BRI0, changed state to up

Once we no shut the BRI interface, we should see it come up and check that the router is communicating with the ISDN switch by examining the layer 1 status to make sure it is ACTIVE and checking the layer 2 status to make sure it reads MULTIPLE FRAME ESTABLISHED Here is what it will look like:

ISDN BRI0 interface

Layer 1 Status:

ACTIVE

Layer 2 Status:

TEI = 70, State = MULTIPLE_FRAME_ESTABLISHED

Layer 3 Status:

No Active Layer 3 Call(s)

We now know that we have correctly defined the ISDN switch type and that our router is talking to the ISDN switch on the D channel The next step is to configure the SPIDs, if necessary Remember, not all ISDN switch-types require SPIDs, especially non-US ISDN switches

3 Configure SPIDs (If Necessary)

The example below shows how SPIDs are entered as well as how we can check that they are configured correctly Note that the SPIDs are configured as an interface command

router(config-if)#isdn spid1 ?

WORD spid1 string

router(config-if)#isdn spid1 0835866201 ?

WORD local directory number

<cr>

router(config-if)#isdn spid1 0835866201 8358662

router(config-if)#isdn spid2 0835866401 8358664

Before we show an example where the SPIDs have been configured correctly, let's look at what you might see when

Trang 4

there is a problem.

ISDN BRI0 interface

Layer 1 Status:

DEACTIVATED

Layer 2 Status:

Spid Status:

TEI Not Assigned, ces = 1, state = 1(terminal down)

spid1 configured, spid1 NOT sent, spid1 NOT valid

TEI Not Assigned, ces = 2, state = 1(terminal down)

spid2 configured, spid2 NOT sent, spid2 NOT valid

Layer 3 Status:

Notice that there is a message for each SPID saying that the SPID has not been sent and is not valid There are a number of ways to fix this problem, but the one I like to use is to bounce the interface by simply shutting down the interface and then no shutting the BRI interface If you still see the same message (that the SPIDs have not been sent and are not valid), you should check to make sure that you are configuring the correct SPIDs on the correct router

One other thing you can try is to use the clear interface bri 0 command Now, let's look at an example where the

SPIDs have been configured correctly, sent, and are valid This will not occur unless the router's configuration

matches the configuration of the ISDN switch exactly

ISDN BRI0 interface

Layer 1 Status:

ACTIVE

Layer 2 Status:

Spid Status:

spid1 configured, spid1 sent, spid1 valid

spid2 configured, spid2 sent, spid2 valid

Layer 3 Status:

In the following example, we enable debug isdn q921 and observe the initial communication with the ISDN switch

when the interface is no shut Notice that the packets are being transmitted and received as indicated by RX and TX

router#debug isdn q921

ISDN Q921 packets debugging is on

router#conf t

router(config)#

router(config)#int bri 0

router(config-if)# no shut

%LINK-3-UPDOWN: Interface BRI0, changed state to up

ISDN BR0: TX -> IDREQ ri = 33114 ai = 127

ISDN BR0: RX <- IDDENY ri = 33114 ai = 127

ISDN BR0: RX <- IDCKRQ ri = 0 ai = 127

ISDN BR0: RX <- IDREM ri = 0 ai = 82

ISDN BR0: RX <- IDREM ri = 0 ai = 83

ISDN BR0: RX <- IDASSN ri = 1708 ai = 85

ISDN BR0: TX -> SABMEp sapi = 0 tei = 85

ISDN BR0: RX <- UAf sapi = 0 tei = 85

ISDN BR0: TX -> INFOc sapi = 0 tei = 85 ns = 0 nr = 0

i = 0x08007B3A0A30383335383636323031

ISDN BR0: RX <- INFOc sapi = 0 tei = 85 ns = 0 nr = 1

i = 0x08007B080382E43A

ISDN BR0: TX -> RRr sapi = 0 tei = 85 nr = 1

ISDN BR0: RX <- IDASSN ri = 29037 ai = 86

ISDN BR0: TX -> SABMEp sapi = 0 tei = 86

ISDN BR0: RX <- UAf sapi = 0 tei = 86

ISDN BR0: TX -> INFOc sapi = 0 tei = 86 ns = 0 nr = 0

i = 0x08007B3A0A30383335383636343031

Trang 5

ISDN BR0: RX <- INFOc sapi = 0 tei = 86 ns = 0 nr = 1

i = 0x08007B080382E43A

ISDN BR0: TX -> RRr sapi = 0 tei = 86 nr = 1

router(config-if)# ^Z

router#

4 Use a dialer-list to define interesting traffic.

A dialer-list is used to define "interesting traffic" (traffic for which you wish to bring up the ISDN connection) We define a dialer-list in global configuration mode then apply the dialer-list using the interface configuration command

dialer-group When I am configuring ISDN DDR, I like to first define my dialer lists very broadly using IP until I have

all features working, such as call setup and teardown, authentication, callback, etc Once I have basic features

working correctly, then I will make the dialer list more selective, if necessary, using an access-list Here is an example that shows traffic that can be defined as interesting using a broad dialer list:

Router(config)#dialer-list 1 protocol ?

Appletalk Appletalk

Bridge Bridging

Clns OSI Connectionless Area Services

Clns_es CLNS End System

Clns_is CLNS Intermediate System

Decnet DECnet

Decnet DECnet node

Decnet_router-L1 DECnet router L1

Decnet_router-L2 DECnet router L2

Ip IP

Ipx Novell IPX

Llc2 LLC2

Vines Banyan Vines

Xns XNS

Using the above syntax, the first dialer list I like to configure is

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

Next, I apply the dialer list to the BRI interface using the dialer-group command:

interface bri0

dialer-group 1

A logical question is "How do I troubleshoot a dialer-list problem?" The answer is to use two debug commands

together: debug ip packet and debug dialer packet We can see in the following example that although CDP is not

interesting because it is not defined in the dialer-list, IP traffic is interesting because it is defined in the dialer-list:

r1#debug ip packet

IP packet debugging is on

r1#debug dialer packet

Dial on demand packets debugging is on

00:25:25: BRI0/0 DDR: cdp, 10 bytes, outgoing uninteresting

(no list matched)

r1#ping 172.19.1.5

00:25:44: BRI0/0 DDR: ip (s=172.19.1.6, d=255.255.255.255),

52 bytes, outgoing interesting (ip PERMIT)

00:25:44: BRI0/0 DDR: sending broadcast to ip 172.19.1.5

failed, not connected

00:25:44: IP: s=172.19.1.6 (local), d=255.255.255.255 (BRI0/0),

len 52, encapsulation failed

00:25:195430010384: %LINK-3-UPDOWN: Interface BRI0/0:1,

changed state to up

00:25:193273528384: %ISDN-6-CONNECT: Interface BRI0/0:1 is now

connected to 8358662

00:25:46: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0/0:1,

changed state to up

(no list matched)

Trang 6

(no list matched)

00:25:51: %ISDN-6-CONNECT: Interface BRI0/0:1 is now connected

to 8358662

5 Check our work to date by configuring a dial string.

At this point, we need to configure only dial strings on each router to test basic connectivity Let's examine an ISDN configuration in its most basic form This is the minimum configuration needed to connect to another router Each router should have a similar configuration, although the dial strings will be different

router1#show run

Version 11.3

Hostname router1

!

isdn switch-type basic-ni1

!

interface bri0

ip address 172.19.1.6 255.255.255.0

dialer string 384000

dialer-group 1

!

dialer-list 1 protocol ip permit

router2#show run

Version 11.3

Hostname router2

!

isdn switch-type basic-ni1

!

interface bri0

ip address 172.19.1.5 255.255.255.0

dialer string 384020

dialer-group 1

!

We can now check our work by pinging from router1 to router2 and vice versa

router1#ping 172.19.1.5

Type escape sequence to abort

Sending 5, 100-byte ICMP Echos to 172.19.1.5, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

6 Configure a Floating Static Route

Floating static routes are a very popular way of implementing DDR because they do not keep an ISDN link up

constantly as a dynamic routing protocol would Floating static routes do not keep the link up because they do not generate any traffic on the link They allow you to control what traffic will bring up the ISDN link in a very selective fashion However, floating static routes do have drawbacks One of the key drawbacks is that you must configure them very carefully

Let's look at an example to illustrate this problem With static routes, there are two possibilities The first possibility references a destination using a local interface address, e.g.,

ip route 0.0.0.0 0.0.0.0 bri 0

The second possibility references the next hop IP address:

ip route 0.0.0.0 0.0.0.0 172.16.1.5

The difference between the two possibilities comes into play when we talk about redistribution With the first

Trang 7

possibility, the static route will appear as a connected route in the routing table and is automatically redistributed by routing protocols whose network statements include the address of the BRI interface The second possibility,

however, appears in the routing table with an administrative distance of 1, so it must be manually redistributed into dynamic routing protocols This can cause problems because you may end up keeping the ISDN line up anyway if you use a static route that references an outbound interface as in the first possibility

7 Encapsulation PPP

Notice that until now, we have not been using PPP In fact, the default encapsulation for a BRI or serial interface is HDLC This creates a problem because we want to configure PPP CHAP authentication later In order to do this, we need to change the encapsulation type to PPP using an interface configuration command under the physical BRI interface We will need to do this on each router Here is an example:

Router1#

Router1#conf t

Router1(config)#

Router1(config)#interface BRI0/0

Router1(config-if)#encapsulation ppp

How can we verify that we are configured for PPP encapsulation? Although there are a number of ways, the easiest is

to view the running configuration, but an alternative is to use the show interface command as follows:

Example 1 - Default HDLC encapsulation

ts#sh int bri 0/0

Bri0/0 is administratively down, line protocol is down

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)

Last input never, output never, 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/0/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

0 packets input, 0 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

0 packets output, 0 bytes, 0 underruns

0 output errors, 0 collisions, 1 interface resets

0 output buffer failures, 0 output buffers swapped out

0 carrier transitions

DCD=down DSR=down DTR=down RTS=down CTS=down

Now we configure PPP encapsulation and observe the difference

Example 2 - PPP encapsulation

ts#sh int bri 0/0

Bri0/0 is administratively down, line protocol is down

Hardware is HD64570

MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255

Encapsulation PPP, loopback not set, keepalive set (10 sec)

LCP Closed

Closed: CDPCP

Last input never, output never, 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/0/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

0 packets input, 0 bytes, 0 no buffer

Trang 8

Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

0 packets output, 0 bytes, 0 underruns

0 output errors, 0 collisions, 3 interface resets

0 output buffer failures, 0 output buffers swapped out

0 carrier transitions

DCD=down DSR=down DTR=down RTS=down CTS=down

8 Configure Dialer Maps

Since the dial string is very limited, we will first remove the dialer string and reconfigure with a more scalable solution instead: dialer maps Dialer maps are very similar to frame relay maps in configuration and function Note that dialer maps and dialer strings are mutually exclusive, so you must use one or the other, not both If you try to configure a dialer map when a dialer string currently exists on the interface, you will see an error message:

Router1(config-if)#dialer map ip 172.16.1.5 384000

%cannot change dialer map when dialer string is present

What we do first is remove the dialer string as follows:

router1(config-if)#no dialer string 384000

Next, we add the dialer map These two steps need to be performed on both routers In its simplest form, the dialer map would be configured like the example below, but in live networks, you will rarely see this because most people do configure authentication The best way to configure the dialer map for authentication will be discussed in the next section of the lab

Router1(config-if)#dialer map ip 172.16.1.5 384000

9 Configure PPP CHAP authentication

To configure authentication with ISDN and PPP, we have two options: PAP and CHAP PAP is rarely used because the password is transmitted in the clear and can easily be seen with a sniffer For this reason, we will use CHAP instead

The first step in configuring CHAP authentication is to set up local user databases on each router What we need to

do is to enter the username for the opposite router and a common password using a global configuration command Don't forget that the passwords are case sensitive For example, on router1, we would enter the following:

Router1(config)#username router2 password cisco

On router2, we would similarly enter:

Router2(config)#username router1 password cisco

Once the database has been created, we only have three more commands that must be entered, but this time they are in interface configuration mode The commands are entered as follows:

encapsulation ppp (if we didn't already configure it)

ppp authentication chap

dialer map protocol next-hop-address name remote_ppp_authentication_name dialer-string

The first two commands are self explanatory, but the last will be more obvious if we use an example such as router1's configuration

Router1(config)# interface bri 0

Router1(config-if)#encapsulation ppp

Router1(config-if)#ppp authentication chap

Router1(config-if)#dialer map ip 172.16.1.5 name router2 384000

Router2 would have a similar configuration How can we test our configuration? We can simply ping from one router

to the other If we get a successful ping, then everything is working correctly We can immediately see if we have an authentication problem because we will see the link going up and down repeatedly We can then troubleshoot the

cause of the problem by enabling debug ppp authentication We will demonstrate this in the next lab with dialer

profiles

Trang 9

Now that we have configured basic legacy DDR with dialer maps and authentication, let's look at the final

configurations for router1 and router2 If you look at the static routes carefully, you will see that we demonstrated two different methods The first method uses a default static route to send all non-local traffic to router2 The second method configures specific static routes on router2 for each network on router1 Notice also that the administrative distances have been changed to something other than 0 or 1

SOLUTION REVEALED

Router 1's Final Configuration

version 12.0

!

hostname router1

!

username router2 password 0 cisco

!

ip subnet-zero

!

interface Ethernet0/0

ip address 10.10.11.1 255.255.255.0

no ip directed-broadcast

!

interface Serial0/0

no ip address

shutdown

!

interface BRI0/0

ip address 172.19.1.6 255.255.255.252

encapsulation ppp

isdn spid1 0835866101 8358661

isdn spid2 0835866301 8358663

dialer map ip 172.16.1.5 name router2 8358660

dialer-group 1

!

ip classless

!

ip route 0.0.0.0 0.0.0.0 172.16.1.5 2

!

line con 0

transport input none

line aux 0

line vty 0 4

login

!

no scheduler allocate

end

Router 2's Final Configuration

version 12.0

!

hostname router2

!

username router1 password 0 cisco

!

ip subnet-zero

!

interface Ethernet0/0

ip address 10.10.12.1 255.255.255.0

Trang 10

interface Serial0/0

no ip address

shutdown

!

interface BRI0/0

ip address 172.19.1.5 255.255.255.252

encapsulation ppp

isdn spid1 0835866001 8358660

isdn spid2 0835866201 8358662

dialer map ip 172.16.1.6 name router1 8358661

dialer-group 1

!

ip classless

!

ip route 172.16.1.4 255.255.255.252 172.16.1.5 100

ip route 10.10.11.1 255.255.255.0 172.16.1.5 100

!

line con 0

transport input none

line aux 0

line vty 0 4

login

!

no scheduler allocate

end

[NA-DDR-LS1-F04]

[2001-02-28-01]

Định dạng
Số trang	10
Dung lượng	36,57 KB

Tiêu đề	Lab Scenario 1 - Legacy DDR Walk Through
Tác giả	David Wolsefer
Thể loại	Lab Scenario
Năm xuất bản	2001