[j-nsp] Syslog action performance impact

[Josef Buchsteiner]

Friday, April 1, 2005, 6:10:50 PM, you wrote:

  
JB> Greetings,

JB>  I'm wondering how much a Syslog action in firewalls filter really
JB>  does impact performances.

JB>  Throwing a few scans (~10 kpps) on a M20 running JunOS 6.4R2.4, I
JB>  noticed that syslog message generation is rate-limited, but I don't
JB>  know to what extent.
JB>  I was unable to find any documentation about it.
JB>  So how is it done ? By the SSB / the routing engine / both ?
JB>  What is the actual rate limit ?

     Jean,
          First there are queues from the Internet Processor towards
          the processor on the Forwarding Engine. If you send to much
          traffic we will start dropping and you would see this with
          the following command under 'hardware input drops'

josefb at Vienna-re0# run show pfe statistics traffic

<...>

PFE Local Traffic statistics:
      78936 local packets input
      36491 local packets output
          0 software input high drops
          0 software input medium drops
          0 software input low drops
          0 software output drops
     194716 hardware input drops          

<..>

            There  are  several queues and this hardware input counter
            is   an  aggregation  of  all  queues  from  the  Internet
            Processor  towards  the Processor on the PFE. Here you can
            make  test  and  will  see  that  you  will start dropping
            packets in hardware at about 6500 to 7000 pps.


            Once  the traffic is then send to the Processor on the PFE
            we  will  have  further  tools  to rate limit those and do
            further  actions.  For  syslog we first look at the syslog
            cache  and  see  if  there  are any occurrence of the same
            message. If this is the case we just report the occurrence
            and we will send 1 pps towards the RE. In case each of the
            syslog  message  is  different  we  will  send about 10pps
            towards the RE. So ultimately you should start dropping as
            early  as you can as once the traffic is already at the RE
            it  is  too  late  ;-). with this scheme you should not be
            able  to  overload the regular syslog queue used for other
            message generated from the PFE to the sylogs server on the
            RE.

            In  case  the  queue is getting hammered ' usually seen in
            lab  environment when you enable debugging' you will get a
            message  log  entry that you lost syslog message due to no
            buffers which you should not have seen.


            hope this helps
            Josef



JB>  Depending on the way the rate-limiting is done, is it possible that
JB>  some important messages, like hardware failures, could not be sent
JB>  if the box is sustaining a really heavy port scan ?
JB>  If this is the case, is it possible to set a different priority to
JB>  each log facilitity ?

JB>  It'd be nice if people of Juniper could comment on both
JB>  issues.

JB>  Any help would be appreciated,

JB>  --
JB>  Jean BENOIT
JB>  Centre Réseau Communication
JB>  Université Louis Pasteur, Strasbourg
JB>  _______________________________________________
JB>  juniper-nsp mailing list juniper-nsp at puck.nether.net
JB> http://puck.nether.net/mailman/listinfo/juniper-nsp