Hi!
I may open a JTAC case, when I understand for which problem I should
open one.
The following has happened:
The system (J6350) is running under 9.3R2.8, so we decided to update
to 9.4R2.8. That was a desaster, and I hope you can help also in this
matter. After upgrading the systems, both thought they are VRRP
master. The problem is obvious, two sstems thinking to be the same
appliance. Was there a change in VRRP configuration?
Because this was not working, we made a rollback. Now we have the same
memory problems again. Starting the shell, bam Low memory, show bgp
summary, los memory. Each event has consequences: disabling a BGP
session.
The system has 1 GB of DRAM. What are the memory intensive processes?
The BGP sessions? We have a J6350 at the AMS-IX where are a lot more
BGP sessions. The VRRP processes? The rpd process has a significant
higher memory consumption than on the AMS-IX router for example.
Before opening a JTAC ticket, you may be saying "get 1 GB of memory,
your problems will disappear".
Regards,
Matthias
Am 17.05.2009 um 14:54 schrieb Richard A Steenbergen:
On Sun, May 17, 2009 at 02:19:56AM -0700, Robert Raszuk wrote:
Hi Matthias,
I wonder now, which is the event, that triggered this behavious? The
numer of ssh-logins at that time or this zbexpected EOF?
I would with good deal of assurance conclude that the cause were
ssh-login attack which apparently starved the poor box to it's memory
limits.
When even your kernel spins a panic message on the low of memory
due to
such attack control plane can exhibit quite unexpected behavior. In
my
opinion end-of-frame BGP message is just a consequence of this.
The advice would be to:
* open a case with jtac to find out why subsequent ssh-logins cause a
memory leak
* reduce to very max rate-limiting for the ssh logins
It's probably more likely that the box was always getting floods of
SSH
connection attempts (because thats what happens to anything you
leave on
the Internet with port 22 open), and the low memory condition was
coincidental or 99% caused by something else. The openssh people would
be shitting bricks if there was actually a memory leak from multiple
connection attempts. Filter thy lo0 (*), but my money is on a leak
somewhere else (or someone running a 256mb RE :P).
(*) I always found it weird that JUNOS lacks a software filter for
access to things like SSH, like a line vty access-class on Crisco.
Obviously a proper lo0 firewall filter is "better", but there have
been
a few occasions where this has been problematic over the years
(logical-routers pre-firewall split where the integration with policy
was tricky, EX for the first year of its life where lo0 filters didn't
work, etc). Something as simple as a prefix-list dumping to
hosts.allow
would probably be sufficient. Also being able to change the listen
port
to something other than 22 might help the people who for whatever
reason
aren't able to do a strict IP based filter (simple option under system
services ssh to pass to sshd).
--
Richard A Steenbergen <r...@e-gerbil.net> http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1
2CBC)
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
