[c-nsp] ME3600X mLDP

[Mark Tinka]

On 10/Jul/15 12:12, Sigurbjörn Birkir Lárusson wrote:
> 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.

Agree that the ME3600X has been up and down in recent years. But I
suppose that is mostly because of the use-case. I don't think Cisco
expected that this box would be considered a decent router for Metro-E
deployment with full IP/MPLS capabilities, and not your traditional
Layer 2 Metro-E networks. Like, it took us quite some time to not only
get egress policing added to the box, but also to allow for egress
policing to be enabled for all classes, and not just the PQ.

Luckily, there was enough intelligence that went into the ME3600X ASIC
that it was flexible enough to do many of these things, but some things
just hit the limit, e.g., NG-MVPN, e.t.c.

I think Cisco have learned a great deal from the ME3600X, and this is
already showing in the basic testing I've done on the ASR920. A lot of
the limitations that were unforeseen on the ASR920 "should" (don't quote
me) addressed by the ASR920, and I welcome this box because I realize
that even though the ME3600X is less than 6x years old, it is showing
its age - which does not mean I won't keep deploying them because they
still give you good bang for your buck if you want to offer
data-centre-style capabilities in the Metro-E Access.

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

That's interesting - we have boxes running 15.4(3)S1 and 15.4(3)S2
without issue apart from (r)LFA.

We had some IPv6 issues, but these turned out to be a difference in
principle between the SPAG and other platform teams in Cisco. So we
adjusted our standard IOS configuration to match.

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

That's a shame - mine are chugging nicely along on 15.4(3)S2.

Mark.