Re: [j-nsp] Junos Telemetry Interface

[Aaron Gould]

You’re welcome Colton.  I understand there are 2 different ways to do telemetry 
on Juniper.  One called Native and the other called gRPC/openconfig.  I’ve done 
the Native form.  I think the native form is a configured form where by which 
the network device constantly streams the sensor objects… and conversely, the 
gRPC form is subscription based where the management app/computer, subscribes 
to the network device to receive telem data objects.

 

I understand the native form to be executed in hardware near the monitored 
object….and because of this, highly scalable.And the grpc/openconfig form 
runs on re cpu.

 

I don’t think we’ve gotten native telemetry to work on ACX.  But I have it 
running on MX960’s.

 

I understand the grpc/openconfig method requires you to download some 
code/software to the network device.

 

Collector I use is the OpenNTI project.  Grafana (web ui) (or a less known 
Cronograf, which I actually use and like), InfluxDB (TSDB), fluentd, and other 
components.  I must credit Dave, my coworker and resident Linux genius in 
assisting my with the server side collector setup.  Some helpful/related links 
below….

 

 

https://puck.nether.net/pipermail/juniper-nsp/2018-October/036602.html

 

 

https://openeye.blog/2017/06/26/using-opennti-as-a-collector-for-streaming-telemetry-from-juniper-devices-part-1/

 

 

https://www.juniper.net/documentation/en_US/junos/topics/concept/junos-telemetry-interface-oveview.html

look under “telemetry sensors and data models”

 

 

https://community.grafana.com/t/how-to-send-juniper-router-telemetry-to-grafana/11071/9

 

 

-Aaron

 

 

From: Colton Conor [mailto:colton.co...@gmail.com] 
Sent: Saturday, April 11, 2020 9:05 AM
To: Aaron Gould
Cc: Juniper List
Subject: Re: [j-nsp] Junos Telemetry Interface

 

Aaron,

 

Thanks, this is indeed helpful. What collector are you using to store and view 
this telemetry data? Also, have you had any luck with getting JTI to work on 
your ACX gear? This only JTI feature is see for the ACX line according to the 
feature explorer is: 
https://apps.juniper.net/feature-explorer/feature-info.html?fKey=8978 

 =Specify%20Routing%20Instance%20for%20JTI I am not sure if that means it 
fully supports JTI or not. 

 

 

On Fri, Apr 10, 2020 at 11:53 AM Aaron Gould  wrote:

Not sure if this is what you are looking for, but here are some of the
sensor agents that I enabled on my MX routers

Maybe it's the linecard or interface specific ones that give me the bits in
bits out utilization graphs.

set services analytics sensor my-sensor-14 server-name my-grafana-srvr
set services analytics sensor my-sensor-14 export-name my-exprt-prfl
set services analytics sensor my-sensor-14 resource
/junos/system/linecard/interface/
set services analytics sensor my-sensor-1 server-name my-grafana-srvr
set services analytics sensor my-sensor-1 export-name my-exprt-prfl
set services analytics sensor my-sensor-1 resource
/junos/system/linecard/packet/usage/
set services analytics sensor my-sensor-2 server-name my-grafana-srvr
set services analytics sensor my-sensor-2 export-name my-exprt-prfl
set services analytics sensor my-sensor-2 resource
/junos/system/linecard/cpu/memory/
set services analytics sensor my-sensor-12 server-name my-grafana-srvr
set services analytics sensor my-sensor-12 export-name my-exprt-prfl
set services analytics sensor my-sensor-12 resource
/junos/system/linecard/fabric/
set services analytics sensor my-sensor-15 server-name my-grafana-srvr
set services analytics sensor my-sensor-15 export-name my-exprt-prfl
set services analytics sensor my-sensor-15 resource
/junos/system/linecard/interface/logical/usage/
set services analytics sensor my-sensor-17 server-name my-grafana-srvr
set services analytics sensor my-sensor-17 export-name my-exprt-prfl
set services analytics sensor my-sensor-17 resource
/junos/system/linecard/npu/memory/
set services analytics sensor my-sensor-18 server-name my-grafana-srvr
set services analytics sensor my-sensor-18 export-name my-exprt-prfl
set services analytics sensor my-sensor-18 resource
/junos/system/linecard/npu/utilization/
set services analytics sensor my-sensor-19 server-name my-grafana-srvr
set services analytics sensor my-sensor-19 export-name my-exprt-prfl
set services analytics sensor my-sensor-19 resource
/junos/system/linecard/optics/
set services analytics sensor my-sensor-21 server-name my-grafana-srvr
set services analytics sensor my-sensor-21 export-name my-exprt-prfl
set services analytics sensor my-sensor-21 resource
/junos/system/linecard/services/inline-jflow/
set services analytics sensor my-sensor-13 server-name my-grafana-srvr
set services analytics sensor my-sensor-13 export-name my-exprt-prfl
set services analytics sensor my-sensor-13 resource
/junos/system/linecard/firewall/

-Aaron

-Original Message-
From: juniper-nsp 

[j-nsp] Juniper Networks AppFormix

[Colton Conor]

Is anyone using Juniper Networks® AppFormix, and what are your thoughts on
the platform? How does it compare to a more traditional NMS such as
SolarWinds?

How much does Juniper Networks® AppFormix cost? I can't seem to find
pricing on licencing this platform.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Netflow config for MX204

[Saku Ytti]

On Sun, 12 Apr 2020 at 12:13, Vincent Bernat  wrote:

> What's a "non-revenue port"?

fxp0, em0, mgmtmethernet0, etc. Any port not hanging off of forwarding hardware.

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

Re: [j-nsp] Netflow config for MX204

[Vincent Bernat]

 ❦ 12 avril 2020 11:43 +03, Saku Ytti:

>> We just export flows in-band. Just seems simpler, and has been reliable
>> for close to 10 years.
>
> in-band is right, Trio can export the flow itself, you will kill your
> performance if you do non-revenue port export.

What's a "non-revenue port"?
-- 
When in doubt, tell the truth.
-- Mark Twain
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Netflow config for MX204

[Saku Ytti]

On Sun, 12 Apr 2020 at 03:53, Mark Tinka  wrote:

> On 11/Apr/20 08:04, Nick Schmalenberger via juniper-nsp wrote:
> > I had the same issue with first trying to export over fxp0, then
>
> We just export flows in-band. Just seems simpler, and has been reliable
> for close to 10 years.

in-band is right, Trio can export the flow itself, you will kill your
performance if you do non-revenue port export.

In my mind JNPR non-revenue ports have no use-case. They are dangerous
with no utility. Cisco is much better here, as they offer true OOB
non-revenue ports. JNPR non-revenue port is a convenient way to
quickly break a lot of your network at the same time, as they entirely
fate-share the control-plane. Cisco has non-revenue ports with their
own isolated management-plane, so state of your control-plane will not
impact the management-plane vice versa.
I think Nokia has true OOB ports too. We should start pushing JNPR to
jump on board. RS232 is not true OOB either, as it fate-shares the
control-plane, but it's lot better than JNPR non-revenue-ports, as
breaking the system is lot harder from there, and as well as break is
HW interrupt, which means, you can potentially reload  your host from
RS232 even if the host Linux is halted/non-responsive, but requires
non-standard+hidden config.

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