Re: [j-nsp] vlan-tagging on ospf interface

[Emille Blanc]

I would expect to have some kind of encapsulation on the interface.
eg; set encapsulation flexible-ethernet-services

-Original Message-
From: jayshankar nair [mailto:n_jayshan...@yahoo.com] 
Sent: Thursday, April 08, 2021 5:46 AM
To: juniper-nsp@puck.nether.net
Subject: vlan-tagging on ospf interface

Hi,
 I have ospf interface ge-0/0/3 on peer routers. I am able to ping from one 
router to other when vlan-tagging is not enabled. When i enable the 
vlan-tagging on peer interface. I am unable to ping. Below is the vlan tagged 
enable configuration. Also the interface is added to ospf protocol
OSPF-MultiArea
jcluser@vMX1# show vlan-tagging;unit 600 {    vlan-id 600;    family inet {     
   address 10.100.12.1/24;    }}--
jcluser@vMX2# show vlan-tagging;unit 600 {    vlan-id 600;    family inet {     
   address 10.100.12.2/24;    }}Please let me know if the configuration is 
right.
Thanks,Jayshankar
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] NCP client licensing

[Emille Blanc]

Good morning folks,

Am wondering if anyone has recently gone through licensing process for an SRX 
with the NCP remote-access license (Eg; SRX-RA1-10 [1])

What I can garner from Juniper documentation, suggests license is included. But 
there's no documented process (I, or that my Juniper reps can find) that covers 
connecting the license to the NCP client itself.
However, assorted NCP readmes suggest we either need a subscription for the 
'Exclusive Entry Client' (yuck), or deploy using the NCP Secure Entry Client - 
which at least has a perpetual license option.

Incidentally, I as recently as last week, attended a Juniper webinar that 
showcased a Juniper branded version of the NCP client.  Presenter stated that 
the client is available for download "After logging in to Juniper website", and 
"that will change to no login required to download, in a couple of weeks."
When I brought up the question about licensing, they declined to provide an 
answer.

Has anyone else been down this fairly rocky road already, and could provide 
some clues?

Thanks in advance.

[1] 
https://www.juniper.net/documentation/en_US/release-independent/licensing/topics/topic-map/understanding-licenses-for-srx-series.html
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SRX300 Sudden Reboot

[Emille Blanc]

What was the reported reboot reason?
You will find that in 'show chassis routing-engine'

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Mohammad Khalil
Sent: Thursday, October 22, 2020 3:13 PM
To: Juniper List
Subject: [j-nsp] SRX300 Sudden Reboot

Greetings
I have SRX300 which is running normally for long time except for the last
two weeks where I have suffered from sudden reboot.
Model: srx300
Junos: 15.1X49-D70.3
JUNOS Software Release [15.1X49-D70.3]

Nothing has been changed or added and nothing in the log messages is
related to this.
As well , no active alrams and temperature levels are fine:
tbzadmin@FW-PB-NEW# run show chassis environment
Class Item   Status Measurement
Temp  Routing Engine OK 45 degrees C / 113 degrees F
  Routing Engine CPU OK 58 degrees C / 136 degrees F
Power Power Supply 0 OK

What could be the issue?

Much appreciated.
___
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] Traffic shaping on SRX340

[Emille Blanc]

Nothing looks out of sorts.
For the sake of testing, if you give the input direction a different policer, 
does it show any hits on 'show policer' output?

Eg;
set firewall family inet filter customer-ZZZ-out term default then policer
policer-20m-TEST

set firewall policer policer-20m-TEST if-exceeding bandwidth-limit 22m
...


-Original Message-
From: Chris Lee [mailto:ch...@datachaos.com.au] 
Sent: Wednesday, October 14, 2020 7:05 PM
To: juniper-nsp@puck.nether.net
Subject: Traffic shaping on SRX340

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
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX routers and DAC cables?

[Emille Blanc]

Though not had any experience with MX's, we were never successful in getting 
DAC's to work with our EX's.
Had to go for optics.
We learned to just not bother with DAC's in future due to off-list anecdotes of 
such behavior - not just with Juniper (HPE, Cisco...)

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Chris Adams
Sent: Friday, June 12, 2020 11:39 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] MX routers and DAC cables?

Is anybody using DAC cables on MX routers?  We have a customer with an
MX10003 connected to EX4600 switches with 40G DAC cables (Juniper parts,
not third-party).  Upon upgrading the router JUNOS to 18.2R3-S3, none of
the interfaces with a DAC cable would come up on the router end.

