[c-nsp] ME3600X mLDP

[Sigurbjörn Birkir Lárusson]

On 10/07/15 10:21, "Mark Tinka" <mark.tinka at seacom.mu> wrote:
>
>
>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.

Yeah, our thoughts were to use it in smaller POPs where we have a demand
for an advanced feature set but not at a large scale, for which these
boxes would have been perfect, hence why we purchased them at the time.

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

And this is exactly why I'm buying some 920s, because they fit exactly the
same purpose as the ME3600x did at the time.

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

That's actually encouraging and might encourage me to take another swing
at getting these boxes on 15.4(3), I had become worried that Cisco didn't
test the most basic things on the ME3600x anymore, but if they can run
semi-recent code they are indeed usable since the hardware is good enough
to do many things well, as witnessed by the fact that the 903 with the
RPS1-55 is now a very capable ME aggregation box.

<snip>

Kind regards,
Sibbi