Re: [j-nsp] SRX Dynamic Address limits

[Chris Lee via juniper-nsp]

Hi Eric,

Thanks for that, not too sure where the dynamic lists are stored in RAM or
some other onboard memory.

That said I ended up loading the lists in a srx340 first which is pretty
similar anyway and couldn't see any issues so went ahead and loaded on the
srx345's and it looks fine so far, I was a little out with my counts anyway
as the lists I'm feeding are v4/v6 so the split ended up less than 20k v4
and less than 10k v6.

Instance Name  : default
Total number of IPv4 entries   : 18226
Total number of IPv4 entries from feed : 17258
Total number of IPv6 entries   : 9733
Total number of IPv6 entries from feed : 9518

I just found another reference at
https://www.juniper.net/documentation/us/en/software/junos/security-policies/topics/topic-map/security-policy-configuration.html
which has a table of the various models and suggest the srx345 can only
have 2048 address objects per policy, which is a bit confusing from the
previous link but that was referring to address-sets I think.

In any case this article seems to suggest to me the policy memory usage is
definitely just loaded into regular RAM, and from what I've seen there was
a little bit of an uptick in memory usage but only by a couple of hundred
MB, just a few percentage points in the overall usage on the RE that I can
see, so doesn't look to be an issue.

I do have a pair of srx1600's on order to swap out the 345's, I just
realised the datasheet doesn't list how much RAM they ship with as was
mostly looking at them from the point of view of more throughput on
interfaces, but hopefully they have been a bit more generous on the memory
modules in the 1600's.

Thanks,
Chris


On Sat, Mar 2, 2024 at 1:51 AM Eric Harrison 
wrote:

>
> I don't know if this is relevant or not in regards to the srx345, but I
> recently stress tested a srx4100 and started to notice some
> anomalies around 64k prefixes. I don't recall anything being logged and it
> reported that it loaded all >=64k prefixes, "show security match-policies"
> gave the right answers, but some actual test traffic started to be logged
> on an unexpected policy.  Opening a ticket is on the TODO list.
>
>
> One of our production srx4100's currently has 53k dynamic IPv4 prefixes
> w/o skipping a beat:
>
> > show security dynamic-address summary
> .
> Instance Name  : default
> Total number of IPv4 entries   : 232848
> Total number of IPv4 entries from feed : 53445
> Total number of IPv6 entries   : 0
> Total number of IPv6 entries from feed : 0
>
>
> -Eric
>
>
> On Fri, Mar 1, 2024 at 5:11 AM Chris Lee via juniper-nsp <
> juniper-nsp@puck.nether.net> wrote:
>
>> Hi All,
>>
>> Does anyone know if there's any specific limits/bounds/impacts on the
>> number of IP addresses that can be imported into a SRX Dynamic Address
>> list, specifically for an SRX345 ?
>>
>>
>> https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/dynamic-address.html
>>
>> Have been trialling it for a little while now with a relatively small
>> number (around 3000 IPv4 and 1200 IPv6 entries), but looking to do some
>> further GeoIP restrictions which would likely be around another 22000 IPv4
>> entries I need to import for the specific countries I need. Will anything
>> topple/break with that many IP's in various dynamic lists ?
>>
>> I've tried looking but my google-fu is failing to turn up any data on
>> limitations anywhere... I've found reference to address sets "One address
>> set can reference a maximum of 16384 address entries and a maximum of 256
>> address sets." but I'm not sure that this applies to dynamic address list
>> entries as I figure that restriction may have more to do with the SRX
>> having to parse a massive configuration file ?
>>
>> Thanks,
>> Chris
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>
>
> --
> Eric Harrison
> Network Services
> Cascade Technology Alliance / Multnomah Education Service District
> office: 503-257-1554   cell: 971-998-6249   NOC 503-257-1510
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] SRX Dynamic Address limits

[Chris Lee via juniper-nsp]

Hi All,

Does anyone know if there's any specific limits/bounds/impacts on the
number of IP addresses that can be imported into a SRX Dynamic Address
list, specifically for an SRX345 ?

https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/dynamic-address.html

Have been trialling it for a little while now with a relatively small
number (around 3000 IPv4 and 1200 IPv6 entries), but looking to do some
further GeoIP restrictions which would likely be around another 22000 IPv4
entries I need to import for the specific countries I need. Will anything
topple/break with that many IP's in various dynamic lists ?