JTAC's response was that no DAC cables are supported on any MX routers.

That seems a little odd to me... I thought DAC cables are a part of the
various specs, so saying they're not supported is saying those aren't
actually Ethernet ports to me.

-- 
Chris Adams 
___
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] EX2300 Code

[Emille Blanc]

We've not had any issues (so far) with either 15.1X53-D5​1, or 18.2R2.6.
Only using them for L2 distribution or QinQ, though. So your mileage may vary.

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Philippe Girard
Sent: Monday, December 09, 2019 10:48 AM
To: Nelson, Brian; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] EX2300 Code

A note on that.

Not only does the switch stop responding and needs to be power cycled, but in 
our case while this happens uplink ports on a redundant ring bridge BPDUs from 
working switches and you get a nice linerate traffic loop going.

We also use those as OOB management for our MX routers and other gear, and 
without any l2 protection MX starts slipping and drops BGP and other important 
protocols while this happens.

As per TAC recommendation, we've downgraded to the latest 15.X version, been 
stable for about a week.




-Original Message-
From: juniper-nsp  On Behalf Of Nelson, 
Brian
Sent: December 9, 2019 10:46 AM
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] EX2300 Code

If Juniper provides a version which is stable for more that a few weeks let me 
know. I've been chasing version upgrades for months now.

Brian Nelson

On 12/9/19 5:15 AM, William wrote:
> Hi,
>
> I am in the process of getting our first stack of EX2300s ready for 
> production, can anyone recommend any specific versions of junos to run 
> on them?
>
> I'm not taking advantage of any advance features, just after something 
> stable :)
>
> Cheers,
>
> William
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net 
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>


--
Supervisor
Computing Systems Support
Dept of Computer Science

___
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] srx ipsec tunnel over mpls l3vpn

[Emille Blanc]

Based on what you described, it sounds like you already got your MPLS/LDP 
running in a packet-mode routing-instance, as otherwise MPLS is dropped on an 
SRX in flow mode.

No obvious ideas with the output provided otherwise.
Do the flows in your IPSEC instance get created?

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Aaron Gould
Sent: Thursday, July 11, 2019 12:27 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] srx ipsec tunnel over mpls l3vpn

Anyone ever done it ?  To be clear, I have mpls/ldp/ospf/bgp enabled the SRX
such that I have an l3vpn functional into the SRX.

 

I have a lo0.99 interface as the external interface used for ike/ipsec.
Seems that I'm pretty close to getting this done, as i have ike phase 1 up
and ike phase 2 up, but only seeing encrypted packets as I try to ping
between the st0.0 interface and the ms-0/0/0.1 inside interface on the other
side (mx104 with ms-mic-16g)

 

Let me know what I'm missing.

 

I'm seeing drops in these to show outputs. which seems to coincide with a
100-packet ping test...

 

 

root@demo-srx300> show security flow statistics

Current sessions: 9

Packets forwarded: 417926

Packets dropped: 15604

Fragment packets: 0

Pre fragments generated: 0

Post fragments generated: 0

 

root@demo-srx300> show security flow status

  Flow forwarding mode:

Inet forwarding mode: flow based

Inet6 forwarding mode: drop

MPLS forwarding mode: drop

ISO forwarding mode: drop

Enhanced route scaling mode: Disabled

  Flow trace status

Flow tracing status: off

  Flow session distribution

Distribution mode: RR-based

GTP-U distribution: Disabled

  Flow ipsec performance acceleration: off

  Flow packet ordering

Ordering mode: Hardware

 

root@demo-srx300> show security ipsec statistics

ESP Statistics:

  Encrypted bytes:   252264

  Decrypted bytes:0

  Encrypted packets:   1618

  Decrypted packets:  0

AH Statistics:

  Input bytes:0

  Output bytes:   0

  Input packets:  0

  Output packets: 0

Errors:

  AH authentication failures: 0, Replay errors: 0

  ESP authentication failures: 0, ESP decryption failures: 0

  Bad headers: 0, Bad trailers: 0

 

root@demo-srx300> show security flow statistics | grep rop

Packets dropped: 15650

 

root@demo-srx300> ping 10.102.199.66 routing-instance one rapid interval .1
count 100

PING 10.102.199.66 (10.102.199.66): 56 data bytes




