Hi Matthew, One thing that you will want to be aware of is that if you are testing the NAT / Telnet setup - is that the machine you are testing from will need to be on another network than the one the Pipeline is on. In other words, if you try and Telnet to the Pipeline's IP assigned by the ISP while you are on, say a 192.168.0.0 network or similar and so is the Pipeline - this will not work in my experience. Of course you would never do this in real life but when setting it up I was on the same network and trying to go out and back so to speak. I almost drove myself crazy with this once thinking it was not working and didn't discover until I tried it from another location it was actually working fine. You mentioned turning off STAC and you should disable VJ Comp as well. Van Jacobsen Compression applies only to packets in TCP applications, such as Telnet (one of the things you mention). From a conversation I had with an Ascend engineer one time when we were troubleshooting very similar problems to those you describe on a T1 between 2 P130's, he said VJ and STAC were most useful on ISDN and slower type connections and that it would actually slow down T1 or faster links. This was indeed the problem in our situation. Hope this helps and good luck. Scott Starbuck Aobe Network Group --------------------- Matthew Watkins wrote: > Mick, > > I genuinely wouldn't know where to start when trying to identify a good > physical connection from a bad one. Presumably a shorter line has reduced > resistance/impedance, are there any other readily measurable factors that > can be taken into account? The BT engineers were apparently surprised at how > good the quality of the line turned out to be... > > I can now confirm that this was definitely something to do with the > configuration of the pipeline... I've made sure that at both ends STAC > compression was turned off, swapped to make sure PPP was the only > encapsulation type that could be negotiated (not MPP etc...) then made sure > bridging was disabled everywhere in the configurations. I saved the > configurations to flash and reset the pipeline with my fingers crossed. > > On coming back up, the pipeline said: > > Port Up: 00:00:04 > Rx signal present > Line Q: 15db Good > > It looked like something on the pipeline was hogging processor time and > causing large packets to be dropped or errored. The reported line quality > now drifts between 7db and 8db. There are fewer CRC errors by a huge factor: > > 20-300 WAN Stat > >Rx Pkt: 4685 > Tx Pkt: 4756 > CRC: 237 > > >From a remote session, the VT-100 interface now actually redraws every > second rather than every ten seconds. > > This seems a little crazy to me. It would appear that most of the default > settings are totally unsuitable? > > I would really like to be able to get that NAT configuration working again. > Does anybody know what I need to do to enable remote telnet access to a > pipeline running NAT? > > -- > > Matthew Watkins > Technical Consultant > Knowware UK Ltd > > Mobile: 07968 755807 > Home Office: +44 (0)1223 300917 > Fax: +44 (0)1223 301280 > Email: matt at knowware.co.uk > http://www.knowware.co.uk > > ++ Ascend Users Mailing List ++ > To unsubscribe: send unsubscribe to ascend-users-request at bungi.com > To get FAQ'd: <http://www.nealis.net/ascend/faq> ++ Ascend Users Mailing List ++ To unsubscribe: send unsubscribe to ascend-users-request at bungi.com To get FAQ'd: <http://www.nealis.net/ascend/faq>