I've tried looking but my google-fu is failing to turn up any data on
limitations anywhere... I've found reference to address sets "One address
set can reference a maximum of 16384 address entries and a maximum of 256
address sets." but I'm not sure that this applies to dynamic address list
entries as I figure that restriction may have more to do with the SRX
having to parse a massive configuration file ?

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

Re: [j-nsp] Junos 21+ Killing Finger Muscle Memory...

[Chris Lee via juniper-nsp]

Hi Jeff,

Any chance the CLI could make use of repeated presses of the TAB key to
cycle through the completion options ?

For instance in the newer 21.x release for EX switches I note a
"synchronous-ethernet" option under the show level, and my muscle memory
for "show system" was reduced down to "show sy" - so could the CLI say show
the "sy is ambiguous" option upon the first TAB press, but when you press
TAB again it then autocompletes "synchronous-ethernet" and another TAB
press to autocomplete "system" ?

root> show sy
 ^
'sy' is ambiguous.
Possible completions:
  synchronous-ethernet  Show synchronous ethernet related information
  system   Show system information
{master:0}
root>

Regards,
Chris

On Wed, Jul 12, 2023 at 11:45 PM Jeff Haas via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:

> You don't need to tell my fingers that. __
>
> With the infrastructure as it is, the only "solution" is we stop adding
> things.  Good luck with that.
>
> The general here is the explosion of keywords.  I have about 15 features
> sitting in my backlog that are small things to do to bgp policy.  The
> policy stanza is already a mess.
>
> ... and that's not including the work to let users match on flowspec
> filter components.
>
> The CLI could be taught to not include certain auto-completions as a
> user-profile, locally, with hints from TACACS, etc... but it means we get
> into an inconsistent user experience.
>
> Feel free to spend some collective thinking time on what a "this would
> suck less" solution would look like.  I suspect that the competing opinions
> on what to do will eventually involve a cage fight match.
>
> -- Jeff
>
>
> On 7/12/23, 9:39 AM, "juniper-nsp on behalf of Chris Wopat via
> juniper-nsp"  juniper-nsp-boun...@puck.nether.net> on behalf of
> juniper-nsp@puck.nether.net > wrote:
>
>
> [External Email. Be cautious of content]
>
>
>
>
> Another offender in 21. `protocols bgp` doesn't autocomplete as it did
> since `bgpmcast` was added.
>
>
> me@r-mx304-lab-re1# set protocols bgp?
> Possible completions:
> > bgp BGP options
> > bgpmcast BGP multicast options
>
>
>
>
>
> https://www.juniper.net/documentation/us/en/software/junos/multicast/topics/ref/statement/bgpmcast.html
> <
> https://www.juniper.net/documentation/us/en/software/junos/multicast/topics/ref/statement/bgpmcast.html
> >
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net  juniper-nsp@puck.nether.net>
>
> https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/juniper-nsp__;!!NEt6yMaO-gk!GRWZYDw9dknfYLkcYhOG-D5DqdTOx4pztouooXch-W7lRlj5lUC_M0CkQf0rZBK0JIiXkU_l-ETb8ikzbZEKXVg$
> <
> https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/juniper-nsp__;!!NEt6yMaO-gk!GRWZYDw9dknfYLkcYhOG-D5DqdTOx4pztouooXch-W7lRlj5lUC_M0CkQf0rZBK0JIiXkU_l-ETb8ikzbZEKXVg$
> >
>
>
>
>
> Juniper Business Use Only
> ___
> 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

[j-nsp] Traffic shaping on SRX340

[Chris Lee via juniper-nsp]

--- Begin Message ---
Hi,

We're running an SRX340 in packet mode as a router for customer internet
access on campus, generally providing smaller speed links around
5/10/20/50Mbps symmetric.

We apply a filter to the customers interface on the input and output, with
a policer policy to discard traffic when exceeding the defined
bandwidth limit.

So in the example configuration below, I find that when running a speed
test on the customers IP that the download traffic to them is shaped
nicely, spot on 22Mbps as in the example below, however on the upload test
it's as if the filter as no impact whatsoever and they get 60-70Mbps.

Anyone have any ideas on what I might be doing wrong? JunOS is 18.2R3-S3 in
this case, however this router was previously running a 15 release and we
had the same issue with the filters only seeming to work on the download
and not the upload traffic.

set interfaces ge-0/0/4 unit 3623 description "CUST-INTERNET-ZZZ Internet"
set interfaces ge-0/0/4 unit 3623 vlan-id 3623
set interfaces ge-0/0/4 unit 3623 family inet filter input customer-ZZZ-in
set interfaces ge-0/0/4 unit 3623 family inet filter output customer-ZZZ-out
set interfaces ge-0/0/4 unit 3623 family inet address 192.0.2.133/30

