JunOS Fusion Provider Edge

Matt Erculiani merculiani at gmail.com
Mon Dec 17 18:26:11 UTC 2018


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20181217/e1dd23c8/attachment.html>


More information about the NANOG mailing list