Help with serial interface

aaron.cowell.au · ‎02-28-2012

I cannot get two frame relay serial interfaces to communicate. Can any body help. Why wont

Serial1/0 is up, line protocol is down (looped) ping each other?

Router 1

---

Current configuration : 1465 bytes

!

upgrade fpd auto

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname router2

!

boot-start-marker

boot-end-marker

!

logging message-counter syslog

!

no aaa new-model

ip source-route

ip cef

!

no ip domain lookup

no ipv6 cef

!

multilink bundle-name authenticated

!

memory-size iomem 0

archive

log config

hidekeys

!

interface FastEthernet0/0

no ip address

shutdown

duplex half

!

interface Serial1/0

ip address 10.0.0.254 255.255.255.0

encapsulation frame-relay

serial restart-delay 0

clock rate 112000

frame-relay interface-dlci 150

frame-relay lmi-type cisco

!

interface Serial1/1

no ip address

shutdown

serial restart-delay 0

!

interface Serial1/2

no ip address

shutdown

serial restart-delay 0

!

interface Serial1/3

no ip address

shutdown

serial restart-delay 0

!

interface Serial1/4

no ip address

shutdown

serial restart-delay 0

!

interface Serial1/5

no ip address

shutdown

serial restart-delay 0

!

interface Serial1/6

no ip address

shutdown

serial restart-delay 0

!

interface Serial1/7

no ip address

shutdown

serial restart-delay 0

!

ip forward-protocol nd

no ip http server

no ip http secure-server

!

control-plane

!

mgcp fax t38 ecm

!

gatekeeper

shutdown

!

line con 0

exec-timeout 0 0

logging synchronous

stopbits 1

line aux 0

stopbits 1

line vty 0 4

login

!

end

----

Serial1/0 is up, line protocol is down (looped)

Hardware is M8T-X.21

Internet address is 10.0.0.1/24

MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation FRAME-RELAY, crc 16, loopback not set

Keepalive set (10 sec)

Restart-Delay is 0 secs

LMI enq sent 135, LMI stat recvd 0, LMI upd recvd 0, DTE LMI down

LMI enq recvd 134, LMI stat sent 0, LMI upd sent 0

LMI DLCI 1023 LMI type is CISCO frame relay DTE

FR SVC disabled, LAPF state down

Broadcast queue 0/64, broadcasts sent/dropped 0/0, interface broadcasts 0

Last input 00:00:07, output 00:00:01, output hang never

Last clearing of "show interface" counters 00:26:19

Input queue: 0/75/0/0 (size/max/drops/flushes); 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)

Available Bandwidth 1158 kilobits/sec

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

136 packets input, 1768 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

136 packets output, 1768 bytes, 0 underruns

0 output errors, 0 collisions, 2 interface resets

0 unknown protocol drops

0 output buffer failures, 0 output buffers swapped out

1 carrier transitions DCD=up DSR=up DTR=up RTS=up CTS=up

John Blakley · ‎02-28-2012

It looks like your ISP may have the circuit looped somewhere down the line. Have you contacted them or is this a lab? If this is back to back, try disabling lmi with "no keepalive" on the interfaces.

HTH, John *** Please rate all useful posts ***

Peter Paluch · ‎02-28-2012

Hello John,

This looks like a lab (S1/0 reminds me strongly of Dynamips).

In any case, on Frame Relay, disabling the keepalives is not a good idea, as it deactivates the LMI protocol completely. In a back-to-back scenario, it will help, but also it is teaching people to configure the Frame Relay connection the wrong way. If they did that in a real Frame Relay network, they would most certainly prevent themselves from ever getting it to work.

Ideally, one of the devices here should be configured as Frame Relay DCE device and specifically declare the DLCI number to use. In Aaaron-James's configuration, the DLCI number has already been specified - it is 150. Now, one (and only one) of these routers should be configured as FR DCE device - that allows it to respond to LMI messages sent by the other (i.e. FR DTE) device. For example, on Router 2, enter these commands:

configure terminal

frame-relay switching

interface Serial1/0

frame-relay intf-type dce

end

That should do the trick, hopefully. Just to remove any doubt: FR DCE/DTE designations are related to the responsiblity of a device to originate/respond to LMI messages. They are not in any way related to the cabling and physical DCE/DTE.

Best regards,

Peter

John Blakley · ‎02-28-2012

Peter,

Frame relay isn't one of my string points, but Cisco has a document on back to back FR connections and states that disabling LMI is a requirement to get it to work. Is this not the case? If not, I'll have to lab this up to see if I can get it to work.

http://www.cisco.com/en/US/tech/tk713/tk237/technologies_configuration_example09186a0080094a3b.shtml

John

Sent from Cisco Technical Support iPhone App

HTH, John *** Please rate all useful posts ***

Peter Paluch · ‎02-28-2012

Hi John,

In Frame Relay, devices depend on Local Management Interface (LMI) signalling - a helper protocol used on a per-link basis that allows the attached devices to verify their liveliness and to discover the individual DLCIs and their status.

The LMI is an asymmetrical protocol in that the devices are designated either as DTE or DCE devices. The Frame Relay DTE device is the endpoint of a virtual circuit, usually a router. DTE devices emit LMI Status Enquiry messages to find out about DLCI numbers and their status, and expect to receive a LMI Status Reply back. This Status Reply is generated by the DCE device which is usually a Frame Relay switch. Therefore, DTE devices send Status Enquiries, DCE devices send Status Replies. It does not work in reverse: a DTE device cannot send Status Replies, and a DCE device cannot send Status Enquiries.

If a DTE device does not receive replies to its Status Enquiry messages, it assumes that the opposite device does not work or does not speak Frame Relay, and puts its interface into up/down state. Similarly, if a DCE device does not receive periodic Status Enquiries, it assumes that the opposite device does not work or does not speak Frame Relay, and also declares a "line protocol down" condition.

By default, Cisco devices work as Frame Relay DTE devices on their interface, as can be easily seen using a show interfaces command:

R1_A#show int s1/0

Serial1/0 is up, line protocol is up

Hardware is M4T

Internet address is 1.1.1.1/24

MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation FRAME-RELAY, crc 16, loopback not set

Keepalive set (10 sec)

Restart-Delay is 0 secs

CRC checking enabled

LMI enq sent 1, LMI stat recvd 0, LMI upd recvd 0, DTE LMI up

LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0

LMI DLCI 1023 LMI type is CISCO frame relay DTE

FR SVC disabled, LAPF state down

So if two routers are connected back-to-back, each of them behaves as a FR DTE device, sends Status Enquiries but never receives a Status Reply back, and thus the connection does not come up. A quick-and-dirty fix is to deactivate the LMI altogether on both devices using the no keepalive command and that is what the document suggests.

However, if you did that in a real network, you would prevent an otherwise correctly configured FR connection from coming up: the DTE would not send Status Enquiries to the DCE (the FR switch), or the DCE would not respond to DTE's enquiries. In any case, the connection would not be working unless you deactivated the LMI on both ends. But why would you want to deactivate the LMI on both ends if they are configured and connected properly and when LMI provides an important signalling/management aspect to the Frame Relay? It is more correct, even in a back-to-back scenario, to configure one of the devices to work in a DCE mode and to allow LMI to work as intended - and that is the point of my suggested configuration correction.

So this is the long story behind why I dislike the no keepalive fix - it works on a back-to-back connection but it can wreak havoc in real FR network if one is not very well aware of what this really does.

Best regards,

Peter