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]