set firewall family inet filter customer-ZZZ-in term allow-icmp from
protocol icmp
set firewall family inet filter customer-ZZZ-in term allow-icmp then accept
set firewall family inet filter customer-ZZZ-in term default then policer
policer-20m
set firewall family inet filter customer-ZZZ-in term default then accept

set firewall family inet filter customer-ZZZ-out term allow-icmp from
protocol icmp
set firewall family inet filter customer-ZZZ-out term allow-icmp then accept
set firewall family inet filter customer-ZZZ-out term default then policer
policer-20m
set firewall family inet filter customer-ZZZ-out term default then accept

set firewall policer policer-20m if-exceeding bandwidth-limit 22m
set firewall policer policer-20m if-exceeding burst-size-limit 625k
set firewall policer policer-20m then discard

Thanks,
Chris
--- End Message ---
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX2300-C-12P PoE issues

[Chris Lee via juniper-nsp]

--- Begin Message ---
Hi Rich,

Thanks for that, LLDP-MED did come into my mind at one point as one of our
EX2300-C's has 10x Axis cameras that all do have LLDP enabled, and this
switch indeed has LLDP and LLDP-MED enabled on all interfaces, but I was
probably a little haphazard in my approach to troubleshooting it since we
were keen to just get it going. I just looked up in the Axis FAQ they do
indeed use it "AXIS products as of today utilize LLDP-MED to further
negotiate power according to IEEE 802.3at when connected to a 30W PoE+
switch."

Will keep that in mind if this comes up again that we could try disable
LLDP-MED, otherwise I'm just as happy to manually configure the PoE as
static on all ports.

I did try lab this up yesterday on a EX2300-C to simulate it, all I could
gather was 9x Meraki MR18 and 1x Meraki MR42 access points, and found that
the MR18's all join as Class 0 devices, and the MR42 as Class 4 device, and
all 10x WAP's would boot up from PoE (even though there was 9x 15.4W max
power across the MR18 ports and 1x 30W max power on the MR42 port) and
similarly after rebooting the switch I just couldn't re-create what we'd
seen with the Class 3 PoE cameras.

JTAC's explanation to me was that max power consumption of PoE devices with
class 0 and 4 is calculated by their actual power consumption, whereas
class 3 is calculated by their max power per port if using PoE management
by class.

Your LLDP-MED explanation does make more sense to me however as that
appeared to be what I was seeing where we still weren't quite at the max
PoE budget and at least one or two more cameras should have come online by
my calculations but wouldn't which must be that additional ~10% reserve
keeping it offline.

Cheers
Chris

On Sat, Sep 21, 2019 at 3:15 AM Richard McGovern 
wrote:

> Chris what is actually happening here is not so much class setting but
> LLDP/LLDP MED.  By default EX switches support LLDP MED POE-Negotiation,
> and use this method 1st.  So whatever wattage the external device requests
> is taken into the total power budget.  Once the switch calculation for
> these reaches max POE for the switch, no additional POE power will be
> provided.  This is even if the device pulls much less power than it
> negotiated for or asked for.  The switch needs to reserve that power
> calculation as a 'just in case'.  We actually reserve more than the value
> with LLDP MED tlv, to account for potential cable loss; this is
> approximately 10% more.
>
> So if you disable LLDP MED, then class value will take over, and there is
> no need to set static.  Of course setting static is always an option, and
> if set that value is used regardless of other settings.
>
> FYI only, Rich
>
> Richard McGovern
> Sr Sales Engineer, Juniper Networks
> 978-618-3342
>
> I’d rather be lucky than good, as I know I am not good
> I don’t make the news, I just report it
>
>
> On 9/5/19, 8:49 PM, "Chris Lee"  wrote:
>
> For the benefit of the archives have found a solution for this, it
> appears
> to come down to power budgets and defaults of class based PoE
> management.
> Have never noticed this before as on all our 24-port EX2300 and 48-port
> EX3400 and 4300's there's always at least sufficient total power
> budget to
> allocate 15.4 watts across every interface.
>
> So class 3 devices allocated 15.4watts of power theoretically means you
> could effectively only have 9x class 3 ports power up with a total of
> 138.6
> watts, unfortunately I currently don't have enough class 3 PoE devices
> in
> the lab to fully test this theory, and what I saw in the field was the
> switch would only provide power to the first 7x ports even though
> there was
> still sufficient power remaining to allocate 2x more ports, maybe it's
> something to do with internal power bank architecture/design or
> additional
> power reserves per class 3 device.
>
> The workaround was to define PoE management type as static and set max
> power for all interfaces to 12 watts, and then the remaining cameras
> interfaces ge-0/0/7 to 9 that previously wouldn't power up all started
> fine
> and are online. Note there's a bit of lag even after committing the
> configuration, seems to take a minute or two for the config change to
> flow
> onto the PoE controller and reflect the change from class to static
> management with max power of 12 watts defined.
>
> z@z> show configuration poe
> management static;
> interface all {
> maximum-power 12;
> }
>
> Regards,
> Chris
>
> On Thu, Sep 5, 2019 at 8:34 PM Chris Lee 
> wrote:
>
> > Hi,
> >
> > Wondering if anyone is successfully running EX2300-C-12P switches
> with at
> > least 8x PoE devices connected ?
> >
> > We've just encountered an issue in the last week across 2 of these
> > switches at different locations with around 10x PoE CCTV cameras
> connected,
> > and only the first 7 

