On 15/12/2011 1:58 PM, Mark Tinka wrote:
On Thursday, December 15, 2011 07:33:32 AM Reuben Farrelly wrote:
Yikes. I don't have this problem in my deployment so far as I have
pushed this job onto edge routers to do this function on all
ingress/egress points to our network.
Are you saying you have egress ACL's applied on dual-stack interfaces
and you're not seeing the issue?
Yes - but not on this platform. I have the switches within our IGP and
the edges (both CPE and at the other end - transit+peering) are on IOS
software based routers which don't have this problem.
So it's likely your problem is actually valid, as our environment isn't
quite the same.
My requirement has to date been to do this on VLAN interfaces -
maybe I should look into doing this on an EFP on this platform to
see if it's any better.
It certainly is, for us. We don't bother applying QoS on SVI's. Just
physical interfaces or EFP's.
Coming up. We have outage night tonight where I can be a bit more
liberal in terms of testing, so I might convert over just one low
priority connection that I have full control over end to end - which
should give me some more options to test in the coming days.
:-), for me, it's still better than the Catalyst - I'm happy not to
need 'mls qos' and all the havoc that comes with it like 'srr or wrr
queues', e.t.c.
Oh...I hadn't gotten that far. In that case I agree - that's the stuff
that seemed needlessly complex that I was hoping to avoid.
- A wholesale carrier hands off a 1G dot1q trunk port to us - Each
end customer is assigned an individual VLAN on that trunk by the
carrier - We need to be able to rate limit/police (or shape I
guess) all traffic in and out on the specific EVC/VLAN for a
customer to a given contracted amount (tricky if it works at all)
We're doing this today - every child VLAN for the wholesale provider
is an EVC. So you can apply ingress/egress QoS policies on each EVC
which represents a remote child of the wholesale provider.
This is why we don't do this stuff on SVI's :-).
Ok, worth noting. I'm going to have to start some internal re-education
about EFP's as this is a new concept for our helpdesk and some of our
other engineers. They are far more familiar (as I am) with SVI configs
as our company had more of a history of integration than SP type work
and configurations...as a carry over from traditional IOS devices.
Progress on this platform is encouraging though, as long as the code
keeps moving along and the bugs keep being fixed and releases become
more frequent. Goal for me for next year is to be able to remove a
power hungry half rack height 7613 access router and replace with a
couple of ME switches, provided the QoS and rate limit stuff gets
sorted, and we get policy routing support. I understand it's on the
roadmap with no ETA, so we'll just have to live in hope.
Thanks for your help and comments Mark - has been useful to share your
experiences with this platform and learn some new things along the way.
Reuben
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
