[c-nsp] ME3600X IOS 15.1(2a)EY1a Code: [Was: Re: Cisco ME3600X and Bridge-Domain Routing config question}

[Mark Tinka]

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?

If so, is your ACL similar to ours?

It's quite easy for us to reproduce this issue across 2x 
different switches. However, I will say that we apply these 
ACL's core-facing, so only on the uplink ports. I don't know 
if a dual-stacked Gig-E port would see the same issue, 
although we normally use uRPF on customer-facing ports 
rather than ACL's (yes, the platform as no uRPF today).

> But I have noted that VLAN interfaces do not have
> accurate counters (on any release).  This is unlike my
> ME6524 and 7600's where I have SNMP pollable counters
> for these interfaces.

Yeah - we try to stay away from using SVI interfaces for 
services at all. For now, we have to because EVC Xconnect 
isn't available in 12.2(52)EY2. But we'll migrate all pw's 
to EVC Xconnect once we migrate to stable code.

That said, you can't escape from using SVI's if you are 
providing Layer 3 services on an EFP. However, we'll be 
monitoring the EVC for counters as well as the QoS service 
policies applied to it.

> 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.

> I've been able to get away with this functionality on
> 7200s and 1800/1900/2800/2900 ISR's and more or less on
> the 7600 and ME6524 in the past:
> 
> policy-map police-10M
>   class class-default
>    police cir 10240000 bc 1250000
>     conform-action transmit
>     exceed-action drop
> 
> On those platforms this allows me to rate limit (in both
> directions if need be) a customer port or VLAN or
> subinterface to 10M and is presumably independent of
> whether the traffic is IPv4 or IPv6.  The point is it's
> simple and it works.

Yes, on ingress, this will work on the ME3600X. But on 
egress, you have two issues with this:

	o class-default is not supported as a match
	  condition today.

	o egress policers assume you're running an LLQ
	  scheduler for the service policy.


I'm waiting for these two issues to get fixed before we 
migrate customers from shapers to policers for egress 
bandwidth control.

> Trying to apply this on the ME3600X results in:
> 
> sw6.nsw(config-if)#service-policy output police-10M
> QoS: Invalid target for service-policy
> QoS: Configuration errors for policymap police-10M
> sw6.nsw(config-if)#
> sw6.nsw(config-if)#service-policy input police-10M
> QoS: Invalid target for service-policy
> QoS: Configuration errors for policymap police-10M
> sw6.nsw(config-if)#
> 
> The documentation:
> 
> http://www.cisco.com/en/US/partner/docs/switches/metro/me
> 3600x_3800x/software/release/15.1_2_ey/configuration/guid
> e/swqos.html
> 
> suggests it's not nearly that straightforward to set up,
> and looks more like Catalyst QoS hell :-(

:-), 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.

Also, the software today only support single-rate, two-color 
marking. trTCM is planned for the future, which would be 
good.

> - 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 :-).

> - We also need to be able to see and graph interface
> counters for each EVC/VLAN for Cacti/Solarwinds (at
> present this does not work on VLAN interfaces)

Yes, one of the things we're looking for.

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20111215/7b77dbab/attachment-0001.sig>