To Configure an interface for HDLC, simply turn it on:
sample-gw# config term Enter configuration commands, one per line. End with CNTL/Z. sample-gw(config)# int ser 0 sample-gw(config-if)# no shut sample-gw(config-if)# ^Z sample-gw#and you should be ready to go. You're interface will not have an IP address which will make testing more difficult if there are problems, but it will generally be enough to get going. You have two options on IP addresses for the interface; you can use IP unnumbered which makes the serial port respond to an IP address elsewhere on the router, or give it an IP address. Generally you'll find it easier to give it an IP address:
sample-gw# config term Enter configuration commands, one per line. End with CNTL/Z. sample-gw(config)# int ser 0 sample-gw(config-if)# ip address 10.2.3.5 255.255.255.252 sample-gw(config-if)# ^Z sample-gw#In this example, we've used a small network block that ranges from 10.2.3.4 - 10.2.3.7 with the only usable address being 10.2.3.5 and 10.2.3.6 which is convenient for this type of situation since we will only need two IP addresses for this link. (the 10.2.3.4 address is the low broadcast address and the 10.2.3.7 address is the high broadcast address - like .0 and .255 in a old Class C address block)
If you don't have address space to spare for serial port addresses, another option is to use IP Unnumbered - which makes the serial port respond to another address that is in use on the router - for instance the ethernet port address.
sample-gw# config term Enter configuration commands, one per line. End with CNTL/Z. sample-gw(config)# int ser 0 sample-gw(config-if)# ip unnumbered ethernet0 sample-gw(config-if)# ^Z sample-gw#This is a good way to preserve address space but it does make debugging T1 problems a little more difficult.
Once we've got an HDLC T1 turned up, your most usefull command for finding information out about the circuit is do run the command show interface XXX where XXX is the interface - in our case Serial0
sample-gw# show interface serial0
Serial0 is up, line protocol is up
Hardware is HD64570
Description: sample.org T1
Internet address is 10.2.3.5/30
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 68/255
Encapsulation HDLC, loopback not set, keepalive set (10 sec)
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0 (size/max/drops); Total output drops: 7082
Queueing strategy: weighted fair
Output queue: 0/64/7082 (size/threshold/drops)
Conversations 0/205 (active/max active)
Reserved Conversations 0/0 (allocated/max allocated)
5 minute input rate 754000 bits/sec, 307 packets/sec
5 minute output rate 413000 bits/sec, 96 packets/sec
744279053 packets input, 2083398797 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 1 giants
1372 input errors, 1094 CRC, 0 frame, 0 overrun, 0 ignored, 277 abort
456736163 packets output, 3829305470 bytes, 0 underruns
0 output errors, 0 collisions, 7 interface resets
0 output buffer failures, 0 output buffers swapped out
9 carrier transitions
RTS up, CTS up, DTR up, DCD up, DSR up
There's alot of usefull information here. Let's go over it:
Serial0 is up, line protocol is upThis is the line you'll care most about at first, as it tells you what's going on with the line. The first part, Serial0 is up tells us that the CSU/DSU is seeing a remote CSU/DSU - this generally means the T1 itself is working. If you see Serial0 is down you'll need to be debugging the T1 itself, not anything on the router. The next part line protocol is up tells us that this router is talking to the remote router. This means we're generally good to go, and if things aren't working it's because we've messed up something else like IP addresses of routing.
If you see line protocol is down you may have excessive errors on the line, or most likely the two ends aren't each turned up and configured for HDLC. One other thing that may cause line protocol to stay down is an incorrect number of channels configured in your CSU - for instance if you've configured your 128K as a full T1.
The next line tells you the description which you can add using the 'description' command - this is usefull for keeping track of what circuits are where but has no operational effect.
After that we see Internet address is 10.2.3.5/30 - this tells us the IP address of the interface, as configured with the ip address command. If you used ip unnumbered you might see something like: Interface is unnumbered. Using address of Ethernet0 (10.3.2.1)
The next line we are about at this point in time is Encapsulation HDLC - which tells us what encapsulation we're using. Other things you might see are PPP or Frame-Relay which we'll go over later.
We can skip over most of the information here, as for basic use we don't really care. When we start having problems with the circuit, the rest of the information will be more usefull.
The packet counters on the bottom half of the interface display are good to watch - you can see on this circuit there's been some input errors - compared to the total input packets they're pretty low, and noting that the 'show interface' counters have never been cleared, this is likely some errors from very long ago when perhaps a CSU was power cycled or maybe some errors were introduced on the line. If you're trying to turn up a T1, you will probably see errors show up when you plug and unplug things or reset equipment. To reset these counters use the command clear counters serial0. Under normal operating circumstances you should not see errors introduced on the line - this could be an indication that there's encoding problems on the T1, perhaps there's some bad cabling or a bad CSU, maybe a bad serial port or v.35 cable, perhaps the wrong number of channels are configured on the CSU for the T1/FT1 or perhaps the distance from the CSU to the smart jack is too long.
Serial3/1 is up, line protocol is up
Hardware is cxBus Serial
Description: Sample ISPs PPP circuit
Internet address is 10.2.3.6/30
MTU 1500 bytes, BW 256 Kbit, DLY 20000 usec, rely 255/255, load 1/255
Encapsulation PPP, loopback not set, keepalive set (10 sec)
LCP Open
Open: ipcp, cdp
Last input 00:00:06, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0 (size/max/drops); Total output drops: 13699
Queueing strategy: weighted fair
Output queue: 0/64/13699 (size/threshold/drops)
Conversations 0/130 (active/max active)
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
42715896 packets input, 2604834695 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants
16 input errors, 8 CRC, 0 frame, 0 overrun, 0 ignored, 8 abort
40790569 packets output, 3251968814 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets
0 output buffer failures, 6227963 output buffers swapped out
3 carrier transitions
RTS up, CTS up, DTR up, DCD up, DSR up
you can see that besides the encapsulation changing to PPP there's
two additional lines:
LCP Open Open: ipcp, cdpYou might also see something like lcp state = OPEN - when doing negociation you'll see the lcp state from from CLOSED to REQSENT to ACKSENT to OPEN - if it get's stuck in any state other and OPEN there's probably some errors on the line, or the remote end is not setup for PPP. Once your LCP state hits open, line protocol will go up.
You can think of Frame Relay as a closed phone system. You have to tell the phone company in advance what phone numbers you want to be able to dial - but you can hold conversations with all of those different locations simultaneously.
Frame Relay has 'PVC's (Permanent Virtual Circuits) and DLCI's to identify each PVC. A DLCI is like a miniature phone number. They typically start at 16. If you have a frame relay circuit and want to talk to two remote locations you'd use DLCI 16 to talk to one remote office, and DLCI 17 to talk to the other remote office. A PVC from each of the remote office frame relay circuits to your frame relay circuit needs to be configured in the phone companies switches to allow this communication to happen
For our example, lets assume you have a frame relay circuit with one PVC to your ISP, isp.net, and one PVC to your Portland office. The PVC to isp.net is on DLCI 16 and the PVC to portland is on DLCI 17. This would all have to have been arranged by the person ordering your service (perhaps someone internally, an agent, or the phone company themselves).
So first we configure the T1 to be frame relay:
sample-gw# config term Enter configuration commands, one per line. End with CNTL/Z. sample-gw(config)# int ser 0 sample-gw(config-if)# no shut sample-gw(config-if)# encap frame ietfYou might need to set the LMI type also. The default LMI type is called 'cisco' by the router, but you might find that phone companies refer to it as 'LMI rev 1' - I generally use an LMI type of 'ansi' but it depends on the carrier as different carriers default to different LMI types. I've found that GTE preconfigures their circuits to use LMIrev1 (cisco) and USWest preconfigures for auto-detect. Other carriers may do do wildly different configurations. One of the cool features of cisco/LMIrev1 is that it will tell you the CIR of your PVC's which is very useful information.
To set the LMI type do:
sample-gw# config term Enter configuration commands, one per line. End with CNTL/Z. sample-gw(config)# int ser 0 sample-gw(config-if)# frame-relay lmi-type ansiYou can substitute ansi above for cisco or ccitt - if you're having problems getting line protocol up, this may be something to try changing.
Now that you've got the serial port configured, look at the serial port to see if we get line protocol.
sample-gw#show int ser 0
Serial0 is up, line protocol is up
Hardware is HD64570
Description: sample.org T1
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
Encapsulation FRAME-RELAY IETF, loopback not set, keepalive set (10 sec)
LMI enq sent 3, LMI stat recvd 3, LMI upd recvd 0, DTE LMI up
LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0
LMI DLCI 0 LMI type is ANSI Annex D frame relay DTE
Broadcast queue 0/64, broadcasts sent/dropped 0/0, interface broadcasts 35789
Last input 00:00:09, output 00:00:09, output hang never
Last clearing of "show interface" counters 3w3d
Input queue: 0/75/0 (size/max/drops); Total output drops: 1
Queueing strategy: weighted fair
Output queue: 0/64/0 (size/threshold/drops)
Conversations 0/12 (active/max active)
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
3 packets input, 192 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 30 frame, 0 overrun, 0 ignored, 0 abort
3 packets output, 192 bytes, 0 underruns
0 output errors, 0 collisions, 18 interface resets
0 output buffer failures, 0 output buffers swapped out
1 carrier transitions
DCD=up DSR=up DTR=up RTS=up CTS=up
Now we're ok, because we have Line Protocol up. If line protocol was not
up, we'd want to look closely at the following line:
LMI enq sent 3, LMI stat recvd 3, LMI upd recvd 0, DTE LMI upThe LMI enq sent will increment every 10 seconds (or whatever amount of time the keepalive value is set to) and all going well, the switch on the other end will send back an LMI stat, and LMI stat recvd should increment in step with LMI enq sent. If you don't see LMI stat recvd's incrementing, you are not talking to the switch. Generally this is an indication of one of four things:
Once your frame relay circuit is up and talking to the switch, we now need to configure your PVC's. Without even configuring the PVC's, we can see what DLCI's the carrier has activated thanks to the Frame Relay protocol. We run the show frame pvc command to see what DLCI's exist. The output will show you all PVC's that the carrier has built, as well as all PVC's you have configured (even if that PVC doesn't exist). We can tell them apart by looking at the DLCI USAGE and PVC STATUS fields.
sample-gw#show frame pvc PVC Statistics for interface Serial0 (Frame Relay DTE) DLCI = 16, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial0 input pkts 0 output pkts 0 in bytes 0 out bytes 0 dropped pkts 0 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 0 out DE pkts 0 pvc create time 5w4d, last time pvc status changed 2w2d DLCI = 17, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial0 input pkts 0 output pkts 0 in bytes 0 out bytes 0 dropped pkts 0 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 0 out DE pkts 0 pvc create time 5w4d, last time pvc status changed 2w2dThis tells us that the carrier has configured our two PVC's, and we hope that they headed our request and ran DLCI 16 to our ISP and DLCI 17 to our Portland office.
The DLCI USAGE of UNUSED tells us that we have not yet configured this PVC, and the PVC STATUS of ACTIVE tells us that the remote end of this PVC is up and talking to the frame relay switch (even though they may not have configured this PVC on their router at the other end).
So let's configure these two PVC's. We're going to create sub interfaces to use these PVC's - another method is to use 'frame-relay map's but it's not as eligant as using sub-interfaces. You might want to consider frame-relay maps if you have a full mesh frame relay cloud, but this is not such an configuration.
First we'll create the sub-interface, and assign its DLCI. Let's assume that our ISP has assigned us 10.2.3.5 to use on our interface, and that 10.2.3.6 is their IP address at the other end of this PVC.
sample-gw# config term Enter configuration commands, one per line. End with CNTL/Z. sample-gw(config)# int ser 0.16 point sample-gw(config-subif)# descript PVC to isp.net sample-gw(config-subif)# frame int 16 sample-gw(config-subif)# ip address 10.2.3.5 255.255.255.252 sample-gw(config-subif)# exit sample-gw(config)# int ser 0.17 point sample-gw(config-subif)# descript PVC to Portland Office sample-gw(config-subif)# frame int 17 sample-gw(config-subif)# ip unnum eth0 sample-gw(config-subif)# ^Z sample-gw)#You can see that we've matched the sub-interface number to the DLCI number to simplify life and we've made the interface pointing towards portland an unnumbered interface since we don't have any spare address blocks to assign to the WAN.
This is getting us pretty close to completion - let's take a look at these PVC's:
sample-gw#show frame map
Serial0.16 (up): point-to-point dlci, dlci 16(0x10,0x400), broadcast
status defined, active
Serial0.17 (up): point-to-point dlci, dlci 17(0x11,0x410), broadcast
status defined, active
so things are looking pretty good - the sub interfaces are correctly assigned
to the PVC's, and we have status's of ACTIVE (up) on all our PVC's.The next thing we want to do is setup some routing. We want to setup a default route pointing towards our ISP since when we want to go out to the internet, we need to send them our traffic. In addition, we need to route traffic to our Portland office - let's assign them 10.5.1.0 (the whole /24 nework).
sample-gw# config term Enter configuration commands, one per line. End with CNTL/Z. sample-gw(config)# ip route 0.0.0.0 0.0.0.0 serial0.16 sample-gw(config)# ip route 10.5.1.0 255.255.255.0 serial0.16 sample-gw(config)# ^Zand lastly, we'll pop in a few other commands to complete our configuration.
sample-gw# config term Enter configuration commands, one per line. End with CNTL/Z. sample-gw(config)# enable secret <password to go into enable mode> sample-gw(config)# enable password <enable password when encryption is disabled> sample-gw(config)# int eth 0 sample-gw(config-if)# no ip directed-broadcast sample-gw(config-if)# exit sample-gw(config)# ip domain-name sample.org sample-gw(config)# ip name-server 10.3.2.2 sample-gw(config)# ip classless sample-gw(config)# ip subnet-zero sample-gw(config)# snmp-server community <snmp community name< RO sample-gw(config)# line vty 0 4 sample-gw(config-line)# password <telnet password> sample-gw(config-line)# exit sample-gw(config)# ^ZAbove are all commands you'll probably want to use.. the password commands are self evident, we've turned off directed broadcast's on your ethernet to make sure people on the internet can't make your machines send broadcast traffic out to the internet, we've set your domain name and configured the nameserver to be 10.3.2.2.
So now we should be ready to go! Use the show config command to take a look at your shiney new config.
sample-gw#show config Using 2408 out of 32762 bytes ! version 11.1 service password-encryption service udp-small-servers service tcp-small-servers ! hostname sample-gw ! enable secret <password> enable password <password> ! ip subnet-zero ! interface Ethernet0 ip address 10.3.2.1 255.255.255.0 no ip directed-broadcast ! interface Serial0 description sample.org T1 no ip address encapsulation frame-relay IETF frame-relay lmi-type ansi ! interface Serial0.16 point-to-point description PVC to Sample ISP ip address 10.2.3.5 255.255.255.252 frame-relay interface-dlci 16 ! interface Serial0.17 point-to-point description PVC to Portland Office ip unnumbered Ethernet0 frame-relay interface-dlci 16 ! interface Serial1 no ip address shutdown ! ip name-server 10.3.2.2 ip classless ip route 0.0.0.0 0.0.0.0 Serial0.16 ip route 10.5.1.0 255.255.255.0 Serial0.17 logging buffered access-list 16 permit 10.3.2.0 0.0.0.255 access-list 16 permit 10.5.1.0 0.0.0.255 ! snmp-server community <community> RO 16 ! line con 0 line aux 0 transport input all line vty 0 4 access-class 16 in password <password> login ! endThe only thing we have't covered yet is the access-list shown here which we'll cover in the next section!