Discussion:
[j-nsp] Moving onto EX2300
William
2017-09-20 16:16:36 UTC
Permalink
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-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Olivier Benghozi
2017-09-20 16:26:27 UTC
Permalink
New additional licence needed to stack (VirtualChassis), VRF not supported.
Post by William
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-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Matt Freitag
2017-09-20 16:35:32 UTC
Permalink
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 <
Post by Olivier Benghozi
New additional licence needed to stack (VirtualChassis), VRF not supported.
Post by William
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?
_______________________________________________
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Chuck Anderson
2017-09-20 17:00:53 UTC
Permalink
Is virtual-router at least supported if not full VRF?
Post by Olivier Benghozi
New additional licence needed to stack (VirtualChassis), VRF not supported.
Post by William
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-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Raphael Maunier
2017-09-20 17:03:21 UTC
Permalink
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" <juniper-nsp-***@puck.nether.net on behalf of ***@WPI.EDU> wrote:

Is virtual-router at least supported if not full VRF?
Post by Olivier Benghozi
New additional licence needed to stack (VirtualChassis), VRF not supported.
Post by William
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-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/jun
Chris Morrow
2017-09-20 18:18:58 UTC
Permalink
At Wed, 20 Sep 2017 17:03:21 +0000,
Post by Raphael Maunier
Not supported at all.
According to a meeting last week, hardware limitation $B!D(B 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-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
William
2017-09-20 19:09:43 UTC
Permalink
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
Post by Chris Morrow
At Wed, 20 Sep 2017 17:03:21 +0000,
Post by 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
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
@EX3400-0401> show chassis hardware
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
_______________________________________________
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://
Gustav Ulander
2017-09-20 19:20:14 UTC
Permalink
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-***@puck.nether.net] För William
Skickat: den 20 september 2017 21:10
Till: Chris Morrow <***@ops-netman.net>
Kopia: juniper-***@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
Post by Chris Morrow
At Wed, 20 Sep 2017 17:03:21 +0000,
Post by 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
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
@EX3400-0401> show chassis hardware
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
_______________________________________________
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https
Pavel Lunin
2017-09-20 19:30:32 UTC
Permalink
VRs on a basic enterprise access switch? You guys are really crazy.

"Gustav Ulander" <***@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-***@puck.nether.net] För William
Skickat: den 20 september 2017 21:10
Till: Chris Morrow <***@ops-netman.net>
Kopia: juniper-***@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
Post by Chris Morrow
At Wed, 20 Sep 2017 17:03:21 +0000,
Post by 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
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
@EX3400-0401> show chassis hardware
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
_______________________________________________
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://pu
Chuck Anderson
2017-09-20 19:36:57 UTC
Permalink
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 ...".
Post by Pavel Lunin
VRs on a basic enterprise access switch? You guys are really crazy.
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-----
Skickat: den 20 september 2017 21:10
Ä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
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.
* 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
Post by Chris Morrow
At Wed, 20 Sep 2017 17:03:21 +0000,
Post by 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
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
@EX3400-0401> show chassis hardware
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-***@puck.nether.net
https://puck.nether.net/mailman/
Gustav Ulander
2017-09-20 19:37:03 UTC
Permalink
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:***@gmail.com]
Skickat: den 20 september 2017 21:31
Till: Gustav Ulander <***@telecomputing.se>
Kopia: juniper-nsp <juniper-***@puck.nether.net>; Chris Morrow <***@ops-netman.net>; William <***@gmail.com>
Ämne: Re: [j-nsp] Moving onto EX2300

VRs on a basic enterprise access switch? You guys are really crazy.

"Gustav Ulander" <***@telecomputing.se<mailto:***@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-***@puck.nether.net<mailto:juniper-nsp-***@puck.nether.net>] För William
Skickat: den 20 september 2017 21:10
Till: Chris Morrow <***@ops-netman.net<mailto:***@ops-netman.net>>
Kopia: juniper-***@puck.nether.net<mailto:juniper-***@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
Post by Chris Morrow
At Wed, 20 Sep 2017 17:03:21 +0000,
Post by 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
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
@EX3400-0401> show chassis hardware
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
_______________________________________________
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net<mailto:juniper-***@puck.nether.net> https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net<mailto:juniper-***@puck.nether.net>
https://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nethe
Pavel Lunin
2017-09-21 07:39:52 UTC
Permalink
Ups, this was supposed to be on-list.

