Re: [j-nsp] Origin Validation on MX80

[Mark Tinka]

On 17/Aug/16 18:51, Brad Fleming wrote:

> Seems to drop a little (not as much as I thought). What I found a
> little odd is that simply disabling the import policy on the BGP peer
> didn't result in decreased CPU after 15mins. I rebooted the MX80 and
> after the ~15mins of BGP flooding and convergence the CPU has calmed
> down a little.

I've found that major BGP changes on the MX80 and MX104 take too long to
settle down while in-flight. The quickest way is to reboot the box. For
instance, we once changed a BGP MSS value for a bunch of peers in one
go, and the sessions could not re-establish after the commit for more
than 30 minutes. Rebooting the box was the only option. That PPC CPU is
pretty slow...


>
> The RPKI you guys have enabled; is it just to test building the
> validation database?

We've enabled RPKI in our network, but are not yet enforcing policy.

One of the reasons was due to buggy code within IOS XE that crashed the
box when it evaluated RPKI data. This is now fixed.

The other reason was most networks that have created ROA's have not done
so for the longer prefixes - only for the aggregates. As such, we end up
the a lot of Invalid routes, even though they are not mis-originated.
This reduces the full table we can send to customers, making RPKI a
little less-than-useful in a practical setting.

But we have it fully enabled on our looking glass for our customers,
peers and interested parties to play with. You can take a look here if
you're interested:

http://as37100.net/

We still plan to re-enable it for practical use going forward.

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

[j-nsp] SRX Deployment Questions

[Jeffrey Nikoletich]

Hello,

We have a SRX we are deploying and are having some issues and some
guidance would be great. We have a SRX 3600 and want to deploy in the
following manner:

It is connected via 2 Dell S55 External switches. 1 10G drop per switch.
We will call that subnet 1.1.1.0/24.

On the Internal side. It is connected to 6 x Dell S55 switches. 1 10G drop
per switch. We will call that 10.0.0.0/24.

For the internal, I setup a AE interface that has all 6 x 10G ports in it.
External has an AE interface as well. External is AE0 and internal is AE1.

The issue I am have was it seems that the AE interfaces were only passing
traffic via a single interface? Any reason why?

Also does this setup look "sane" just wanted some feedback as this is our
first SRX deployment.

Thanks in advance.

Regards,

Jeffrey Nikoletich - Chief Information Officer | 213-201-6080

Xfernet
 | 1-855-XFERNETPh  213-201-6080 | http://www.xfernet.net
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Origin Validation on MX80

[Brad Fleming]

Seems to drop a little (not as much as I thought). What I found a little
odd is that simply disabling the import policy on the BGP peer didn't
result in decreased CPU after 15mins. I rebooted the MX80 and after the
~15mins of BGP flooding and convergence the CPU has calmed down a little.

The RPKI you guys have enabled; is it just to test building the validation
database?

On Wed, Aug 17, 2016 at 9:54 AM, Mark Tinka  wrote:

>
>
> On 17/Aug/16 16:46, Brad Fleming wrote:
>
> Hello all,
>
> We’ve been playing around a bit with BGP origin validation on a lab MX80.
> While everything seems to work CPU load is pretty high. We’ve observed this
> elevated CPU with both 14.3R and 16.1R1.7. Just wondering if
> anyone else experienced similar or whether we’ve configured something
> sideways and caused a problem.
>
>
> We have RPKI enabled on our MX routers (including the MX80), but not
> performing any policy.
>
> Does your CPU utilization reduce if you disable the policies that work on
> RPKI?
>
> Mark.
>



-- 
Brad Fleming
bdfle...@gmail.com
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] open source packages to monitor ex2200/vc

[raf]

Le 17/08/2016 à 17:28, Catalin Dominte a écrit :

I usually create a snmp filter to avoid polling interfaces ending in .0. If you 
poll an ex2200 / 3300 / 4200 it spends a long time polling the ifTable and 
ifxTable. The polling time is reduced considerably if .0 interfaces are dropped 
and I can poll the device every 5 minutes.



Yes snmp request can kill the control plane of EXs. For example 
Observium was killing my ex4550 (causing ldp sessions to drop and so 
on). I still consider that completely ridiculous...


With correct snmp filter the situation is less worse, but I still have 
to patch the Observium poller to let some breathes to my ex(s).
OK the Observium poller is quite aggressive (or stupid depend of the 
point of view :).




What is everyone using to monitor their EX2200/VC stacks?



I've made some ugly scripts in python to check via ssh the output of 
"show virtual-chassis".



We are using check_mk to monitor our network which is great, however due to
the way it polls or due to the low power of the ex2200 I'm unable to
monitor all the individual interfaces.


Check-mk is great, but do lot of snmpwalk to check network devices. (If 
I had time I will take a look to patch and make it use an interfaces cache)


--
Raphael Mazelier


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

Re: [j-nsp] open source packages to monitor ex2200/vc

[Chuck Anderson]

Okay, attachments don't come through the list, so I've done what I
should have done long ago and put this on github:

https://github.com/cranderson/nagios-plugins

