Re: [j-nsp] How to pick JUNOS Version

[John Kristoff]

On Wed, 19 Aug 2020 14:42:32 +
Colton Conor  wrote:

> How do you plan which JUNOS version to deploy on your network? Do you stick
> to the KB21476 - JTAC Recommended Junos Software Versions or go a different
> route?

I've occasionally got some good advice from bigger operators who often
have significantly more testing and deployment experience than I,
Although their concerns are often incongruent to mine, since we are apt
to rely on a very different set of interfaces, services, and features.
Just hearing something like "do not use version X because Y, or we're on
version Z" can be helpful.  Maybe just ask on this list what version
people are using or have had problems with before deciding?  Not very
scientific, but seems like a fair use of the list.

I'm not sure it is worth the time invested, but I'm probably a rare
breed that reads through release notes and tries to determine what I'm
in for or what I may have to change for an install or upgrade.  It is
very time consuming, but has been helpful a few times for things I
would have otherwise been unprepared for.  Here is an old of example of
the sort of thing I've done:

  

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

Re: [j-nsp] Buffer Size

[John Kristoff]

On Mon, 20 Apr 2020 20:58:02 +
Mohammad Khalil  wrote:

> Am trying to conduct a comparison for campus refresh , my end customer is
> deeply interested in deep details.
> He is interested to know the buffer size of Juniper switches (EX series)
> and I could not find such a piece of information in any place.

I'm not sure how well maintained this page is today and you'll
probably want to verify the info if you can, but it may at least give
you some leads:

  

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

Re: [j-nsp] Netflow config for MX204

[John Kristoff]

On Thu, 9 Apr 2020 06:20:00 +
Liam Farr  wrote:

> However I am getting export packet failures.

Some loss of flows being exported may be unavoidable depending on
your configuration and environment.  If you want to see fewer errors
you may just have to sample less frequently.  The numbers reported in
your "accounting errors" don't seem that large.

In my repo page were the example config is from you'll see a couple of
images at the bottom that show the difference between the two modes.  I
was aware of the flex mode when I originally did this.  I think at the
time I was under the impression that setting the memory pools manually
offered some desirable predictability.

Looking back at my notes, I think it was when Juniper TAC told me this
that led me to that conclusion: "And regarding flex-flow-sizing; this
configuration results in a first-come-first-serve creation of flows.
Whichever flow comes first, that is allowed to occupy the flow-table if
there is space in the table. Otherwise, the flow is dropped and an
error count is created."  Rightly or wrongly, I recall seeming to want
to ensure some amount of reasonable memory for both v4 and v6 flows.

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

Re: [j-nsp] Netflow config for MX204

[John Kristoff]

On Wed, 8 Apr 2020 09:26:10 +
Liam Farr  wrote:

> Just wondering is someone here has a working netflow config for a MX204
> they might be able to share.

I've used IPFIX before, here is an example of how that might be setup,
whether it is good or not I'll let others judge and I can fix if there
is feedback:

  

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

Re: [j-nsp] Decoding DDOS messages

[John Kristoff]

On Wed, 18 Mar 2020 16:18:18 +
Saku Ytti  wrote:

> I set SPORT to 179
> I access your SSH port

Yep, I get all that.  I can tighten that up.  Care to show us how you
do loopback filters?

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

Re: [j-nsp] Decoding DDOS messages

[John Kristoff]

On Wed, 18 Mar 2020 16:02:09 +
Saku Ytti  wrote:

> It is completely broken, you use 'port' so you expose every port in your 
> system.

Ha, OK thanks.  I think that would require some not so easy spoofing
unless I'm missing something.  We can convert any statement that just
uses port to directional, which I think will require additional rules
to tighten it up.  Feel free to submit example configs.

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

Re: [j-nsp] Decoding DDOS messages

[John Kristoff]

On Wed, 18 Mar 2020 14:39:19 +
Saku Ytti  wrote:

> Unfortunately even non-broken lo0 filter is extremely uncommon, even
> MX book has fundamentally broken example, as is CYMRU example.

