<div dir="ltr"><div>QFX10k is the AD in Fusion Datacenter. In a Fusion Edge setup it is MX.</div><br><div class="gmail_quote"><div dir="ltr">On Fri, Dec 21, 2018 at 8:21 PM Nikos Leontsinis <<a href="mailto:Nikos.Leontsinis@eu.equinix.com">Nikos.Leontsinis@eu.equinix.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-GB">
<div class="gmail-m_3325145994843829317WordSection1">
<p class="MsoNormal"><span lang="EN-US">There is a fundamental product limitation.  CoS on Cascade port  for MX is not officially supported as well QFX acting as AD.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">I agree with those who perceive all these approaches as  </span><span style="color:rgb(34,34,34);background:white">proprietary lock-in</span><span>
<span lang="EN-US">(disguised as cheap).<u></u><u></u></span></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> NANOG <<a href="mailto:nanog-bounces@nanog.org" target="_blank">nanog-bounces@nanog.org</a>>
<b>On Behalf Of </b>Vincentz Petzholtz<br>
<b>Sent:</b> Wednesday, December 19, 2018 9:01 AM<br>
<b>To:</b> nanog <<a href="mailto:nanog@nanog.org" target="_blank">nanog@nanog.org</a>><br>
<b>Subject:</b> [EXTERNAL] Re: JunOS Fusion Provider Edge<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Hi there,<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">About Juniper Fusion PE and our experience with it.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<p class="MsoNormal">For example, you can't get SNMP oids for light levels or even read them right from the CLI.<u></u><u></u></p>
</div>
</blockquote>
<div>
<p class="MsoNormal">Sure it’s possible but also with a big „meh“. Here is how:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">"show interfaces diagnostics optics satellite <interface>“ (<- on the MX)<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">BUT at least with MX Junos 16.1R7 and aligned SAT Image aka SNOS these values are wrong<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">by a pretty big offset. Juniper promised they already fixed it but we can’t confirm (at least not in MX Junos 16.1).<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Soon we will take a look at MX Junos 17.3 with aligned sat image.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<p class="MsoNormal"> 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<u></u><u></u></p>
</div>
</blockquote>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
</blockquote>
<p class="MsoNormal">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).<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
</div>
</blockquote>
<p class="MsoNormal">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)<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
</div>
</blockquote>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">real reason why fusion should NOT be capable of pushing some mpls labels on already tagged 802.1br packets.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Best regards,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Vincentz<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">—<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">PS: some have received this mail multiple times because I’ve send it from the wrong account … time for vacation I guess.<u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"><br>
<br>
<u></u><u></u></p>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<p class="MsoNormal">Am 17.12.2018 um 19:26 schrieb Matt Erculiani <<a href="mailto:merculiani@gmail.com" target="_blank">merculiani@gmail.com</a>>:<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<div>
<p class="MsoNormal">Fusion has made a lot more sense since Juniper changed the licensing model from every switch AND the MX to just the MX.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal">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.<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Very interested in hearing about other's experiences with Fusion, good, bad, and ugly.<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">-Matt<u></u><u></u></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Mon, Dec 17, 2018 at 12:08 PM Mehmet Akcin <<a href="mailto:mehmet@akcin.net" target="_blank">mehmet@akcin.net</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal">Hey there<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Any ISP using Juniper Fusion Provider Edge? <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"><a href="https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-fusion/junos-fusion.html" target="_blank">https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-fusion/junos-fusion.html</a><u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Any feedback good/bad appreciated. <u></u><u></u></p>
</div>
<p class="MsoNormal">-- <u></u><u></u></p>
<div>
<p class="MsoNormal">Mehmet<br>
+1-424-298-1903<u></u><u></u></p>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
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.
</div>

</blockquote></div></div>