--- 10.102.199.66 ping statistics ---

100 packets transmitted, 0 packets received, 100% packet loss

 

root@demo-srx300> show security ipsec statistics

ESP Statistics:

  Encrypted bytes:   267864

  Decrypted bytes:0

  Encrypted packets:   1718

  Decrypted packets:  0

AH Statistics:

  Input bytes:0

  Output bytes:   0

  Input packets:  0

  Output packets: 0

Errors:

  AH authentication failures: 0, Replay errors: 0

  ESP authentication failures: 0, ESP decryption failures: 0

  Bad headers: 0, Bad trailers: 0

 

root@demo-srx300> show security flow statistics | grep rop

Packets dropped: 15755

 

-Aaron

 

___
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] RFC2544 on Juniper SRX300

[Emille Blanc]

Page 6 of the SRX300 series datasheet states in the fineprint;
16* "Throughput numbers based on UDP packets and RFC2544 test methodology."

That said, I don't see RFC2544 generation and reflection explicitly stated 
anywhere, nor do I see the config syntax supported up to 15.1X49-D160.2

Juniper KB shows ACX and MX as supported platforms, so perhaps you could create 
a loopback on the SRX, or do your tests between routing-instances on the MX.

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Matthew Crocker
Sent: Wednesday, April 17, 2019 7:05 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] RFC2544 on Juniper SRX300


Hello,

I have a customer WAN with 20ish SRX300s & 1 MX80 connected and need to setup 
RFC2544 to prove out the WAN circuits.

Is RFC2544 supports on the SRX in later JunOS versions?

I don’t want to go through the process of upgrading the OS and not get access 
to the feature.

Current versions running.


Model: srx300

Junos: 15.1X49-D140.2

JUNOS Software Release [15.1X49-D140.2]


Model: mx80

Junos: 15.1R6.7


___
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] Show me all the system syslog things!

[Emille Blanc]

> I would avoid changing "messages" since JTAC usually relies on the standard 
> stuff being there (and often increasing the logging to daemon any; kernel 
> any;)

Despite our messages configuration, I second this sentiment. You're better to 
play it safe unless you have reason to otherwise.

We rarely maintain support contracts on our equipment after a probationary 
period, so it is less of a concern in our case. Your mileage may vary...

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Anderson, Charles R
Sent: Thursday, March 21, 2019 1:47 PM
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Show me all the system syslog things!

I would avoid changing "messages" since JTAC usually relies on the standard 
stuff being there (and often increasing the logging to daemon any; kernel 
any;).  Instead, create a se
parate log file for your own cut-down logging.

On Thu, Mar 21, 2019 at 03:09:30PM -0400, Jason Lixfeld wrote:
> Hi,
> 
> I’m looking for some ideas about configuring syslog.
> 
> Starting from the bare-minumum syslog config, and log-updown in BGP:
> 
> jlixfeld@lab# show system syslog
> user * {
> any emergency;
> }
> host 10.219.51.130 {
> any info;
> }
> file messages {
> any info;
> }
> time-format year millisecond;
> 
> The messages file produces a great set of useful logs for day-to-day 
> operations and monitoring:  up/down for LDP, LLDP, ISIS, BFD, interface, BGP 
> and also executed CLI commands (mgd UI_CMDLINE_READ_LINE).  It’s great.
> 
> However, an enormous amount of logs from mgd (UI_*), chassisd, and a bunch of 
> other processes are also caught in this messages file, and while it’s 
> definitely useful to capture, it doesn’t need to be in the same file as the 
> day-to-day stuff.  I’m sure others have constructed some useful syslog 
> configs for separating these day-to-day messages into one file, and other 
> stuff into other file(s).  I’m interested in seeing other people’s work for 
> some inspiration on how I can construct a useful set of files myself.
> 
> Anyone care to share?
> 
> Thanks in advance!
___
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] Show me all the system syslog things!

[Emille Blanc]

Our 'messages' content is pretty minimal. We try to keep as little data in one 
lump on the device(s) to make auditing easier.
If we need to login to the device to check something, we want to find an answer 
quick. If we have time or it's looking like a far more complex problem, then we 
can scrape the syslog store.

