02-28-2012 03:32 AM - edited 03-07-2019 05:14 AM
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.1 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
---
Router2
----
Current configuration : 1467 bytes
!
upgrade fpd auto
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname router1
!
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 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
02-28-2012 03:40 AM
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.
02-28-2012 05:00 AM
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
02-28-2012 05:26 AM
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
02-28-2012 06:31 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide