Re: [j-nsp] Moving onto EX2300

[Pavel Lunin]

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 +,
> > 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
> > respec

Re: [j-nsp] Moving onto EX2300

[Chris Morrow]

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

[Jason Healy]

> 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

[Nathan Ward]

> 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

[Gustav Ulander]

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<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 <morr...@ops-netman.net<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 
<morr...@ops-netman.net<mailto:morr...@ops-netman.net>> wrote:

> At Wed, 20 Sep 2017 17:03:21 +,
> Raphael Maunier <raph...@zoreole.com<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 0

Re: [j-nsp] Moving onto EX2300

[Chuck Anderson]

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" <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 +,
> > 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
> > 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 

Re: [j-nsp] Moving onto EX2300

[Pavel Lunin]

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 +,
> 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
> 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

[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 <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 +,
> 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
> 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

[William]

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

[Chris Morrow]

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

[Raphael Maunier]

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

[Chuck Anderson]

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

[Olivier Benghozi]

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

[j-nsp] Moving onto EX2300

[William]

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?

Cheers,

William
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp