«

Hi,
I have the following network:

Hopefully this diagram won't get messed up when I post it.

internet
|
R1
/ \
1 / \2
/ \
internet---R2------R3-----internet
|\ 3 |
| \ |
| \ |
|4 \5 |6
| \ |
| \ |
| \ |
R5------R4
7

The links beween the routers are provisioned by various methods as follows:
link 1 mpls vpn
link 2 mpls vpn
link 3 POS
link 4 ethernet vlan
link 5 POS
link 6 mpls vpn
link 7 ethernet vlan

I have switches located with each router, clients connect into the switches.
I need to be able to rate limit seperate clients whilst allowing them
out to the internet via any access. I had intended to run network wide
vlans (one for each client) and rate limit each vlan on every switch,
which would allow their traffic to take which ever route it required in
order to get to the internet - ie as far as our systems would be
concerned, each link would be a dot1q trunk regardless of how it was
provisioned. My problem with this is links 4 & 7 which are presented to
us as vlan's - as I see it, I'd need to run something like Q-in-Q. For
Q-in-Q, does all the equipment on the providers network need to know
about the stacked tags ?
Can any one offer suggestions as to what I should look into to achieve
what I want ?

FYI, it is imagined that all routers will be 7603's and switches will be
3550's.

TIA,
Jon

--
remove goaway for email

Here's the diagram again.

internet
|
R1
/ \
1 / \2
/ \
internet---R2------R3-----internet
|\ 3 |
| \ |
| \ |
|4 \5 |6
| \ |
| \ |
| \ |
R5------R4
7

--
remove goaway for email

Not sure about your requirement for vlan's with regard to systems, however
you don't need vlan's in order to police user traffic, a 3550 can do this on
a per port basis at ingress.

http://www.cisco.com/en/US/partner/p...products_confi
guration_guide_chapter09186a008014f36e.html#102497 7

This would seem to obviate the need for q in q? In the only case of q in q I
have seen first hand I believe the provider was aware of what vlans were
being encapsulated. I doubt this is a technical requirement however, more so
a billing one, i.e. to restrict the vlans allowed to whatever has been sold.


"Jon Lawrence" <> wrote in message
news:...
> Here's the diagram again.
>
> internet
> |
> R1
> / \
> 1 / \2
> / \
> internet---R2------R3-----internet
> |\ 3 |
> | \ |
> | \ |
> |4 \5 |6
> | \ |
> | \ |
> | \ |
> R5------R4
> 7
>
> --
> remove goaway for email

Ben wrote:
> Not sure about your requirement for vlan's with regard to systems, however
> you don't need vlan's in order to police user traffic, a 3550 can do this on
> a per port basis at ingress.
>
> http://www.cisco.com/en/US/partner/p...products_confi
> guration_guide_chapter09186a008014f36e.html#102497 7
>
> This would seem to obviate the need for q in q? In the only case of q in q I
> have seen first hand I believe the provider was aware of what vlans were
> being encapsulated. I doubt this is a technical requirement however, more so
> a billing one, i.e. to restrict the vlans allowed to whatever has been sold.
>
>
Odd, I can't get to that url - and yes I've got a CCO login.

I know you can rate limit on a per port basis. DOH I'm losing the plot
I had been thinking that by rate limiting on a per vlan basis it
would somehow magically limit them to that across the entire vlan, it
wouldn't. It would simply limit the amount that each router would allow
into/out off the vlan.
Say that client wanted 10Mb, on a per vlan basis R1 would allow 10Mb
in/out so would R2, R3 etc. So it would be possible for the client to
get more than 10Mb.
Am I right in my thinking that rate limiting the port that the client is
connected to is the only way to actually limit the amount of data that
flows to/from the client.
What happens if the client takes a 2nd connection at another POP ie they
now have a connection at R1 pop and R2 pop. How can I stop them pulling
10Mb through each connection ?

Jon

--
remove goaway for email

Well normally these things are productised on a per port basis...
But you could certainly do some policing on more than one port - provided
there is a single aggregration point somewhere in the network. This would
need to be linked to an access-list to define traffic from that customer.

If traffic from both ports can take totally different paths then there is no
way to limit them both to a total of 10Mb.

"Jon Lawrence" <> wrote in message
news:...
> Ben wrote:
> > Not sure about your requirement for vlan's with regard to systems,
however
> > you don't need vlan's in order to police user traffic, a 3550 can do
this on
> > a per port basis at ingress.
> >
> >
http://www.cisco.com/en/US/partner/p...products_confi
> > guration_guide_chapter09186a008014f36e.html#102497 7
> >
> > This would seem to obviate the need for q in q? In the only case of q in
q I
> > have seen first hand I believe the provider was aware of what vlans were
> > being encapsulated. I doubt this is a technical requirement however,
more so
> > a billing one, i.e. to restrict the vlans allowed to whatever has been
sold.
> >
> >
> Odd, I can't get to that url - and yes I've got a CCO login.
>
> I know you can rate limit on a per port basis. DOH I'm losing the plot
> I had been thinking that by rate limiting on a per vlan basis it
> would somehow magically limit them to that across the entire vlan, it
> wouldn't. It would simply limit the amount that each router would allow
> into/out off the vlan.
> Say that client wanted 10Mb, on a per vlan basis R1 would allow 10Mb
> in/out so would R2, R3 etc. So it would be possible for the client to
> get more than 10Mb.
> Am I right in my thinking that rate limiting the port that the client is
> connected to is the only way to actually limit the amount of data that
> flows to/from the client.
> What happens if the client takes a 2nd connection at another POP ie they
> now have a connection at R1 pop and R2 pop. How can I stop them pulling
> 10Mb through each connection ?
>
> Jon
>
> --
> remove goaway for email

Try this URL instead:

http://www.cisco.com/en/US/customer/...e.html#1024977
Jack

Interesting link, but this won't work for the situation in question where a
customer will have connections on two separate switches.


"Jack" <> wrote in message
news: oups.com...
> Try this URL instead:
>
>
http://www.cisco.com/en/US/customer/.../products_conf
iguration_guide_chapter09186a008014f36e.html#10249 77
> Jack
>