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

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

Re: [j-nsp] [JUNK] Re: Moving onto EX2300

On Wed, 20 Sep 2017 20:46:19 -0400, Jason Healy wrote: > > On Sep 20, 2017, at 2:18 PM, Chris Morrow wrote: > > > > I found the 3400's are painfully different from 3300/3200's.. with > > respect to vlans, trunks and access port assignment into said > >

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

Re: [j-nsp] [JUNK] Re: Moving onto EX2300

On Sep 20, 2017, at 2:18 PM, Chris Morrow wrote: > > 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.

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

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

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

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

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

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

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

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

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?

[j-nsp] Moving onto EX2300

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?

Re: [j-nsp] SRX - CPU utilization exceeds

Are you sure? BGP and policy options don't require packet mode to be enabled. What does `show security flow status` show under Inet forwarding mode? From: juniper-nsp on behalf of sameer mughal

Re: [j-nsp] SRX - CPU utilization exceeds

"packet mode" because we are configuring BGP and route map on this device. On Wed, Sep 20, 2017 at 4:37 PM, sameer mughal wrote: > Hi, > Device is working in packet flow. > > On Wed, Sep 20, 2017 at 3:21 PM, Phil Mayers > wrote: > >> Datasheet

Re: [j-nsp] SRX - CPU utilization exceeds

Hi, Device is working in packet flow. On Wed, Sep 20, 2017 at 3:21 PM, Phil Mayers wrote: > Datasheet numbers are often optimistic. > > Is the device forwarding in flow or packet mode? If flow mode, what type > of firewall services (appfw, IDP, etc.) and what is the

Re: [j-nsp] SRX - CPU utilization exceeds

Datasheet numbers are often optimistic. Is the device forwarding in flow or packet mode? If flow mode, what type of firewall services (appfw, IDP, etc.) and what is the session rate like? What does the bytes/packet distribution look like? On 19 September 2017 08:47:51 WEST, sameer mughal