On Wed, Aug 17, 2016 at 11:12:12AM -0400, Chuck Anderson wrote:
> (trying again with gzipped code to make message small enough)
> 
> For Juniper hardware/software fault monitoring, we use Nagios with the
> check_snmp_environment plugin, extended with more Juniper checks.
> I've attached the one we use here.  I'd like to improve this further
> by removing duplicate alerts (often the Component State and FRU states
> are identical, so we get alert messages with the same alerts printed
> twice, but I didn't know that when I wrote it originally and wanted to
> not miss anything).
> 
> For interface statistics and historical graphing/trending, we use
> AKiPS.  AKiPS can also do threshold and fault alerting if you'd rather
> have a single solution that does everything.  The nice thing about
> AKiPS is that it has pretty comprehensive support for many vendors of
> not just networking gear, but also servers, power systems, wireless,
> etc.  It also has a syslog and NetFlow collector.  They also add new
> functionality pretty rapidly.
> 
> On Wed, Aug 17, 2016 at 12:15:12PM +0100, William wrote:
> > Hi list,
> > 
> > What is everyone using to monitor their EX2200/VC stacks?
> > 
> > We are using check_mk to monitor our network which is great, however due to
> > the way it polls or due to the low power of the ex2200 I'm unable to
> > monitor all the individual interfaces.
> > 
> > Cheers,
> > 
> > Will
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] open source packages to monitor ex2200/vc

[Catalin Dominte]

I usually create a snmp filter to avoid polling interfaces ending in .0. If you 
poll an ex2200 / 3300 / 4200 it spends a long time polling the ifTable and 
ifxTable. The polling time is reduced considerably if .0 interfaces are dropped 
and I can poll the device every 5 minutes.

Catalin

Sent from my mobile device

> On 17 Aug 2016, at 12:15, William  wrote:
> 
> Hi list,
> 
> What is everyone using to monitor their EX2200/VC stacks?
> 
> We are using check_mk to monitor our network which is great, however due to
> the way it polls or due to the low power of the ex2200 I'm unable to
> monitor all the individual interfaces.
> 
> Cheers,
> 
> Will
> ___
> 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] open source packages to monitor ex2200/vc

[Chuck Anderson]

(trying again with gzipped code to make message small enough)

For Juniper hardware/software fault monitoring, we use Nagios with the
check_snmp_environment plugin, extended with more Juniper checks.
I've attached the one we use here.  I'd like to improve this further
by removing duplicate alerts (often the Component State and FRU states
are identical, so we get alert messages with the same alerts printed
twice, but I didn't know that when I wrote it originally and wanted to
not miss anything).

For interface statistics and historical graphing/trending, we use
AKiPS.  AKiPS can also do threshold and fault alerting if you'd rather
have a single solution that does everything.  The nice thing about
AKiPS is that it has pretty comprehensive support for many vendors of
not just networking gear, but also servers, power systems, wireless,
etc.  It also has a syslog and NetFlow collector.  They also add new
functionality pretty rapidly.

On Wed, Aug 17, 2016 at 12:15:12PM +0100, William wrote:
> Hi list,
> 
> What is everyone using to monitor their EX2200/VC stacks?
> 
> We are using check_mk to monitor our network which is great, however due to
> the way it polls or due to the low power of the ex2200 I'm unable to
> monitor all the individual interfaces.
> 
> Cheers,
> 
> Will
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Origin Validation on MX80

[Mark Tinka]

On 17/Aug/16 16:46, Brad Fleming wrote:

> Hello all,
>
> We’ve been playing around a bit with BGP origin validation on a lab MX80.
> While everything seems to work CPU load is pretty high. We’ve observed this
> elevated CPU with both 14.3R and 16.1R1.7. Just wondering if
> anyone else experienced similar or whether we’ve configured something
> sideways and caused a problem.

We have RPKI enabled on our MX routers (including the MX80), but not
performing any policy.

Does your CPU utilization reduce if you disable the policies that work
on RPKI?

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

[j-nsp] Origin Validation on MX80

[Brad Fleming]

Hello all,

We’ve been playing around a bit with BGP origin validation on a lab MX80.
While everything seems to work CPU load is pretty high. We’ve observed this
elevated CPU with both 14.3R and 16.1R1.7. Just wondering if
anyone else experienced similar or whether we’ve configured something
sideways and caused a problem.

lab-mx80> show version
Junos: 16.1R1.7


lab-mx80> show validation session
Session  State   Flaps Uptime
#IPv4/IPv6 records
   Up  0   00:31:03 24360/3555


lab-mx80> show bgp summary
  97906 66   0   0
29:44 615844/615844/615844/0 0/0/0/0


lab-mx80> show chassis routing-engine
Load averages: 1 minute   5 minute  15 minute
   0.94   1.00   0.92

lab-mx80> show system processes summary
  PID USERNAME   THR PRI NICE   SIZERES STATETIME   WCPU COMMAND
 2016 root 3  760   476M   385M RUN 29:23 93.99% rpd


set policy-options policy-statement rpki-validation term valid from
protocol bgp
set policy-options policy-statement rpki-validation term valid from
validation-database valid
set policy-options policy-statement rpki-validation term valid then
validation-state valid
set policy-options policy-statement rpki-validation term valid then
community set valid
set policy-options policy-statement rpki-validation term valid then accept
set policy-options policy-statement rpki-validation term invalid from
protocol bgp
set policy-options policy-statement rpki-validation term invalid from
validation-database invalid
set policy-options policy-statement rpki-validation term invalid then
validation-state invalid
set policy-options policy-statement rpki-validation term invalid then
community set invalid
set policy-options policy-statement rpki-validation term invalid then accept
set policy-options policy-statement rpki-validation term else then
community set unknown
set policy-options policy-statement rpki-validation term else then accept


We don’t have a bigger MX chassis spare so MX240-480-960 boxes might have
enough horsepower to get through this. Anyone else tried playing with
origin validation on Juniper gear yet? If so, did you get similar results?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] open source packages to monitor ex2200/vc

[William]

Hi list,

What is everyone using to monitor their EX2200/VC stacks?

We are using check_mk to monitor our network which is great, however due to
the way it polls or due to the low power of the ex2200 I'm unable to
monitor all the individual interfaces.

Cheers,

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