[c-nsp] ME3600X mLDP

Fri Jul 10 06:12:08 EDT 2015

On 10/07/15 09:30, "Mark Tinka" <mark.tinka at seacom.mu> wrote:

>
>
>On 10/Jul/15 10:56, James Bensley wrote:
>> Agreed, in the earlier code versiosn we had some faily ridiculous bugs
>> on the ME3's that just fed my every grown lack of faith with Cisco in
>> their ability to test their own code. Bugs like pseudowires not
>> forwarding any data traffic at all, I mean how can you miss that!
>
>We started working on this box back in late 2009 when Cisco were just
>about ready to start shipping. Those days (even at the time of FCS), it
>was 12.2EY. We always knew that we'd be rebooting the box every couple
>of weeks-to-months for about 3x years, but we were fine with that
>because Cisco were really the only vendor at the time that offered us a
>solution to get MPLS all the way into the Access in a manner that made
>sense (platform size, form factor, cost, feature set, e.t.c.).

Sadly we've come accustomed to this sort of product launch from Cisco and
we've been dealing with this on the 901 and 903 for a few years now, I've
logged quite a few bug reports due to things not working (at all, or not
the way they are supposed to) and done a fair number of updates.  I'm
reasonably happy with the stability of the current software trains for
these boxes and the feature parity is getting to a point where I'm happy
to have them in production.

My problem with the ME3600, which to me has always been a bit of bastard,
is that it has never stabilized, it was largely superseded by the 903
(which with with the RSP1 is the same hardware but does not seemingly run
the same code train) and now with the 920, the 903's RSP2 brethren.

As an example of this I tried updating one of my ME3600X's to 15.4(3)S1 a
few months ago to get them into the same code train as the 903s (which
have been running pretty much bleeding edge code since day one to escape
things not working and get the feature set up to par with what we need)
and basic things like MPLS forwarding didn't work, all MPLS forwarding was
uni-directional and you could see that the forwarding labels were not
being correctly programmed into the hardware (we're talking very basic LDP
+ OSPF here, this is not fancy in any way).

I had to revert back to 15.3(3)S4 to get the box up and running again.

To me these boxes are now almost bricks, if I can't trust basic features
to work on semi-recent code and I've slowly moved the boxes I have into
being MPLS based CPEs for larger customers where the requirement for an
ISP feature set is small and I can run older (but patched) code

Kind regards,
Sibbi
>
>Mark.
>
>_______________________________________________
>cisco-nsp mailing list  cisco-nsp at puck.nether.net
>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at http://puck.nether.net/pipermail/cisco-nsp/