[prev in list] [next in list] [prev in thread] [next in thread]
List: inet-access
Subject: RE: Configuring an ATM-OC3 card for a Cisco3662
From: "Jeff Groth" <jeff () groth ! com>
Date: 2002-10-28 20:51:49
[Download RAW message or body]
How's this.. It will set the rate-limit for either ingoing or outgoing.
I just used out bound in the example.
router1(config-if)#rate output ?
WORD 8,000-10,000,000,000 bits per second for conform rate
(postfix k, m,
g optional; comma allowed if used properly)
access-group Match access list
dscp Match dscp value
qos-group Match qos-group ID
And just for an fyi:
router1(config-if)#?
Interface configuration commands:
<snipped a few entries>
bandwidth Set bandwidth informational parameter
Jeff
- The T1 ref was just anecdotal...
-----Original Message-----
From: owner-list@inet-access.net [mailto:owner-list@inet-access.net] On
Behalf Of Brian Johnson
Sent: Monday, October 28, 2002 1:56 PM
To: Inet-access List
Subject: RE: Configuring an ATM-OC3 card for a Cisco3662
OK...
Thank you for posting, but I don't think your example would apply in
this situation.
I am talking about an ATM circuit here, not a T1. If the bandwidth
statement is just "for show" that's fine, but what about the UBR
statement. Is that "for real," or is it also just "for show"?
If they are both just for show, then how would you limit an ATM circuit
to a specific amount of bandwidth?
On Mon, 2002-10-28 at 12:31, Jeff Groth wrote:
> Brian,
>
> They are right. The bandwidth statement is indeed just for show.
Well,
> it is used when calculating routing costs if you are using that type
of
> protocol. The number doesn't reflect the true bandwidth of the
circuit.
> We've had T1 customers call in complaining because their interface
said
> 1536k instead of 1544k. So we just changed their interface to read
> 1544k and they were happy. Didn't change a thing on their circuit,
but
> it kept the guy happy. Explaining the 8k signalling overhead would
have
> been opening another can of worms.
>
> Jeff
>
>
>
> -----Original Message-----
> From: owner-list@inet-access.net [mailto:owner-list@inet-access.net]
On
> Behalf Of Brian Johnson
> Sent: Monday, October 28, 2002 9:22 AM
> To: Inet-access List
> Subject: Re: Configuring an ATM-OC3 card for a Cisco3662
>
>
> Is there anybody with experience in this area that could give us a bit
> of advice/information?
>
> We would really appreciate it.
>
> TIA.
>
> Brian J
>
> On Fri, 2002-10-25 at 11:08, Brian Johnson wrote:
> > I would be VERY interested in the answer to this one. I'm stumped.
:)
> >
> > Brian J.
> >
> >
> >
> > On Thu, 2002-10-24 at 11:45, Barry Kiesz wrote:
> > > I've got a question on the bandwidth statement within the ATM
> interface.
> > > Below is a snip from my Router. My understanding is that it's in
> Kb/s.
> > > I was trying to get my answer from the Cisco site and it says that
> that
> > > this number is 'informational only'. Is this true?
> > >
> > > The other number of interest is the 'UBR 6800' in the actual PVC.
> Is
> > > this in Kb/s too? That's what the docs tell us (if we're reading
> them
> > > right). The only thing is when we had these numbers set to 4500
> > > (customer was paying for 4.5Mb) we couldn't get over 3.18Mb. This
> makes
> > > me think we're talking about cell rates. But when I pull out my
> cell
> > > rate to kb/s formula, it doesn't make sense.
> > >
> > > We now have it set to 6800 and we seem to spike at 5.41Mb, but
it's
> not
> > > a sustained usage. I want to make sure that the customer is
getting
> > > what they're paying for (6Mb as of right now).
> > >
> > > FYI, the PVC on the Nortel ATM switch is set to 7Mb UBR
> > >
> > > Any insight to this issue would be greatly appreciated.
> > >
> > >
> > > !
> > > interface ATM6/0.2 point-to-point
> > > description To subscriber
> > > bandwidth 6800
> > > ip address 64.68.161.185 255.255.255.252
> > > no ip directed-broadcast
> > > pvc 0/33
> > > ubr 6800
> > > encapsulation aal5snap
> > > !
> > >
> > > Sincerely,
> > >
> > > Barry Kiesz
> > >
> > >
> > >
> > > -
> > > Recent archives of the list can be found at:
> > > http://mix.twistedpair.ca/pipermail/inet-access/
> > > Send 'unsubscribe' in the body to 'list-request@inet-access.net'
to
> leave.
> > > Eat sushi frequently. inet@inet-access.net is the human contact
> address.
> >
> >
> > -
> > Recent archives of the list can be found at:
> > http://mix.twistedpair.ca/pipermail/inet-access/
> > Send 'unsubscribe' in the body to 'list-request@inet-access.net' to
> leave.
> > Eat sushi frequently. inet@inet-access.net is the human contact
> address.
> --
> ______________________________
> Brian Johnson brianj@nvc.net
> Internet Operations Specialist
> Northern Valley Communications
> V:605.725.1059 F:605.725.1050
>
> -
> Recent archives of the list can be found at:
> http://mix.twistedpair.ca/pipermail/inet-access/
> Send 'unsubscribe' in the body to 'list-request@inet-access.net' to
> leave.
> Eat sushi frequently. inet@inet-access.net is the human contact
> address.
>
>
> -
> Recent archives of the list can be found at:
> http://mix.twistedpair.ca/pipermail/inet-access/
> Send 'unsubscribe' in the body to 'list-request@inet-access.net' to
leave.
> Eat sushi frequently. inet@inet-access.net is the human contact
address.
--
______________________________
Brian Johnson brianj@nvc.net
Internet Operations Specialist
Northern Valley Communications
V:605.725.1059 F:605.725.1050
-
Recent archives of the list can be found at:
http://mix.twistedpair.ca/pipermail/inet-access/
Send 'unsubscribe' in the body to 'list-request@inet-access.net' to
leave.
Eat sushi frequently. inet@inet-access.net is the human contact
address.
-
Recent archives of the list can be found at:
http://mix.twistedpair.ca/pipermail/inet-access/
Send 'unsubscribe' in the body to 'list-request@inet-access.net' to leave.
Eat sushi frequently. inet@inet-access.net is the human contact address.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic