[log in to unmask] wrote:
>
> AT&T is Frame provider...  I have a firm belief that they just lie to
> me, no matter what the problem...  CIR and burst are =.  Another,
> interesting point: Not all clients get dropped at the same time???  If
> there were an interuption in WAN, would that not disconnect all clients?

OK, some more guesswork since I don't know the details of your circuit,
configuration, or service agreement...

If there is a catastrophic WAN interruption, then yes, most clients
would disconnect at about the same time.  But I suspect you are just
experiencing traffic congestion, which is an order of magnitude more
difficult to pinpoint than a blatant failure.  In the former case,
sessions that are "active" (exchanging data) will drop at more or less
the same time.  Idle sessions will die some time later as their TCP
keepalives start to expire, or they attempt to exchange traffic only
to learn their destination is now unreachable.  In the latter case,
it is a function of what sort of packets are dropped and how many; you
would have to exceed the retransmit threshhold, or exceed keepalives
(not the usual case for congestion) or your TCP window size becomes
reduced to some unworkable value given the packet loss.

If CIR=burst, you should have no discard eligible frames that you are
obligated by your service agreement to accept being dropped.  But if
packets are being dropped while your bandwidth remains < CIR then you
have an issue with your provider.  You might look for packet drops on
your end (most likely if you are the host) or possibly on the far end
(possible but not likely).  But since it is frame relay, you can also
check for FECN/BECN counts on either end.  If you are not exceeding
the CIR this implies congestion in the provider's cloud, and again,
they aren't supposed to let this happen.

The above arguments assume you have a point-to-point DLCI to the remote
site, and neither you nor your remote have multiple DLCIs on the same
serial link, and you are not doing multipoint DLCIs.  Furthermore, the
CIR (and burst) should be equal on both ends; if not, and you are
dropping packets on the slower end, the ball ends up in your court
with some caveats.  You never know what the drop counts/FECN/BECN
values are on your provider's end, and they'll probably not tell you.
Those finger-pointing sessions are really aggravating and the main
reason I hate frame relay.

And a final note, ask if the frame cloud switch even supports BECN/FECN
in the first place; not all do, or lie about it, or only provide them
in one direction only.  Still more cover for them to hide beneath.  But
if they do, your cisco should provide the values.  You should only have
to deal with them if your burst > CIR, but they will still leak through
if their switch supports it if the provider's cloud is congested.

Apologies for getting progressively further off-topic for HP3000-L but
it started with a HP3000 problem!

Jeff Kell <[log in to unmask]>