I'd avoid the 7280R for this. Works great as a P router for cheap, fast
label switching, but their VRF implementation is lacking with both
route-leaking and MP-BGP address family (other than standard ipv4+ipv6)
support being nonexistent.
The 5150 will 'do MPLS', which is pretty clear from their website. The
references 5160, too.
I wouldn't recommend it personally, but it is there.
Yes, stay well away from the Ciena MPLS code... based on my experience
with the CN5100/3900 series...
Tue, Apr 18, 2017 at 02:08:05AM +0100, Tom Hill wrote:
Thanks Tom... I might be wrong, I thought I remembered Ciena not having the
MPLS routing capabilities I needed... I do see this on their website... so
maybe it does more MPLS L2/L3VPN capabilities than I remembered... I might
have to take another look at this and talk to my Ciena POC and VAR...
Thanks again.
http://www.ciena.com/products/5160/
RFC 2205, 3031, 3036, 3985 MPLS PWE3 Pseudowire Emulation Edge-to-Edge
RFC 5654 MPLS-Transport Profile (TP)
LSP Static provisioning
1:1 Tunnel protection
LSP BFD via Gal/Gach
MPLS Virtual Private Wire Service (VPWS)
RFC 4762 VPLS (Virtual Private LAN Service) and Hierarchical VPLS
(H-VPLS)
Provider Edge (PE-s) Functionality for VPLS and H-VPLS
VPLS with multiple VPLS Mesh Virtual Circuits
H-VPLS with Hub and Spoke Virtual Circuits
MTU-s Functionality for H-VPLS deployment
MTU-s Multi-homing (redundant VCs to different PE-s switches)
MPLS Virtual Circuit as H-VPLS spoke Virtual Circuit
PBB-TE Service Instance as H-VPLS spoke Virtual Circuit
Q-in-Q Ethernet Virtual Circuit as H-VPLS spoke Virtual Circuit
MPLS Label Switch Path (LSP) Tunnel Groups
MPLS Label Switch Path (LSP) Tunnel Redundancy
Layer 2 Control Frame Tunneling over MPLS Virtual Circuits
RFC 3209 RSVP-TE (for MPLS Tunnel Signaling)
RFC 3630 OSPF-TE (for MPLS Tunnel Routes)
RFC 3784 IS-IS-TE (for MPLS Tunnel Routes)
RFC 3036 LDP & Targeted LDP (for VPLS VC signaling)
RFC 4090 MPLS Fast ReRoute signaling
LSP Ping & Traceroute
-Aaron
Oh, ok... hmmm
So what was the issue with Ciena and MPLS Patrick ?
-Aaron
Eeee... We're still in the mist of a battle royal with 6 QFX 5100 here =D
We'll know who wins soon.
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:
Sorry, slight correction to the below - GMPLS Sub-TLVs inside the TE LSAs
were being advertised with nil values instead of being removed completely.
One additional thing that really irked me is that their TE code is that
they set all TE metrics to 0 for every interface/link and no way to use
the IGP metric or set it, so if you have two links of equal distance
in terms of hops, there was no way to steer a CSPF computed LSP to prefer
one without using EROs to do it. They also have no concept of attribute
flags or link colors.
Ultimately, their TE implementation was very basic. They openly admitted
their focus was on GMPLS and not MPLS-TE. For us, GMPLS has no real
use case in our network.
Patrick
Fri, Apr 21, 2017 at 11:45:06PM +1000, Patrick Cole wrote:
Hi Erik, as a follow-up to this email from back in April...previously I
hadn't yet tested any qos things on the ACX5048. Now I have tested some
policing and seems to be working thus far in the lab. I am policing at the
unit (subinterface) level to I can accomplish per-vlan/per-unit policers.
I have 5 policers like this....
{master:0}
agould@eng-lab-5048-2> show configuration firewall | display set | grep
policer
set firewall policer test-policer-1000 if-exceeding bandwidth-limit 100k
set firewall policer test-policer-1000 if-exceeding burst-size-limit 3125
set firewall policer test-policer-1000 then discard
set firewall policer test-policer-1001 if-exceeding bandwidth-limit 100k
set firewall policer test-policer-1001 if-exceeding burst-size-limit 3125
set firewall policer test-policer-1001 then discard
set firewall policer test-policer-1002 if-exceeding bandwidth-limit 100k
set firewall policer test-policer-1002 if-exceeding burst-size-limit 3125
set firewall policer test-policer-1002 then discard
set firewall policer test-policer-1003 if-exceeding bandwidth-limit 100k
set firewall policer test-policer-1003 if-exceeding burst-size-limit 3125
set firewall policer test-policer-1003 then discard
set firewall policer test-policer-1004 if-exceeding bandwidth-limit 100k
set firewall policer test-policer-1004 if-exceeding burst-size-limit 3125
set firewall policer test-policer-1004 then discard
{master:0}
agould@eng-lab-5048-2> show configuration interfaces ge-0/0/19 | display set
set interfaces ge-0/0/19 flexible-vlan-tagging
set interfaces ge-0/0/19 mtu 9216
set interfaces ge-0/0/19 encapsulation flexible-ethernet-services
set interfaces ge-0/0/19 unit 1000 description "TEST att mtso - tower 98
Drain 1 - vlan 1000"
set interfaces ge-0/0/19 unit 1000 encapsulation vlan-vpls
set interfaces ge-0/0/19 unit 1000 vlan-id 1000
set interfaces ge-0/0/19 unit 1000 input-vlan-map pop
set interfaces ge-0/0/19 unit 1000 output-vlan-map push
set interfaces ge-0/0/19 unit 1000 statistics
set interfaces ge-0/0/19 unit 1000 family vpls policer input
test-policer-1000
set interfaces ge-0/0/19 unit 1001 description "TEST att mtso - tower 99
Drain 1 - vlan 1001"
set interfaces ge-0/0/19 unit 1001 encapsulation vlan-vpls
set interfaces ge-0/0/19 unit 1001 vlan-id 1001
set interfaces ge-0/0/19 unit 1001 input-vlan-map pop
set interfaces ge-0/0/19 unit 1001 output-vlan-map push
set interfaces ge-0/0/19 unit 1001 statistics
set interfaces ge-0/0/19 unit 1001 family vpls policer input
test-policer-1001
set interfaces ge-0/0/19 unit 1002 description "TEST att mtso - tower 100
Drain 1 - vlan 1002"
set interfaces ge-0/0/19 unit 1002 encapsulation vlan-vpls
set interfaces ge-0/0/19 unit 1002 vlan-id 1002
set interfaces ge-0/0/19 unit 1002 input-vlan-map pop
set interfaces ge-0/0/19 unit 1002 output-vlan-map push
set interfaces ge-0/0/19 unit 1002 statistics
set interfaces ge-0/0/19 unit 1002 family vpls policer input
test-policer-1002
set interfaces ge-0/0/19 unit 1003 description "TEST att mtso - tower 101
Drain 1 - vlan 1003"
set interfaces ge-0/0/19 unit 1003 encapsulation vlan-vpls
set interfaces ge-0/0/19 unit 1003 vlan-id 1003
set interfaces ge-0/0/19 unit 1003 input-vlan-map pop
set interfaces ge-0/0/19 unit 1003 output-vlan-map push
set interfaces ge-0/0/19 unit 1003 statistics
set interfaces ge-0/0/19 unit 1003 family vpls policer input
test-policer-1003
set interfaces ge-0/0/19 unit 1004 description "TEST att mtso - tower 102
Drain 1 - vlan 1004"
set interfaces ge-0/0/19 unit 1004 encapsulation vlan-vpls
set interfaces ge-0/0/19 unit 1004 vlan-id 1004
set interfaces ge-0/0/19 unit 1004 input-vlan-map pop
set interfaces ge-0/0/19 unit 1004 output-vlan-map push
set interfaces ge-0/0/19 unit 1004 statistics
set interfaces ge-0/0/19 unit 1004 family vpls policer input
test-policer-1004