Re: [j-nsp] Origin Validation on MX80
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
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
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
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
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
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
(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
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
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
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