PIX monitoring and fine tunning question

[Shahin Ansari <zohal52 () yahoo com>]

Greetings-
   I read the following on a different group, and
wonder if you are trying to investigate what you are
spending your firewall resources, and where your
bottleneck ( cpu, connections, etc ) is; and most
important how to get rid of bogus packets vs. real
traffic would you use syslog or snmp, and what level
would you monitor at?  ie. From the eight level of
logging, what level should I monitor at?  What
speciffic information will help me fine tune and
understand for instance a higher than normal number of
connections per sec? Thank you in advance. 
Here is the discussion:
*******************************************
Actually, Michael, syslog is more "on-topic" than you
may realize. 

For normal network management functions the SNMP traps
are good and
useful.  They overlap with the logging levels 1-6
("emergencies" through
"informational"--see the table at
http://www.cisco.com/univercd/cc/td/doc/product/software/ios112/112cg_cr/1rbook/1rsysmgt.htm#24127).

And the SNMP applications (HP OpenView, Tivoli, etc.)
are easy on the
eye and easy to interpret.  But syslog provides some
additional
capabilities which are particularly relevant to R&D
work or to CCIE
practice.  

SNMP will give you the link-down and link-up and gross
hardware status
messages you would need to do day-to-day monitoring of
a production
network (informational messages).  But if you want to
get down into the
guts of a problem, or measure a particular interaction
between and among
your routers, syslog is an unparalleled
troubleshooting tool.  

The very best thing syslog can do for you is take your
router's debug
messages and store them in a database for retrieval
and examination
later.  Recall that with many debug commands, the
output tends to scroll
off the screen before you can read it--syslog to the
rescue here.  And,
if you configure your router to put timestamps on your
debug output, you
can get a nice indication of how long the router(s)
is/are taking to do
something.  The timestamps applied by the router are
independent of
delays imposed by overloaded network segments and
buffering delays. 

Inasmuch as all the routers in a routing domain work
as a system, the
timestamped debug output can be useful in figuring out
how much time it
takes for a router in one part of your network to get
information from a
router in another part, and how much time it takes to
process the
information into the routing table.  If you need to
look at the output
of several routers, this is the only way to do it. If
the routers are
using a universal time source (NTP or an atomic
clock), and each router
is inserting the timestamp when it sends the packet,
you should get a
reasonable picture of when things are happening
relative to each other
within the network. 

So, what do you need for this to work?  Configure your
routers for NTP,
first of all.  This will cause them all to coordinate
their internal
clocks so the timestamps will be reasonably accurate
and synchronized. 
Then, configure your routers to timestamp their debug
output (service
timestamps debug datetime msec).  Finally, configure
the routers to send
their debug output to a syslog server instead of the
console: 

logging nnn.nnn.nnn.nnn !ip address of syslog server
logging trap debugging  !very important--otherwise you
only get 
                        !informational messages, no
debug output
no logging console      !turns off those nasty debug
messages to console

Of course, you need a syslog daemon (server) on a
separate box to accept
the packets and organize them.  There are syslog
daemons for all common
OSs, including Windows 95 and NT, and every flavor of
UNIX.  

Good luck, and good debugging.

Pamela

Jim.Grina@xxxxxxxx wrote:
> Micheal,
>
> It sounds like you have both an SNMP based
monitoring system (openView,
> Tivoli, or something like that) plus a UNIX host to
do syslog on. I'd focus
> on getting the SNMP traps to your network monitoring
station and not worry
> too much about syslog, especially if you have a
person monitoring the
> monitor. If it is just for yourself, take whatever
is easier.
> Jim
>
> "Michael Cox" <mscox@xxxxxxxxxxxxxx> on 11/09/98
02:24:33 PM
> Please respond to cisco@xxxxxxxxxxxxxx
>
> To:   cisco@xxxxxxxxxxxxxx
> cc:    (bcc: Jim Grina/US/BULL)
> Subject:  traps/syslogs (may be off-topic)
>
> I hope this isn't considered off-topic. I don't
suppose it would be since
> it
> seems we have a general Cisco help-line going here
though geared towards
> the
> certifications. Many thanks to Pamela and the many
others who have been so
> helpful...
>
> My question regards SNMP traps and syslog messages
and the best way to
> implement in an 80+ router enterprise environment.
Currently we are
> receiving neither (sounds kinda bad but that's the
way I inherited it).
> I understand that syslogs can be sent as traps if
configured to do so, so I
> was thinking of going that route to send to the same
box as other traps.
> But
> what level of messages should I be receiving? What
traps? Would I be
> running
> into some overlap (I don't really want to get a
linkdown trap and a similar
> syslog-originated trap for the same event)? Do I
need to do syslogs at all
> -
> is there anything there that I couldn't get from the
other MIBs?
> I'm mostly concerned with the WAN side of the house,
btw.
> Hope that's not too vague... thanks in advance for
any response.



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
_______________________________________________
firewall-wizards mailing list
firewall-wizards () listserv icsalabs com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards