Re: [j-nsp] Moving onto EX2300
Ups, this was supposed to be on-list. : 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 > *Kopia:* juniper-nsp ; Chris Morrow < > morr...@ops-netman.net>; William > *Ämne:* Re: [j-nsp] Moving onto EX2300 > > > > VRs on a basic enterprise access switch? You guys are really crazy. > > > > "Gustav Ulander" : > > 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 > 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 > wrote: > > > At Wed, 20 Sep 2017 17:03:21 +, > > Raphael Maunier 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 wi
Re: [j-nsp] Moving onto EX2300
On Wed, 20 Sep 2017 22:29:44 -0400, Jason Healy wrote: > > > > On Sep 20, 2017, at 10:10 PM, Chris Morrow wrote: > > > > man.. I'd like to take a gander at your setup.. because I'm fairly > > certain I'm going to send this 3400 back and work out my anger on some > > firewood. :) > > Mail it my way; I'd be happy to have a spare! I probably have a few > 3200s left for trade. ;-) > ha :) > I misread your earlier email; yes, you would need an irb as the L3 > interface for management where you previously used a vlan... a find > and replace should take care of that, though. > ah! ok, so... that's a bit of a bummer, I didn't see this sort of thing documented in the release-notes, though I admit to quick-skim :( I suppose I'm really opposed to a mounds turning into an almond joy on me without pretty clear notice. > I haven't bumped into the "default VC" port issue yet, but I guess I > was lucky and chose xe-0/2/3 as my uplink. > our standard config was 0 & 1 .. so we just went with that :( good thing there's a 2 & 3 though :) > We had some growing pains when we got a QFX5100 for our all-EX > network and had to adjust to the ELS stuff. "port" became > "interface", "vlan" became "irb", etc. Plus they moved a bunch of > stuff around. > I think we don't actually do the ELS functions, and at other places i've run into the QFX I hadn't notice this problem either, but... I also don't deploy switch stacks (voodoo!) and we happen to treat the qfx more like a tiny router ... that has a slew of lan ports :( > Juniper does have a conversion tool where you dump in your non-ELS > config and it will output the ELS version (requires JTAC login). It > wasn't perfect, but if you work through it by hand you can figure most > of it out: > > > https://www.juniper.net/customers/support/configtools/elstranslator/index.jsp > ok, cool.. this would be handy for 'not this time' switch installs :) I think I'll also just update my 'make me a switch!' script to just do the right thing here... we were over eager and tried to mangle the config by hand.. oops. > Since we did the QFX a couple years ago, once the 3400s, I was > familiar enough that it wasn't a huge deal. > > The commit script I wrote lets you put stuff like this in the config: > > interfaces { > ge-0/0/0 { > apply-macro sa-portrole { > role static; # or trunk/dot1x > vlan some-vlan; > } > } > } > oh,that's pretty neat.. i think we just whack on the port types with an apply-group choice (and then add the vlan, of course). I tried to keep the ports 'simple': TRUNK-PORT -> carry all vlans, used to link to the core. EDGE-PORT -> connect hosts, don't trunk... we aren't 100% that simple, but.. mostly :) > I just finished that last month, so I'm still rolling it out. Happy > to share if you think it will help. Unfortunately, it won't paper > over the other ELS differences for you; just the stuff dealing with > VLANs, trunk/access, STP, and dot1x. > ah. .I'll see how the now-working-ports 3400 fares, hopefully less headaches than so far ;) thanks! (for also making me re-think and find the other ports solution) -chris ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Moving onto EX2300
> On Sep 20, 2017, at 10:10 PM, Chris Morrow wrote: > > man.. I'd like to take a gander at your setup.. because I'm fairly > certain I'm going to send this 3400 back and work out my anger on some > firewood. :) Mail it my way; I'd be happy to have a spare! I probably have a few 3200s left for trade. ;-) I misread your earlier email; yes, you would need an irb as the L3 interface for management where you previously used a vlan... a find and replace should take care of that, though. I haven't bumped into the "default VC" port issue yet, but I guess I was lucky and chose xe-0/2/3 as my uplink. We had some growing pains when we got a QFX5100 for our all-EX network and had to adjust to the ELS stuff. "port" became "interface", "vlan" became "irb", etc. Plus they moved a bunch of stuff around. Juniper does have a conversion tool where you dump in your non-ELS config and it will output the ELS version (requires JTAC login). It wasn't perfect, but if you work through it by hand you can figure most of it out: https://www.juniper.net/customers/support/configtools/elstranslator/index.jsp Since we did the QFX a couple years ago, once the 3400s, I was familiar enough that it wasn't a huge deal. The commit script I wrote lets you put stuff like this in the config: interfaces { ge-0/0/0 { apply-macro sa-portrole { role static; # or trunk/dot1x vlan some-vlan; } } } I just finished that last month, so I'm still rolling it out. Happy to share if you think it will help. Unfortunately, it won't paper over the other ELS differences for you; just the stuff dealing with VLANs, trunk/access, STP, and dot1x. Jason ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Moving onto EX2300
> On 21/09/2017, at 4:16 AM, William wrote: > > Hi list, > > We currently have the EX2200-48P deployed across our building in various > stacks/non stacks and it has served us well, abit slow to commit in a stack > but still been ok! > > Due to the ex2200 going eol/eos we are looking at the EX2300 - can anyone > share their experience with this model? Anything to watch out for? We use them as management network switches and use private VLANs for isolation. These have been on the EX2200 since a software update a while back. These are not on the EX2300 yet as far as I’m aware (and like the EX2200 early on no indication that they will be), so if you use private VLANs you may want to stick with the EX2200. I don’t see any details on the Juniper site about the EX2200 EOL. Where are you seeing that? -- Nathan Ward ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Moving onto EX2300
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 Kopia: juniper-nsp ; Chris Morrow ; William Ämne: Re: [j-nsp] Moving onto EX2300 VRs on a basic enterprise access switch? You guys are really crazy. "Gustav Ulander" mailto: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<mailto:juniper-nsp-boun...@puck.nether.net>] För William Skickat: den 20 september 2017 21:10 Till: Chris Morrow mailto:morr...@ops-netman.net>> Kopia: juniper-nsp@puck.nether.net<mailto: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 mailto:morr...@ops-netman.net>> wrote: > At Wed, 20 Sep 2017 17:03:21 +, > Raphael Maunier mailto: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 > ChassisNX0217020007 EX3400-48T > Pseudo CB 0 > Routing Engine 0 BUILTIN BUILTIN RE-EX3400-48T > FPC 0REV 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,
Re: [j-nsp] Moving onto EX2300
I don't normally rely on VRs on my access layer devices, but it comes in handy once in a while for troubleshooting to add a l3-interface to a VLAN, but keep the routing separate from the in-band management VLAN. For this I use a routing-instance of instance-type virtual-router. I can then use "ping routing-instance FOO ...". On Wed, Sep 20, 2017 at 09:30:32PM +0200, Pavel Lunin wrote: > VRs on a basic enterprise access switch? You guys are really crazy. > > "Gustav Ulander" : > > 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 > 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 wrote: > > > At Wed, 20 Sep 2017 17:03:21 +, > > Raphael Maunier 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 > > ChassisNX0217020007 EX3400-48T > > Pseudo CB 0 > > Routing Engine 0 BUILTIN BUILTIN RE-EX3400-48T > > FPC 0REV 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
Re: [j-nsp] Moving onto EX2300
VRs on a basic enterprise access switch? You guys are really crazy. "Gustav Ulander" : 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 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 wrote: > At Wed, 20 Sep 2017 17:03:21 +, > Raphael Maunier 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 > ChassisNX0217020007 EX3400-48T > Pseudo CB 0 > Routing Engine 0 BUILTIN BUILTIN RE-EX3400-48T > FPC 0REV 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
Re: [j-nsp] Moving onto EX2300
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 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 wrote: > At Wed, 20 Sep 2017 17:03:21 +, > Raphael Maunier 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 > ChassisNX0217020007 EX3400-48T > Pseudo CB 0 > Routing Engine 0 BUILTIN BUILTIN RE-EX3400-48T > FPC 0REV 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
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 wrote: > At Wed, 20 Sep 2017 17:03:21 +, > Raphael Maunier 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 > ChassisNX0217020007 EX3400-48T > Pseudo CB 0 > Routing Engine 0 BUILTIN BUILTIN RE-EX3400-48T > FPC 0REV 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
Re: [j-nsp] Moving onto EX2300
At Wed, 20 Sep 2017 17:03:21 +, Raphael Maunier 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 ChassisNX0217020007 EX3400-48T Pseudo CB 0 Routing Engine 0 BUILTIN BUILTIN RE-EX3400-48T FPC 0REV 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
Re: [j-nsp] Moving onto EX2300
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 On 20/09/2017, 18:01, "juniper-nsp on behalf of Chuck Anderson" wrote: Is virtual-router at least supported if not full VRF? On Wed, Sep 20, 2017 at 05:26:27PM +0100, Olivier Benghozi wrote: > New additional licence needed to stack (VirtualChassis), VRF not supported. > > > On 20 sept. 2017 at 17:16, William wrote : > > > > Due to the ex2200 going eol/eos we are looking at the EX2300 - can anyone > > share their experience with this model? Anything to watch out for? ___ 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] Moving onto EX2300
Is virtual-router at least supported if not full VRF? On Wed, Sep 20, 2017 at 05:26:27PM +0100, Olivier Benghozi wrote: > New additional licence needed to stack (VirtualChassis), VRF not supported. > > > On 20 sept. 2017 at 17:16, William wrote : > > > > Due to the ex2200 going eol/eos we are looking at the EX2300 - can anyone > > share their experience with this model? Anything to watch out for? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Moving onto EX2300
My biggest initial gotcha was the difference between "original" Junos and Junos with "ELS" in the EX2300's. If you haven't gone through it yet http://www.juniper.net/documentation/en_US/junos13.2/topics/task/configuration/getting-started-els.html is worth a read. Matt Freitag Network Engineer Information Technology Michigan Technological University (906) 487-3696 <%28906%29%20487-3696> https://www.mtu.edu/ https://www.mtu.edu/it On Wed, Sep 20, 2017 at 12:26 PM, Olivier Benghozi < olivier.bengh...@wifirst.fr> wrote: > New additional licence needed to stack (VirtualChassis), VRF not supported. > > > On 20 sept. 2017 at 17:16, William wrote : > > > > Due to the ex2200 going eol/eos we are looking at the EX2300 - can anyone > > share their experience with this model? Anything to watch out for? > > ___ > 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] Moving onto EX2300
New additional licence needed to stack (VirtualChassis), VRF not supported. > On 20 sept. 2017 at 17:16, William wrote : > > Due to the ex2200 going eol/eos we are looking at the EX2300 - can anyone > share their experience with this model? Anything to watch out for? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp