[c-nsp] RSVP on a sub-rate ethernet interface?

[Temkin, David]

Thanks.  One other question - I'm trying to mark up traffic that's in a
l2tpv3 tunnel, and I'm reading through the doc:

http://www.cisco.com/en/US/customer/products/sw/iosswrel/ps1829/products
_feature_guide09186a0080222e21.html#wp1057627

So basically, if I do a class map and do a "match protocol ip" on the
input interface for the tunnelled traffic I should be able to apply a
policy map to set the precedence of the tunnel, correct?

Thx,
-Dave 

> -----Original Message-----
> From: Rodney Dunn [mailto:rodunn at cisco.com] 
> Sent: Friday, August 06, 2004 9:58 AM
> To: Temkin, David
> Cc: Rodney Dunn; cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] RSVP on a sub-rate ethernet interface?
> 
> Then you need to do MQC with shaping and then apply CBWFQ 
> that will determine how traffic over the shape rate is serviced.
> 
> On Fri, Aug 06, 2004 at 09:48:42AM -0400, Temkin, David wrote:
> > They drop, unfortunately. 
> > 
> > > -----Original Message-----
> > > From: Rodney Dunn [mailto:rodunn at cisco.com]
> > > Sent: Friday, August 06, 2004 9:46 AM
> > > To: Temkin, David
> > > Cc: cisco-nsp at puck.nether.net
> > > Subject: Re: [c-nsp] RSVP on a sub-rate ethernet interface?
> > > 
> > > Do they drop anything over 50mbps or are you charged 
> differently for 
> > > it?
> > > 
> > > The drawback to CAR is there isn't any backpressure so 
> you can't do 
> > > any queueing for bandwidth allocation.
> > > It's a policer.
> > > 
> > > For the queueing part you would need to do MQC with shaping/CBWFQ 
> > > for bandwidth control.
> > > 
> > > Rodney
> > > 
> > > On Fri, Aug 06, 2004 at 09:30:04AM -0400, Temkin, David wrote:
> > > > I've got an ethernet interface that faces an Ethernet 
> WAN provider 
> > > > that I'd like to use RSVP on, and I can't find any
> > > reference on how to
> > > > do it aside from on frame- I only get 50mbps from the provider, 
> > > > but the handoff is 100mb...  I'm wondering how RSVP + 
> CAR behave...
> > > > 
> > > > My only other thought is to limit down what doesn't need 
> > > > guaranteed bandwidth to a number below what the max of 
> that + what 
> > > > does need guaranteed bandwidth would add up to, but 
> that's kind of ugly...
> > > > 
> > > > Thx,
> > > > -Dave
> > > > 
> > > > 
> > > > IMPORTANT: The information contained in this email and/or
> > > its attachments is confidential. If you are not the intended 
> > > recipient, please notify the sender immediately by reply and 
> > > immediately delete this message and all its attachments.  Any 
> > > review, use, reproduction, disclosure or dissemination of this 
> > > message or any attachment by an unintended recipient is strictly 
> > > prohibited.  Neither this message nor any attachment is 
> intended as 
> > > or should be construed as an offer, solicitation or 
> recommendation 
> > > to buy or sell any security or other financial 
> instrument.  Neither 
> > > the sender, his or her employer nor any of their respective 
> > > affiliates makes any warranties as to the completeness or 
> accuracy 
> > > of any of the information contained herein or that this 
> message or 
> > > any of its attachments is free of viruses.
> > > > 
> > > > 
> > > > _______________________________________________
> > > > cisco-nsp mailing list  cisco-nsp at puck.nether.net 
> > > > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > > > archive at http://puck.nether.net/pipermail/cisco-nsp/
> > > 
> > > 
> 
>