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

[Mark Tinka]

On Wednesday, December 14, 2011 04:57:30 PM Reuben Farrelly 
wrote:

> I took the plunge and have now gradually upgraded 5
> ME3600X units in production to 15.1(2a)EY1a software
> which was released a couple of weeks ago.

So I decided to join you and try the new release and see 
whether it fits us better than our current 12.2(52)EY2.

By the way, CCO claims the release is 15.1(2a)EY1a, but both 
the filename and representation on the switch are 
15.1(2)EY1a. Oh well...

> So far:
> 
> - IPv6 is in, enabled, and it works well carrying 50+
> prefixes and OSPFv3 within our AS.  Not a hugely taxing
> environment, but IPv6 works.

I tested IPv6 - yes, it's enabled but massively broken:

	o I turned it on and configured a v6 address on one
	  of the uplink ports.

	o Link-local is generated and all looks well.
	  However, there is no v6 communications of any kind
	  to the other side of the link (a Juniper MX480).

	o I check everything on the interface. A good v6
	  filter is there, so I chuck it, no joy.

	o I remove an outbound QoS policy (unlike some of
	  other IOS systems, the ME3600X does not support
	  'match any' in MQC - this can filter packets in
	  the data plane, as we saw), no joy.

	o As much as every bone in my body was saying,
	  "What's left is v4 stuff, you can't possibly be
	  thinking about that", I decided to remove an
	  outbound v4 ACL. And voila! You can imagine how
	  wide I had to open my mind to do that :-).

	o And this is a very simple egress v4 filter - the
	  usual "we shouldn't be seeing these in the global
	  table" type of thing:

lab#sh ip access-lists filter-outgoing
Extended IP access list filter-outgoing
    10 deny ip any 10.0.0.0 0.255.255.255
    20 deny ip any 127.0.0.0 0.255.255.255
    30 deny ip any 169.254.0.0 0.0.255.255
    40 deny ip any 172.16.0.0 0.15.255.255
    50 deny ip any 192.0.2.0 0.0.0.255
    60 deny ip any 192.42.172.0 0.0.0.255
    70 deny ip any 192.168.0.0 0.0.255.255
    80 deny ip any 198.18.0.0 0.1.255.255
    90 permit ip any any (23 matches)
lab#

	o Surprisingly, the egress v6 filter has no undue
	  effect, which is expected behavious in our
	  network.

	o I also notice that the output of "sh ipv6 int"
	  shows that ACL's and QoS service policies are
	  still applied to the interface even when they
 	  aren't. I try the same on another interface before
	  applying a v6 address to it, and the issue isn't
	  seen. I suspect that "bumping" the interface would
	  clear the faulty programming (or represention of
	  programming), but it's the interface I'm coming
	  through for remote access. So I reboot the box
	  instead and the issue is resolved. I'm not sure
	  this has anything to do with anything, though, but
	  is worth having Cisco check out.


