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:
frame-relay intf-type dce
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.
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.
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 126.96.36.199/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.
This is actually a pretty cool feature, i didn't even know it existed until I was looking for a solution to advertise a subnet (prefix in BGP talk), only if a certain condition existed. This is exactly what conditional advertisements does
j ai une question j ai achete un routeur cisco 887VA-k9 , je le configuré avec la configuration ci- dessous
si je le lier avec mon pc portable sur l un de ses ports directement ça marche toute est bien ( la connexion internet + m...
Attached policy provides CLI access to the Cisco 4G router over text messaging. Two files are in the attached .tar file:
2. PDF with instructions on how to load and use the .tcl file.