[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 05:05:43 PM Reuben Farrelly 
wrote:

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

Yes, that's right. We have tons of other Cisco platforms 
(ASR1000's, 7200-VXR's, 2800's, e.t.c.) that do not have 
this particular issue.

My guess is it's PI code that's already available to all 
other IOS-based devices, but porting it over to the ME3600X 
had a little bit of a boo-boo.

It certainly seems like it's fixable, so that's good. It's 
just really weird that an IPv4 ACL would filter IPv6 traffic 
:-).

> So it's likely your problem is actually valid, as our
> environment isn't quite the same.

Yeah - I've reproduced the issue reliably on 2x separate 
boxes. So it's most definitely a bug.

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

Sounds good.

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

One of the reasons we were quite reluctant to deploy the 
ME3750 for this purpose, because even though it supports 
MPLS and many of its applications, it's still a Catalyst 
switch.

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

I know what you mean.

Coming from the ME3750 side of things (we have hundreds of 
them we're replacing with the ME3600X), Ops folk would get 
used to SVI's.

Personally, I always found SVI's rather odd. We'll be glad 
not to need them anymore for the majority of cases. I wish 
there was some way to run Layer 3 services on an EFP :-).

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

Indeed.

The only issue is spacing updates so we don't incur too many 
customer-annoying reboots just to bring the systems up-to-
speed.

The next 3 years, I think, will be crucial in getting these 
boxes to anywhere near where they should be, both in terms 
of Cisco bringing out code, and operators actually rolling 
it out.

Keeping Access devices up-to-date is not easy.

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

Best of luck with that, Reuben.

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

Most welcome.

Will keep sharing as we continue our adventure :-).

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/352599b2/attachment.sig>