Re: [j-nsp] EX2300-C-12P PoE issues

[Chris Lee via juniper-nsp]

--- Begin Message ---
For the benefit of the archives have found a solution for this, it appears
to come down to power budgets and defaults of class based PoE management.
Have never noticed this before as on all our 24-port EX2300 and 48-port
EX3400 and 4300's there's always at least sufficient total power budget to
allocate 15.4 watts across every interface.

So class 3 devices allocated 15.4watts of power theoretically means you
could effectively only have 9x class 3 ports power up with a total of 138.6
watts, unfortunately I currently don't have enough class 3 PoE devices in
the lab to fully test this theory, and what I saw in the field was the
switch would only provide power to the first 7x ports even though there was
still sufficient power remaining to allocate 2x more ports, maybe it's
something to do with internal power bank architecture/design or additional
power reserves per class 3 device.

The workaround was to define PoE management type as static and set max
power for all interfaces to 12 watts, and then the remaining cameras
interfaces ge-0/0/7 to 9 that previously wouldn't power up all started fine
and are online. Note there's a bit of lag even after committing the
configuration, seems to take a minute or two for the config change to flow
onto the PoE controller and reflect the change from class to static
management with max power of 12 watts defined.

z@z> show configuration poe
management static;
interface all {
maximum-power 12;
}

Regards,
Chris

On Thu, Sep 5, 2019 at 8:34 PM Chris Lee  wrote:

> Hi,
>
> Wondering if anyone is successfully running EX2300-C-12P switches with at
> least 8x PoE devices connected ?
>
> We've just encountered an issue in the last week across 2 of these
> switches at different locations with around 10x PoE CCTV cameras connected,
> and only the first 7 ports (ge-0/0/0 to ge-0/0/6) providing PoE power.
>
> One switch is running JUNOS 15.1X53-D591.1 and the other is JUNOS
> 18.1R3-S7.1.
>
> Both have had the PoE firmware controller update done on them that comes
> with releases beyond 15.1X53-D58 I think it was, which when you look at
> firmware detail the PoE version on chassis is  2.1.1.19.3
>
> I have an active JTAC case open for it, I've done PR Search and can't see
> anything against POE or Power for either of those two releases that relate
> to the EX2300/3400 series.
>
> In both cases the PoE cameras on the end of the line are very low power
> bullet / fixed style cameras only drawing around 3 watts each, and the most
> I've seen reported on show poe controller is around 25 watts power draw
> which is no where near the EX2300-C-12Ps max power budget of 146watts.
>
> If I deliberately disable PoE on an interface like ge-0/0/0, then after a
> minute or so interface ge-0/0/7 will then magically start providing power,
> and as soon as I rollback the config and commit it will revert right back
> to port ge-0/0/7 providing no power, and ge-0/0/0 powering up.
>
> Thanks,
> Chris
>
--- End Message ---
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] EX2300-C-12P PoE issues

[Chris Lee via juniper-nsp]

--- Begin Message ---
Hi,

Wondering if anyone is successfully running EX2300-C-12P switches with at
least 8x PoE devices connected ?

We've just encountered an issue in the last week across 2 of these switches
at different locations with around 10x PoE CCTV cameras connected, and only
the first 7 ports (ge-0/0/0 to ge-0/0/6) providing PoE power.

One switch is running JUNOS 15.1X53-D591.1 and the other is JUNOS
18.1R3-S7.1.