We aren't watching ldp/lldp/isis/bfd by means of forwarding via syslog, but the 
following catches the things 'we' care about, while cutting down on 99.9% of 
the noise of which we don't.
Things it doesn't catch, we fudge with event-options, I'm sure you could 
probably do the same to give you better control rather than leaning on the 
built-in priorities.
Since we use TACACS+, all our command accounting goes there. In light of this, 
only config items that have been changed, but creates a nice audit trail by 
itself (who did what where, when...).  Maybe you would want that to go to a 
dedicated file if you're not running any centralized AAA...
I would strongly encourage the use of the 'allow-duplicates' in the syslog root 
to avoid "last message repated 'n' times" from obscuring bigger problems.

We also log things like interface events directly to the device for ease of 
troubleshooting. I only show the one example to give some idea how it may suit 
your needs.

syslog { 
 host foobar {
  any emergency;
  authorization warning;
  daemon warning;
  kernel critical;
  change-log any;
  explicit-priority;
 }
 file messages {
  any critical;
  authorization info;
 }
 allow-duplicates;
 file interfaces {
  any any;
  match SNMP_TRAP_LINK;
 }
}

event-options {
 policy PROTOCOL-STATE-OVERRIDE {
  events [ rpd_ospf_nbrdown rpd_ospf_nbrup rpd_bgp_neighbor_state_changed ];
   then {
priority-override {
 severity warning;
}
   }
 }
}


-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Jason Lixfeld
Sent: Thursday, March 21, 2019 12:10 PM
To: juniper-nsp
Subject: [j-nsp] Show me all the system syslog things!

Hi,

I’m looking for some ideas about configuring syslog.

Starting from the bare-minumum syslog config, and log-updown in BGP:

jlixfeld@lab# show system syslog
user * {
any emergency;
}
host 10.219.51.130 {
any info;
}
file messages {
any info;
}
time-format year millisecond;

The messages file produces a great set of useful logs for day-to-day operations 
and monitoring:  up/down for LDP, LLDP, ISIS, BFD, interface, BGP and also 
executed CLI commands (mgd UI_CMDLINE_READ_LINE).  It’s great.

However, an enormous amount of logs from mgd (UI_*), chassisd, and a bunch of 
other processes are also caught in this messages file, and while it’s 
definitely useful to capture, it doesn’t need to be in the same file as the 
day-to-day stuff.  I’m sure others have constructed some useful syslog configs 
for separating these day-to-day messages into one file, and other stuff into 
other file(s).  I’m interested in seeing other people’s work for some 
inspiration on how I can construct a useful set of files myself.

Anyone care to share?

Thanks in advance!
___
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] SNMP OIDs for Yellow/Red Alarm on MX204

[Emille Blanc]

I expect you don't like the idea of syslog for the same reason as SNMP traps...

So perhaps you could craft something using SLAX? I would be a little surprised 
if someone hasn't already done this somewhere:

https://www.juniper.net/documentation/en_US/junos/topics/example/junos-script-automation-snmp-script-example.html

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Joerg Staedele
Sent: Thursday, February 28, 2019 9:33 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] SNMP OIDs for Yellow/Red Alarm on MX204

Hi Guys,

i just found out that it seems not to be possible to poll Yellow/Red Alarm 
(Count or State) on MX204 via SNMP.

On other platforms the craft panel (craftd) handles that alarms and its not 
there on MX204 so you can't use it.

Also there seems to be no alternative OID to poll for Alarms ☹

I dont like snmp traps as they can get lost 

Any hints or ideas?

Regards
 Joerg

___
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] EX9253 to QFX5110 dac not coming up

[Emille Blanc]

Our experiences with DAC's have been atrocious to date - Genuine Cisco, Genuine 
HPE, compatible or generic from FS.com...
In the end, we chose Optics (after some off-list recommendations via this 
list), and all our problems with devices not linking were resolved.

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Event Script
Sent: Thursday, January 17, 2019 8:15 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] EX9253 to QFX5110 dac not coming up

Anyone had any experience with this?  Have tried changing auto negotiation,
and that didn't seem to fix anything.
___
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] SNMP_EVLIB_FAILURE - snmp not working anymore

[Emille Blanc]

Juniper has always been accommodating in my occasional request to provide 
disambiguation to KB's or PR's, whenever I use the feedback widget.
Let them know your thoughts.

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Sebastian Wiesinger
Sent: Friday, December 21, 2018 4:48 AM
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] SNMP_EVLIB_FAILURE - snmp not working anymore