Team Cymru only lists a Cisco BGP, general NTP (which includes a
Juniper example), and Juniper IP multicast template publicly now:

  

If you are referring to one of those, there is an email right on the
page to contact them and you should if there are mistakes and
improvements.  They will welcome input.  I edited the NTP template and
helped facilitate the IP multicast one Lenny did, so if there is a
problem with either of those I'd be interested to know about it, but I
am no longer an employee of Team Cymru so I can't fix them.

The other templates, including a generic Juniper template you can
find via a net search, but not through Team Cymru's website navigation,
are many years old and no longer maintained. It would be unwise to
trust or relay on those.

I have some example templates for more recent stuff work I've done, but
does not cover currently this thread's case and may be less
generically applicable.  They are probably also not perfect, but people
are welcome to submit an issue there and I'll do my best to keep them
maintained:

  

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

Re: [j-nsp] IPv6 hardening

[John Kristoff]

On Mon, 30 Dec 2019 14:19:51 +
harbor235  wrote:

> Does anyone have any updated router hardening guidelines, some of the sites
> I reference have not been updated for some time. e.g. www.team-cymru.org

There are a small handful of things I've done, or considered doing,
here:

  

It doesn't include some things like rpki-rtr that I've added in a
firewall filter config or tweaks I may have made in production, but
there may be some ideas in these templates for you.

John
___
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

[John Kristoff]

On Thu, 28 Feb 2019 22:06:27 +
Theo Voss  wrote:

> do you have an ER (Enhancement Request) ID for us to beg our SE/sales
> rep for in order to support this?

I just requested from a local rep.  When and if I get one I'll respond
to this thread.

John
___
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

[John Kristoff]

On Thu, 28 Feb 2019 20:48:52 +
Simon Lockhart  wrote:

> I'm running 18.1R2.5 on these - wonder if they add it back in on later
> versions...

Not available on 18.4R1.8.

John
___
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

[John Kristoff]

On Thu, 28 Feb 2019 20:19:36 +
Tom Beecher  wrote:

> These don't work on the 204?
> 
> Red Alarm: jnxRedAlarmState 1.3.6.1.4.1.2636.3.4.2.3.1
> Yellow Alarm: jnxYellowAlarmState 1.3.6.1.4.1.2636.3.4.2.2.1

No.

$ snmpwalk -v2c -c foobar 192.0.2.1  1.3.6.1.4.1.2636.3.4.2.3.1
SNMPv2-SMI::enterprises.2636.3.4.2.3.1 = No Such Object available on this agent 
at this OID

$ snmpwalk -v2c -c foobar 192.0.2.1 1.3.6.1.4.1.2636.3.4.2.2.1
SNMPv2-SMI::enterprises.2636.3.4.2.2.1 = No Such Object available on this agent 
at this OID

I had recently discovered this as well and opened a ticket about it
just to make sure.  The responses I got included:

  "There is no MIB available to monitor the chassis cluster state, only
  SNMP traps are supported for failover and other events"

Unless there is some unknown (to me) hardware-related limitation, I
intend to contact our local sales rep for a feature request.
Presumably this is the right path for a change, so others should do
this as well as a signal to Juniper that there is customer demand.

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

Re: [j-nsp] Recommended MX80 JUNOS version?

[John Kristoff]

On Mon, 6 Aug 2018 10:30:16 +
Chris Adams  wrote:

> I've got an old MX80 running the JTAC recommended release 15.1R7, but
> that has a USB bug (PR 108) that is causing crashes.  The PR says it
> is fixed in 16.1R4 and 17.1R1, but I was wondering what releases other
> people might be running and recommend on the MX80 these days.

I've seen good experience with 14.1R7.4 on a boxes that have a mix of
1/10 Gb/s interfaces, NetFlow/IPFIX export, OSPF, BGP, PIM, ... I've
heard others running the 17.1 rev are happy.

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

