Would be nice to hear if anyone has encountered similars problem and has any ideas how to get past some of the sometimes animal behaviour of frame-relay.
Setting up a frame-relay cloud; Router A needs to connect to Router B, DLCIs are given. Disable inverse-arp and install frame-relay map statements and vice versa. Router A tries to ping to Router B, nothing, dead. Had a quick look at the DLCI’s coming into the interface - sure enough, the DLCI number is there, both sides see their respective DLCI‘s. So I enable inverse-arp and take out the map statements. Ping Router B and yes it sees it, so the link and cables are fine. Clear inarp cache and install map statements, disable inarp. Nothing… Double check the frame switch, looks ok. Disable inarp and reboot the Router. Install map statements, ping Router B, nothing. Ping again, nothing, wait, nothing. Go have a cup of coffee, come back 20 minutes later. Ping Router B, it’ working. So, now one hour wasted on one pvc... Is there something or some sequence that I missed here? I have done loads of frame-relay labs and seldom have problems. But twice now frame-relay decides it is on its own coffee break. For no apparent reason. I have also heard of DLCI’s leaking into other interfaces and neighbour statements disappearing. I have also seen a similar situation where you write erase a stubborn router and copy the same config back on and it works. Any tips or forced workarounds? Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=66509&t=66509 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
