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

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

Đang tải... (xem toàn văn)

Thông tin tài liệu

CertificationZone Page 1 of 10 http://www.certificationzone.com/studyguides /?Issue=32&IssueDate=03-01-2001&CP= 11/06/01 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. CertificationZone Page 2 of 10 http://www.certificationzone.com/studyguides /?Issue=32&IssueDate=03-01-2001&CP= 11/06/01 isdn switch-type basic-ni 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 CertificationZone Page 3 of 10 http://www.certificationzone.com/studyguides /?Issue=32&IssueDate=03-01-2001&CP= 11/06/01 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: router#sh isdn stat The current ISDN Switchtype = basic-ni1 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 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: router#sh isdn stat The current ISDN Switchtype = basic-ni1 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) Activated dsl 0 CCBs = 0 Total Allocated ISDN CCBs = 0 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 CertificationZone Page 4 of 10 http://www.certificationzone.com/studyguides /?Issue=32&IssueDate=03-01-2001&CP= 11/06/01 there is a problem. router#sh isdn stat The current ISDN Switchtype = basic-ni1 ISDN BRI0 interface Layer 1 Status: DEACTIVATED Layer 2 Status: Layer 2 NOT Activated 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: 0 Active Layer 3 Call(s) Activated dsl 0 CCBs = 0 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. router#sh isdn stat The current ISDN Switchtype = basic-ni1 ISDN BRI0 interface Layer 1 Status: ACTIVE Layer 2 Status: TEI = 76, State = MULTIPLE_FRAME_ESTABLISHED TEI = 77, State = MULTIPLE_FRAME_ESTABLISHED Spid Status: spid1 configured, spid1 sent, spid1 valid spid2 configured, spid2 sent, spid2 valid Layer 3 Status: 0 Active Layer 3 Call(s) Activated dsl 0 CCBs = 0 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 <- IDCKRQ ri = 0 ai = 127 ISDN BR0: TX -> IDREQ ri = 38651 ai = 127 ISDN BR0: RX <- IDREM ri = 0 ai = 82 ISDN BR0: RX <- IDREM ri = 0 ai = 83 ISDN BR0: TX -> IDREQ ri = 1708 ai = 127 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: TX -> IDREQ ri = 29037 ai = 127 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 CertificationZone Page 5 of 10 http://www.certificationzone.com/studyguides /?Issue=32&IssueDate=03-01-2001&CP= 11/06/01 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) 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 00:25:46: BRI0/0 DDR: cdp, 275 bytes, outgoing uninteresting (no list matched) 00:25:46: BRI0/0 DDR: sending broadcast to ip 172.19.1.5 00:25:46: BRI0/0 DDR: cdp, 275 bytes, outgoing uninteresting (no list matched) CertificationZone Page 6 of 10 http://www.certificationzone.com/studyguides /?Issue=32&IssueDate=03-01-2001&CP= 11/06/01 00:25:46: BRI0/0 DDR: sending broadcast to ip 172.19.1.5 00:25:46: BRI0/0 DDR: cdp, 275 bytes, outgoing uninteresting (no list matched) 00:25:46: BRI0/0 DDR: sending broadcast to ip 172.19.1.5 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 ! dialer-list 1 protocol ip permit 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 CertificationZone Page 7 of 10 http://www.certificationzone.com/studyguides /?Issue=32&IssueDate=03-01-2001&CP= 11/06/01 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 06:21:23: %SYS-5-CONFIG_I: Configured from console by console 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 06:21:38: %SYS-5-CONFIG_I: Configured from console by console 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 CertificationZone Page 8 of 10 http://www.certificationzone.com/studyguides /?Issue=32&IssueDate=03-01-2001&CP= 11/06/01 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. CertificationZone Page 9 of 10 http://www.certificationzone.com/studyguides /?Issue=32&IssueDate=03-01-2001&CP= 11/06/01 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 ! isdn switch-type basic-ni ! 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 no ip directed-broadcast encapsulation ppp isdn switch-type basic-ni isdn spid1 0835866101 8358661 isdn spid2 0835866301 8358663 dialer map ip 172.16.1.5 name router2 8358660 ppp authentication chap dialer-group 1 ! ip classless ! ip route 0.0.0.0 0.0.0.0 172.16.1.5 2 ! dialer-list 1 protocol ip permit ! 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 ! isdn switch-type basic-ni ! interface Ethernet0/0 ip address 10.10.12.1 255.255.255.0 no ip directed-broadcast CertificationZone Page 10 of 10 http://www.certificationzone.com/studyguides /?Issue=32&IssueDate=03-01-2001&CP= 11/06/01 ! interface Serial0/0 no ip address shutdown ! interface BRI0/0 ip address 172.19.1.5 255.255.255.252 no ip directed-broadcast encapsulation ppp isdn switch-type basic-ni isdn spid1 0835866001 8358660 isdn spid2 0835866201 8358662 dialer map ip 172.16.1.6 name router1 8358661 ppp authentication chap 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 ! dialer-list 1 protocol ip permit ! 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] Copyright © 2001 Genium Publishing Corporation . 1 of 10 http://www.certificationzone.com/studyguides /?Issue=32&IssueDate=0 3- 0 1- 20 01& amp;CP= 11 /06/ 01 Date of Issue: 0 3- 0 1- 20 01 Lab Scenario 1 - Legacy. 1 ! ip classless ! ip route 17 2 .16 .1. 4 255.255.255.252 17 2 .16 .1. 5 10 0 ip route 10 .10 .11 .1 255.255.255.0 17 2 .16 .1. 5 10 0 ! dialer-list 1 protocol ip permit ! line

Ngày đăng: 18/01/2014, 04:20

Tài liệu cùng người dùng

Tài liệu liên quan