Hello all!
I have a question about frame relay bandwidth settings. I'm looking at my
production router and noticed that all the serial sub interfaces (hub and
spoke topology) have no bandwidth set on them, and of course we aren't
paying for T1 speeds. I know 1.54 mbs is the default when nothing is set.
But my question is this: will the hub always try to transmit at T1 and have
packets dropped by the service provider when there is congestion in the
cloud? One of my "spokes" complains about slow speeds and they have 256k
connection. Could this bandwidth setting be part of the bottleneck problem?
Sorry for the novel....and thanks for the help!

Report this post to a moderator

> Hello all!
> I have a question about frame relay bandwidth settings. I'm looking at my
> production router and noticed that all the serial sub interfaces (hub and
> spoke topology) have no bandwidth set on them, and of course we aren't
> paying for T1 speeds. I know 1.54 mbs is the default when nothing is set.
> But my question is this: will the hub always try to transmit at T1 and have
> packets dropped by the service provider when there is congestion in the
> cloud? One of my "spokes" complains about slow speeds and they have 256k
> connection. Could this bandwidth setting be part of the bottleneck problem?
> Sorry for the novel....and thanks for the help!

The "bandwidth" command has nothing whatever to do with actual
throughput through an interface. It is really only used for metric
calcs in routing protocols.

Without more info, it is difficult to tell what the cause is. The slow
speed at the one site could be caused by something as simple as a bad
interface on a hub there, or by congestion in the provider's FR network
in that geographic region, or by congestion at your HQ site.

The hub site will send every packet out the FR interface as soon as it
is processed, unless the traffic intended to exit that interface exceeds
the bandwidth of the port speed of the interface. In that event,
packets are queued up in buffers as they await transmission. You can
never send frames such that the amount transferred exceeds the actual
port speed of the interface--it is physically impossible.

Note that the port speed of the interface is not necessarily 1.5M. Dont
confuse the access speed (always DS-0, DS-1, DS-3, etc.) with port
speed. You might have a FR T-1 at HQ, but it may only have a 768k port.
In that event, 768k is the max you can send, even though it is
provisioned across a T-1 loop.

Also do not confuse CIR with port speed. CIR is simply how much BW the
carrier guarantees at all times across a single PVC through the network.
You might have 10 x 256k CIR PVCs terminating on this 768k port--in
which case you would be oversubscribed by a factor of about 3x. In
reality, any one of these PVCs could (and frequently does) seize the
entire 768k port for transmission of a burst of data. In that event,
2/3 of the frames would be marked Discard Eligible--meaning that they
are still transmitted, but if there is congestion anywhere in the FR
network along the path to the destination, these are among the first to
be dropped. The only time FR frames are dropped in a FR network is when
there is congestion. But, in today's world of over-capacity, that is
relatively rare.

If you can provide more detail as to the problem, perhaps we could help
more.

kr

Report this post to a moderator