Both have had the PoE firmware controller update done on them that comes
with releases beyond 15.1X53-D58 I think it was, which when you look at
firmware detail the PoE version on chassis is  2.1.1.19.3

I have an active JTAC case open for it, I've done PR Search and can't see
anything against POE or Power for either of those two releases that relate
to the EX2300/3400 series.

In both cases the PoE cameras on the end of the line are very low power
bullet / fixed style cameras only drawing around 3 watts each, and the most
I've seen reported on show poe controller is around 25 watts power draw
which is no where near the EX2300-C-12Ps max power budget of 146watts.

If I deliberately disable PoE on an interface like ge-0/0/0, then after a
minute or so interface ge-0/0/7 will then magically start providing power,
and as soon as I rollback the config and commit it will revert right back
to port ge-0/0/7 providing no power, and ge-0/0/0 powering up.

Thanks,
Chris
--- End Message ---
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] QFX5100 System Process SNMP monitor

[Chris Lee via juniper-nsp]

Hi Dale

Thanks you are spot on, I ended up finding hrSystemProcesses inside the
rfc2790a MIB and was able to get exactly what I needed into PRTG

Thanks
Chris

On Sun, 20 May 2018 at 18:48, Dale Shaw <dale.shaw+j-...@gmail.com> wrote:

> Hi Chris,
>
>
> On Sun, 20 May 2018 at 1:01 pm, Chris Lee via juniper-nsp <
> juniper-nsp@puck.nether.net> wrote:
> >
> > Hi all,
> >
> > We recently hit a jdhcpd bug in our QFX5100 VC (14.1X53-D30 release)
> which
> > looks to be from the number of defunct zombie processes increasing over
> > time leading up to an ungraceful failover of the routing engines.
> >
> > I have LibreNMS monitoring the QFX and it automagically graphs the
> running
> > process count, but I'm struggling to figure out an SNMP MIB object number
> > that gives me the same process count, as I'd like to monitor the same
> value
> > in our existing PRTG installation to send email/SMS alerts when certain
> > thresholds are reached until we can follow JTAC's recommendation to
> upgrade
> > the QFX release to D46.
> >
> > I've downloaded the MIB pack from Juniper and tried grepping the files
> for
> > "process" and "processes" but can't seem to find anything relevant.
> >
> > Anyone familiar with the SNMP on the QFX know where I might find total
> > system process count ?
>
> Junos implements HOST-RESOURCES-MIB, so you should be able to poll the
> "hrSystemProcesses" object (gauge). Maybe that's how LibreNMS is doing it?
>
> admin@gw> show snmp mib walk hrSystemProcesses
> hrSystemProcesses.0 = 125
>
> admin@gw> show system processes summary
> last pid: 40910;  load averages:  0.20,  0.19,  0.17  up 29+08:45:43
> 08:45:48
> 126 processes: 18 running, 95 sleeping, 1 zombie, 12 waiting
> [...]
>
> Cheers
> Dale
>
>
> >
> >
> > Thanks,
> > 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

[j-nsp] QFX5100 System Process SNMP monitor

[Chris Lee via juniper-nsp]

Hi all,

We recently hit a jdhcpd bug in our QFX5100 VC (14.1X53-D30 release) which
looks to be from the number of defunct zombie processes increasing over
time leading up to an ungraceful failover of the routing engines.

I have LibreNMS monitoring the QFX and it automagically graphs the running
process count, but I'm struggling to figure out an SNMP MIB object number
that gives me the same process count, as I'd like to monitor the same value
in our existing PRTG installation to send email/SMS alerts when certain
thresholds are reached until we can follow JTAC's recommendation to upgrade
the QFX release to D46.

I've downloaded the MIB pack from Juniper and tried grepping the files for
"process" and "processes" but can't seem to find anything relevant.

Anyone familiar with the SNMP on the QFX know where I might find total
system process count ?

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

Re: [j-nsp] What is your experience with the EX2200

[Chris Lee via juniper-nsp]

On Tue, Dec 12, 2017 at 2:29 AM, Kevin Day  wrote:

> The problems with the EX2300 I've seen:
>
> * The out-of-the-box version of Junos on them has a clock bug where it
> says its NTP synced, but the system clock gets advanced to 2038 and things
> go crazy. It's sometimes difficult to keep the switch running long enough
> to upgrade it.
>

Yep hit this bug several times but was hard to pinpoint an exact cause,
sometimes it seemed to be worse if I'd powered the switch up and left it
for a while before loading the initial config. After a while I found that
manually setting the time to within a few minutes of correct local time and
rebooting the switch that it would be enough to get the new image deployed.