Re: [j-nsp] ACL for lo0 template/example comprehensive list of 'things to think about'?

[John Kristoff]

On Wed, 11 Jul 2018 18:22:36 +
Chris Boyd  wrote:

> Team Cymru has a “JunOS Secure Template” that I found a good place to start. 
> It quotes version 4 though.  I think that means it’s well tested?
> 
> http://www.cymru.com/gillsr/documents/junos-template.pdf

That document is old and should be considered unreliable.  I'm speaking
with some authority since I contributed major parts to it, including
the now bad advice of UDP rate rate limits (their demise hastened with
the rise of QUIC/SPDY years ago).

I've been redoing a slew of JUNOS configuration standards and am
documenting them as I go.  I've not finalized new loopback filters yet,
but you might be interested in others and keeping an eye on this repo.
Loopback filters will soon appear within a few weeks.

  

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

[j-nsp] EX 3300 vs EX 3400 for access layer

[John Kristoff]

Friends,

Our engineering team is reviewing and contemplating whether to stick
with the Juniper EX 3300 switch at the edge access layer (to user wired
ports, some VoIP phones, and some wireless APs also connect to these).

Typically these devices can last out in the field for five or more
years.  There are at least two potential concerns about this series of
switches.  One, when stacking them into a larger virtual chassis (i.e.
six or more), the management plan performance appears to be horribly
slow and burdened by this extra maintenance work.  Two, will these
devices sustain the future PoE requirements that we may see from edge
devices?

I suspect the answer to the latter question is probably yes, but the
first issue is what bothers me the most.

The link access speeds and up links are probably OK given our traffic
projections.

Curious what others are using or have considered if you're running
Juniper devices at the edge.

Note, we're very cost conscious so the 3300 is much more appealing over
the 3400 or higher end line.  Also note, while a different vendor may
be a long term option, consider that out of scope for this thread.

Thank you,

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

[j-nsp] debug messages - kernel: rt->rt_proto and fpc0 Next-hop resolution requests throttled

[John Kristoff]

Hello friends,

Curiosity may have killed the cat, but I'm not a cat so here goes.

Evaluating some debug logs on an EX-9208 I've seen two flavors of log
messages that I'd be interested in learning more about.  One set looks
like the following:

  /kernel: rt->rt_proto ipv4 plen 32
  /kernel: rt->rt_proto vpls plen 80
  /kernel: rt->rt_proto ipv6 plen 128

The other like this:

  fpc0 Next-hop resolution requests from interface 498 throttled

>From the text I think I have an idea what they sort of information they
are conveying, but I'd like to hear definitively a bit more.  Under
what conditions and for what reason they are being generated?  Yes,
these are from enabling debug message, which generally you wouldn't do,
but would otherwise ignore these if you saw them.  I opened a low
priority case and apparently not much is documented about them and I
didn't want to push the JTAC to expend a lot of effort on this.  Hoping
someone here might have this obscure knowledge.

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

[j-nsp] Secure JUNOS IP Multicast Template

[John Kristoff]

Friends,

With all credit to Lenny Giuliano, we're happy to make this secure
configuration template available:

  

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

Re: [j-nsp] NTP Reflection

[John Kristoff]

On Mon, 13 Jan 2014 20:47:08 -0500
ML m...@kenweb.org wrote:

 Juniper didn't want to be outdone by Cisco.  Cisco devices act the
 same way once they are configured as NTP clients.

IOS devices, at least those with which I'm familiar, don't implement the
full specification that includes mode 6/7 functions so they can be
somewhat less bad from an amplification perspective.

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

Re: [j-nsp] NTP Reflection

[John Kristoff]

On Tue, 14 Jan 2014 12:38:12 +1100
Mark Tees markt...@gmail.com wrote:

 Can we get detailed lo0 filters listed too please?

Hi Mark,

While I'll defer to Juniper for their recommendations, we've had this
for some time (scroll down to the Juniper section):

  http://www.team-cymru.org/ReadingRoom/Templates/secure-ntp-template.html

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