+<H2><A NAME="ss3.6">3.6 Telnet echo</A>
+</H2>
+
+<P>Cluster links in particular suffer greatly from the presence of telnet echo.
+This is caused by the telnet negotiation itself and can create at worst severe
+loops. At best it creates unnecessary bandwidth and large logfiles! There are
+things that can be done to limit this problem but will not always work dependent
+on the route taken to connect.
+<P>
+<P>Telnet echo itself should only be a problem if the connection is being made to
+the telnet port (23). This port uses special rules that include echo negotiation.
+If the connection is to a different port, such as 8000, this negotiation does
+not happen and therefore no echo should be present.
+<P>
+<P>Sometimes it is not possible to make a direct connection to another node and this
+can cause problems. There is a way of trying to suppress the telnet echo but
+this will not always work, unfortunately it is difficult to be more specific.
+Here is an example of what I mean ...
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+timeout 35
+abort (Busy|Sorry|Fail)
+connect telnet mary.lancs.ac.uk
+'ogin:' 'gb7mbc'
+'word:' 'mypasswd'
+'\$' 'stty -echo raw'
+'\$' 'telnet 44.131.93.96'
+'connect' ''
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>So, the first connection is made by Spider. This is fine as Spider uses the
+Net_Telnet script from within perl. This actually uses TCP rather than TELNET
+so no negotiation will be done on the first connection. Once connected to
+mary.lancs.ac.uk, the command is sent to suppress echo. Now a telnet is made
+to a cluster node that is accepting connections on port 23. The problem with
+this link is that the negotiation is made by the remote machine, therefore you
+have no control over it. The chances are that this link will create echo and
+there will be no way you can stop it.
+<P>
+<P>
+<H2><A NAME="ss3.7">3.7 Automating things</A>