> * It's also painfully slow to reboot, but not quite as bad as the EX2200.
>

Yeah was equally disappointed to see that boot times hadn't improved any
over the EX2200, in my experience both platforms take a full 5 minutes to
boot and start forwarding traffic.


> * Some old half-duplex devices don't negotiate with the EX2300, but work
> with the EX2200. It's improved with later builds, but not perfect.
>

We similarly had issues with old model Gallagher cardax controllers not
properly negotiating on the EX2300, they used to negotiate themselves to
10Mbps Half-Duplex on the old Cisco 3750 switches just fine, took a bit of
trial and error on the EX2300 configs to work out to just set the port to
10Mbps Full-Duplex with no auto-negotiate and no flow-control and they show
up as working at 10Mbps Full Duplex now.

>
> Overall neither switch has had bad enough issues that I'd shy away from
> them. The 2300 is definitely an upgrade that I'm happy with.
>

Agreed, although the need to purchase a "paper" licence for the 2300 just
to enable virtual-chassis when it was otherwise standard on the EX2200
seems to be a step backwards as well, I'm having to store a whole heap of
envelopes with the paper licence to apparently prove the right to use that
feature.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX3400 experiences / software recommendation

[Chris Lee via juniper-nsp]

On Wed, Dec 6, 2017 at 6:32 PM, Gert Doering  wrote:

> On Tue, Dec 05, 2017 at 09:07:25PM +0100, Gert Doering wrote:
> > quick question about the EX3400 series... is one of you using them in
> > earnest, and can recommend a software version?
>
> Thanks for your feedback - and I find this interesting, that all replies
> I got was "we use D56 and it is fine".
>
> > One of my customers was sold four of them, and we see "funny things"
> > (like, switch ports only forwarding ARP packets but no IP, bunch of
> > copper GE ports going down and back up simultaneously with nobody
> > near the box, untypical things in logs...) and "common wisdom" hints
> > at "you want a more recent software version".
>
> I found PR1282438 in the meantime, fixed in D57 - which matches one of
> the funny explosions we saw.  Configured new VLAN, removed other VLAN
> from some trunks at the same commit, and afterwards the switches acted
> up extremely weird until I gave up and reloaded...
>

We've got around 22x EX3400's running D55.5.. we use Space and Network
Director however to deploy port profiles, and had no end of trouble
initially with the schema in Space for D55.5 where we couldn't deploy a
port profile in Network Director which had PoE set to enabled. From memory
this also impacted the EX2300's which run the same code base.

Eventually JTAC issued us a new schema file to import in Space and it's
been good since, however last I tried upgrading an EX3400 switch to D56 I
found the same issue in Space being unable to deploy a port profile with
PoE so rolled back to D55.5

I just read about PR1282438 last week also and it sounds very concerning,
the weird thing being, touch wood, I can't recall encountering this in
production yet and have done a lot of VLAN changes! The only thing I can
think of is whether deploying a VLAN change through Network Director where
I do the bulk of changes hasn't trigged this bug yet? Can't think that I've
done a manual VLAN edit/deploy in the CLI post the initial config.

But otherwise so far D55.5 has been reasonably stable for us (again, touch
wood!)

Either way I'm tempted to stage a switch with D57 and have a crack at
upgrading it and checking if I have any schema/port profile deployment
issues in Space... and then I know our Space/ND install also could probably
do with some updates as well, but having spent the first 3 months of this
year working with JTAC on squashing the port profile duplication bugs we
hit during the last upgrade I haven't been in any great hurry to move
forward on that front either.

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

[j-nsp] RSTP best practices on ELS switching (EX2300/3400/4300)

[Chris Lee via juniper-nsp]

Hi All,

Interested to know what others have as their RSTP best practice setups for
access-layer switches in the ELS platform, specifically EX2300/3400/4300's

Until today I had thought that having defined my access interfaces (to end
devices like PC's/printers etc) with "edge" and "no-root-port" was offering
protection from people plugging in random stuff like other switches.

After some more research it looks like I should probably be defining
bpdu-block-on-edge,so interested to know if others are defining this along
with a disable-timeout setting like 5 minutes, or do you not generally
bother with a disable-timeout and manually clear these if they occur ?

Options I'm looking at defining :-

[edit protocols]
+   layer2-control {
+   bpdu-block {
+   disable-timeout 300;
+   }
+   }
[edit protocols rstp]
+   bpdu-block-on-edge;

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