* Olivier Benghozi  [2018-12-21 02:05]:
> PR1270686
> 
> restart statistics-service

This PR is one example of something I don't like in most Juniper PRs.
It states the command you quoted but then there is also this text:

Workaround:

Disable pfed's periodic refresh using config:
set accounting-options periodic-refresh disable

Nowhere in this PR is explained what that does and what possible
side-effects are. You only find this exact command in a post on the
Juniper forums:


> set accounting-options periodic-refresh disable
> -->Periodic-refresh is disabled to change the default behavior for
> stats collection. Pre-BBE, stats were constantly collected in JUNOS.
> This uses CPU cycles that are needed for call set up.
> -->With the introduction of BBE in JUNOS, we needed to change the
> behavior for stats to be on demand. That is what disabling
> periodic-refresh does. There is no negative impact to accurate stats
> or interim stats.
> -->Without this disabled, accounting will be very inefficient and not
> scale.

This might be the correct explanation or it might be just a text from
someone who wants to gain "kudos" so that he can get to the next level
in the Juniper Support pantheon aka "The Stack Exchange disease".

Either way it would be very nice if Juniper would post some more
information on *what* a workaround does and when it would not be wise
to use it. In this case you should probably not use the workaround if
you have a scaled BBE setup I would imagine.

Regards

Sebastian

-- 
GPG Key: 0x58A2D94A93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0 B9CE)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
-- Terry Pratchett, The Fifth Elephant
___
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] IPAM like tool/DB for managing communities

[Emille Blanc]

+1 for PHPIPAM.
It's code is clean and super-easy to modify if needed, and it has GUI built-ins 
to add custom fields.

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Roger Wiklund
Sent: Thursday, December 13, 2018 7:09 AM
To: adamv0...@netconsultings.com
Cc: Juniper List
Subject: Re: [j-nsp] IPAM like tool/DB for managing communities

NIPAP maybe?
http://spritelink.github.io/NIPAP/

Personally I like phpIPAM, it's quite easy to add custom stuff.
https://phpipam.net


On Mon, Dec 10, 2018 at 10:30 AM  wrote:

> Hi folks,
>
> I'm just wondering if anyone happens to know about a tool that can be used
> to manage BGP communities (standard/extended/large communities).
>
> I'd appreciate any pointers
>
> Thanks
>
>
>
> adam
>
>
>
> netconsultings.com
>
> ::carrier-class solutions for the telecommunications industry::
>
>
>
>
>
> ___
> 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] Remote access vpn on srx1500

[Emille Blanc]

I can't offer any working samples or clue-bats, but I too am interested in this.
I've not been successful in getting this working since I last ran 12.3X48-D35.

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Mohamed Faye
Sent: Thursday, October 25, 2018 9:20 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Remote access vpn on srx1500

Hi all,

Anyone configured remote access vpn on srx1500 would need a guide on a temple 
if available thanks all in advance.

- Mohamed
___
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] If there's anyone from Juniper on the list.....

[Emille Blanc]

> If it is on a Web page you can simply use the star rating and leave feedback 
> with a comment. 
> My response rate from the  documentation team is still 100%.‎

+1

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Karsten Thomann via juniper-nsp
Sent: Tuesday, May 15, 2018 10:34 AM
To: Chris Boyd; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] If there's anyone from Juniper on the list.

Hi,

If it is on a Web page you can simply use the star rating and leave feedback 
with a comment. 
My response rate from the  documentation team is still 100%.‎
  Originalnachricht  
Von: Chris Boyd
Gesendet: Dienstag, 15. Mai 2018 19:08
An: juniper-nsp@puck.nether.net
Betreff: [j-nsp] If there's anyone from Juniper on the list.

Who can get a message over to the Documentation group, it would be great if you 
could update the doc on the “insert” command to note that you have to create 
the object first, and then move it with the insert.

May be common knowledge to old hands, but I’m still learning the ins and outs 
of JunOS. Looking at the doc, it seems that the order of operations would be 
this:

edit firewall family inet filter foo
insert term bar before term xyzzy
error: statement ‘bar' not found

But it’s actually this:

edit firewall family inet filter foo
set term bar from source-prefix-list source
set term bar from destination-prefix-list dest
set term bar from protocol tcp
set term bar from destination-port ssh
insert term bar before term xyzzy

—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] SRX 550 BGP Flapping

[Emille Blanc]

