Re: More "Connection reset by peer" problems.

From: C. Jon Larsen <jlarsen@dont-contact.us>
Date: Sun, 20 Dec 1998 11:23:35 -0500 (EST)

Using the redirection did not work so well for me on a Cisco 4000. So, I
simply setup the linux server as the default gateway, and let it pick the
packets off it wants to redirect, and then forward the rest of the traffic
on to the cisco. That worked much better for me, and has the advantage of
not bouncing the traffic back and forth an extra time. I also use the
linux box to transparently proxy smtp, so again, that was a nice solution
for me. I use dhcp on the linux box to pass out the linux's ethernet
IP address as the gateway. Another advantage is that the cisco fast
switches everything, b/c there is no policy routing happening.

For maximum redundancy, in case the box running the squid cache fails
(crashes), you could enable ospf on the squid box, and the egress router,
but have the squid box with the lower cost. Traffic comming from an
ospf-speaking internel router will prefer the squid cache box as long as
its up, and gated is alive and well (I have a crude script which "pings"
the cache, and shuts down gated if the cache ping script fails - which
it never has, btw). If you use RFC1918 address space, like I do, you'll
need to setup a NAT engine on the egress Cisco, and then NAT any packets
that start coming through (this will happen if the squid box is no longer
processing the packets through ipfwadm). Connections will drop if/when the
switchover occurs, but then pick back up. This setup worked in testing,
but so far the linux/squid has never crashed ! [Management demanded a
failover scenario for the squid / linux piece, but actually, its just as
likely the router(s) will fail first ! ]

Again, my setup really works only if you have a client subnet, internal
router, and then an internet service subnet, where the squid box(es) live,
and then the external router. Regular PCs don't speak OSPF, so they won't
detect the failed cache box.

hth

On Fri, 18 Dec 1998, Ben Kohn wrote:

> After taking the suggestions of Henrik, we've completed a trouble ticket
> case with Cisco. They told us that these problems are not stemming from
> the router as it is setup for port redirection correctly. They told us
> that this is definately the fault of the cache engine software as we are
> not seeing any errors on either the Fast Ethernet interface or the
> Ethernet controller on the Squid box. Too ruleout timeouts, I've increased
> all timeouts to 1 hour which seemed to lessen the amount of errors, but
> they are still ridiculous
>
> Is anyone successfully using a configuration similar to this,
> trouble-free?
>
> (Client) > (Cisco 7000 series router) > (Linux Squid box running version
> 2.0)
>
> Also, should I be able to telnet to port 80 on squid and receive a
> response from squid if the ipfwadm is working correctly on the linux box?
>
> Thanks again for everyone's help.
>
> Ben Kohn
> Manager of Information Systems
> Triton Technologies
>
>

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
C. Jon Larsen Email: jlarsen@ford.ajtech.com
Systems Engineer Voice: +1.804.353.2800 x118
                          Cell: 357.3040
                          Pager: 219.3406
A&J Technologies http://www.ajtech.com

PGP Key fingerprint: 8A 62 4C 6E 1E 3C CD 63 B3 16 1A 1B D2 61 EE 97
PGP Public key available at: http://intranet.ajtech.com/~jlarsen/CJL.txt
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Received on Sun Dec 20 1998 - 09:17:52 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:43:41 MST