frame-relay questions

Bill Kaster

ok, so I have a couple of simple questions for you experienced guys here. My lab consists of 3 x 2524 routers. R1's s0 link is DLCI = 100 connected to R2's S0 int (R2 is in the middle and I'm going to configure both it's serial ports as DCE as I assume it's customary practice). R3 is at the other end connected from its own s0 port to R2's s1 port (that's DLCI 200). My question is simple; are the following commands correct and the best way to go about setting up frame relay?

R1:
conf t
int s0
encapsulation frame-relay
ip address 172.16.10.10 255.255.255.0
frame-relay interface-type dlci 100
exit

R2:
conf t
frame-relay switching
exit
conf t
int s0
encapsulation frame-relay
clock rate 64000
frame intf-type dce
frame-relay route 100 int s1 200
exit
conf t
int s1
encapsulation frame-relay
clock rate 64000
frame intf-type dce
frame-relay route 200 int s0 100
exit

R3:
conf t
int s0
encapsulation frame-relay
ip address 172.16.20.20 255.255.255.0
frame-relay interface-type dlci 200
exit

And if that's all correct, what would you guys recommend to check/troubleshoot it, a show frame map or show frame lmi or something else?

Netstudent

show frame-relay PVC to see if the PVC is active. Then ping across the Frame-relay network. If you can ping, then it's done. Check your books or cisco whitepapers on frame-relay and play with all the show commands that are relevant. Read the explanantion on the commands and see how the cisco explanantions relate to your setup and your outputs.

For troubleshooting, you could play with debug commands like debug fframe-relay to debug packets on a frame-relay interface, then debug frame-relay events to check out your ARP events, and debug frame-relay LMI to check out the keepalives and access-link. But keep in mind that running all these debugs would consume resources on production equipment with a heavy load.

Looks like your Point-to-point frame-relay connection is not in the same subnet. You can either change your subnet mask to 255.255.0.0 or chnage the IP's to be in the same subnet.

There are many methods and requirements that could influence how frame-relay is implemented. So there is no "best" configuration. Also I think most of the time, the PVC will put put on a subinterface. You could run into split-horizon issues by using the physical interface.

Bill Kaster

Netstudent wrote:

show frame-relay PVC to see if the PVC is active. Then ping across the Frame-relay network. If you can ping, then it's done. Check your books or cisco whitepapers on frame-relay and play with all the show commands that are relevant. Read the explanantion on the commands and see how the cisco explanantions relate to your setup and your outputs.

For troubleshooting, you could play with debug commands like debug fframe-relay to debug packets on a frame-relay interface, then debug frame-relay events to check out your ARP events, and debug frame-relay LMI to check out the keepalives and access-link. But keep in mind that running all these debugs would consume resources on production equipment with a heavy load.

Looks like your Point-to-point frame-relay connection is not in the same subnet. You can either change your subnet mask to 255.255.0.0 or chnage the IP's to be in the same subnet.

There are many methods and requirements that could influence how frame-relay is implemented. So there is no "best" configuration. Also I think most of the time, the PVC will put put on a subinterface. You could run into split-horizon issues by using the physical interface.

OK, so it would look more like this:

R1: 
conf t
int s0
encapsulation frame-relay
int s0.100 point-to-point
ip address 172.16.10.10 255.255.255.0
frame-relay interface-dlci 100
exit

R2:
conf t
int s0
encapsulation frame-relay
int s0.200 point-to-point
ip address 172.16.10.20 255.255.255.0
frame-relay interface-dlci 200
exit

Bill Kaster

Also, I remember reading that pinging can be misleading if you have a routing protocol up and running, which makes plenty of sense. That's the only reason I don't want to depend on ping. When I get back to my equipment later tonight, I'll take a look at how good the show frame-relay pvc command troubleshoots and confirms frame-relay network settings.

oh and netstudent good catch on the split horizon issue i almost forgot that you can't have ip addresses enabled on the interfaces.

elvant

Bill Kaster wrote:

Also, I remember reading that pinging can be misleading if you have a routing protocol up and running, which makes plenty of sense. That's the only reason I don't want to depend on ping. When I get back to my equipment later tonight, I'll take a look at how good the show frame-relay pvc command troubleshoots and confirms frame-relay network settings.

oh and netstudent good catch on the split horizon issue i almost forgot that you can't have ip addresses enabled on the interfaces.

Just like to point out 1 thing. Since Pinging is a layer 3 protocol, before you can successfully ping a host, the layer 2 must be correctly configured. So, if you can ping a host, the layer 2 is in good shape.

penguinking

Are you sure you have to set both clock rate and frame-relay intf-type dce?