> Your Cisco config assumes all traffic from the upstream provider goes to the
> customer (otherwise you would not be able to use class default). If this is
> indeed the case, you can apply a policer to the upstream provider interface
> to police all incoming traffic.
Nope, it does not assume this. The situation I described in the second mail
was oversimplified. The actual configuration is more like this:
upstream1 peering upstream2
\ | /
\ | /
\ | /
juniper m5 ---- c7206vxr
/ | | \
/ | | \
customer customer customer customer
So we have two upstreams, one connected to the M5, one connected to a Cisco
7206VXR and lots of customers connected to either the M5 or 7206. We want to
limit traffic comming in from *any* of the upstreams. If I use the solution
you suggest and limit traffic destined for customer to 2Mbps at upstream
interface 1 and to 2Mbps at upstream interface 2, then the customer actually
has 4Mbps available. If I limit him to 1MBps at upstream 1 and 1Mbps at
upstream 2, the he can not use full 2Mbps through upstream 1 (and 0Mbps
through upstream 2 in this case). I want the customer to have 2Mbps of
upstream connectivity (for example, he could use up to 1Mbps at upstream 1 and
1Mbps at upstream 2, or 512Kbps at upstream 1 and 1.5Mbps at upstream 2, or
whatever he pleases, up to the maximum of 2Mbps). So, his *aggregate*
international connectivity can not exceed 2Mbps.
The only way to achieve this, is to somehow mark packets comming in from the
upstreams and than on the customer-facing interface limit the throughput of
only those marked packets.
> If this is not the case, define a similar policer that matches not all
> traffic, but only traffic with destination address within the customer
> address-space.
...which is fine but has two problems: first is, that customer could have lots
of address space and it is hard to keep track of all of it all the time and
it's easy to miss some (plus I'm lazy :-). Also, take into account that we
have *two* upstreams (see above), so this solution doesn't actually limit the
aggregate international traffic for the customer.
> Note that there is a difference between the shaping that you apparently use
> in your Cisco solution, and the policing described above. Shaping will do
> tail drop when the queue fills up, whereas policing will (or may, depending
> on your setup) drop out-of-profile traffic.
Yeah, I understand the difference between shaping and policing. I prefer
shaping, but simple policing would do (as I can't do shaping on the M5
anyway).
This archive was generated by hypermail 2b29 : Mon Aug 05 2002 - 10:42:40 EDT