You might want to check the MTU of the path, or ensure that pmtu is enabled.
It looks like you're using a redundant ethernet interface (reth). If you're 
using a non-standard MTU, make sure it is set correctly for its member 
interface(s).


From: juniper-nsp [juniper-nsp-boun...@puck.nether.net] On Behalf Of sameer 
mughal [pcs.same...@gmail.com]
Sent: Monday, January 29, 2018 8:20 PM
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] SRX 550 BGP Flapping

I have seen hold time error. what will be the fix on this issue?

show bgp neighbor xx.xx.xx.xx
Peer: xx.xx.xx.xx+179 AS   Local: xx.xx.xx.xx+56228 AS 
  Type: ExternalState: EstablishedFlags: 
  Last State: OpenConfirm   Last Event: RecvKeepAlive
  Last Error: Hold Timer Expired Error
  Export: [ IMPORT-LAN-INTO-BGP ] Import: [ Reject-BGP ]
  Options: 
  Options: 
  Authentication key is configured
  Local Address: xx.xx.xx.xx Holdtime: 90 Preference: 170
  Number of flaps: 30
  Last flap event: HoldTime
  Error: 'Hold Timer Expired Error' Sent: 30 Recv: 0
  Peer ID: xx.xx.xx.xx Local ID: xx.xx.xx.xx   Active Holdtime: 90
  Keepalive Interval: 30 Group index: 0Peer index: 0
  BFD: disabled, down
  Local Interface: reth2.0
  NLRI for restart configured on peer: inet-unicast
  NLRI advertised by peer: inet-unicast
  NLRI for this session: inet-unicast
  Peer supports Refresh capability (2)
  Stale routes from peer are kept for: 300
  Peer does not support Restarter functionality
  Peer does not support Receiver functionality
  Peer does not support LLGR Restarter or Receiver functionality
  Peer supports 4 byte AS extension (peer-as xx.xx.xx.xx)
  Peer does not support Addpath
  Table inet.0 Bit: 1
RIB State: BGP restart is complete


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Tue, Jan 30, 2018 at 9:14 AM, sameer mughal 
wrote:

> Hi,
> Can anyone help me on this bgp flapping issue?
>
> show bgp summary
> Groups: 1 Peers: 1 Down peers: 0
> Table  Tot Paths  Act Paths SuppressedHistory Damp State
> Pending
> inet.0
>   37 31  0  0  0
> 0
> Peer AS  InPkt OutPktOutQ   Flaps Last
> Up/Dwn State|#Active/Received/Accepted/Damped...
> xx.xx.xx.xx 9541 86 70   0  *30 *
>  28:28 31/37/36/0   0/0/0/0
>
> {primary:node0}
>
> Peer: xx.xx.xx.xx +179 AS 9541 Local: xx.xx.xx.xx +56228 AS 64520
>   Type: ExternalState: EstablishedFlags: 
>   Last State: OpenConfirm   Last Event: RecvKeepAlive
>   Last Error: Hold Timer Expired Error
>   Export: [ IMPORT-LAN-INTO-BGP ] Import: [ Reject-BGP ]
>   Options: 
>   Options: 
>   Authentication key is configured
>   Local Address: 192.168.111.74 Holdtime: 90 Preference: 170
>   Number of flaps: 30
>   Last flap event: HoldTime
>   Error: 'Hold Timer Expired Error' Sent: 30 Recv: 0
>   Peer ID: xx.xx.xx.xx Local ID: xx.xx.xx.xxActive Holdtime: 90
>   Keepalive Interval: 30 Group index: 0Peer index: 0
>   BFD: disabled, down
>   Local Interface: reth2.0
>   NLRI for restart configured on peer: inet-unicast
>   NLRI advertised by peer: inet-unicast
>   NLRI for this session: inet-unicast
>   Peer supports Refresh capability (2)
>   Stale routes from peer are kept for: 300
>   Peer does not support Restarter functionality
>   Peer does not support Receiver functionality
>   Peer does not support LLGR Restarter or Receiver functionality
>   Peer supports 4 byte AS extension (peer-as 9541)
>   Peer does not support Addpath
>   Table inet.0 Bit: 1
> RIB State: BGP restart is complete
> Send state: in sync
> Active prefixes:  31
> Received prefixes:37
> Accepted prefixes:36
> Suppressed due to damping:0
> Advertised prefixes:  48
>   Last traffic (seconds): Received 28   Sent 10   Checked 58
>   Input messages:  Total 80 Updates 30  Refreshes 0 Octets 2749
>   Output messages: Total 64 Updates 5   Refreshes 0 Octets 1618
>   Output Queue[0]: 0(inet.0, inet-unicast)
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_-4192711485207260329_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list 

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

[Emille Blanc]

We've got a half dozen EX2300 and EX2300-C's in production, and no issues for 
us with those so far.
EX2200's have been fine for us less a pair of 2200-C's that managed to go out 
the door with 15.x JunOS. But as someone stated in this thread earlier, there 
are known issues attempting this on the fanless compact form factor switch. We 
rolled them back to 12.x and they've been as solid as the rest since.
We're only using L2 features on both platforms though, less a few niche cases 
or temporary L3 config for network diagnosis purposes.
So can't provide much in the way of feedback on L3 features that OP is 
interested in.
Overall, we're quite happy with both platforms, and usually only bring in a 
2300 over a 2200 if we need the SFP+ cages for 10gig uplinks.

Our typical feature use;
TACACS+
802.1ad tunnels and VLAN mapping
802.1q VLAN push/pop
802.1p marking
VSTP
LACP / Aggregated ether / port channel

From: juniper-nsp [juniper-nsp-boun...@puck.nether.net] On Behalf Of Christian 
Scholz [c...@ip4.de]
Sent: Saturday, December 09, 2017 11:29 AM
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] What is your experience with the EX2200

I would only buy the EX2300 if somebody points a Gun in my Face - seriously!
Anyone recommending a Device that purely relies on 15.1 Software does not
even closely know what he is talking about...

The 2300 is a Joke so far - We have 7 PR's open and weekly Core-Dumps...
Stick with the EX2200 since the EX2200 is not EOL and the EX2300 is unusable
until a fine Release (17.3 onwards) is available, fixing all the critical
things.
15.1 is the new Windows Vista - unstable, unreliable and just a big joke -
never ever ever ever use a 15.X in Production until you want to watch the
World burn...

Just my 2 cents...


___
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] EX3400 or EX4600, and HPE FlexFabric-20/40, QSFP+ DAC's

[Emille Blanc]

To close this thread, DAC's appear to have been a wash.
Using like-vendor branded optics on both sides, and we have a functioning 
40Gbps link.

Thanks for the feedback on, and off-list. :]

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Chuck Anderson
Sent: November-21-17 7:10 AM
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] EX3400 or EX4600, and HPE FlexFabric-20/40, QSFP+ DAC's

On Tue, Nov 21, 2017 at 06:28:07AM -0800, Emille Blanc wrote:
> Hello folks,
> 
> Trudging through the woes that are cross-vendor compatibility issues, and 
> failing completely at getting a link between an EX3400 or EX4600, and an HPE 
> FlexFabric-20/40 F8 card in our c7000 enclosure using an HPE branded QSFP+ 
> 3mtr DAC.  That is to say, Juniper on one side, HPE on the other.
> As an added bonus, the HPE module seems to be allergic to Juniper's QSFP 
> completely.
> 
> After the inevitable "It's not us, it's them" back-and-forth between JTAC and 
> HPE Support, I'm looking for any success (or failure) stories from the 
> community.
> 
> We've been testing with a pair of HPE DACs, and they each work fine when we 
> loop it to two QSFP+ slots in the same chassis/module.
> 
> Has anyone been successful in making such a connection in the wild?

Buy cheap QSFP+ optics and use fiber?
___
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] EX3400 or EX4600, and HPE FlexFabric-20/40, QSFP+ DAC's

[Emille Blanc]

Hello folks,

Trudging through the woes that are cross-vendor compatibility issues, and 
failing completely at getting a link between an EX3400 or EX4600, and an HPE 
FlexFabric-20/40 F8 card in our c7000 enclosure using an HPE branded QSFP+ 3mtr 
DAC.  That is to say, Juniper on one side, HPE on the other.
As an added bonus, the HPE module seems to be allergic to Juniper's QSFP 
completely.

After the inevitable "It's not us, it's them" back-and-forth between JTAC and 
HPE Support, I'm looking for any success (or failure) stories from the 
community.

We've been testing with a pair of HPE DACs, and they each work fine when we 
loop it to two QSFP+ slots in the same chassis/module.

Has anyone been successful in making such a connection in the wild?

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