10G MetroE 1-2U Switch

Fri Apr 21 13:45:06 UTC 2017

Aaron,

The code is very green;  the platform originally was inherited from
Nortel and as such they invested heavily in PBB-TE first and foremost.    

To give you an idea they're currently at version 6.16 and the MPLS 
code was introduced in 6.10 (from memory).

They support just enough OSPFv2 or IS-IS to implement basic MPLS TE 
functionality but it does not interop with any other vendor well
at all from my testing.

They only support protected active/standby LSP groups withI maximum
2 paths per group.  Paths inside a group cannot be computed automatically
and /must/ have EROs specified.  

They do not support Fast Reroute PLR/MP in any way and their product
manager said they have no plans to do so in the future.  They do support
"signalling" desired FRR protection on an LSP, however, in my lab testing
this is a moot point as they don't interop with our Cisco core gear.
They seem to add GMPLS TLVs in to their PATH msgs with nil values even
when you aren't using GMPLS, which Cisco doesn't like.

I was able to get their gear to interop with our Brocade routers, but
it was world of hurt of problems in production as they don't do make
before break on LSPs or anything useful like that.

Even when running only their gear in isolation, we had numerous extremely
large service impacting problems with their software - things that as
a software and network engineer by trade I can only put down
to extremely badly written code. For example we had an issue where when
BFD would flap on links rapidly through our network, the MPLS cross
connect table would get misprogrammed with a bad value and then from
that point onwards all transit LSPs would fail to signal through the
node.

Even further to this, the biggest issue I had is that their software 
was not written with enough easy-to-access diagnostic/debugging capability 
to be able to allow the vendor to triage and get to the root cause 
of issues.  Most major issues never got solved because the things
the vendor required you to troubleshoot were outragously inconvenient
or massively service affecting in nature.  Example;  there was no
way to send debugging via the network (syslog etc).  In quite a
few cases I had to break out in to the linux CLI and run their 
debug streaming program on all our nodes and use netcat to transport
it back to our servers to capture it.

They implement LDP signalled PWE and VPLS but the cli has a lot of
really annoying nuances like, you can't change the LSP on a pseudowire
without detaching it from its virtual switch (no make-before-break 
functionality exists either).

We stuck with it for a while, hoping it would get better but every
release seemed to bring different bugs, and the old ones never 
seemed to get fully fixed and would resurface in the future.  I
suspect they were dealing with race conditions in their code and
they just never could seem to reproduce the conditions that would
cause them in their lab.  I think our microwave network tested their
code in ways they never had before when storms rolled through.

This might all be different on their larger packet optical devices
I don't know - this all applies to the SA-OS on 39XX/51XX platform.

We now use the ASR920 platform and comparatively it's night and
day in terms of feature set and stability.  Only thing I'm missing 
is lack of tunnel byte counters for use by auto-bw, but Cisco say 
this is coming in Everest...

Regards,

Patrick

Wed, Apr 19, 2017 at 03:06:42PM -0500, Aaron Gould wrote:

> Oh, ok... hmmm
> 
> So what was the issue with Ciena and MPLS Patrick ?
> 
> -Aaron
> 
> 

-- 
Patrick Cole <z at wwwires.com>
Senior Network Specialist
World Without Wires
PO Box 869. Palm Beach, QLD, 4221
Ph:  0410 626 630