Ups, this was supposed to be on-list. <plu...@gmail.com>:
Well in fact it's not really about "removing a feature". Both ex2200 and ex3300 were based on marvell pfe (and control plane cpu as well) while 2300/3400 have broadcom chips inside. If juniper could, they would be happy to reuse the same code. But no. And trust me, you don't want them to even try to rewrite all the features for the new platform at once (hello those who remember the famous ScreenOS to SRX and E series to MX BNG "rapid" migration stories). Not sure, this "hardware limitation" is really that hardware that they won't ever implement it. VRs were added relatively recently to ex2200/3300, while it had been known as "hardware limitation" for many years. Anyway, I won't rely on VRs on this kind of switch both because it implies a clumsy design, and because it is a rarely used feature, poorly tested and generating little market pressure in case of bugs. I am not even sure it's really 100% supported on EX2200/3300, I've recently seen that cross-VR routes just don't work on ex3300, and it seems to be rather a feature than a bug. 20 сент. 2017 г. 9:37 ПП пользователь "Gustav Ulander" < gustav.ulan...@telecomputing.se> написал: I agree it not the best platform but im guessing there are atleast a couple > of implementations out there that use it for one reason or the other. > > Its not so much the feature itself as the hole “lets remove a feature and > not replace it with something similar” that gets me. It shows a lack of > commitment to ones customers. > > To be honest perhaps Juniper shouldn’t have added VRF support on the 2200s > at all and just point to 3300s or SRX line. > > > > //Gustav > > > > *Från:* Pavel Lunin [mailto:plu...@gmail.com] > *Skickat:* den 20 september 2017 21:31 > *Till:* Gustav Ulander <gustav.ulan...@telecomputing.se> > *Kopia:* juniper-nsp <juniper-nsp@puck.nether.net>; Chris Morrow < > morr...@ops-netman.net>; William <wil...@gmail.com> > *Ämne:* Re: [j-nsp] Moving onto EX2300 > > > > VRs on a basic enterprise access switch? You guys are really crazy. > > > > "Gustav Ulander" <gustav.ulan...@telecomputing.se>: > > Yea lets make the customers job harder partly by not supporting old > features in the next incarnation of the platform (think VRF support) . Also > lets not make them work the same so that the customer must relearn how to > configure them. > Excellent way of actually pushing the customer to also look at other > platforms... > > //Gustav > > -----Ursprungligt meddelande----- > Från: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] För William > Skickat: den 20 september 2017 21:10 > Till: Chris Morrow <morr...@ops-netman.net> > Kopia: juniper-nsp@puck.nether.net > Ämne: Re: [j-nsp] Moving onto EX2300 > > > Thanks to all the replies so far! > > Regarding a VC Licence - > https://www.juniper.net/documentation/en_US/junos/topics/ > concept/ex-series-software-licenses-overview.html#jd0e59 > > Here are the features which require a EFL: > > Bidirectional Forwarding Detection (BFD) IGMP (Internet Group Management > Protocol) version 1 (IGMPv1), IGMPv2, and > IGMPv3 > IPv6 routing protocols: Multicast Listener Discovery version 1 and 2 (MLD > v1/v2), OSPFv3, PIM multicast, VRRPv6 Multicast Source Discovery protocol > (MSDP) OSPF v2/v3 Protocol Independent Multicast (PIM) dense mode, PIM > source-specific mode, PIM sparse mode Real-time performance monitoring > (RPM) RIPng (RIPng is for RIP IPv6) Virtual Router Redundancy Protocol > (VRRP) > > Which seems straight forward, but they have this bit at the end - > Note: You require a paper license to create an EX2300 Virtual Chassis. If > you do not have a paper license, contact Customer Support. > > > And looking at the EX2300 packing list: > > * Paper license for Virtual Chassis (only for the models EX2300-C-12T-VC, > EX2300-C-12P-VC, EX2300-24T-VC, EX2300-24P-VC, EX2300-48T-VC, and > EX2300-48P-VC) > > So it appears I may need to ensure i'm ordering EX2300-48P-VC if I want to > stack 'em, I need to check the finer details with Juniper. > > Cheers, > > William > > > On 20 September 2017 at 19:18, Chris Morrow <morr...@ops-netman.net> > wrote: > > > At Wed, 20 Sep 2017 17:03:21 +0000, > > Raphael Maunier <raph...@zoreole.com> wrote: > > > > > > Not supported at all. > > > > > > According to a meeting last week, hardware limitation … EX2200 or > > > 3400 but no support of BGP, if bgp is needed EX3300 / 4300 > > > > > > > I found the 3400's are painfully different from 3300/3200's.. with > > respect to vlans, trunks and access port assignment into said vlans.. > > and actually getting traffic to traverse a trunk port to an access > > port. > > > > this coupled with what seems a requirement to enable an IRB interface > > to attach the management ip address to seems ... wonky. > > > > I don't find the docs online particularly enlightening either :) I > > have a 3300 config, it should 'just work' on a 3400.. I would have > > expected anyway. > > > > also, I don't think you can disable the VC functions in the > > 3400: > > @EX3400-0401> show chassis hardware > > Hardware inventory: > > Item Version Part number Serial number Description > > Chassis NX0217020007 EX3400-48T > > Pseudo CB 0 > > Routing Engine 0 BUILTIN BUILTIN RE-EX3400-48T > > FPC 0 REV 14 650-059881 NX0217020007 EX3400-48T > > CPU BUILTIN BUILTIN FPC CPU > > PIC 0 REV 14 BUILTIN BUILTIN 48x10/100/1000 > > Base-T > > PIC 1 REV 14 650-059881 NX0217020007 2x40G QSFP > > PIC 2 REV 14 650-059881 NX0217020007 4x10G SFP/SFP+ > > Xcvr 0 REV 01 740-021309 FS40531D0014 SFP+-10G-LR > > Xcvr 1 REV 740-021309 FS40531D0015 SFP+-10G-LR > > Power Supply 0 REV 05 640-060603 1EDV6486028 JPSU-150W-AC-AFO > > Power Supply 1 REV 05 640-060603 1EDV7021509 JPSU-150W-AC-AFO > > Fan Tray 0 Fan Module, > > Airflow Out (AFO) > > Fan Tray 1 Fan Module, > > Airflow Out (AFO) > > > > (port xe-0/2/0 and xe-0/2/1 are what I'd like to disable) > > > > @EX3400-0401> request virtual-chassis vc-port delete pic-slot 2 port 0 > > error: interface not a vc-port > > @EX3400-0401> request virtual-chassis vc-port delete pic-slot 2 port 1 > > error: interface not a vc-port > > > > of course, possibly they are not vc-ports, and are only acting like > > 3300 vc ports before I diable VC functionality :) > > > > -chris > > _______________________________________________ > > 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 > _______________________________________________ > 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