Trap and Syslog Query
Hi Everyone, Could anyone help with the following scenario and associated questions... Imagine you have a network consisting of 10,000 elements split into 1,000 devices and 9,000 interfaces. For arguments sake assume the following:- 1. The maximum number traps that the management platform will receive is 200 per second and the typical number of traps is 10 per second. 2. For Syslog - assume we have 4 syslog servers (250 devices per server) that receive a maximum of 10 messages per second per server and a typical 1 message per second per server 3. The devices are using 'out of the box' trap and syslog settings in terms of what they send. Q1. What do you think will be the percentage of 'useful' traps from a fault management perspective? Of course it all depends upon what you are interested in and what the network is doing but some thoughts about the volume of useful traps and what those traps are would be really useful :) Q2. Same question as Q1 but for syslog. Q3. What do you expect the real figures to be based upon the network operating normally and what, from your experience, are they likely to be under fault conditions? Q4. What, again from your experience, devices send the most traps and syslog messages? - is it that a particular manufacturer are particularly trap-heavy for example? Any thoughts or advice would be most appreciated. regards, Matt. _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx
Re: Trap and Syslog Query
### On Wed, 20 Mar 2002 08:34:41 +, Matt Duggan ### [EMAIL PROTECTED] casually decided to expound upon [EMAIL PROTECTED] ### the following thoughts about Trap and Syslog Query: MD Q1. What do you think will be the percentage of 'useful' traps from a fault MD management perspective? Of course it all depends upon what you are MD interested in and what the network is doing but some thoughts about the MD volume of useful traps and what those traps are would be really useful :) Everything is useful. |8^) You are right however in that it all depends on what you would consider critical, severe, informative. For instance, I would consider chassis alarms, link hard up/downs, BGP peer up/downs and adjacency failures to be immediately useful since they are directly related to correct operation of the network. Assuming a nominal state, you should be seeing zero of such useful traps. |8^) In practice, I would expect them to make up no more than 5% of your total traps unless you're having a REALLY bad day or suffering through a maintenance window. But again, it all depends on your network topology, how complex it is, what you're monitoring and what kind of services it's carrying (which ultimately defines the former criterias). Now if you extend your definition of useful to things like ACL violations then you might be seeing a lot of those (probably 80% of your traps). MD Q2. Same question as Q1 but for syslog. In general, I think the answer to Q1 holds true for this question too. You might see some things in syslog which you won't see from traps however such as boot messages and this will skew the percentages but in general I think you get nearly a one-to-one relationship between the amount and type of inromation from syslog as from traps. Based upon your description of syslog collectors (distributed and thusn presumably closer to target devices) vs trap collector (central), I would expect you might get a slightly higher number of syslog messages overall due to UDP lossage of traps but of course, not knowing you topology and network loads that's just an off-the-cuff guess. MD Q3. What do you expect the real figures to be based upon the network MD operating normally and what, from your experience, are they likely to be MD under fault conditions? I'm not sure I can provide an accurate answer to that. There are too many variables and unknowns [to me] about your network. MD Q4. What, again from your experience, devices send the most traps and syslog MD messages? - is it that a particular manufacturer are particularly trap-heavy MD for example? I think it has more to do with the configuration of the snmp agent and/or syslog facility than any particular vendor or device type. It also has to do with what the device is doing. For instance, a dialup access server configured to log every user signon/signoff will probably generate more logging information than a core router configured to just log link alarms and adjacencies. In general, I would guess that customer facing devices would be more trap-heavy than core components. -- /*===[ Jake Khuon [EMAIL PROTECTED] ]==+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=*/
Re: Yahoo Hacked?
David McGaugh wrote: Maybe it has nothing to do with it then, but No one saw a significant decrease in traffic with Yahoo between 17:00 PST and 17:15 PST? Well, yes. It appears lots of people saw it. And it was caught by Catbird, and lasted quite long... See http://www.catbird.com/images/yahoo.jpg -- Rodney Joffe CenterGate Research Group, LLC. http://www.centergate.com Technology so advanced, even we don't understand it!(SM)
Survey on IBGP persistent route oscillation problem
IBGP and Persistent Route Oscillation The Draft BGP Persistent Route Oscillation draft describes route oscillation occurring in networks today. This draft can be obtained at: http://www.ietf.org/internet-drafts/draft-ietf-idr-route-oscillation-01.txt In order to evaluate how significant a problem the route oscillation is, I would like to get input from network operators. If you could take a few moments and fill out this survey, it would help in determining the severity of the problems. Any information solicited by this survey will remain private. Summaries of this information will be sent to this list and the IDR working list. Sue Hares IDR co-chair 1) Contact information: Name: Company: Position/Responsibility: Email address: Phone number: 2 What type of network do you run (select one of the choices)? a) Enterprise network b) Service provider Tier 1 c) Service provider Tier 2 d) Service provider - other e) Exchange point f) Specialized service provider g) Other (please specify) 3) Have you seen persistent route oscillation in your network? What type of route oscillation? a) Experiencing Type I MED churn with Route Reflectors? b) Experiencing Type I MED churn with AS Confederations c) Experiencing Type II MED churn with 2 Tiers of Route Reflectors? d) Experiencing Type II MED church with AS Confederations? What steps have you taken to fix this problem? 4) If you run IBGP, please answer the questions below. (If you don't run IBGP, then the whole survey is irrelevant to you) a) How many IBGP peers in your network? How many of routes are carried in IBGP? b) Do you use MED? Are you transit for other Ass? c) Do you use Router Reflectors? How many levels? d) Do you use AS confederations? How many AS in confederations? 5) If you run EBGP, How many EBGP peers do you have? How many other Autonomous Systems (ASs) do you peer with? Do you use MED or AS Confederations? [If you don't run EBGP, then the whole survey is irrelevant to you)
Re: Yahoo Hacked?
The whois server has a really loose pattern matching engine. This is actually a host record for: JIMPHILLIPS.ORG ACIDULOUS.COM CANADIAN.ORG COM.BR SHEEPSTER.COM SAFESEARCH.COM The last one is what you are looking for - yahoo.com This is becoming more and more common. Look at microsoft.com, apple.com, etc. At 06:17 PM 3/19/02, David McGaugh wrote: whois -h whois.internic.net yahoo.com Whois Server Version 1.3 Domain names in the .com, .net, and .org domains can now be registered with many different competing registrars. Go to http://www.internic.net for detailed information. YAHOO.COM.REALLY.NEEDS.TO.GET.A.CLUE.AT.JIMPHILLIPS.ORG YAHOO.COM.IS.TRYING.TO.STEAL.YAHOO.VU.HOW.ACIDULOUS.COM YAHOO.COM.IS.NOT.CANADIAN.ORG YAHOO.COM.BR YAHOO.COM.AND.SAFESEARCH.COM.AINT.NOTHING.COMPARED.TO.SHEEPSTER.COM YAHOO.COM.AINT.NOTHIN.COMPARED.TO.SAFESEARCH.COM YAHOO.COM To single out one record, look it up with xxx, where xxx is one of the of the records displayed above. If the records are the same, look them up with =xxx to receive a full display for each record. Last update of whois database: Tue, 19 Mar 2002 17:10:53 EST The Registry database contains ONLY .COM, .NET, .ORG, .EDU domains and Registrars. -- Brandon Handeland [EMAIL PROTECTED] Senior Network Engineer wyoming.com NOC (307) 857-1092 --
Re: Question re. SSH
On Wed, 20 Mar 2002 11:50:22 -0500, Steve Sobol wrote: Apologies in advance for any operational content this may contain. I have a customer who wants to get a static ip with his dialup. He uses SSH extensively and plans to do X11 forwarding, and if he gets disconnected and redials and gets another IP the previous sessions would be inaccessible. I can do static IP but I want to try to save the guy a couple bucks. :) Would a static IP be required to make sure he doesn't lose those X11 sessions after a disconnect? No. He just has to be able to request a 'preferred' IP and be granted it if it's available. DHCP can do this. On his end, he must request his last IP as his 'preferred' IP. On your end, you must give a client the IP they request if it's available. If you want to be really slick, you will 'reserve' an IP for 2 minutes after it's released and only allow it to be reissued (within those two minutes) to the same user. This protects all your dialup users from session hijacking and gives them some of the benefits of a static IP while still allowing you to overcommit IP addresses. Asking here because I figure my chances of getting an accurate answer are better here than on any of the other mailing lists I read. DS
Re: ICMP filters again
At 05:16 AM 3/20/2002 -0700, Christopher E. Brown wrote: Is it just me, or are the Tripod member sited filtering type 3 ICMP again? (Think 1500 octet MTU links and DF/FN) Would be nice if there was a list somewhere of sites that did this. Would sure make troubleshooting customers complaining of unreachable web sites a heck of a lot easier. (Think MLPS over 1514 byte pipes)
Reliable, mass distribution (was Re: CEOlink)
On Thu, 14 Mar 2002, Iljitsch van Beijnum wrote: In theory, news would be more rebust than mail, because of its distributed nature and it should be possible to make news work without relying on the DNS. USENET/news has a few properties which make it reliable. The most important is the flooding method of propagation. Second, it propogates over multiple types of transport (UUCP, TCP/IP, Satellite, Magtape via Fedex, etc). That combination results in an extremely robust mass-distribution method for messages. It is also extremely fast (a few seconds for the core news sites), but has a very long tail. Mailing lists, web sites, etc. have a bottleneck in the distribution process. But are much better for controlled, or authenticated information. The CDC may get hacked, or may be wrong about Anthrax, but if you go to the CDC web site it is highly probable the information on the web site is from the CDC. The lack of control of USENET is its strength and its weakness. It would be interesting to come up with a protocol that combined the robust flooding algorithm of USENET with a way to verify the source (i.e. prevent spam).
Re: Reliable, mass distribution (was Re: CEOlink)
On Wed, 20 Mar 2002, Sean Donelan wrote: It would be interesting to come up with a protocol that combined the robust flooding algorithm of USENET with a way to verify the source (i.e. prevent spam). I'm not sure what problems you see with Usenet that would prevent it being used for what you require. It's certainly almost as easy to varify as email. With email you let just about any site on the internet contact you and send deliver using any address, with news you have a limited number of sites that you have directly authorized. You can also sign (via pgp or whatever) news articles the same way you sign email messages. It is also fairly easy to make news keep working even after long-term DNS failures (it tends to not be affected by short term ones). Verifying the source is not the same as preventing spam, like email spam most news spam comes from open sites and throw away accounts. I doubt most people here check most web pages and email messages they view for DNS poisoning or forged headers. -- Simon Lyall.| Newsmaster | Work: [EMAIL PROTECTED] Senior Network/System Admin | Postmaster | Home: [EMAIL PROTECTED] ihug, Auckland, NZ | Asst Doorman | Web: http://www.darkmere.gen.nz
Re: ICMP filters again
On Wed, Mar 20, 2002 at 04:58:03PM -0800, Donn Lasher wrote: Would be nice if there was a list somewhere of sites that did this. Would sure make troubleshooting customers complaining of unreachable web sites a heck of a lot easier. (Think MLPS over 1514 byte pipes) http://home.earthlink.net/~jaymzh666/solaris/mss_initiative.html -- religious fanatics are not part of my desired user base. - [EMAIL PROTECTED]
