RE: [cobalt-users] Cube 3 - email problems

["Colin J. Raven" <cjraven@xxxxxxxxxxx>]

> On Thu, 7 Jun 2001, Josh Gasber wrote:
>
> > >Josh Gasber wrote:
> > >>
> > >> We are using a Cube 3 to handle all of our outbound mail
> relay and have
> > >>         Problems sending email with attachments
> > >
> > >Will DeHann wrote -
> > >
> > >Mis-matched duplex settings on any connection between Qube
> and clients
> > >can cause the timeout in sending mail that you're experiencing.
> > >
> > Will,
> >
> > The cube is sitting on a 10bT hub. That hub is uplinked to
> another 10bT hub
> > which is connected to a Cisco 2610 router which is connect
> to Frame Relay
> > over Frac-T1 (384k to the cloud) The remote side is connect
> via 64k line to
> > the cloud, Cisco 1600 router and then 10bT hub.
> >
> > The troubling fact is that this exact same setup is used to
> connect to
> > multiple remote sites, in the exact same configuration,
> none of which is
> > experiencing the same problem.
> >
> > Does this change anything or help you in any way point me
> at some trouble
> > shooting ideas.
>
> Josh,
>
>  I think Will has hit a very likely problem , i have seen the
> same problem
> elsewhere, see if you can dig up docs / specs on the hubs and
> make sure
> they are really full-duplex cabable. A lot of low-cost hubs,
> particularly
> the 10Bt ones are not really full-duplex.
>  The fact that you can send externally
> just reinforces this suspiscion, packets going outside will be spaced
> apart timewise because your internal lan speed is greater than the
> external link speed, the only case where you are saturating
> the internal
> link is sending from the client to the qube, which is exactly the case
> where a
> half duplex hub trying to manage a fullduplex data stream
> would start to
> barf, as the ACK packets coming back will collide with the
> outgoing data
> packets. Because of the way TCP handles collisions, once this
> starts to
> happen, the errors just start piling up , it can take hours
> for a small
> transfer to finish under this condition, the client will
> likely timeout
> and give up long before this.
>  The fact that small emails work is just due to the fact that a
> certain quantity of data is sent before the other end ACK's
> back , so in
> effect , you are only sending packets one direction at a time (half
> duplex) ...[the magic size here is usually around 32-65K of
> streamed data]

It might be helpful to put a sniffer on the network and see what's
happening to the bitstream.

I'm in agreement with your conclusion re: the hub. I had a frighteningly
similar experience a few years back. I didn't have the benefit of wise
eyes such as this list, but by conicidence I changed the hub because
someone in the company wanted the "bad" (half duplex) hub back and the
problem disappeared.
-Colin