[EXTERNAL] Re: JunOS Fusion Provider Edge

Tue Dec 25 13:24:26 UTC 2018

QFX10k is the AD in Fusion Datacenter. In a Fusion Edge setup it is MX.

On Fri, Dec 21, 2018 at 8:21 PM Nikos Leontsinis <
Nikos.Leontsinis at eu.equinix.com> wrote:

> There is a fundamental product limitation.  CoS on Cascade port  for MX is
> not officially supported as well QFX acting as AD.
>
> I agree with those who perceive all these approaches as
> proprietary lock-in (disguised as cheap).
>
>
>
> *From:* NANOG <nanog-bounces at nanog.org> *On Behalf Of *Vincentz Petzholtz
> *Sent:* Wednesday, December 19, 2018 9:01 AM
> *To:* nanog <nanog at nanog.org>
> *Subject:* [EXTERNAL] Re: JunOS Fusion Provider Edge
>
>
>
> Hi there,
>
>
>
> About Juniper Fusion PE and our experience with it.
>
>
>
> For example, you can't get SNMP oids for light levels or even read them
> right from the CLI.
>
> Sure it’s possible but also with a big „meh“. Here is how:
>
> "show interfaces diagnostics optics satellite <interface>“ (<- on the MX)
>
> BUT at least with MX Junos 16.1R7 and aligned SAT Image aka SNOS these
> values are wrong
>
> by a pretty big offset. Juniper promised they already fixed it but we
> can’t confirm (at least not in MX Junos 16.1).
>
> Soon we will take a look at MX Junos 17.3 with aligned sat image.
>
>
>
>  I've also heard you can have them do local L2 forwarding, which can be
> nice for latency and conserving uplink bandwidth, but we don't do any L2
> that way so I wouldn't know the implications
>
> Same thing here … we don’t really need it. At least it’s on the roadmap
> and/or already implemented with higher Junos/SNOS versions.
>
>
>
> From what we can tell though, it does give you Trio L3 performance and
> features with a MUCH cheaper port cost which is exactly what we were
> looking for, the extended reach of the chassis was just a fantastic bonus.
>
> Yep, that is really amazing and the reason we use it on many MXes. You can
> get rid of almost all ports you want (restrictions apply tho).
>
>
>
> We also REALLY like that we can have one pair of MX dists for a whole data
> center with hundreds of thousands of square feet of raised floor and deploy
> QFX5100 or EX4300 switches in every pod and haul back over just a few pairs
> of fiber. Saves a lot of time because all that's required to turn up a new
> connection is a cross connect in the pod. It also allows us to offer copper
> ports very far away from the MX device, which would normally require media
> converters.
>
> We use Junos PE NOT as a replacement for any switch and/or ip fabrics
> within a datacenter. We use it to get rid of many customer/client ports
> (mainly 1G and 10G ports)
>
> which were directly connected to our MXes before. Atm I would not
> recommend using any closed fabrics beyond that scope. If it works for you …
> ok.
>
>
>
> We've wanted to experiment with doing this over dark fiber in the metro as
> well, but we want to feel out any kinks locally before we add additional
> failure modes.
>
> At the moment? Don’t do it. If you run mpls on so called „core
> router/dwdm/wan facing ports“ you have to know that this is totally not
> supported on extended satellite ports.
>
> It’s not even on the roadmap. I already started to „collect“ some other
> ISPs to push juniper towards this feature because technically there no
>
> real reason why fusion should NOT be capable of pushing some mpls labels
> on already tagged 802.1br packets.
>
>
>
> Best regards,
>
> Vincentz
>
> —
>
> PS: some have received this mail multiple times because I’ve send it from
> the wrong account … time for vacation I guess.
>
>
>
> Am 17.12.2018 um 19:26 schrieb Matt Erculiani <merculiani at gmail.com>:
>
>
>
> Fusion has made a lot more sense since Juniper changed the licensing model
> from every switch AND the MX to just the MX.
>
>
>
> We've deployed it in some of our sites. It is very cool from a forwarding
> plane perspective, but from a control plane standpoint it's very...meh. For
> example, you can't get SNMP oids for light levels or even read them right
> from the CLI. You have to log into the satellite switch like you would log
> into an FPC just to get light levels. That's probably the dumbest thing
> we've dealt with though. I've also heard you can have them do local L2
> forwarding, which can be nice for latency and conserving uplink bandwidth,
> but we don't do any L2 that way so I wouldn't know the implications. From
> what we can tell though, it does give you Trio L3 performance and features
> with a MUCH cheaper port cost which is exactly what we were looking for,
> the extended reach of the chassis was just a fantastic bonus.
>
>
>
> We also REALLY like that we can have one pair of MX dists for a whole data
> center with hundreds of thousands of square feet of raised floor and deploy
> QFX5100 or EX4300 switches in every pod and haul back over just a few pairs
> of fiber. Saves a lot of time because all that's required to turn up a new
> connection is a cross connect in the pod. It also allows us to offer copper
> ports very far away from the MX device, which would normally require media
> converters.
>
>
>
> We've wanted to experiment with doing this over dark fiber in the metro as
> well, but we want to feel out any kinks locally before we add additional
> failure modes.
>
>
>
> Very interested in hearing about other's experiences with Fusion, good,
> bad, and ugly.
>
>
>
> -Matt
>
>
>
> On Mon, Dec 17, 2018 at 12:08 PM Mehmet Akcin <mehmet at akcin.net> wrote:
>
> Hey there
>
>
>
> Any ISP using Juniper Fusion Provider Edge?
>
>
>
>
> https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-fusion/junos-fusion.html
>
>
>
>
>
> I am trying to chat with an engineer besides Juniper engineers to
> understand how buggy (or not) this is to go on production for a medium size
> ISP.
>
>
>
> Any feedback good/bad appreciated.
>
> --
>
> Mehmet
> +1-424-298-1903
>
>
> This email is from Equinix (EMEA) B.V. or one of its associated companies
> in the territory from where this email has been sent. This email, and any
> files transmitted with it, contains information which is confidential, is
> solely for the use of the intended recipient and may be legally privileged.
> If you have received this email in error, please notify the sender and
> delete this email immediately. Equinix (EMEA) B.V.. Registered Office:
> Amstelplein 1, 1096 HA Amsterdam, The Netherlands. Registered in The
> Netherlands No. 57577889.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20181225/9e774158/attachment.html>