Re: Anyone from Verio here?
Just going off your email address/domain, it occurs to me that your problem may in fact be far to leet for the likes of nanog to handle. Have you tried an efnet oper? They have far superior leetness, and quite likely a little more time on their hands. One of them may also own that botnet, so you'd be hitting two birds with one stone. - billn On Wed, 16 Apr 2008, Jake Matthews wrote: I've sent repeated emails to [EMAIL PROTECTED]/com/*, no response yet. There is an IRC DDoS bot on EFnet actively attacking users - and has been for quite a while, as you can see from the signon date. I am one of those being hit - any idea how to take care of it? g is [EMAIL PROTECTED] * sharon stone g on @#tcp @#ping @#nsa.gov @#london @#jupe @#dust g using irc.wh.verio.net ooh omnipotence. mm yes gotta get me some of that. g actually using host 81.19.98.235 g has been idle 2mins 12secs, signed on Thu Apr 03 23:53:18
OT: vendor spam
Anyone seen spam from Uplogix.com? As it came to this email address, which I don't give to vendors for exactly this reason, I'm suspecting it's been harvested from this list or maybe c-nsp, the only other list I'm active on, for sporadic amounts of active. Has anyone else seen this? I'd like to verify the source before I add nails to the clue-by-four. - billn
Re: do you know how to dump packet to see vlan info
You can use the 8021q module in linux, and the vlan tools to run an interface as a dot1q trunk. I'm not sure off-hand about the other distributions, but under Debian you just need the 'vlan' package. modprobe 8021q ifconfig eth1 up vconfig add eth1 vlan id ifconfig eth1.vlan id ip address netmask netmask Configure your switch port to trunk mode, tag your vlans onto it, et voila. This will give you a presence in as many broadcast domains as you decide to tag. - billn On Wed, 19 Mar 2008, Jon R. Kibler wrote: ann kok wrote: Hi all I am using linux as router to connect to switch do you know how to dump packet to see vlan info? Thank you You won't see vlan info unless you are on a trunking port. Jon Kibler
Re: load balancing and fault tolerance without load balancer
NANOG really isn't the forum for this kind of conversation. That said, look into devices like Alteons, or open source solutions like Balance-NG. Even Apache can be used for this with something like mod_proxy. Good luck. - billn On Sat, 15 Mar 2008, Joe Shen wrote: hi, we plan to set up a web site with two web servers. The two servers should be under the same domain name. Normally, web surfing load should be distributed between the servers. when one server fails, the other server should take all of load automatically. When fault sever recovers, load balancing should be achived automatically.There is no buget for load balancer. we plan to use DNS to balance load between the two servers. But, it seems DNS based solution could not direct all load to one server automatically when the other is down. Is there any way to solve problem above? we use HP-UX with MC-Service Guard installed. thanks in advance. Joe __ Tired of visiting multiple sites for showtimes? Yahoo! Movies is all you need http://sg.movies.yahoo.com
RE: Area Social Activity
Given that the last reported water temperature in Monterey was 52.9F, I think there will be more drinkers than divers. - billn On Thu, 14 Feb 2008, Rod Beck wrote: I am suggesting a Certified Drinkers Event in the hotel bar Sunday evening. -Original Message- From: [EMAIL PROTECTED] on behalf of Owen DeLong Sent: Thu 2/14/2008 3:36 PM To: North American Network Operators Group Subject: Area Social Activity Sorry for the short notice. For anyone coming to NANOG early who is a certified SCUBA DIver, I'll be diving in Monterey (about 1 hour drive from San Jose) Saturday and Sunday. If you're interested in joining me, send an email off-list. Owen DeLong Open Water SCUBA Instructor (PADI)
Re: [admin] Using the NANOG list as a paging mechanism
On Fri, 4 Jan 2008, Patrick Clochesy wrote: I think the page is going to the list because the sender does not know the contact for the site, and the list provides a good way to find someone to handle the request... the intended recipient of the page being a north american network operator :) We could come up with a list or an updateable site, but it's bound to be abused and thus ignored, the same reason people arn't sending to abuse@ and postmaster@ in the first place. I think the reason such a site doesn't exist already is because it's a spam seed. Nanog lists are archived, aren't they? Searching for a user from a specific domain might net more immediate results, in some cases, provided the search result doesn't have a timestamp of 2005 or older. - billn
Re: [admin] Errors to NANOG list subscribers take II
On Fri, 9 Nov 2007, Jay R. Ashworth wrote: On Fri, Nov 09, 2007 at 11:11:28AM -0500, Martin Hannigan wrote: On Nov 9, 2007 11:00 AM, Bill Nash [EMAIL PROTECTED] wrote: Given the serious impact this is having on operations, does this have a master ticket number or escalation id of some type? Has the vendor been involved yet? When can we expect to see a post mortem/RFO? Try not to get overly ridiculous here. The updates are to keep people informed that everyone on the back end cares. Now, see, Bill, I could've *told* you that humor would be too dry for Martin. :-) Cheers, -- jra For those scoring on technique or style, I call that one 'Shooting the Moon'. =) - billn
Re: [admin] Errors to NANOG list subscribers take II
Given the serious impact this is having on operations, does this have a master ticket number or escalation id of some type? Has the vendor been involved yet? When can we expect to see a post mortem/RFO? - billn On Fri, 9 Nov 2007, Martin Hannigan wrote: Dear Colleagues: As you know, we are all seeing a single mailer message show up in our mailboxes at ~0330/est on a daily basis. We are aware that this is on-going. The issue is being actively worked on by the admin team at Merit and a resolution is forthcoming. Since the message happens once a day, it's understandably difficult to make a best effort determination that a fix will take hold. There isn't a test or dev system to try out solutions. This problem has been assigned a reasonable priority by the folks at Merit and we hope to see it fixed soon. Thanks to all who have let us know about this. Best Regards, Martin Hannigan NANOG MLC Member
Re: OT: Vendors Using NANOG for a Sales Channel
On Fri, 26 Oct 2007, Scott Weeks wrote: I would suggest that no one should buy from vendors who get email addresses from NANOG or other technical mailing lists. It will only encourage them to do it more and ruin the value of the mailing list in question. You obviously haven't had the experiences that some have had with sales folks that use this method. Some are like the little Chihuahua that won't quit trying to hump your leg. No matter how many times you tell them you're not going to do it they keep trying. However, the company in this case did redeem themselves and I respect a company like that. Which is to say, they were one of the few that apologised. The recurring theme is that it's always a rogue salesperson who didn't know better, or some overzealous marketing person. I'd agree with Scott on this point, that you shouldn't buy from vendors who do this, but ultimately, it's not going to change the way they behave. Over the course of my entire career, I've never been a fan of salespeople, because they do what they're supposed to do: whatever they can to make money. In our particular field, it cuts both ways, because they're either hassling you to buy something, or your own salespeople are selling something you can't support or don't even offer. It's the kind of thing that probably won't change until someone whips out one of the spam laws and sues a couple people over it, or engages in executive carpet bombing. Either way, it's always going to be a temporary reprieve until it gets out of hand again. It'd be churlish of NANOG, as an organization, to organize blacklists and boycotts, and probably even shooting itself in the foot because some vendors may actually be offering something worthwhile, but is there any other real solution? How often do people take the time to ask any given salescritter how they came by contact info? - billn
Re: ICMP unreachables, code 9,10,13
On Wed, 28 Mar 2007, Christos Papadopoulos wrote: My next question is about responses to ICMP pings (echo request), when they return ICMP UNREACHABLE with codes 9,10 or 13. Responses with these codes seem to imply the presence of a firewall. Is this assumption correct or are these codes meaningless? They do have meaning, and you do see them in production (generally in traceroute responses.) These can indicate the presence of either a firewall, or an ACL. Both traffic barriers are typically configurable, and whether or not you get a response is very often dictated by how hardcore the network engineer or security engineer is about giving up information about their network. If this a configurable parameter, how to you typically decide what to set it to? See previous comment about relative values of hardcore. Arguably, use of these options is telling the end user things about your network configuration, including, very specifically, which device is blocking their traffic. Depending on your security stance and requirements, this may be good or bad. Personally, I simply drop the offending packets into the bitbucket and let the user wonder. - billn
Re: Phishing and BGP Blackholing
On Thu, 4 Jan 2007, Pete Templin wrote: This place is full of people with opinions. Some like it hot, some like it not. We are never going to agree on top/inline/bottom posting. Why can't we all just get along and discuss operational issues? Let's throw preference out the window and speak to practicality for a minute. If you're reading nanog-l from a blackberry or mobile, and paying by the byte to do so, you're either an idiot or work for a company wealthy enough not to care (My opinion.) But, even blackberry users land at a laptop or workstation at some point. 9 times out of 10, nanog chatter isn't about life-and-death critical ops outages and the like, it's people having casual discussions. Most blackberry users are on-the-go types, running from meeting to meeting or site to site. The only reason I could see such a user reading nanog is because they're bored, have some downtime, or have a fervent need to look cool at Starbucks. Much like anything else, the world will not warp and bend to your preference. As a living organism, it's up to you to adapt to your environment. Just don't be like Randy and whiz in the pool because someone did something you didn't like and we'll all get along great. - billn
Re: Phishing and BGP Blackholing
On Wed, 3 Jan 2007, Andy Davidson wrote: From a 'problem solving' perspective, a Team Cymru-style bgp peer that injected very specific routes into their routing table, and matching configuration which caused those particular routes to be dropped would be ideal. Additions and deletions would be as close to real-time as possible. From a political perspective, I could only advocate to clients such a service that had a strict policy of adding routes to addresses because of a provable policy infringement. For example, a route for 1.2.3.4/32 would only be announced by my bgp-blacklist peer if it could be demonstrated that a device reachable at 1.2.3.4 was an open http proxy (or socks proxy, or smtp relay) and not because a phishing site was hosted there. Different priorities for different networks I guess .. disclaimer: I do development work for the company I'm about to endorse. I endorsed this product before when I was a client. I've since left my previous position and gone to work on it. This is one of the very few posts I'll ever make that's in any way representative of an employer. Mainnerve's Darknet product is exactly that: A managed blacklist of malicious/hacked sites. Currently, phishing sites and open proxies, make it into blacklist, but drone network CCs do. Darknet is intended to intercept traffic leaving your network to known CCs. Currently, this involves a device deployed to your network, that hosts a BGP peer to your network to supply the blackhole routes, redirecting the CC traffic to the darknet device for packet analysis. I'm currently working on a newer implementation that involves just a BGP peering session and a GRE tunnel, to eliminate the hardware deployment and simplify the whole process, so it functions very much like the bogon filter. - billn
Re: http://cisco.com 403 Forbidden
On Wed, 3 Jan 2007, D'Arcy J.M. Cain wrote: On Wed, 3 Jan 2007 16:39:40 + Simon Waters [EMAIL PROTECTED] wrote: [...] Working fine here. Resolves to 198.133.219.25 What does DNS resolution have to do with 403 web errors? Determining if this is an episode of GSLB's Gone Wild. - billn
Re: Phishing and BGP Blackholing
On Wed, 3 Jan 2007, Bill Nash wrote: malicious/hacked sites. Currently, phishing sites and open proxies, make it into blacklist, but drone network CCs do. Darknet is intended to Someone pointed out my typo. This should read 'phishing sites and open proxies don't make it into the blacklist'. Sorry for any confusion the may have inflicted. Drink more coffee! - billn
Re: Phishing and BGP Blackholing
The biggest challenge I can see is scrubbing phishing reports that aren't.. themselves.. maliciously crafted phishing attacks against a registry of such addresses. Likewise, since BGP isn't application aware, when you blackhole an address that's both website and mail server, how do you inform the end user about their problem, or get a notice from them that it's been fixed? This kind of solution has a huge trust factor hole in it. Distributing a BGP based blackhole list is trivial. The intelligence that goes into it is the hard part. There are companies that provide managed services like this (bgp blackhole route servers for known problem sites, like drone CC's). (disclaimer: I do development for one.) - billn On Tue, 2 Jan 2007, Joy, Dylan wrote: Happy New Year all, I'm curious if anyone can answer whether there has been any traction made relative to blocking egress traffic (via BGP) on US backbones which is destined to IP addresses used for fraudulent purposes, such as phishing sites. I'm sure there are several challenges to implementing this... Regards, Dylan Joy Network Security Analyst, BECU NOTICE: This communication and any attachments may contain privileged or otherwise confidential information. If you are not the intended recipient or believe that you may have received this communication in error, please reply to the sender indicating that fact and delete the copy you received without printing, copying, retransmitting, disseminating, or otherwise using the information. Thank you.
Re: Phishing and BGP Blackholing
Hi. You have sent a message to the entire list that seems to be some sort of automatically generated product of the Smugotron-2000, intended to annoy a single person but is actually annoying everyone. Your mail user agent detected something you didn't like, and instead of simply deleting it, went out of it's way to be annoying. I do not accept such mail. Yes, I know your mail environment automatically responded to it, but seriously, why inflict your curmudgeonly attitude on everyone else? Thankfully, I'm not quite as pedantic as all that, so I took the time to hand craft this missive, just for you! When I'm done, I'll think about coding myself an auto-responder that sends you something else, just like it, whenever you post. Because that's cool, right? /troll - billn On Tue, 2 Jan 2007, Randy Bush wrote: you have sent a message to me which seems to contain a legal warning on who can read it, or how it may be distributed, or whether it may be archived, etc. i do not accept such email. my mail user agent detected a legal notice when i was opening your mail, and automatically deleted it. so do not expect further response. yes, i know your mail environment automatically added the legal notice. well, my mail environment automatically detected it, deleted it, and sent this message to you. so don't expect a lot of sympathy. and if you choose to work for some enterprise clueless enough to think that they can force this silliness on the world, use gmail, hotmail, ... randy
Re: Phishing and BGP Blackholing
On Tue, 2 Jan 2007, Travis H. wrote: On Tue, Jan 02, 2007 at 06:20:01PM -0700, Bill Nash wrote: The biggest challenge I can see is scrubbing phishing reports that aren't.. themselves.. maliciously crafted phishing attacks against a registry of such addresses. Can you rephrase that? I want to understand but I'm failing. If you decide to operate some sort of registry for these sites, what's to stop a user from crafting what appears to be a malicious submission, with the intent of getting someone blackholed, just for grins and giggles? Again, trust factor. IIRC, Riverhead DoS-mitigation systems use a similar mechanism for filtering out DoS packets en route. I think Prolexic also uses a similiar method. Oh, and yes, even for one IP, you're still going to have collateral damage if they're doing shared hosting, since one IP serves many sites. The only way around this is to actually do layer 7 decoding, but if the intruder can already set up one phishing account, I would be hesitant to assume the other co-located sites are really safe to browse. Well, in many of those cases, you're talking about shared hosting environments, hundreds of mom and pop sites that actually are safe to browse, but running whatever vulnerable content-management kit was provided to them that got the box popped in the first place. - billn
Re: GBLX issues?
On Wed, 13 Dec 2006, Aaron Glenn wrote: On 12/13/06, J. Oquendo [EMAIL PROTECTED] wrote: Anyone seeing issues for GBLX around NY? dude, chill. no need to yell. you know, GBLX sells a lot of different stuff - are we talking IP transit, MPLS transport, wavelength, voice? what kind of issues? how is anyone going to know what you're talking about when you're as vague as humanly possible. You're awful at this game. When faced with a totally vague question, lacking context or useful information, it's up to you to supply your own. Start with, always: Yes, vendor is having problems in location. Then, tap your coworkers for assistance: 1: Name a hardware Vendor (the lower the stock value, the better) 2: Name a transport technology (frame relay, sonet, etc) 3: A number between 1 and 10. 4: A number between 8 and 32. 5: A seasonally relevent catastrophic event (snow storm, backhoe, exploding squirrel) Respond: Yes, vendor is having problems in location. Seems 5 hit this morning around 3 am, effecting 2 connections in that location. Vendor is having problems getting backup systems online, because they were idiots and deployed 1 gear without failover. At last check, it'll be at least 4 hours before they get things sorted out. - billn
RE: GBLX issues?
On Wed, 13 Dec 2006, Alex Rubenstein wrote: this morning around 3 am, effecting 2 connections in that You mean 'affecting.' Pobody's nerfect. - billn
Re: link between Sprint and Level3 Networks is down in Chicago
On Thu, 9 Nov 2006, Deepak Jain wrote: Does someone know if this is a *single* link down?? It seems bizarre to me that there would only be a single link (geographically) between those two. Whatever happened to redundancy? Accounting. ;) - billn
Re: Interesting new spam technique - getting a lot more popular.
And let me tell you.. inheriting a network like that, knowing a better way to do it, will make you want to put a gun in your mouth. Two /19's worth of address space in VLAN1 (not just in one vlan, but in vlan *1*. Cisco nerds are slapping foreheads or spitting Coke right now.) Trying to migrate customers to their own vlan when they've been alloted IPs, willy nilly, across one of the bajillion /24's secondaried on the vlan interface drives me into an entire new dimension of pissed off. Don't even get me started on allocation and traffic accounting. - billn On Wed, 14 Jun 2006, Richard A Steenbergen wrote: On Wed, Jun 14, 2006 at 07:03:10PM -0400, Matt Buford wrote: As a hoster with many customers on large shared VLANs perhaps I can add a bit... Note that if you're reading this list, you have already identified yourself as a non-typical hoster. Go read WHT or GFY for 10 minutes for an example of typical hosters, and if you're not a drooling idiot in need of a brain transplant afterwards consider yourself lucky. :) And don't forget, there are hundreds of hosting networks like the ones I described, a lot of whom are in the 1 - 30Gbps traffic range, with absolutely no clue how to do better. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Geo location to IP mapping
It works for spammers. - billn On Mon, 15 May 2006, Brian Wallingford wrote: I'm not quite comfortable with the idea of building a market audience based on data with at best dubious accuracy. On Mon, 15 May 2006, Martin Hannigan wrote: :At 12:49 PM 5/15/2006, Brian Wallingford wrote: : :cough scam_snake_oil_etc /cough : : :How so?
Re: Geo location to IP mapping
Google's available geolocation resources are much more direct: They can get the information directly from the user. Google mail users setting location information, google home page users setting weatherbug details, common location searches in google maps, or local business directory searches. Taken in connection with neighboring IPs, you can generate the correlations statistically, even going so far as being able to make a good guess at a dialup IP versus an 'always on' connection. This would be the same for MSN, Yahoo search, or any portal based search engine. Forget relying on a thousand different companies hopefully keeping accurate records, *if any* about what IP where. The user is, for once, a much better source of information. - billn On Mon, 15 May 2006, Kevin Day wrote: We use a Geo/IP location database. It's surprisingly accurate, with a few exceptions. The company we purchased the database from uses a number of sources of data, to produce something pretty accurate: 1) WHOIS records for the IP assignment 2) WHOIS records for domain in the PTR record for the IP 3) Parsing the PTR record for city names and airport codes 4) Purchasing IP/billing and shipping city,state,zip records from sites with accurate records (e-commerce and other sites that people need to enter their local info) 5) All of the above for the hop or two before the end in a traceroute 6) BGP and traceroute comparisons to determine where the boundaries are in how you've internally routed things Even if you're just allocating from a single /20, you probably have some hierarchy, and that can be picked up through routing or DNS or SWIP. Comparing the database to the IP that our customers used to make purchases we exceed 95% accuracy in identifying the country, and 75-85% in city/state. The big exception is AOL, since their IP assignments are pretty well randomized with respect to geography. Never underestimate what can be done through regular expressions and an army of people sitting at terminals in China to verify what can't be automated. :) For those of you really interested, email me privately and i'll dump what we have on record for a block or two of yours.
Re: Determine difference between 2 BGP feeds
Were I faced with this reporting equirement on an on-going basis, I'd
suggest establishing a read-only BGP peer with both devices and comparing
directly. I've got a perl BGP peering daemon that feeds and maintains a
mirror of the BGP routing table into SQL, applying updates and withdrawals
as they come in. Setting up something similar, and adding some additional
metrics to keep entries unique by peer source would facilitate your end
goal with simple SQL grouping mechanics.
- billn
On Tue, 18 Apr 2006, Marco d'Itri wrote:
On Apr 18, Scott Tuc Ellentuch at T-B-O-H [EMAIL PROTECTED] wrote:
Is there a utility that I can use that will pull the
routes off each router (Foundry preferred), and then compare
them as best it can to see why there is such a difference?
I have one, but it's cisco-specific:
http://www.bofh.it/~md/software/cisco-tools-0.2.tgz (the dumppeers script)
Then you can easily find the missing routes with commands like:
awk '{print $1}' ../routes/1.2.3.4 | sort ROUTER1
awk '{print $1}' ../routes/1.2.3.5 | sort ROUTER2
comm -23 ROUTER1 ROUTER2 MISSING2
--
ciao,
Marco
Re: Determine difference between 2 BGP feeds
On Tue, 18 Apr 2006, David Andersen wrote: Much of what Bill described below is already present using Nick Feamster's bgptools release: http://nms.lcs.mit.edu/software/bgp/bgptools/ Start with zebra / quagga / etc., which do a great job of dumping tables and updates. Then use bgptools to take the MRT-formatted dumps that Zebra spits out and turn them into text, etc. With the '-q' option, can insert the BGP updates or table snapshot directly into a SQL database. My peer actually comes from a Zebra box, so I'm not talking directly to any production devices, in the event that I want to bounce my db feed up and down (debugging, featuritis treatments, etc) Z/Q + bgptools is a great suggestion for doing complex reporting/comparison on the routing tables, though. I've got a need for a more real-time view, so my setup fits me a little better than your suggestion, but potato/potatoe. =) then the libbgpdump.a library gives you lots of cool things on top of that. You'd have to do a little work to get the analysis tool you want, but it's pretty easy. Use the 'buildtree' starting program to build the prefix tree from each provider and then compare those two trees (see which prefixes are present/not present, see if any parts of the IP space are unreachable in in one and unreachable in the other, etc.) This is pretty interesting, I'll have to tinker with it, especially since I know one of my providers doesn't give me a full routing table. It starts as Bill suggested - a read-only BGP peer from the devices, which takes about 3 seconds to set up. And for folks to whom this is new stuff: don't be an idiot, put Zebra/Quagga up as a peer/buffer for attaching analysis tools to your network. *Never* attach development grade tools to a production device, most especially when you're dealing with a routing table. Not that I've ever taken down a live router in this manner[1], I'm just saying.. ;) - billn [1] All smirking current/past coworkers are kindly invited to stfu. =)
Re: Backbone Monitoring Tools
Wouldn't you be better served just walking the netToMedia tables for your devices? Parsing configs sucks. Even caching the contents of a simple snmpwalk would save you some pain. Shovel 'em into a db and call it a day. - billn On Wed, 29 Mar 2006, Ashe Canvar wrote: Well, True. But the idea is to have a full mesh of 'n' sensors each doing 'tests' to the remaining n-1 sensors. Finding asymmetric routes should be trivial as I plan to feed it my router configs from rancid, for detecting interfaces that belong to the same router. ( Of course, this can't be extended to the Internet in genral. ) From all the replies I have received, I don't think anything open source fits the bill. Going to the mines to write my own. Good bye cruel world... On 3/29/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Tue, 28 Mar 2006 16:07:27 PST, Ashe Canvar said: 2. actively detect routing changes / failover to redundant paths using traceroutes i.e. alert if SFO-CHG-NYC changes to SFO-LXE-HOU-NYC ( link state protocols suck as far as testing backup paths go) Two words: Asymmetric routes. Just be aware of the implications.
Re: Backbone Monitoring Tools
If you can't say something useful.. Assuming you're looking for basic latency and availability monitoring, with alerts: http://www.smokeping.org - billn On Tue, 28 Mar 2006, Jon Lyons wrote: mrtg.. Ashe Canvar [EMAIL PROTECTED] wrote: Hi All, I want a simple backbone monitor for my 5 datacenters. My backbone consists of redundant IPSEC/GRE tunnnels. At the very least I want to ping, traceroute and transfer a small file every few minutes over all IPSEC links. I am sure there are products that do this already, but I am having a hard time finding any. The display format should be noc-friendly. A basic grid with green/red status indicators at the least. Geographical maps a plus. Do most of you use a home grown tool for this monitoring and alerting ? Regards, Ashe - Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1cent;/min.
Re: UDP Badness [Was: Re: How to measure network qualityperformance for voipgameservers (udp packetloss, delay, jitter,...)]
On Fri, 10 Mar 2006, Richard A Steenbergen wrote: On Fri, Mar 10, 2006 at 11:52:40AM +, tony sarendal wrote: Does traceroute really do that ? Even for ICMP. Think about it. Hint: the return packets your traceroute produces, do they have the same return path for every hop ? Think Internet, think large providers with many peerings. On behalf of every network operator on the planet, I would like to take this opportunity to encourage every person who implements a traceroute or traceroute like program to ALWAYS DISPLAY THE SOURCE ADDRESS IN THE OUTPUT OF THE [EMAIL PROTECTED] Very few things in life suck more than asymmetric paths + wannabe network engineers armed with a noc phone number list and traceroute, mtr, or those wonderful visual traceroute programs that they insist on taking 6MB bmp screenshots of and sticking into word documents so they can email that as an attachment. You will not learn hatred until that MMO you host implements a 'Report network problem' button that does a traceroute, and automatically emails it and a canned message to your NOC mailbox. Ultima Online did this, back in my nocling days. Like monkeys expecting a reward, those little bastards pounded on that button until the lag stopped. It gave the west coast sucking sound that was Mae-West an entirely different flavor. We could monitoring peering conditions based solely on mailbox volume. - billn
Re: Quarantine your infected users spreading malware
The simplest method is to issue a different gateway to a registry of known offenders, forcing their into a restrictive environment that blocks all ports, and uses network translation tricks to redirect all web traffic to a portal. For cable modems and bridged DSL, you can do this with DHCP, matching their MAC address. PPPOE/DSL or similiar, you match on user name. Issue RFC1918 space with a gateway to your quarantine network. The rest is NAT/PAT and w3proxy stunts. You could pull it off with something as simple as iptables and squid, after dealing with the DHCP or authentication servers (ala Radius) to issue to the correct credentials. - billn On Tue, 28 Feb 2006, Christopher L. Morrow wrote: On Tue, 28 Feb 2006, Jim Segrave wrote: www.quarantainenet.nl It puts them in a protected environment where they can get cleaned up on-line without serious risk of re-infection. They can pop their e-mail, reply via webmail, but they can't connect to anywhere except a list of update sites. there was little in the way of 'how' in the link above though :(
Re: 95th percentile - the sociology study.
On Mon, 27 Feb 2006, Jo Rhett wrote: All but three of the people who tried to teach me how to calculate 95th percentile were polite and clueful when I reminded them that I wanted the math, not a tutorial. A couple of misunderstanding actually wandered off into statistical analysis ramblings which was an amusing offset to the next set. Only three of the people insisted on telling me I was doing it wrong (never posted how we were doing it in the first place, so this was amusing) and tried to clue by four me into their approach. What? Blanket assumptions of 'You are wrong because you are not $self'? Crazy talk. That never happens. 1 tried to convince me that modern equipment can't handle being sampled more often than every 5 minutes. I hope you disabused him/her of this notion. Generally, it's not modern equipment that can't handle it, it's usually a (literally, not 'in my opinion') stupid polling mechanism that isn't designed (or tuned!) to be friendly or intelligent in its efforts. Many tools do bulk table gets (friendlier, but still overkill, depending on the platform and port density) or full table walks (Unga! You give me data now!), The general non-availability of efficient bulk delivery methods on a universal basis usually means people are implementing full walks. Having a poller that does one poll an hour/day to inventory administratively active interfaces (and keeping unused interfaces disabled), and consequently only polling active interfaces for counter increments, is probably the single most intelligent piece of logic you could implement in a poller to gaurantee the least amount of wasted CPU on your network hardware, especially since CPU time on an x86 database is cheaper than router CPU. This is also handy for reconciling ifIndex shifts where persistance is not available or feasible (storing ifIndex as a property of ifName, not vice versa.) Also, classifying your interface with externally applied data (Peer? Edge? Vlan logical interface? Customer? Infrastructure?) can help you pare down how much polling you really need to be doing, and at what interval. I'm a big advocate of network inventory databases, for this reason. An example of this would include using a Vlan's aggregated traffic counter instead of the 50 individual ports that comprise it, if you don't need it for your billing model (Unless you're taxing the customer for non-routed netbios chatter across your backplane, which I'm fine with.) Standardized interface naming or network discovery toolsets support automating this, as well as encouraging engineers to keep the network tidy and labelled. This little gem of a practice is usually the core of network management standards. Based on the active interface volume and CPU impact incurred by the SNMP agent on the network device, you should be able to poll platforms on a fairly constant basis and use sliding intervals in your averaging processes, as requirements and router impact demand. Taking the time to benchmark the effects of your polling at different intervals is an engineering step that will keep your operational impact low as you scale. As always, your mileage may vary. Note: If you're small enough that you're still using MRTG, you can likely just ignore everything I just wrote. And for those of you who can count, yes, one of the people who tried to teach me how to calculate 95th percentile didn't respond back either positively or negatively when I tried to remind him of the questions asked, and one was rude. (I don't blame him, after the 10th or so reply I was too) My process for self-filtering posts to nanog: 1. Read post in thread. 2. Is post by a known windbag? If yes, delete and continue. 3. Draft response. 4. Suspend response in outbox for at least half an hour. 5. Ask, 'Does this post add anything constructive/funny to the thread?' If no, delete and continue. 6. Ask, 'Will this post likely trigger hits on my procmail filter by the aforementioned windbags?' If yes, flip a coin, because anything posted with an opinion will likely cause that. (Yes, Martin, it's there, before you respond to check.) 7. Ask, 'Was I pissed off when I wrote this?' If yes, let sit for another hour, goto 5. This entire process used to be prefaced with '0. Subscribe to posting list.' This was usually enough to deter a post until something annoyed me sufficiently to get through the whole process. ;) - billn
Re: Quarantine your infected users spreading malware
On Tue, 21 Feb 2006, [EMAIL PROTECTED] wrote: Why not just bypass them and go direct to the unwashed masses of end users? Offer them a free windows infection blocker program that imposes the quarantine itself locally on the user's machine. This program Offering them free software won't work to the levels you want. At first, you'll get a response, because consumers always jump at free shiny things, until something happens that makes them not like it anymore, and then they'll dig in and never use it again. If you want to get this kind of filtering into your core, you have a need to get this to a compulsory level for access. I don't think there's any disagreement as to the roots of this problem: - Modern users are generally clueless. - Most don't have firewalls or even the most basic of protections. - Getting tools deployed where they need to be most is the hardest. With that said.. If you're talking about a compulsory software solution, why not, as an ISP, go back to authenticated activity? Distribute PPPOE clients mated with common anti-spyware/anti-viral tools. Pull down and update signatures *every time* the user logs in, and again periodically while the user is logged in (for those that never log out). Require these safeguards to be active before they can pass the smallest traffic. The change in traffic flow would necessitate some architecture kung fu, maybe even AOL style, but you'd have the option of selectively picking out reported malicious/infected users (*cough* ThreatNet *cough*) and routing them through packet inspection frameworks on a case by case basis. Quite possibly, you could even automate that and the users would never be the wiser. - billn
Re: Quarantine your infected users spreading malware
On Tue, 21 Feb 2006, [EMAIL PROTECTED] wrote: If you're talking about a compulsory software solution, why not, as an ISP, go back to authenticated activity? Distribute PPPOE clients mated with common anti-spyware/anti-viral tools. Pull down and update signatures *every time* the user logs in, and again periodically while the user is logged in (for those that never log out). Require these safeguards to be active before they can pass the smallest traffic. Cost prohibitive.. In order to do that you'll need licenses from the AV companies.. Oddly enough, AOL and several other large providers seem to have no problems advertising some variant on 'free A/V software'. When referring to AOL customers, though, you're talking about a target market that is accustomed to being offered a bundled package, and for lack of a better term, doing what it's told. Largely, AOL users aren't the problem. Comcast, Cox, Adelphia, and similiar providers with raw IP consumers are the problem.[1] A la carte services are all good and well for the end user, but it's a double edged sword in that they're good for the botnet crews, too. I used to sneer at offerings like AOL or Compuserv, because they weren't what I needed. Now, I'm actually kind of glad they exist because some users clearly need the training wheels. This is as much of a social problem as it is a technical one. I'm starting to understand the perspective of a legislative heavy federal government that has to pass laws to protect folks who are pretty much ignorant of the problem. - billn [1] I don't point those out because of specific problems, I point them out to describe service offering styles and network architecture. I have no interest in detailing why provider X sucks, or talking to your lawyers about it.
Re: Quarantine your infected users spreading malware
On Tue, 21 Feb 2006, Jason Frisvold wrote: On 2/21/06, Bill Nash [EMAIL PROTECTED] wrote: If you're talking about a compulsory software solution, why not, as an ISP, go back to authenticated activity? Distribute PPPOE clients mated with common anti-spyware/anti-viral tools. Pull down and update signatures *every time* the user logs in, and again periodically while the user is logged in (for those that never log out). Require these safeguards to be active before they can pass the smallest traffic. Cost prohibitive.. In order to do that you'll need licenses from the AV companies.. Big deal. You're talking about volume licensing at that point, and offering vendors an opportunity to compete to get on every desktop in your customer base. That's a big stick to negotiate with, especially if you're an Earthlink or AOL. The change in traffic flow would necessitate some architecture kung fu, maybe even AOL style, but you'd have the option of selectively picking out reported malicious/infected users (*cough* ThreatNet *cough*) and routing them through packet inspection frameworks on a case by case basis. Quite possibly, you could even automate that and the users would never be the wiser. And then the privacy zealots would be livid.. Silently re-routing traffic like that.. How dare you suggest such a ... wait.. hrm.. The internet basically does this already.. I wonder if the zealots are aware of that.. :) Yeah, the privacy zealots, of which I'm one, don't have much of a leg to stand on, since as the direct service provider, you'd be directly within AUP/Contractually provided rights to do so, under that particular service model. They can't ding you for being active in your *response* to complaints about malicious activity sourced from your network, and taking the time to verify it. So long as you're keeping their personal information out of the hands of others, they don't have much to bitch about. The ISPs win because they've got ready means to tie complaints directly back to an active customer, AND verify the complaint. Consumers win because they've got cheap anti-virus they still don't have to do anything about. The internet wins because ISPs are sharing non-personally identifying information about naughty behaviour and maybe increasing the mean TTL for new Windows machines. In the long term, privacy advocates win because networks have implemented active responses to attacks that routinely lead to identity theft. The biggest hole I see in this concept is home routers that do NAT (linksys, linux boxes, etc). While capable of PPPOE, you can't quite mandate the A/V clients. You still have the option of doing packet inspection, which is still better than nothing. - billn
Re: Quarantine your infected users spreading malware
On Tue, 21 Feb 2006, Gadi Evron wrote: Many ISP's who do care about issues such as worms, infected users spreading the love, etc. simply do not have the man-power to handle all their infected users' population. The ISPs will be a part of the solution. However, ISPs fall into two major categories: 1) The ones that read the types of lists that you posted this to 2) The ones that have the problem. You're preaching to the choir, Gadi - and if there's *one* thing I'd like a solution for, it's *that* problem. How do you get the unwashed masses of ISPs to join the choir so you can preach to them? What products that answer this are out there, and how good, in your experience, are they? We discussed this here before non-conclusively and stayed on philosophy, anyone has new experience on the subject? Let's be clear in what we're addressing. Are we talking about an en masse quarantine of IP addresses sending the worm traffic, or identifying the CC-payload conversations and applying blocks accordingly? Where are the anti-virus and software firewall vendors in this conversation? To be plain, this obviously isn't a problem you can solve with some border filters. The complexity, and fallout, from trying to put those kinds of filtering in is just too great. It's cumbersome to manage manually and operational impact is too great. If we're going to philosophize about solutions, let's throw some ideas out. Where do concepts like ThreatNet fit into this notion? (http://ali.as/threatnet/) To save some reading, the idea behind ThreatNet is to establish a closed threat sharing network with trusted peers, sharing information about malcontents doing things on your network that they shouldn't be. If you can positively identify SSH brute force sources, port scan patterns, worm traffic, spam sources, etc, and report them to trusted peers in a collaborative fashion, it becomes easier to support intelligent and rapid traffic filtering concepts in your network designs, where appropriate, even if it's something as simple as putting together a business case for filtering entire netblocks or regions. (Yes, I write my own analyzers, and yes, I'm involved peripherally with this project.) ThreatNet is still pretty nascent, but conceptually it's got merit. I'll bring up MainNerve again since they're the only vendor I've worked with that's got tools for selectively filtering known troublemakers. As a potential solution, I bring both of these items up because they provide the ability to take good, distributed intelligence gathering and apply them to your network in a precision manner, if at all, in accordance with any unique policies you may have. The problem, as I see it, is that even if one ISP sees the bad behaviour, there's no communication amongst the community (that I can see) to relay or collate the history. It's like playing Mom off against Dad because they never talk to each other. For coming up with clear patterns of abuse and shenanigans, we're suffering from collective myopia because we're ignoring an aspect of of our favorite big ass communications medium. Or I'm completely off base, in which case tell me to shut up and I'll go back into my code coma. - billn
RE: Fed Bill Would Restrict Web Server Logs
On Tue, 14 Feb 2006, David Hubbard wrote: From: Andy Davidson Speaking with my e-commerce vendor hat on, server logs (apache, mail, application audit logs) and other information about visitors (especially those who have conducted a purchase transaction with us, or signed up to our newsletter) never stop having a business purpose - it's called referential integrity. We want to use them to track the behaviour fraudulent users for example. Anyone who runs mailing lists has to keep that info to be able to prove how and when someone opted in. Have you ever tried getting opt-in information out of someone, especially when they know they've screwed up? You practically need a subpeona to do it. In many cases (I went through this recently with ZDnet) you literally have to play the escalation game just to rattle enough cages to get people to realize you're a: serious and b: not a kook. Oddly enough, I have the hardest time with the latter. ;) It'll be interesting to see what this legislation looks like when/if it gets signed. Maybe it'll finally be the extra kick I need to get some of our larger databases purged. - billn
Re: Fed Bill Would Restrict Web Server Logs
On Tue, 14 Feb 2006, Hyunseog Ryu wrote: I guess the question is how to read legitimate word. ^.^ I guess the bill was written in mind of privacy concern. But also there is some requirement for security/law-enforcement viewpoint. I received the request from some law-enforcement about actual user of IP address 3 year ago or older. Without all log info, how can I tell it? In the context of the legislation in question, if the user is still a current customer, you have a legitimate business use for the data. If the user was no longer a customer, I would surmise that you should have purged it, as you would no longer have a need for that user's personal data. I'm really curious whether this was a kind of post-action to the cell-phone use log business such as locatecell.com or something like that. An exploration of the side effects would be interesting. I think it'll provide a legal cudgel for mailing lists and opt-in tracking, as well as ensuring that your information is purged when/if you opt-out. It may also have dampening effects on the sale/trade of personal information, as it would now be questionably criminal to possess the personally identifying information of a person you have engaged in zero business with. From the text of the bill, there are some pretty loose points that'll give lawyers a lot of vine to swing from, including the definition of 'legitimate business practice'. Associating all of it to 'Internet website', as defined, is another loophole waiting to happen. I think the single best element of the bill is the declaration that consumers have an ownership in interest in their personal information. Owndership implies control, and by extension, some amount of control in who gets to have it. I'd like to see what happens when the final bill is mated with US Federal CAN-SPAM law. - billn
Re: Interesting netflow entry
On Mon, 6 Feb 2006, Wil Schultz wrote: Incidentally (because I ask everyone this), what's your flow volume (flows per second)? Cannot get ahold of the machine until tomorrow. I did a 'wc' on 4 devices for 5 minutes and it comes out to just under 3600, about 11-12 per second... Erm, that seems kind of low. Flow volume for two 6509s in what I consider a small to medium size hosting site, with about 6+ gigs of differentiated egress generates more than 8 to 9 *thousand* flows per second, and that's after discard incomplete tcp flows (port scans, half open syns, etc.) Are you sure you're getting everything? - billn
Re: Interesting netflow entry
On Tue, 7 Feb 2006, Christopher L. Morrow wrote: Are you sure you're getting everything? he did previously state he was only using about 120mbps... and it'd depend upon his/your sample rates as well... Missed that part. Even so, 120mbps of actual usage, I would expect to see a higher volume. Sampling would definitely bring this down a bit, but for a volume that small, why bother sampling? You'll miss too much. One problem I had while checking out various packages, flow-tools specifically, is that some can't handle differing flow versions. Also, flow generation from a routing-capable 6509 is configured in two different places, so the potential to lose flow traffic due to poor documentation (of both the collector and the generator) definitely exists. Flow-tools picks which version it processes based on the version of the first flow packet it receives, and then discards all else. - billn
Re: Interesting netflow entry
On Mon, 6 Feb 2006, Wil Schultz wrote: Here is another pattern, sourced off of one the destinations: [snip] You may find it far simpler to just ask the person who owns the sources that those packets are. While this may not be politically feasible (insert network and privacy policies here), given the amount of VPN traffic that's encapsulated in UDP, that may be anything. The problem with netflow is that it does reveal many interesting, hypnotic patterns inside your network. Having spent my share of time on the receiving end of that lunacy, I can only offer this advice: Drinking from the firehose is only funny for a little while. Depending on your deployment method (transit flow monitoring vs locally sourced, data center vs office campus, college campus vs four hippies with tin cans), identifying flows may be far easier if you have a network inventory to refer to. Even something as simple as parsing XML output from NMAP into a db will give you better insight into what your flows are. Incidentally (because I ask everyone this), what's your flow volume (flows per second)? - billn
Re: GoDaddy.com shuts down entire data center?
On Tue, 17 Jan 2006, Matt Ghali wrote: On Tue, 17 Jan 2006, Robert E.Seastrom wrote: The first and second paragraphs are sane. The last paragraph gives Go Daddy the right to capriciously and arbitrarily delete your domain for any reason they wish (Morally objectionable activities will include, but not be limited to...) Do you believe that your philosophical objections to the language absolves you as a customer from the minimal due dilligence of knowing what you are agreeing to? Find me a registrar that DOESN'T have that kind of language in their user agreements, then tell me if anyone wishing to do any kind of e-commerce has a choice. I've gone off on a tear about this before: A registrar has a license to print money. Boilerplate user agreements that leave the user zero recourse are the standard. I haven't seen a registrar yet that doesn't have this kind of verbiage completely freeing them from liability for *any* action taken on a domain registration, including none. - billn
Re: Cisco, haven't we learned anything? (technician reset)
Just as an offshoot discussion, what's the state-of-the-art for AAA services? We use an modified tacacs server for multi-factor authentication, and are moving towards a model that supports single-use/rapid expiration passwords, with strict control over when and how local/emergency authentication can be used. I'd be interested in that discussion, on or offlist. - billn On Thu, 12 Jan 2006, Rob Thomas wrote: Hi, NANOGers. ] On the other hand, the most common practice to hack routers today, is ] still to try and access the devices with the notoriously famous default ] login/password for Cisco devices: cisco/cisco. This is NOT a default password in the IOS. The use of cisco as the access and enable passwords is a common practice by users, but it isn't bundled in the IOS. I've heard it began in training classes, where students were taught to use cisco as the passwords. Oh, and for those of you who think it mad leet to use c1sc0 as your access and enable passwords, the miscreants are on to that as well. ;) We've seen large, massively peered and backbone routers owned through this same technique. We've even seen folks who have switched to Juniper, yet continue to use cisco as the login and password. :( The nice thing about cooking up blame is that there is always enough to serve everyone. Thanks, Rob. -- Rob Thomas Team Cymru http://www.cymru.com/ ASSERT(coffee != empty);
Re: Reporting botnets?
There are companies/products that specialize in mitigating CC traffic in a fairly elegant manner. One specific one that we've had good experiences with is Mainnerv's Darknet product. They deploy a box on the network, interfacing with your enterprise via a BGP peer, which issues a handful of routes to actively blackhole, intercept, and analyzer traffic to known CC's that are being actively tracked. That part isn't too exotic, their strength lies in the good intelligence processes on their side, for maintaining their blackhole listing. The implementation impact is minimal and trojan outbreaks are generally stopped dead even as the compromise is taking effect. As a proactive measure, it's a fast way to spot compromised machines within your network even as the malignant activity is mitigated. - billn On Tue, 10 Jan 2006, Martin Hannigan wrote: Please advise, where to can I report botnet control activities? I'm from overseas and interested if there are some law enforcement organizations in US who may handle these issues? I assume it is illegal business in US, and I have enough evidence how botnet control sites command our trojaned customer PC's to send spam and activate DDoS attacks. I think your best bet is to report it first to your local authorities and then report it to the ISP that the CC is sitting on. There are techniques that have been established over time and a few things you can do to mitigate, at least temporarily, (1) identify it and any others (2) make sure that taking action won't cause collateral damage or important stuff runs on it and blackhole it, (3) contact the dns provider and ask them to (a) lock out the user, (b) extend the TTl to the max that their software allows, (c) change the CC resolution to 127.0.03. That will at least do some level of mitigation and allow you to clean up the mess while you figure out how you want to pursue it. I'm sure you'll also hear from some people on this list who can assist. Botnets are a dime a dozen. It's good to kill the CC's and it's good to report them to LEA's, but from there, all bets are off. I believe any action would depend on exactly what they were doing with them. For example, if it's a bunch of skiddies fighting over who controls an iRC channel and they are DDOS'ing each other, well, that may not get much attention. Hope that helps. -M
Re: live chat with other nanog'ers
On Fri, 30 Dec 2005, Christian Kuhtz wrote: This must be the holiday lull... Is this thread a glue pot yet? The surest sign that a thread has run its full course and is now descending into true wankerhood.. is when I post to it. Happy New Year, kids. - billn
Re: zotob - blocking tcp/445
On Thu, 18 Aug 2005, Roger Marquis wrote: My question is not what can we do about bots, we already filter these worst case networks, but what can we do to make it worthwhile for bot-providers like NETNET to police their own networks without involving lawyers? Establish and document a history that determines peering with that network, or it's providers, presents a significant risk to your network, or that of your customers. If you've got a view into your traffic that looks like this: (Select source, proto, dstPort, count(destination) from flows where packets 4 group by source, proto, dstPort order by count descending) Source proto dstPort count 62.149.195.129 6 42 13018 203.69.204.250 6 445 12889 213.123.129.237 1 204812693 70.17.255.436 443 12685 217.132.56.139 6 489911056 209.181.111.12 6 135 8148 221.210.149.97 6 48997368 212.24.201.220 6 135 6451 172.131.83.244 6 135 6025 209.188.172.66 6 445 5055 80.177.36.162 6 445 4982 64.121.65.197 6 48994262 64.32.117.250 6 135 3954 213.144.99.241 6 445 3493 64.231.44.656 135 3157 213.123.129.237 6 139 2988 222.84.236.98 6 10232414 222.84.236.98 6 98982398 64.228.209.103 6 135 2305 Determining who to consider peering with gets a lot easier. (ASN's left off to annoy the truly curious.) As a provider, we don't want to be filtering heavily, as it invariably leads to making allowances for Customer X. The management overhead, as well as the impact on packet processing, is too great. It's easier for us to be able to monitor and report to our customers what's affecting them, and make sure they have the right tools in place to protect them from these kinds of shenanigans. - billn
Re: zotob - blocking tcp/445 (fwd)
Resent to address formatting misbehaviour: Source proto dstPort count 62.149.195.129 6 42 13018 203.69.204.250 6 445 12889 213.123.129.237 1 204812693 70.17.255.436 443 12685 217.132.56.139 6 489911056 209.181.111.12 6 135 8148 221.210.149.97 6 48997368 212.24.201.220 6 135 6451 172.131.83.244 6 135 6025 209.188.172.66 6 445 5055 80.177.36.162 6 445 4982 64.121.65.197 6 48994262 64.32.117.250 6 135 3954 213.144.99.241 6 445 3493 64.231.44.656 135 3157 213.123.129.237 6 139 2988 222.84.236.98 6 10232414 222.84.236.98 6 98982398 64.228.209.103 6 135 2305
RE: London incidents
Would the folks posting news related events please footnote source URLS, especially if arguing over factual details? Thanks. - billn On Mon, 11 Jul 2005, Sean Donelan wrote: On Mon, 11 Jul 2005, Hannigan, Martin wrote: All this while I was trying unsuccessfully to use my mobile to ring the office. Some cell relays were temporarily shut to prevent a remote detonation of additional explosives. Cellular remotes seem to be a favorite of Al Qaeda and others. UK Government officials deny they shutdown any cell phone service.
OT: Stupid vendor tricks.
Co-workers from past lives will recognize this as a subject near and dear to my little black heart: CISCO-SLB-MIB::slbServerFarmBindId.4.10.0.0.10 = Gauge32: 0 CISCO-SLB-MIB::slbServerFarmBindId.4.10.0.0.11 = Gauge32: 0 CISCO-SLB-MIB::slbServerFarmBindId.4.10.0.0.12 = Gauge32: 0 CISCO-SLB-MIB::slbServerFarmBindId.4.10.0.0.13 = Gauge32: 0 The pure numerics are even worse, right down to the polling response behavior. - billn
Catalyst Flow Export wierdness.
Configured to export v5 flows, cat6509 running IOS is sourcing 95% v7, and 5% v5. Anyone seen this kind of behaviour? - billn
Netflow voodoo.
Thanks for the emails, y'all very quickly confirmed my theories and I'm starting an argument with the network guys about it. Thanks again! - billn
Re: Catalyst Flow Export wierdness.
I've been out of the hands-on config game for a while, so certain portions of my clue is rusting. I knew the MSFC and the SUP both had their own ideas about how things were supposed to go, but (especially with IOS running on switches) wasn't 100% on the configuration behaviour. I can look at the configs and see that v5 export is configured, but I don't see an instruction to the SUP to export v5, which is what's tripping up my collection. Netflow being something our engineers haven't worked with extensively, and required configurations on recent IOS on Cats being something I'm not up to speed on, there's a a divide between me saying it's broken, and them saying that it's configured and that my tools are broken. So there's head scratching and finger pointing on both sides that just needed a nudge. The versions didn't make the difference, the clued respondants still saw the break for what it was. Thanks again. - billn On Wed, 8 Jun 2005, Andrew - Supernews wrote: Bill == Bill Nash [EMAIL PROTECTED] writes: Bill Configured to export v5 flows, cat6509 running IOS is sourcing Bill 95% v7, and 5% v5. Anyone seen this kind of behaviour? You don't mention what version of IOS or what supervisor/PFC version in the cat. With 12.1 at least, the MSFC doesn't support version 7 flows, so for traffic routed in software you will get a v5 flow, and for traffic routed in hardware you'll get v7 if that's what you configured. If you have sup2/PFC2 and IOS = 12.1(13), you can configure the PFC to export v5 as well, and get everything in the same format. -- Andrew, Supernews http://www.supernews.com
Re: On the-record - another off-topic post
On Tue, 3 May 2005, Dean Anderson wrote: Basically, when the discussion degenerates to dean is a troll, on a forum like this, it means they've run out of ideas, but don't want to concede anything, and are looking to divert attention to something else. And of course, one can't make someone (on a forum like this, anyway) concede anything, and they wouldn't do so willingly. Pot calling kettle, pot calling kettle, come in, kettle. As long as we're explaining fun words: If neither party is willing to back down from their point of view, *right or wrong*, that's called an impasse. Since nothing any part is saying is changing anyone's mind, agree to disagree and take it offlist. - billn
RE: Getting a BGP table in to a lab
Zebra is a great option here, I use it to eat a routing table from production routers, peer a perl Net::BGP daemon with it, and then do SQL injections from there to instruct my netflow engine on baseline subnetting for external networks, as well as provide AS clue for non-AS aware netflow export segments. - billn On Wed, 20 Apr 2005, Scott Morris wrote: None of the routers that are tested in the lab are capable of supporting a full BGP feed If you just want to play with BGP stuff, you can use Zebra (unix) or go to www.nantech.com and get their BGP4WIN program. That may help you a bit more. Scott -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nathan Ward Sent: Wednesday, April 20, 2005 8:35 PM To: nanog@merit.edu Subject: Getting a BGP table in to a lab I'm trying to come up with a way to get a full BGP routing table in to my lab. I'm not really fussed about keeping it up to date, so a snapshot is fine. At the moment, I'm thinking about spending a few hours hacking together a BGP daemon in perl to peer with and record a table from a production router, disconnect, and then start peering with lab routers. Am I reinventing a wheel here? -- Nathan Ward
Re: SORBS Identity theft alert
On Mon, 11 Apr 2005, Dean Anderson wrote: See http://www.iadl.org/sorbs/sorbs-story.html And with some clever correlation, googling, and patience, I could do the same for the majority of people posting to this list on a regular basis. In short, what's your point? If you have substantial evidence that information collected by SORBS has been used as such, by all means, come out and accuse them of it. Otherwise, kindly keep your pissing contest to yourself. - billn
Re: SORBS Identity theft alert
On Sun, 10 Apr 2005, Randy Bush wrote: SORBS lists Dean. I suspect this makes him angry. who's dean? the problem with feeding trolls is that they puke it up on the carpet. Negative reinforcement is better than procmail. The problem with trolls is that they keep coming back if you don't beat them properly. I'm a great example. ;) - billn
Re: Maybe OT: MPLS QOS SLA Monitoring
On Mon, 11 Apr 2005 [EMAIL PROTECTED] wrote: I'm currently looking at what the possibilities are for monitoring network activity and SLAs against Cisco QOS mechanisms within VRFs. The most desirable method seems to be using NetFlow collectors, though it seems as though the benchmark for this is NetFlow 9, and I'm not sure if it's terribly well deployed on NetFlow collectors out there. Anyone know if it *is* well implemented for a given product? Or even if there's just a better way? My knee jerk response was to suggest that flow-tools[1] can handle v9 output, but now that I look closer, it doesn't appear to. What you're talking about wouldn't be *too* difficult to implement externally, you just need some way to connect your SLA metrics to your aggregate flows for violation checks. If you're perl-ish, the flow-tools kit + dplonka's toys should give you what you're after with some implementation fu. - billn [1] www.splintered.net/sw/flow-tools/
Re: Network-Automation discussion mailing list created
On Thu, 7 Apr 2005, Brent Chapman wrote: I've created a Network-Automation mailing list for discussions of issues related to automating network configuration and management, including (but not limited to) methods, mechanisms, techniques, philosophies, policies, and products. In the spirit of making CAN-SPAM useful, and extending the reasonable recourse NANOG provides end users against harvesting, can you update your AUP to specifically (and publically) prohibit the harvesting of email addresses from list traffic or web visible archives for the purpose of commercial mailings? - billn
Re: Network-Automation discussion mailing list created
On Thu, 7 Apr 2005, Brent Chapman wrote: At 3:15 PM -0700 4/7/05, Bill Nash wrote: I've created a Network-Automation mailing list for discussions of issues related to automating network configuration and management, including (but not limited to) methods, mechanisms, techniques, philosophies, policies, and products. In the spirit of making CAN-SPAM useful, and extending the reasonable recourse NANOG provides end users against harvesting, can you update your AUP to specifically (and publically) prohibit the harvesting of email addresses from list traffic or web visible archives for the purpose of commercial mailings? Sure, that sounds like a good idea. Can you point me at any suggested language, or any other list's version of this policy, which I can use as a template? Sure. Harvesting of email addresses from this mailing list, or web visible archives, for the purposes of commercial mailings, is prohibited. Cheers. - billn
Re: Vonage Hits ISP Resistance
On Fri, 1 Apr 2005, Stephen Sprunk wrote: I understand the woes of mixing 911 and VoIP myself, although I'm not a Vonage user. The VoIP phone on my desk connects 911 calls to the Vancouver, BC, PSAP (since it's off a PBX at work), but I also know the direct-dial number for the local Dallas, TX, PSAP -- the emergency line, not the administrative line that Vonage uses -- and if I bothered, I could easily set the PBX to reroute 911 there instead. Location information is tougher, but I have to tell the operator my location on a cell phone too, so it's not a deal-killer. It kinda makes you wonder how people contacted the police in the early 80s, completely discounting that people had even conceived of the notion of 'emergency' before the 70s. When I was a kid, I was made to memorize my home address, my phone number, an emergency contact number, and the local police number. 911, while a great idea, is a classic example of the desire to let technology replace basic common sense. I don't mean to get off on a rant here.. - billn
Re: potpourri (Re: Clearwire May Block VoIP Competitors )
On Fri, 1 Apr 2005, Adi Linden wrote: If VoIP companies are regulated into providing 911 service, minimum availability standards, etc is one thing. Forcing anyone that might be transporting VoIP into becoming a Telco is quite another... At this point, I think it's simply an argument over the interpretation of 'signalling technology'. - billn
Re: Cisco to merge with Nabisco
On Fri, 1 Apr 2005, Robert Boyle wrote: Brilliant move Cisco! This should give Cisco a keen and unprecedented insight into the inner workings of the cracker culture which will enable better network security. 'Network devices are rated by total packet volume, not chassis weight. Packets may settle during shipping.' - billn
RE: Cisco to merge with Nabisco
On Fri, 1 Apr 2005, Church, Chuck wrote: Incorrectly chosen switching path can now result in lost packets AND indigestion. Is this mitigated by activating Nabisco Express Forwarding?
Re: Yes, I realize it's April Fools Day, but... (was: Cisco to merge with Nabisco)
On Fri, 1 Apr 2005, Bill Woodcock wrote: ...the reformed NANOG list moderation committee seems to suffer foolishness somewhat more gladly than the old regime. Could we have a little more backbone in the moderation, please? I don't want to be reading about crackers until this time next year. In a stunning response to Cisco's purchase of Nabisco, Juniper Networks has rapidly countered this foray into cross-marketing by quickly snapping up food conglomerate General Mills. In a statement released by early this afternoon, Juniper Networks founder Pradeep Sindhu points out, 'It's no surprise Cisco bought a company renowned for snack foods, look at their entire product lineup. Garbage in, garbage out. Keep an eye out for our seriously robust line of Cheerio routers. All the fiber you can handle!' - billn
Re: Vonage Hits ISP Resistance
On Thu, 31 Mar 2005, Fergie (Paul Ferguson) wrote: Who said it was QoS? Blocking is QoS. ;) - billn
Re: Vonage Hits ISP Resistance
On Thu, 31 Mar 2005, Suresh Ramasubramanian wrote: Korea Telecom recently decided to scrap its flat rate high speed [1] broadband offering and move to a traffic based charging plan - must be because most korean broadband gets used for online gaming, which is as high bandwidth use an app as you can get ... and they're hit by the same situation, which does start to bite when a few users start maxing out their pipes, and really begins to hurt when few suddenly becomes most Actually, gaming usually isn't a high bandwidth app, it's merely sensitive to latency. The flows are longer, and I'd imagine with Korea's gaming addiction, highly numerous, but really only large when taken in volume. Now, downloading large patches or entire games.. that's another story, of course. This is one of the problems things like BitTorrent is designed to tackle. A time-lapse flow matrix demonstrating the effects of BitTorrent on egress traffic would be an interesting project. - billn
Re: Vonage Hits ISP Resistance
On Thu, 31 Mar 2005, Steve Sobol wrote: Bill Nash [EMAIL PROTECTED] wrote: I have no idea what my cable company pays for their bandwidth, but I am certain it's more than the $40 per month I pay for my 3Mbps down/256 Mbps up... and I am able to actually *get* 3Mbps on many occasions, and I average between 1 and 2 (on HTTP/FTP transfers, fwiw). Yes, I know the connectivity cost is shared between several thousand customers in this area, but what happens if large numbers of customers start using VOiP on a regular basis? Not to be cynical, but if large numbers of customers start using VOIP on a regular basis, I imagine regulation will happen, especially if ISPs keep trying to inhibit consumer choices. Vonage is in the right place at the right time, I think. They're a notable pioneer for consumer VOIP services, and it puts them in a good position to supply meaningful insight into what it takes to make VOIP work for the consumer. Chances are, if you're a VOIP customer, you're some form of digirati. That means email, IM, and a cell phone. I'm more enamored of my Vonage service for the simultaneous ringing feature than I am of having a home phone. Self-enabled number portability is a huge win for me as well. My actual VOIP traffic use is pretty minimal. As was mentioned in another post, being able to fire up a softphone on my portable hardware, anywhere I can get packets, is pretty much the holy grail of nerd mobility. I don't think this evolutionary marriage of data and voice is a surprise to anyone, and these conflicts are growing pains. The incumbent telcos see it as a threat, which they should, but my personal view on this is like monkeys trying to fight against walking upright because it violates the existing natural order, nevermind the benefits of opposable thumbs. There's already too much momentum, and too many options to completely circumvent even the ISPs. Hell, even Cringely gets it. - billn
Re: Vonage Hits ISP Resistance
On Thu, 31 Mar 2005, Steve Sobol wrote: Bill Nash [EMAIL PROTECTED] wrote: regular basis, I imagine regulation will happen, especially if ISPs keep trying to inhibit consumer choices. There's a fine line between inhibiting consumer choices and ensuring that you don't end up spending more money than you're collecting for the services you provide. I'm not discounting that. It just doesn't seem to me that actual VOIP usage is significant enough, in existing billing models, to warrant the behaviour we're seeing. I'd be interested in seeing the figures surrounding this, if anyone has them. - billn
Re: Vonage Hits ISP Resistance
On Thu, 31 Mar 2005, Jamie Norwood wrote: On Wed, 30 Mar 2005 21:36:19 -0600, Chris Adams [EMAIL PROTECTED] wrote: Once upon a time, Eric A. Hall [EMAIL PROTECTED] said: Do you also block NNTP so that customers have to use your servers? Change that to SMTP and you'll get a bunch of yes answers. Why is one right and the other wrong? Heard of a little thing called 'spam'? SMTP and NNTP are an apples / oranges comparison. Email is well nigh ubiquitous, when people think about the Internet. NNTP, like IRC, is a niche subset compared to HTTP, SMTP, and IM. The long and short, is that popular services will remain largely unregulated, by ISPs or by government, until it's clear that they're being abused. Many ISPs did this with NNTP before they did it with SMTP, largely with the advent of higher speed connections facilitating shorter turnaround on warez traffic. Once spam took off, same deal. If ISPs can't play nice with third party service providers, I predict things will get ugly. Regulators are already sniffing around, both locally and internationally. VOIP is quickly becoming a hot item, and anti-competitive tactics that limit or remove the consumers choices are going to be blood in the water for politicos looking for something to gnaw on. Obviously VOIP needs QoS to function well on oversold, commodity broadband networks. Why not just paint VOIP with a broad QoS brush (as in, prioritize all of it, not just your own service) and defang the folks just looking for an excuse to step in and take the option away from you? - billn
Re: Vonage Hits ISP Resistance
On Wed, 30 Mar 2005, Eric A. Hall wrote: | to bear the additional cost of my customers choosing to use a | competitor's VOIP service over my own, says Greg Boehnlein, who | operates Cleveland, Ohio-based ISP N2Net. | | Without control of the last mile, we're screwed, Boehnlein says, | which is why I can identify with Clearwire's decision and say | more power to them. Do you also block NNTP so that customers have to use your servers? And if some other service used higher cumulative bandwidth than VoIP (say, Apple's music service) and didn't ~reimburse you for the use of your network, would|do you block that service too? For that matter, do you block the various P2P systems that don't make money but that generate massive traffic? I find this to be entertaining, since as a VOIP consumer, I'm reimbursing my ISP for the cost of the traffic as part of my monthly tithe. Why exactly are networks taking this stance to QoS VOIP traffic, generated by their customers, into uselessness? This will all be especially hysterical when it's done by an ISP that comprises 100% of it's local market's internet connectivity. Munn vs. Illinois, round 2! - billn
OT: Chasing spam.
I'm chasing after some spam that appears to have been built from a nanog post culling, and am looking for anyone else who may have recieved some mail a few weeks back, relevent info looks like: Date: Tue, 8 Mar 2005 12:01:59 -0800 From: Steve Gladstone [EMAIL PROTECTED] Subject: Register for the VoIP Deployment, Diagnostics Monitoring Webinar Sniffing about the opt-out functions gave me: You have already been opted-in to the system Email Address: [EMAIL PROTECTED] Email Type: not specified, defaulted to MIME Date and time signed up:March 03, 2005 at 07:16:16 PST A description of how your email address was obtained: Internal Sources From Empirix A discussion with the VP running the division responsible for the mailing has met with.. a door in the face, basically. Anyone with time (and a log trail), would you mind checking to see if you recieved it as well, and contact me offlist? Thanks! - billn
Re: OT: Chasing spam.
Thanks for the speedy responses, gang. All my suspicions are confirmed, and I'm putting an edge on my cudgel. =) - billn On Tue, 29 Mar 2005, Bill Nash wrote: I'm chasing after some spam that appears to have been built from a nanog post culling, and am looking for anyone else who may have recieved some mail a few weeks back, relevent info looks like: Date: Tue, 8 Mar 2005 12:01:59 -0800 From: Steve Gladstone [EMAIL PROTECTED] Subject: Register for the VoIP Deployment, Diagnostics Monitoring Webinar Sniffing about the opt-out functions gave me: You have already been opted-in to the system Email Address: [EMAIL PROTECTED] Email Type: not specified, defaulted to MIME Date and time signed up:March 03, 2005 at 07:16:16 PST A description of how your email address was obtained: Internal Sources From Empirix A discussion with the VP running the division responsible for the mailing has met with.. a door in the face, basically. Anyone with time (and a log trail), would you mind checking to see if you recieved it as well, and contact me offlist? Thanks! - billn
RE: outage/maintenance window opinion
Also, the possibility of equipment failure should *always* be factored into backout/recovery plans. You can have all the faith in your hardware that you want, but Murphy has enable/root. If it's something has simple as having redundant capacity to shift the load to, or as drastic as having a spare chassis sitting on hand, it's always a possibility, however remote. - billn On Mon, 28 Mar 2005, Matthew Kaufman wrote: My opinion: For the customer, the outage starts when their service stops working* and ends when their service starts working again. Your goal should be to make that all happen during the maintenance window. If it doesn't, then the part that was during the window is planned outage and the part that wasn't is unplanned outage. Good ISPs have good explanations for, and sometimes even monetary credit, for unplanned outages. Planned outages can simply be explained by pointing at the announced maintenance interval policy. Matthew Kaufman [EMAIL PROTECTED] *Note that this can be different times for different customers, and stops working means different things to different people... Some customers are unhappy if their traffic is taking the slightly longer alternate path, others are happy as long as they can reach CNN, even if the rest of the net disappears.
Re: IRC bots...
On Mon, 21 Mar 2005, Alan Sparks wrote: On Sun, 2005-03-20 at 14:25, Florian Weimer wrote: * Martin Hannigan: Who's got time for all that? Chase the controller, shut down the user until they buy some AV software. That should read AV software from at least three vendors, with direct Am I the only one who is getting mailbombed by dozens of these duplicate messages? -Alan Could have something to do with folks not trimming conversation participants from the TO: fields. - billn
Re: Traceroute with ASN
On Tue, 15 Mar 2005, Bruce Pinsky wrote: Ziggy David Lubowa wrote: | On Tue, 15 Mar 2005 17:51:32 +0800 (CST), Joe Shen wrote | |Yes. Can I do this on a Linux box without having to |install Zebra BGP on it? | Doesnt look like you have to, below is the link to the tarball | | http://oppleman.com/dl/?file=lft-2.3.tar.gz | According to the doc, it relies on RADB for its info, so it *might* not be as accurate as an actual BGP feed. Also, don't run it as an automated tool, unless you tweak the source to use your local radb mirror. - billn
Re: IRC bots...
On Sat, 12 Mar 2005, John Kristoff wrote: Tallying then just the TCP 6667 traffic, perhaps eliminating very short lived or small flows, should be a good indicator of IRC traffic usage, but tagging those as potential sources for problems may be Yes and no, in my experience. Depending on the drone, some connect to a server and stay connected. You could say the inverse is true, and look for long connections, but that will likely snare you legitimate traffic from the screen-running nerd set. difficult. Perhaps in environments where IRC as an application is strictly forbidden or blocked this will work well, but on more open and larger network this may waste time, not save it. Since in the latter case, figuring out what is legit and what is not will likely be a lot of leg work. This is why I suggested a snort filter, to actually inspect the packet traffic. Watching IRC traffic is only valid so long as the standard ports are being honored. What about bounces, and non-standard traffic? You need to go after the single common property, the protocol itself. Even so, you're still in an arms race. You can automate some of this further, by building white lists or black lists of IRC server addresses. A white list doesn't tend to scale very well. A black list scales better, but you have to get those black listed addresses and doing that part is harder. There are some people/groups who spend time finding black list hosts so leveraging their data can be very useful and time saving. This will backfire, in my opinion. Many drone nets hide in plain sight, connecting to public IRC networks where they can't reliably be traced to an authoritative user. You'll bejuggling access to public resources, and that's a waste of energy, I think. - billn
Re: IRC bots...
On Sat, 12 Mar 2005, Fergie (Paul Ferguson) wrote: Somewhat related to operational issues... It was interesting to read the daily handler log at the ISC which related their experiences with detecting (and disabling/disinfecting) a machine/network infected with several IRCbot drone computers. As someone who has had to deal with with this issue on several customer networks, it is sometimes intriguing at the length at which some of the developers of these damned things go through to accomplish their feats. :-) A fun solution to mitigating this problem: NAT or PBR to funnel all standard outbound IRC traffic to an internal ircd of your choice. When that doesn't work anymore, throw Snort on egress SPAN segments doing protocol inspection for irc protocol 'CONNECT' and similiar, hitched up to a syslog analyzer to catch outbound connections in real-time. The right tools in the right place would let you hitch the alarm to trigger execution of a utility capable of injecting packets into the stream to send RST in both directions. False positives might be a problem. I officially declare them to be 'yours.' ;) - billn
RE: IRC bots...
On Sat, 12 Mar 2005, Hannigan, Martin wrote: [ SNIP ] Who's got time for all that? Chase the controller, shut down the user until they buy some AV software. We've gone beyond I didn't know for endusers in most regions. Enterprise IT staff running from whip-cracking security staff, that's who has time for it. Unless, however, you have no security requirements surrounding your accounting records, network inventory, provisioning tools, and credit card processing services. Other reasons: .. if you're providing a premium service to business grade customers who can sum up their connectivity requirements as '80, 443, 25, 53, period.' ..if you're running honeynets. ..if you're providing structured services with explicit controls on what goes on (ala AOL, some .edu networks, etc.) ..you've been singled out by your peers because a significant portion of large DDoS attacks are originating from your network. ..you've been singled out by accounting because of the traffic costs involved with sourcing DDoS attacks. As popular as instant messenger, and increasingly, voip toys, have become, actual IRC usages represents a diminishing percentage of inter-user chatter. Even something as simple as carving irc usage out of your netflow records and tagging specific endpoints as potential sources is a piece of automation that will save you some time down the road. A decent network inventory would facilitate this. - billn
Re: Vonage service suffers outage
On Thu, 10 Mar 2005, Christian Kuhtz wrote: I think the final nail in this coffin is the Vonage banner ad/masthead which describes them as the broadband phone company. But it's broadband! Shsh. It's an information service. It's IP. These are not the packets you're looking for. ;) What all this really shows is just how outdated the regulatory framework really is. Once VoIP (or whatever the application formerly known as VoIP) stops looking like a PSTN emulation, this will get only more absurd than it already is. I disagree that the regulatory framework is outdated, but instead offer that the classification of IP networks has changed as new services have arisen, and been embraced by, the consumer. I don't purchase POTS service for my home. I have cable internet, and that's it. I don't even purchase cable TV service. Just a data feed. A la carte, I purchase VOIP service from whoever I want. It stops being a mere broadband information service the instant it connects to global PSTN. If a VOIP provider wants to avoid the label of telephony carrier, they should be strictly end-to-end service with no connection into the global PSTN infrastructure. An example of this would be enterprise internal phone systems, designed to propagate calls within a single corporate entity. They could then purchase PSTN connectivity, or VOIP access to such, from a company who IS labelled as a telephony carrier, if they want to accept and send calls to the outside world. This could something as small as a legal office running VOIP internally for phone system/contact management, call centers deploying pure IP networks for all internal services, or any other *end user*. If you're transiting VOIP traffic, intentionally because that's your product, or incidentally because you're an IP transit carrier and you've agreed to pass that traffic, you are, by definition if not by intent, a telephony carrier. This includes Vonage, as a VOIP-PSTN gateway, and *each of the ISPs they connect to*, having agreed to sell them service. Propagate through peering agreements, et voila: The Internet is part of the global PSTN network. If there's anything that's going to kill VOIP as a viable consumer platform, it will be ISP/NSP unwillingness to fall under the telecomms regulatory structure. For companies with existing networks and peering agreements, it may very well be too late to change. VOIP has grown fast enough that customers will begin shifting in droves if ISPs start announcing they won't transit or support VOIP. The impact on revenue is significant enough, in my opinion, that CEOs, or shareholders, for that matter, won't be willing to give it up. - billn
Re: VoIP Port Blocking Draws Congressional Interest
On Tue, 8 Mar 2005, Fergie (Paul Ferguson) wrote: http://www.eweek.com/article2/0,1759,1773832,00.asp - ferg 'He also urged Congress to pass legislation to ensure the complete neutrality of wire-line and wireless telephone companies to enable VOIP customers to freely access any telephone network in the country.' Some of the broad language in the Telecommunications Act of 1996 already does this, in my opinion. Some of the language is loose enough: (from http://www.fcc.gov/Reports/tcom1996.txt) `(45) NETWORK ELEMENT- The term `network element' means a facility or equipment used in the provision of a telecommunications service. Such term also includes features, functions, and capabilities that are provided by means of such facility or equipment, including subscriber numbers, databases, signaling systems, and information sufficient for billing and collection or used in the transmission, routing, or other provision of a telecommunications service. I alluded a bit to this yesterday, about the arguable classification of any network as local loop, so long as it's transiting VOIP traffic. I don't think there's really much argument against the notion that VOIP is in fact a telecommunications service, in even the loosest sense of the term. Following in that, IF an ISP is classified as a carrier because of this broad distinction, they're subject to, at a minimum: `SEC. 251. INTERCONNECTION. `(a) GENERAL DUTY OF TELECOMMUNICATIONS CARRIERS- Each telecommunications carrier has the duty-- `(1) to interconnect directly or indirectly with the facilities and equipment of other telecommunications carriers; and `(2) not to install network features, functions, or capabilities that do not comply with the guidelines and standards established pursuant to section 255 or 256. And in big shiny plain text: `SEC. 256. COORDINATION FOR INTERCONNECTIVITY. `(a) PURPOSE- It is the purpose of this section-- `(1) to promote nondiscriminatory accessibility by the broadest number of users and vendors of communications products and services to public telecommunications networks used to provide telecommunications service through-- `(A) coordinated public telecommunications network planning and design by telecommunications carriers and other providers of telecommunications service; and `(B) public telecommunications network interconnectivity, and interconnectivity of devices with such networks used to provide telecommunications service; and `(2) to ensure the ability of users and information providers to seamlessly and transparently transmit and receive information between and across telecommunications networks. Now that this is on Congressional radar, I don't think Vonage, or any other VOIP provider, is going to be able to hold out much longer as an unregulated entity. It's entirely possible that ISPs, by extension, may be swept into this by association, as call termination providers. It's also possible that an entirely new set of fees, taxes, levies, and general political financial rapaciousness will now be imposed on internet traffic and providers. - billn
Re: US slaps fine on company blocking VoIP
On Mon, 7 Mar 2005, Adi Linden wrote: If VOIP doesn't run on your network because you've oversold your capacity, no amount of QoS is going to put the quality back into your service. People will find better ISPs. If you deliberately set QoS to favor your services over a competitor, whom your customers are also paying for service, you'll be staring down prosecutors, at some point. It's anti-competitive behavior, as you're taking deliberate actions to degrade the service of a competitor, simply because you can. Let's say I sell a premium VoIP offering for an additional fee on my network. I apply QoS to deliver my VoIP offering to my customers but as a result all other VoIP service is literally useless during heavy use times you'd consider this anti-competitive behavior? Applying QoS to your VOIP traffic at the expense of *all* other traffic would be edging against a gray area. Applying QoS to competitive VOIP traffic specifically to improve the quality of your service at the expense of theirs is likely to be a problem. Again, I am not a lawyer. I would strongly suggest consulting one if this is a serious concern. The Internet is not regulated because operators tend to be effective at self policing. Engaging in these kinds of practices is asking for regulation. - billn
Re: US slaps fine on company blocking VoIP
On Fri, 4 Mar 2005, Robert Blayzor wrote: Bill Nash wrote: At the root of it, it's deliberate anti-competitive behavior, and that's what the fine is for. I'm generally fine to have the government stay out of the internet as much as possible, but this move was the correct one, as it was on behalf of the end consumer. It's not the choice of port blocking that matters, it's the intent. Wait a minute, since when is the Internet service I provide regulated by ANY entity? It's not, therefore I can run the network any way I see Since you applied for a license to operate a business in your city/county/state. fit. If customers don't like it, they can choose another ISP; if they can't choose another ISP, not my problem, I'm not a regulated entity, you get my service or none at all. Unregulated does not mean unencumbered by legal responsibilities. What would your take on a local competitor be, if they began filtering all traffic to your network when they happen to control all long haul egress? It's their network, they can do it, right? You don't get a say, do you? They're just leveraging their control of local peering to deliberately obstruct your ability to do business. That's legal, right? Lets take port blocking out of this. Lets say I'm an ISP that offers digital phone service to my customers. Of course I'm going to provide my customers with the best voice service possible, which means QoS for my voice customers. If Vonages service is basically unsable on my network due to oversubscription/latency/packetloss on some legs/remotes am I obligated now to provide voice quality? No, I'm not. My voice works because my customers pay me for that, is that anti-competitive? That's intentional as well... If VOIP doesn't run on your network because you've oversold your capacity, no amount of QoS is going to put the quality back into your service. People will find better ISPs. If you deliberately set QoS to favor your services over a competitor, whom your customers are also paying for service, you'll be staring down prosecutors, at some point. It's anti-competitive behavior, as you're taking deliberate actions to degrade the service of a competitor, simply because you can. Your obligation to your customers is to provide the service they're paying for. If they buy voice, you give them voice. If they buy packets, you give them packets. The first time a customer pipes up and says his competitive-VOIP service functions worse than his neighbor's, who's buying from you, it's absolutely in your best interests to pay attention to it, because you don't want your first hint about it to be from a state or federal investigator. Nobody says I have to carry Vonage traffic so long as I do not violate any SLA's with the customers I provide service for. Regardless if it's not competitive, if you want to really get technical and bring in regulation and law like the telcos do, Vonage should be paying ISP's to transport and terminate their voice customers traffic. Vonage DOES pay ISPs to transport their traffic. They're paying their direct peers for it, or at the barest minimum, the ISPs they purchase connectivity from, who are in turn paying, or being paid by, THEIR peers, ad infinitum, through transit agreements. Do you see my point yet? Seems that Vonage wants to have their cake and eat it to when it comes to regulation... Regulation doesn't even need to enter into this. The more peers you have, the less freedom you have to dictate what can and can't happen on your network, because you have a contractual obligation to live up to those agreements. In turn, those same obligations are passed on, from peer to peer to peer, until even Kevin Bacon gets the point: you can't just selectively refuse to transit traffic because a specific port number offends you. Note: I am not a lawyer. It's entirely possible I'm wrong. Please correct me, if so. To supply some legal context to this discussion, consider the rise of the CLEC, and the practices engaged by the incumbent telco's to restrict or inhibit market entry. Covad's struggles with Bell South. Caltech and Pacbell. Going back farther, MCI and ATT's local loop squabbles. There's a lot of text in the Telecommunications Act of 1996 that's relevent here, especially with regard to the provision of voice services, and the requirement of competitors to facilitate unhindered delivery of service to the consumer. (Sec 251, Interconnection) This does open up avenues for many other debates, including treatment of any given ISPs facilities as local loop, with respect to VOIP termination, and the obligations of ISPs to provide QoS, technical or otherwise, to VOIP traffic. - billn
Re: US slaps fine on company blocking VoIP
On Fri, 4 Mar 2005, Nathan Allen Stratton wrote: I don't speak for BroadVoice, but this seams to be to be stupid. Why should the government get involved in ISPs blocking ports? If customers don't like it, go to a new provider, what country is this?? Frankly, I don't see the point, any provider that requires 5060 or any other port to offer VoIP services deserves to be shutoff by networks blocking those ports. It is just to easy to talk to CPE on any port. At the root of it, it's deliberate anti-competitive behavior, and that's what the fine is for. I'm generally fine to have the government stay out of the internet as much as possible, but this move was the correct one, as it was on behalf of the end consumer. It's not the choice of port blocking that matters, it's the intent. I'm a Vonage customer myself, because I like the flexibility and control it provides me over my phone service. I'm also a Cox broadband customer. With Cox being a telephone provider, the instant they decide to begin filtering VOIP in order to reduce competition for their product, you can bet I'm going to voting with my dollar. Any CPE based customer is paying for a connection to the Internet. Unless they're subscribing to a specifically limited or structured access service (like AOL, for example), they have a reasonable expectation to use the service to do.. customer-like things. Knowingly subscribing to a service that will allow me to connect, outbound only, to tcp ports 80 and 443, with all mail going to a specific MTA, I would not reasonably expect to be utilizing that style of service for VOIP, and that would be fine. This is not, however, the style of service I'm paying for, and far less than my provider has already agreed to provide me with. This extends all the way to transit peering agreements, as well. I don't recall ever seeing one that says We agree to transit all traffic except VOIP. What would be the point? I wouldn't agree to buy incomplete transit any more than I'd try to sell it. To have a company that also provides telephone service to specifically block a competiting service, which customers are paying them to transit, is a breach of contract at best, and outright criminal at worst. - billn
Re: US slaps fine on company blocking VoIP
On Fri, 4 Mar 2005, Nathan Allen Stratton wrote: The fact is, the company was preventing it's users from using technology offered by said company's competitors. No, they are just preventing companies that are using port X, most providers have figured out how to make VoIP work on any port. It's a portable scenario, and it doesn't matter which port you block. Flip it around: HTTP can transit on any port. Block port 80 and see how long you last. Here's another take on it. Don't think of this in terms of tracing packet routes. Trace the path of SLAs, AUPs, and peering agreements between Vonage and those blocked customers. Madison River buys transit from someone. At some point, their contractual obligations for that peering arrangement are passing on elements of other peering agreements, which in turn pass on still more. This is the essential layer of cooperation and good faith that make the internet work. On the other end, Vonage, or any Voip provider, for that matter, has purchased peering and transit with the reasonable expectation that they can pass end-to-end traffic, unfiltered. It would not be entirely unreasonable to see a peering agreement terminated for this behavior. I am not a lawyer, and I am not privy to the details of the peering agreements for the networks between Vonage and their end customers, but it's their faith in the basic nature of peering agreements that make their entire business model viable. - billn
Re: High volume WHOIS queries
On Tue, 1 Mar 2005, Paul G wrote: point - they're trying to restrict the practicality of attempting to harvest the data and an open to the public whois server with no access restrictions would defeat that. I don't know that this is the case, I suspect it's resource management. If the database is getting slaughtered by applications on uncontrolled auto pilot, it's unusable for the rest of us. well, the OP quoted a portion of the aup that requires bulk whois data recipients to take measures to prevent harvesting, so i presume that arin does care about that and, in fact, that consideration is likely the reason they declined to permit the OP to run *his own* whoisd off of his *local* copy of the data. If memory serves, that restriction didn't appear until spam became a problem. The verbiage in the AUP is there to give ARIN recourse in the event that some spammer, and it has happened, runs a harvest against domain names or serialized NIC handles to seed a spam source. - billn
RE: NANOG Changes
On Sun, 20 Feb 2005, Hannigan, Martin wrote: [ snip ] As I was browsing the archive, I noticed my post and his and another one from William Leizon that quoted mine have been removed from it. From what I understand, the archive feature wasn't turned on until just before the first post that was actually archived appeared. So, now that archiving is on (for those of us reading the archive instead of subbing to the traffic), can those posts be resubmitted for the sake of posterity? - billn
RADB anon ftp server stoned or deprecated?
$ ftp ftp.radb.net Connected to ftp.radb.net (198.108.1.48). 421 Service not available, remote server has closed connection $ ftp ftp.merit.edu Connected to ftp.merit.edu (198.108.1.48). 421 Service not available, remote server has closed connection - billn
Re: RADB anon ftp server stoned or deprecated?
Quite possibly, didn't even occur to me to check from that host. Donkey shins for the clue by four. - billn On Mon, 14 Feb 2005, Mike Tancsa wrote: Works for me. Are you sure you are not coming from a PTR/A record mismatch ? smarthost1# host 66.235.194.37 37.194.235.66.IN-ADDR.ARPA domain name pointer ds194-37.ipowerweb.com smarthost1# host ds194-37.ipowerweb.com Host not found. smarthost1# smarthost1# host -tns ipowerweb.com ipowerweb.com name server ns2.ipowerweb.net ipowerweb.com name server ns1.ipowerweb.net smarthost1# host ds194-37.ipowerweb.com ns1.ipowerweb.net Using domain server: Name: ns1.ipowerweb.net Addresses: 64.70.61.130 smarthost1# host ds194-37.ipowerweb.com ns2.ipowerweb.net Using domain server: Name: ns2.ipowerweb.net Addresses: 66.235.217.200 smarthost1# At 10:05 PM 14/02/2005, Bill Nash wrote: $ ftp ftp.radb.net Connected to ftp.radb.net (198.108.1.48). 421 Service not available, remote server has closed connection $ ftp ftp.merit.edu Connected to ftp.merit.edu (198.108.1.48). 421 Service not available, remote server has closed connection - billn
RE: IRC Bot list (cross posting)
On Wed, 9 Feb 2005, Hannigan, Martin wrote: out botnet lists to NANOG, fine by me. I never said I can stop them. I just said I didn't want them as a subscriber. I understand that you don't know where these existing lists are. Look hard. If you suddenly care about bots enough in the last 24 hours to spend all night writing a post about me, you should be able to expend the same energy and find a botnet list to enjoy. My point is simple. There's more people on this list besides you and William. This list should not run by the preference of two vocal people who can't be bothered to skim/trim/ignore threads they aren't interested in. This isn't exactly a high volume list. The percentage of subscribers who actually post is a distinct minority, and from the volume of mail I got last time you and I went around, there's a lot of smaller operators who simply monitor the list for interesting things who may find those kinds of discussions interesting. This thread is already longer than it likely would have been had it simply been recognized as uninteresting signal (but signal nonetheless) and left alone. I'm hardly an icon of self-restraint, but worry about off-topic when it's actually a problem, and stop discouraging people to post entirely. - billn
Re: IRC Bot list (cross posting)
[ Edited and resent, the first appears to have vanished in transit ] I concede the point that operational tracking of botnets doesn't belong here, and I offer apologies to Martin, and the list in general, for not counting to ten before replying to his email. However, simply suppressing discussion of the topics isn't a good way to foster a cooperative working environment. I'd like to thank those few folks who corrected me, today. I was wrong in what I felt was appropriate, and I shouldn't have gone off in the manner I did. Moving to a more productive stance for this thread: How many people have subbed in the past month? The past year? There's stuff in the FAQ about what's directly relevent to this particular list, but there are a million related sub-topics with low level chatter that would overwhelm a single list, like this one. Is there a helpful resource that references these lists, to give subscribers a better grasp on topic specific lists that other nanog users deem productive, clue packed and useful? - billn
Re: IRC Bot list (cross posting)
You don't mass an army if you're not about to use it. This situation can (very quickly) have operational relevance. Bringing it to light to a wider forum than special interest groups is a good idea. You'd certainly care more if it was pointed at you. - billn On Tue, 8 Feb 2005, william(at)elan.net wrote: Wasn't there supposed to be special mail list setup for botnet tracking? If so can we please move this thread there and not continue it on main nanog list...
RE: IRC Bot list (cross posting)
On Wed, 9 Feb 2005, Hannigan, Martin wrote: Bill, haven't we been here before? :) There's TWO places that are doing this botnet stuff and the NANOG AUP discourages cross posting. I for one certainly don't want yet another list full of botnet stuff. And I'm not subscribed to either. Yet, I've no less than a /19 of space under my purview and I don't believe that publishing botnet lists in the manner that has been done is either off topic, or off charter. Some of us, as hosting providers or similiar entities, have network costs to keep to a minimum. For those of us with security concerns, a heads up to compromised hosts within our bailiwick will *always* be appreciated. Yes, we've been here before. I'm not sure what the view is like from your horse, but I imagine it's very different from mine, since my job security is based on performance, not monopoly backing. This kind of topical suppression is as bad as draconian moderation. In the years I've been subscribed to nanog, I've taken a very simple stance to threads I'm not interested in: I ignored them. I highly suggest you do the same, because frankly, I'm rapidly tiring of your condescension. What exactly is it that makes your viewpoint more important than mine? Based on the simple evidence that you're literate, I'm going to guess that you can read, and delete, an accurately described thread by interpreting the subject line. Various persons put forth some amount of effort to, graciously, give other operators a heads up to the ongoing/potential abuse of their networks, and you're concerned about topical relevance? Why aren't you, in the least, THANKING them for their efforts? Maybe it's because these thousands of drones are being used to pump out spam across the internet, which may require (at some point) some form of domain registration at the end site pushing whatever product, which at later trickles into Verisign's coffers? If you're not going to be part of a productive solution, do us a favor and stop getting in the way of people actually trying to do something useful. - billn
Re: Graphing Peering
If you're already using MRTG, hopefully you're at least passingly familiar with perl and SNMP. If so, you can do some hackery to identify your BGP peer interfaces automatically and then use it to reference existing interface graphs. Take a peek in the BGP4 mib, specifically at the BgpPeerEntry subtree. You may need to do some correlation inside the ifTable or maybe even ifX, depending on platform and implementation, to correctly identify the interface of your peer. - billn On Wed, 19 Jan 2005, andrew matthews wrote: no i mean graph bgp sessions... it's a single interface, and i want to graph every bgp session so i can see how much traffic i'm doing between each peer. On Wed, 19 Jan 2005 22:25:37 + (GMT), Stephen J. Wilcox [EMAIL PROTECTED] wrote: On Wed, 19 Jan 2005, andrew matthews wrote: Anyone have any suggestions on graphing peering on a cisco router? I'm using mrtg and i did mac address accounting but the numbers are off. do you mean how to graph traffic to each host on a lan..? what platform do you have? Steve
Re: Graphing Peering
Ah, completely different animal altogether, that. Thanks for the clarification. My initial read was multiple peers on separate interfaces, which isn't overly complex to track. - billn On Wed, 19 Jan 2005, Daniel Golding wrote: Andrew's issue is this - he's got an Ethernet port on a public peering switch with a bunch of peers. He can see the interface stats just fine but he's having trouble figuring out how much traffic is going to (or coming from) each peer. One interface, many peers, confusing problem. There isn't one VLAN per peer on most public peering switches - its one big Ethernet segment with each peer getting an IP out of a common subnet. Welcome to the world of broadcast multi-access peering. The classical way to do this is mac accounting. This can be pretty rough - its not really useful for anything more than a ratio, from what I've seen - the numbers tend to not add up properly. Another possibility (on Cisco) is using BGP Policy Accounting, although support can be spotty depending on hardware. For other platforms, there's some good information here: http://www.switch.ch/misc/leinen/snmp/monitoring/bucket-accounting.html The link on that page for Juniper's Destination Class Usage (DCU) is broken. Try this one instead: http://www.juniper.net/techpubs/software/junos/junos70/swconfig70-interfaces /html/interfaces-family-config25.html - Dan On 1/19/05 5:56 PM, Bill Nash [EMAIL PROTECTED] wrote: If you're already using MRTG, hopefully you're at least passingly familiar with perl and SNMP. If so, you can do some hackery to identify your BGP peer interfaces automatically and then use it to reference existing interface graphs. Take a peek in the BGP4 mib, specifically at the BgpPeerEntry subtree. You may need to do some correlation inside the ifTable or maybe even ifX, depending on platform and implementation, to correctly identify the interface of your peer. - billn On Wed, 19 Jan 2005, andrew matthews wrote: no i mean graph bgp sessions... it's a single interface, and i want to graph every bgp session so i can see how much traffic i'm doing between each peer. On Wed, 19 Jan 2005 22:25:37 + (GMT), Stephen J. Wilcox [EMAIL PROTECTED] wrote: On Wed, 19 Jan 2005, andrew matthews wrote: Anyone have any suggestions on graphing peering on a cisco router? I'm using mrtg and i did mac address accounting but the numbers are off. do you mean how to graph traffic to each host on a lan..? what platform do you have? Steve
Re: Proposed list charter/AUP change?
On Wed, 5 Jan 2005, Janet Sullivan wrote: Bill Nash wrote: On/off topic is very relevant, since it determines moderator involvement. Many people feel moderation is broken, and topical candidates are an element of it. Seeing post after post from people who feel they've been unfairly sanctioned, or having clueful users appearing on virtual milk cartons is a problem. Fix it. https://lists.bgp4.net/mailman/listinfo/netops This is an excellent point to bring up, and it's good to have alternative forums. But. It's a band-aid, in the short term, and won't do much to 'unalienate' (disalienate?) those who have departed, by choice or otherwise, because of moderator actions. - billn
Proposed list charter/AUP change?
On Mon, 3 Jan 2005, Steve Sobol wrote: Susan keeps on claiming spam is offtopic for Nanog, yet the AUP/Charter/FAQ don't mention spam other than telling us not to ask I'm being spammed, how can I make it stop? If it's flat-out offtopic, no matter what, or if the majority of list members don't want to talk about it on the list, why hasn't the FAQ been updated? Or does Merit just want us to try to guess what is offtopic? Spam represents a significant percentage of email traffic, and its delivery is increasingly via trojaned dsl/broadband devices. Even spam delivered from quasi-legitimate sources is usually an abuse of resources that some NSP/ISP is paying for. Discussion of functional spam control at the ISP level, I think, is absolutely on topic for a list of this scope. Please note, that I say 'functional'. Random complaints would obviously not fall into this category. Examples would include: Working enterprise-scale spam filtering (Hourly mail volume measured in thousands) Discussion of edge/core SMTP filtering to curtail spam sources. Policy discussions for handling domestic and international spam sources. Implementation, or requests for implementation, of SPF and similiar controls. Inter-network cooperation for handling large scale issues. I think this last is pretty much exactly what a list like this is for, be it spam, regional power outages, BGP shenanigans, or widespread squirrel detonations. - billn
Re: Proposed list charter/AUP change?
On Tue, 4 Jan 2005, Stephen J. Wilcox wrote: Hi Bill, to be fair, there are specific forum for discussion of spam tackling measures and people have been pointed in that direction on numerous occasions, however in its generic sense it might still be on topic for nanog. I note the original post that sparked this (assuming i'm following these discussions correctly) was actually about abuse desks not spam specifically... So if the question is about anti-spam i think its OT, if its about abuse or a new spam technique then its probably of interest. I would agree with this. I touched on that with mention of trojaned sources, but perhaps I should have been more clear. Thanks for the correction. - billn
Re: Sunday evening meeting
On Mon, 3 Jan 2005, Susan Harris wrote: Also, what are the expected outcomes of this meeting? We can't predict outcomes until we hear from you folks - that's the goal of the meeting, to hear any and all concerns about moderation of the NANOG list, selection of talks for the meetings, and whatever else is on your mind. We'll then take your input back to Merit and the program committee and suggest some potential solutions. At the risk of being a caustic agitator, I should imagine the outcomes would include: - A change of moderation policy and practices for the mailing list. - A change of moderators for the mailing list. - A change of venue for the mailing list. - Nothing. At the minimum, one would hope to see: - Periodic reminders of what's on topic and what isn't. - A working warning system for repeat short-term offenders. - Increased visibility into the why's of sanctions applied to productive clueful posters. - Actual responses to direct queries regarding policy and actions. From the dearth of emails sent by the various folks who crawled out of the woodwork with denigrating remarks about what I could reasonably expect with my direct request for moderator comment on ratification of the list's charter, I'd say this last item is the most significant. I am, in fact, still waiting, as many people predicted I would be. I realize I may seem the interloper on this subject, as a read-only non-expert for most of the common discussions, but at the very minimum I would 'reasonably expect' the professional courtesy of a response, even if it had been as minimal as This can be discussed at the next meeting. I'd rather be blown off with some well placed smoke or sunshine than be made to think I'm null routing my own email. - billn
RE: Anycast 101
On Mon, 20 Dec 2004, Hannigan, Martin wrote: there are some million-bot drone armies out there. with enough attackers I know I haven't seen any 1MM+ zombie armies out there and I'm looking for them. Why spend all that time getting 1MM bots when you only need 100K? Dormant reinforcements. Multiple operational floodnets in smaller cells. Rapid reconfiguration of a cell, cycling in new hosts, removing hosts that have sustained functional losses to reactive routing changes. Having those kinds of resources on hand allows an attacker to use a 'Captain Tripps'[1] style of attack to maintain a sustained assault on single, or even multiple targets. As for why? I can only answer 'why not?' Zombies are being created in an automated fashion, as it is. If you've got the resources to handle 100k, it's not that hard to tap some of that volume to multiplex or scale your drone management. - billn [1] Stephen King, 'The Stand'
RE: Anycast 101
On Mon, 20 Dec 2004, Hannigan, Martin wrote: Look at how the discussions surrounding SPAM have evolved. It went from damn abusers, to damn software, to where's the money coming from?. The BotNet problem has already evolved to where's the money. Botnets are a new phenomenon. [ Gadi!?] Botnets aren't new. They've been prototyped on various IRC networks for years. It started with hordes of linked eggdrop bots for Death Star style privmsg/notice flood attacks on single users (1998? 1999?). When the response was to hunt down and remove the bots in a mass fashion (I hacked up one of the early tools for doing it), it turned into submarine botnets on private servers (or not connected to IRC at all) doing DDoS attacks against targetted IP addresses. These days, it's virally injected remote controls and soon, sharks with frickin laser beams. - billn
Enterprise syslog management and alert generation.
Some people call this 'Netcool' or products of a similiar stripe. I'm ramping up a project to rebuild some previous work done on this front with an open source distribution in mind (those of you on the syslog-ng list have seen mention of it), so I'm fishing for requirements I may not have already covered. I currently have: Perl regexp engine for applied rules. Tokenization and extraction of data from inbound syslog data. Assigning (single|multiple) customized event handlers to rule matches Ability to run multiple analyzers concurrently Optional linear rule application versus weighted optimization SQL storage of rules for centralized management and redistribution. Fully customized alert generation. My current production implementation has handled over 20 gigs a day, at peak, on a single analyzer (dual amd 2800+), using syslog-ng as a transport mechanism (forked socket transport with local disk logging for backup). Every network is different, as are particular requirements. Who's got wish lists? I personally wouldn't mind an on-list discussion about this, as it applies to standard operations toolsets, but if that's not kosher, feel free to contact me off-list. - billn
Re: Enterprise syslog management and alert generation.
On Tue, 7 Dec 2004, Alexei Roudnev wrote: In such products, only 20% value is in engine; 80% are in rules, because I can not wrire rules myself - I have not event until it happen, and I can not filetr out noice until it happen. We use a few syslog analyzers (using syslog-ng as a transport), some with simple logcheck, other with database for rules and hosts; and every time problem is the same - writing rules is 90% of the problem. But... do you have rules, such as fort example _send alert if any system began to generate 10 times logs / hour more vs. average? Or saying _single PCI ERROR on Solaris - ignore, 10 in a straight line - send warning... The X over time is a new one, it's been mentioned a couple times today, and I can certainly account for it. I've added it to my rapidly growing list. - billn