<***@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" <
***@telecomputing.se> написал:

I agree it not the best platform but im guessing there are atleast a couple
Post by Gustav Ulander
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
*Skickat:* den 20 september 2017 21:31
*Ämne:* Re: [j-nsp] Moving onto EX2300
VRs on a basic enterprise access switch? You guys are really crazy.
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-----
Skickat: den 20 september 2017 21:10
Ä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
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.
* 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
Post by Chris Morrow
At Wed, 20 Sep 2017 17:03:21 +0000,
Post by 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
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
@EX3400-0401> show chassis hardware
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
_______________________________________________
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.n

Jason Healy
2017-09-21 00:46:19 UTC
Permalink
Post by Chris Morrow
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.
Amen. I've finally written a commit script that allows me to assign roles to ports and then sets the correct config options depending on platform. That's making my life a little easier.
Post by Chris Morrow
this coupled with what seems a requirement to enable an IRB interface
to attach the management ip address to seems ... wonky.
What's this one? I don't remember having to do that part on my switch. That said, I'm currently hunting down some weird disconnect issues on my 3400s so maybe I do...

Jason
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Chris Morrow
2017-09-21 02:10:11 UTC
Permalink
On Wed, 20 Sep 2017 20:46:19 -0400,
Post by Jason Healy
Post by Chris Morrow
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.
Amen. I've finally written a commit script that allows me to assign
roles to ports and then sets the correct config options depending on
platform. That's making my life a little easier.
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. :)
Post by Jason Healy
Post by Chris Morrow
this coupled with what seems a requirement to enable an IRB interface
to attach the management ip address to seems ... wonky.
What's this one? I don't remember having to do that part on my
switch. That said, I'm currently hunting down some weird disconnect
issues on my 3400s so maybe I do...
Since all of our 33/3200's have a mgmt-vlan trunked down to them and
an l3 interface configured like:

# show interfaces vlan unit 1
unit 1 {
description "VLAN 1 (INFRA)";
family inet {
address 192.168.88.150/28;
}
}

and the vlans portion:
INFRA {
description "VLAN 1 (INFRA)";
vlan-id 1;
l3-interface vlan.1;
}


That config doesn't appear to work in the same fashion...
Oh, in dicking around.. it looks like:
FPC 0 REV 14 650-0 NX021 EX3400-48T
CPU BUILTIN IN FPC CPU
PIC 0 REV 14 BUILTIN IN 48x10/100/1000 Base-T
PIC 1 REV 14 650-0 NX02 2x40G QSFP
PIC 2 REV 14 650-0 NX02 4x10G SFP/SFP+
Xcvr 2 REV 01 740-0 FS40 SFP+-10G-LR
Xcvr 3 REV 01 740-0 FS40 SFP+-10G-LR
Power Supply 0 REV 05 640-0 1EDV JPSU-150W-AC-AF

If I put the sfp+'s in slot 0 and 1 ... I can't get packets up the
trunk and to devices downstream to hosts. If I put the sfp+'s in 2 and
3...works like a charm.

So, it smells like the 0 and 1 are 'virtual chassis ports'... even
though i can't unconfigure them from the VC setup?

Now, when I try to revert the IRB to VLAN L3-interface setup, I see
this in config mode:

{master:0}[edit vlans INFRA]
***@EX3400-0401# set l3-interface vlan.1
error: l3-interface: 'vlan.1': Only IRB interface is supported, e.g. irb.10


so... I'm pretty sure i'm not going to be able to have the same config
from 3300->3400 :( unless, of course it's clear I messed something up
to other folk?

-chris
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Jason Healy
2017-09-21 02:29:44 UTC
Permalink
Post by Chris Morrow
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-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Chris Morrow
2017-09-21 03:28:26 UTC
Permalink
On Wed, 20 Sep 2017 22:29:44 -0400,
Post by Jason Healy
Post by Chris Morrow
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 :)
Post by Jason Healy
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.
Post by Jason Healy
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 :)
Post by Jason Healy
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 :(
Post by Jason Healy
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
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.
Post by Jason Healy
Since we did the QFX a couple years ago, once the 3400s, I was
familiar enough that it wasn't a huge deal.
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 :)
Post by Jason Healy
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-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Loading...