Re: [j-nsp] Opinions on fusion provider edge
hey, Yep, Juniper told us at the time that Fusion was based on open standards (802.1BR) and not proprietary in any way. Funny how they don't support the use of any other 802.1BR complaint device and, I doubt it would work. They must have some property gubbins in there like pushing the Fusion firmware blob from the aggregation device to the satellite device. If the Fusion firmware wasn't on the QFX the MX and QFX wouldn't "bond". Not sure how the MX detects that (LLDP?) - I had a (albeit quick) look at the standard back then and couldn't seen anything related, so I presume an MX AD would reject a random 802.1 BR compatible device. Well, the 802.1BR part might very well be standard. But it does not cover functionality like loading the software to port extender, discovery etc. This is proprietary and as a result makes the whole thing vendor specific. Funny enough, they do use standards to implement this functionality (why reinvent the wheel?). One vendor I know creates internal VRF with DHCP server to boot up and manage port extenders. -- tarko ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Licenses needed for inline J-Flow
Hmmm, I just recently turned on inline jflow on my mpc7e-mrate in a MX960, and I don’t think I did anything with a license. Aaron Hi Aaron, that's correct. It works without installing a license. As Nick stated, they're trust-based. Regards, Alex On Nov 7, 2018, at 3:49 PM, Alex D. wrote: Hi, i would like to use inline J-Flow on MX480 routers with a mix of MPC2E-NG and MPC7E-MRATE. I found the following licenses that might fit: S-JFLOW-CH-MX480 S-ACCT-JFLOW-CHASSIS S-ACCT-JFLOW-IN I'm wondering which license i have to buy ? Can someone explain the differences ? Regards, Alex ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Opinions on fusion provider edge
On Thu, 8 Nov 2018 at 20:33, James Bensley wrote: > Yep, Juniper told us at the time that Fusion was based on open standards > (802.1BR) and not proprietary in any way. Funny how they don't support the > use of any other 802.1BR complaint device and, I doubt it would work. They > must have some property gubbins in there like pushing the Fusion firmware > blob from the aggregation device to the satellite device. If the Fusion > firmware wasn't on the QFX the MX and QFX wouldn't "bond". Not sure how the > MX detects that (LLDP?) - I had a (albeit quick) look at the standard back > then and couldn't seen anything related, so I presume an MX AD would reject a > random 802.1 BR compatible device. I would be very surprised if they said 'not proprietary in any way', I'm sure they said 'based on open standards'. But that's like saying whatsapp is based on open standards, entirely true, but it's also hella proprietary, these statements are not mutually exclusive. Curiously Fusion seems to be 'expensive' feature, as it's one of the very few features which do not work with 'hyper-mode', which according to my co-worker's very recent test is ~25% pps upside. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Opinions on fusion provider edge
On 8 November 2018 14:23:02 GMT, Tarko Tikan wrote: >hey, > >> There is >> nothing wrong with layer 2 aggregation switches in my opinion, the >> only technical advantage in my opinion to using SP Fusion for a layer >> 1 extension to a router compared to a layer 2 switch is that SP >Fusion >> is one device to configure and monitor instead of two. > >Except that it's not L1. It's still L2 with 802.1BR (or vendor >proprietary version of that). Yep, Juniper told us at the time that Fusion was based on open standards (802.1BR) and not proprietary in any way. Funny how they don't support the use of any other 802.1BR complaint device and, I doubt it would work. They must have some property gubbins in there like pushing the Fusion firmware blob from the aggregation device to the satellite device. If the Fusion firmware wasn't on the QFX the MX and QFX wouldn't "bond". Not sure how the MX detects that (LLDP?) - I had a (albeit quick) look at the standard back then and couldn't seen anything related, so I presume an MX AD would reject a random 802.1 BR compatible device. >You highlight the exact reasons why one should stay away from >fusion/fex/satellite - features must explicitly be >ported/accommodated/tested for them. Not all performance data is >available, OAM/CFM is a struggle etc. Agreed. Cheers, James. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Opinions on fusion provider edge
hey, There is nothing wrong with layer 2 aggregation switches in my opinion, the only technical advantage in my opinion to using SP Fusion for a layer 1 extension to a router compared to a layer 2 switch is that SP Fusion is one device to configure and monitor instead of two. Except that it's not L1. It's still L2 with 802.1BR (or vendor proprietary version of that). You highlight the exact reasons why one should stay away from fusion/fex/satellite - features must explicitly be ported/accommodated/tested for them. Not all performance data is available, OAM/CFM is a struggle etc. -- tarko ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Opinions on fusion provider edge
On Wed, 7 Nov 2018 at 13:03, Antti Ristimäki wrote: > Wrt the original question about possible issues with Fusion, we have faced > quite a many. Currently one of the biggest pains is to get CoS configured > properly on Fusion ports. We have a case open, where any CoS scheduler change > stops traffic forwarding out from the cascade port, if one has explicitly > configured schedulers for the cascade port logical control (32769) and data > (32770) units. This is pretty irritating, as traffic between the extended > customer facing port and the CE device works just fine, keeping e.g. BGP up > and running, but traffic to/from the core does not work. > > I'm also somewhat concerned about the fact that the whole Fusion thing is > more or less a black box and as such much more difficult to debug than > traditional technologies. > > From monitoring point of view it also a bit challenge that not all > information related to satellite ports is not available via SNMP. E.g. queue > specific counters are not available but have to be queried via CLI command, > and IIRC also ifOutDiscards is not recorded for the extended ports. My experiences with SP Fusion so far have been to add more ports to routers in a cost effective manner. Filling a chassis with 1G/10G ports isn't super cost efficient as line cards are expensive and ports are rarely run near 100% utilisation for an extended period of time, so it makes for a poor ROI. At $job-1 we went down the road of using SP Fusion as a layer 1 extension to PEs, using a 40G uplinks to the router as the aggregation link. Operators have been doing this for years using dumb layer 2 switches as a layer 2 extension. There is nothing wrong with layer 2 aggregation switches in my opinion, the only technical advantage in my opinion to using SP Fusion for a layer 1 extension to a router compared to a layer 2 switch is that SP Fusion is one device to configure and monitor instead of two. Unless we had deployed thousands of aggregation + satellite devices it's not really having any major positive impact on my monitoring licensing costs thought. Equally when using a typical router + layer 2 switch extension, the config that goes into the layer 2 switch is so basic, touching two devices instead of one again seems like a negligible disadvantage to me. The benefit we had from SP Fusion is that, and I'm guessing here, is that Juniper wanted guinea pigs; they sold us QFX5100s as SP Fusion devices plus line cards for the MX's for cheaper than we could buy line cards + EXs, and guinea pigs we were. It took quite a bit of effort to get the QFXs onto the correct code version in stand alone mode. We also had to upgrade our MXs to 17.1 (this was not long after it's release) and use the then new RE-64s because we needed HQoS over Fusion and this was the only way it was supported. It was then more hassle to get the QFXs to migrate into Fusion mode and download their special firmware blob from the MXs. We had to get JTAC to help us and even they struggled. Another issue is that we were a heavy users of Inter-AS MPLS option B's and they aren't supported over SP Fusion links. There is technically no reason why it wouldn't work, as Fusion is a layer 1 extension, however, Inter-AS Opt B isn't one of the features they test when releasing new Fusion code versions, so it's officially unsupported, so we still had to deploy EX's for Opt B links. A colleague of mine worked on a separate project which was a DC Fusion deployment and similar issues and it took him a lot of headache and JTAC assistance to get that deployment working. In my current $job we have/had a QFX switch stack in the office (so nothing to do with Fusion) at that has been very troublesome. As per some of the other threads on this list we've had lots of problems with QFX switches and certain optics not working, either in stacked mode or on certain code versions. Again, this went to JTAC, they couldn't fix it, eventually we fixed it by trying various different code versions and breaking the stack out. So overall, not impressed with the QFX5100s at all. Cheers, James. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
