thanks for the details. seeing those, I think some key data is missing in the messages thus making them insufficient for taking any action. You have also demonstrated that it is possible to document how to read them (reference manual along with admin guide?). For example, a reference guide could include drawings of the headers and fields, and explanations of the types of errors that are noted. Granted, attack types change over time but some must be long standing, documentable issues. In addition, some of these error messages might relate to hardware problems or misconfigurations that could receive some troubleshooting assistance. (what will show up if one side is using HDX and the other FDX? other mismatches, etc?)

I think there is a major difference between a somewhat cryptic syslog message and what one should be putting in an email. So this happened, which IP address attempted to do the deed? if you are going to send me email, please include enough information to act on it! otherwise it is no better than spam.

Given that IPS is noting, repelling, and counting attacks, shouldn't this be handled just as some other attacks would? or did these mean some of the thresholds in the setup page were exceeded triggering the email? If that is the case, then the email ought to say which one of those thresholds was exceeded as well.

finally, I would expect any messages important enough to go out through email to also appear in the 'local log'.

nrf

Yeah, Neal I understand what you mean as far as having some mechanism to translate the messages to a more readable format. The problem with that would require more code to be included in the firmware and more CPU power to process the information. This would cause the device to be more expensive and also slow down the processing of packet information. The log system is made up of different code modules that are designed to inspect different parts of network traffic which adds more complexity. Just to follow one of your examples given concerning NIC duplex, if the NICs do not negotiate proper speed / duplex there would be no readable traffic passing through because we would have collisions. So it would be impossible to get information from the other NIC. All we would be able to capture is the default negotiation of our own NIC and nothing else.

Some of the message outputs are built into the code and relate directly to the TCP information. So taking these messages and translating them would mean more code and even then it would be extremely difficult to execute. What would be nice is if the log told us in a more readable format what "Threshold"; as you stated, was breached to at least point the administrator in the right direction.

The problems you are mentioning are not specific to our equipment however, this will hold true accross other manufacturers and you will also be able to see similarities with logging on a Linux box with IP Tables.

I know I am not really answering your concerns directly, but I can tell you that Cisco does look at the forums and suggestions posted are taken into account. What you can do, is do a google search or look into the O'Riley books for a more in depth look at the TCP packet structure. I do not mean for this to come accross in a rude or "blowing you off" manner, just as a personal suggestion.

right, google is one's friend. no offense taken.

• suppose we relegate cryptic log-like messages to the syslog, make the local log work, and restrict email to messages that make sense to be in email?
• for those looking at the logs, suppose we make them numbered into categories that make sense so they can be filtered and examined without poring over an endless surge of useless data? right now it is all or nothing - if 4 is turned on you get it all, if not you get a few dribs and drabs now and again. putting the right log level on a log message couldn't cause too much extra code, someone is already setting '4' and why not a reasonable value in its place?
  
• hex / unprintable binary codes in messages may be indicative of some issue with bad pointers or heap corruption, so in general, paying attention to symptoms can lead to a better product if one is wanting a better product.
• improved paper/pdf documentation costs zero firmware, can reduce customer inquiries, or if the customer won't read it you can quickly point them to the appropriate material.
• to the extent that a reference manual or help page documents a screen section by repeating what the screen already says, it is not doing anyone a favor.

I really like that IPS counts and categorizes events without making you pour through tons of log entries the way other routers might make you do. And when I want to review who is attacking me, I get a short list of IPs to look up without scanning logs.

At this point Cisco seems to be the place to go if one wants SNMP and more advanced network capabilities such as VLAN, The only question is whether the bottom line of quality, price, and frustration index are a good match.

nrf

ok, forums seem to have little impact on product support/quality, but at least I can dump...

Just got a WNDR3300 wireless router, as I set it up with the vendor firmware I was reminded of the slowness of setting up this rvs4000. every time you 'save' the settings, you get a slow reboot. deja-vu!

then I moved it to dd-wrt, and what a difference! Folks, if you want to see what a truly user-friendly router setup looks like, I suggest experiencing this. On each and every page you can 'save' settings, resulting frequently in additional gui items added related to extra abilities of the saved changes. When you have done all the change you want to make, then you hit a "apply changes" button and get a SINGLE REBOOT!  It can be done better, it has been done better,

get a clue!

nrf

I am attaching a document so you can see the odd hex data in the 'security emails'.

apparently, both sending the ntp request (not in attached file) and receiving a ntp reply is a security violation.

it also appears to be triggering some other stuff which is then logged as a security violation.

later, followed by some cryptic syslog stuff that is further masked by unprintable data and/or evidence of a loose pointer.

see attached.

while using free stuff to make money sounds great, if you are not contributing to making the free stuff better you are essentially a leach.

nrf