This, for us, is a real show-stopper. Not being able to 
support a v4 filter and v6 forwarding on the same interface 
is not going to fly. So we'll stay without v6 until it's 
ready :-(.

> - IPv4 OSPF...

We're running IS-IS.

Glad to see that IS-IS MT is available in the code, and 
working well. No major drama.

> with limited iBGP worked in previous builds
> and still seems OK.

BGP is working well too, including support for IPv6 prefix 
lists now.

Match conditions for IPv6 prefix lists were there even 
before IPv6 code was available, so those are part of the 
template on 12.2(52)EY2.

One thing I saw on one of the switches I tested - it is 
possible to configure the IPv6 neighbors in the global BGP 
context on early code that has no v6 support, but not in the 
AF context, which is fine. After upgrading to the new code, 
enabling the AF context for v6 on one of the switches 
immediately brought up v6 sessions. However, the 2nd switch 
didn't go as smoothly. After nearly 15 minutes of looking 
over what looked like a good configuration, I removed the 
global context v6 neighbors, re-added them as they were 
before, and voila, the session came up. 

Could be something to do with the inheritance of the session 
templates. I could see the neighbors with a "sh bgp ipv6 
unicast summary", but they were idle like no session 
parametres were defined.

> - Issues CSCtr83500 and CSCtr83418 are fixed - so hardset
> and auto speed/duplex ports is no longer a showstopper.

We do see issues in 12.2(52)EY2 where the Gig-E ports don't 
report utilization statistics for the interface. I'm not 
running any traffic on any of the Gig-E ports in my lab 
right now, so can't tell whether this issue is fixed in the 
new code.

Not sure whether you're seeing anything like this. The 
10Gbps uplink ports are fine, though, even in the older 
code. The issue only affects the Gig-E ports.

I'll get a chance to pump some traffic through and test.

> - Limited MPLS testing shows no issues that I can tell.

MPLS still seems fine here too.

Traffic forwarded via MPLS has no issues.

> - Bridge domain routing restrictions relaxed somewhat are
> welcome!

On our side, EVC's seem to take the 'xconnect' command just 
fine - EVC Xconnect, as Cisco call it.

I'm remote right now, so don't have another box with 'up/up' 
interfaces to test with to see whether it actually signals 
okay. Will work on that later (including sessions with SVI-
based and EVC-based xconnects on Cisco's, as well as toward 
a Juniper).

> - QoS options seem still very much like a Catalyst switch
> than a router.

I don't think so - while the ME3600X/3800X does not have a 
fully developed QoS compliment, it's more along the "router" 
lines than the "Catalyst" lines. Thank God!

As it stands now, I'm glad to see that the issues with QoS 
are not hardware related, so far.

> For example applying a very basic 10M
> inbound and outbound policer on a VLAN interface to rate
> limit a customer for example, is not as simple as say, a
> software based router.

We normally apply the service policy either on the physical 
interface or EVC.

Anyway, QoS is still broken re: egress policing - this new 
release still supports only specifying non-default classes, 
and said classes MUST be serviced by the LLQ scheduler. So 
no joy here.

We still can't use this until egress policing supports all 
classes (especially the default class) and is not limited to 
Priority queue servicing.

In general, I think IOS still doesn't support Priority and 
Custom queuing for IPv6 packets. I need to confirm this as 
of today.

> Note:  there are 21 pages of resolved caveats in this
> code compared to the original 15.1(2)EY release.  It's
> undoubtedly a good thing that problems are being fixed,
> however 21 pages of caveats resolved (about 180 bugs)
> and IPv6 support appearing is arguably more than a
> "minor rebuild" as the version number would indicate,
> but sounds rather like some serious fixes have gone on
> behind the scenes.

Do you have a link to the release notes? I normally follow 
the one in the download section but that one definitely 
isn't 21 pages long :-).

> I am hoping the next rebuild release will be in 6 weeks
> with 30 caveats fixed, and not 5 months with 150+ queued
> up.  ME guys if you are listening...more releases with
> fewer changes is easier to manage and deploy and less
> risky to upgrade in the field than fewer, far between
> drops of code.

Well, what I know now is that we certainly aren't ready to 
leave our old 12.2(52)EY2 just yet. There wouldn't be much 
point except some bug fixes (and the introduction of new 
ones), given the number of boxes we have in the field.

> Having said that, things are looking good and I'm giving
> this code a thumbs up.  Well worth the upgrade from
> 12.2(EY)3a.

Definitely good to see Cisco have moved quick in bringing in 
IPv6, and I certainly applaud them (IPv6 ACL's as well VTY 
access works too via a v6-supporting Cisco SSH server). But 
it's nowhere near production quality for us, especially when 
it affects how we run IPv4.

So we'll be taking a pass on this release.

Thanks for sharing, Reuben.

PS: some key things we're still missing on this box (there's
    more but these are the ones I think the list would find
    more generic across operators):

	- v4 and v6 uRPF support.
	- EVC SNMP monitoring.
	- 4-byte ASN support.
	- MC-LAG.
	- 

Cheers,

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/177d4d63/attachment-0001.sig>