Troubleshooting Frame Relay networks isn’t any harder than troubleshooting any other type of network as long as you know what to look for, which is what I’m going to cover now. We’ll go over some basic problems that commonly occur in Frame Relay configuration and how to solve them.
First on the list are serial encapsulation problems. As you learned recently, there are two Frame Relay encapsulations: Cisco and IETF. Cisco is the default, and it means that you have a Cisco router on each end of the Frame Relay network. If you don’t have a Cisco router on the remote end of your Frame Relay network, then you need to run the IETF encapsulation as shown here:
RouterA(config)#int s0
RouterA(config-if)#encapsulation frame-relay ?
ietf Use RFC1490 encapsulation
<cr>
RouterA(config-if)#encapsulation frame-relay ietf
Once you verify that you’re using the correct encapsulation, you then need to check out
your Frame Relay mappings. For example, take a look at
Figure 1:Frame Relay mappings
So why can’t RouterA talk to RouterB across the Frame Relay network? To find that out, take a close look at the frame-relay map statement. See the problem now? You cannot use a remote DLCI to communicate to the Frame Relay switch; you must use your DLCI number! The mapping should have included DLCI 100 instead of DLCI 200.
Now that you know how to ensure that you have the correct Frame Relay encapsulation, and that DLCIs are only locally significant, let’s look into some routing protocol problems typically associated with Frame Relay. See if you can find a problem with the two configurations in
Figure2:Frame Relay routing problems
Hmmmm, well, the configs look pretty good. Actually, they look great, so what’s the problem? Well, remember that Frame Relay is a non-broadcast multi-access (NBMA) network by default, meaning that it doesn’t send any broadcasts across the PVC. So, because the mapping statements do not have the broadcast argument at the end of the line, broadcasts, like RIP updates, won’t be sent across the PVC.
Okay, now let’s use the SDM to configure our serial WAN connections—should be pretty simple!
First on the list are serial encapsulation problems. As you learned recently, there are two Frame Relay encapsulations: Cisco and IETF. Cisco is the default, and it means that you have a Cisco router on each end of the Frame Relay network. If you don’t have a Cisco router on the remote end of your Frame Relay network, then you need to run the IETF encapsulation as shown here:
RouterA(config)#int s0
RouterA(config-if)#encapsulation frame-relay ?
ietf Use RFC1490 encapsulation
<cr>
RouterA(config-if)#encapsulation frame-relay ietf
Once you verify that you’re using the correct encapsulation, you then need to check out
your Frame Relay mappings. For example, take a look at
Figure 1:Frame Relay mappings
So why can’t RouterA talk to RouterB across the Frame Relay network? To find that out, take a close look at the frame-relay map statement. See the problem now? You cannot use a remote DLCI to communicate to the Frame Relay switch; you must use your DLCI number! The mapping should have included DLCI 100 instead of DLCI 200.
Now that you know how to ensure that you have the correct Frame Relay encapsulation, and that DLCIs are only locally significant, let’s look into some routing protocol problems typically associated with Frame Relay. See if you can find a problem with the two configurations in
Figure2:Frame Relay routing problems
Hmmmm, well, the configs look pretty good. Actually, they look great, so what’s the problem? Well, remember that Frame Relay is a non-broadcast multi-access (NBMA) network by default, meaning that it doesn’t send any broadcasts across the PVC. So, because the mapping statements do not have the broadcast argument at the end of the line, broadcasts, like RIP updates, won’t be sent across the PVC.
Okay, now let’s use the SDM to configure our serial WAN connections—should be pretty simple!
No comments:
Post a Comment