RE: European Nanog?
Too many nogs- The RIPE NCC ran a Euro Operators forum that was probably the most useful. Neil.
Re: European Nanog?
On 13.09.2004 11:18 Neil J. McRae wrote: Too many nogs- The RIPE NCC ran a Euro Operators forum that was probably the most useful. 1. EOF is still alive though hardly visible/audible. 2. EOF is not a RIPE NCC activity. Arnold
RE: European Nanog?
2. EOF is not a RIPE NCC activity. Who runs/funds/maintains it then? Neil.
Problem
Hi Nanogers, A brief introduction before i begin. I am Abhishek and am doing my masters in Comp Sc. from IT BHU. This is my first mail to Nanog, which i believe has the most number of network operators in its list. We have simulated a mini model of the Internet here in our labs with around 50 dedicated linux machines. We use and play around with Zebra for routing. I know its a small number to simulate the 'Internet' but its something that we have just started off with, and we hope to expand as time flies by. We are now facing a small problem and i want to know what people, who manage the 'real' networks do in such cases: We use a combination of OSPF and ISIS inside the autonomous systems as the IGPs and BGP4 as the EGP to interconnect the ASes. I am receiving two BGPv4 routes for a network (some server announcement) from two of my upstream peers (each of which happens to be, unfortunately in a different AS). For me both the routes are similar in preference hence can install both of them in my forwarding table to split the traffic across these autonomous systems. My question is, that is this allowed and is it the right thing to do? What i mean by this is, that if i install the two routes in my forwarding table, and i announce just one, then am i not hiding information about the routes that i am using from my downstream peers? I take it, that this is a very normal scenario and people on this list must have seen it many times. How do people deal with this. Do they install just one route, despite having multiple ways to reach a network(s). Thanks, Abhishek P.S. I searched for a group similar to Nanog that caters to South East Asia and found out about SANOG. Is the group alive? I could see no mail archives there. -- Class of 2004 Institute of Technology Varanasi -- India
Re: European Nanog?
- Original Message - From: Neil J. McRae [EMAIL PROTECTED] To: 'Nicolas DEFFAYET' [EMAIL PROTECTED]; 'Arnold Nipper' [EMAIL PROTECTED] Cc: 'Ken Gilmour' [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, September 13, 2004 5:18 AM Subject: RE: European Nanog? Too many nogs- The RIPE NCC ran a Euro Operators forum that was probably the most useful. in europe, same as in the US, there is a limited number of people who are at least peripherally interested in participating. not everyone is interested in everything - based on nanog experiences, there are rather large (proportionally) groups of people who are only interested in discussing spam, gmail invites or bad analogies for example. in our case, all of this is merged into one discussion stream. in europe, with ripe running several more specific lists, there isn't enough traffic for an everything goes, including crap forum. /imho paul
Re: European Nanog?
On Sun, Sep 12, 2004 at 09:16:33PM +0200, Michel Renfer wrote: Hi, The NOG philosophy don't work in Europe. That's not correct. The concept works in switzerland with SwiNOG very well - at least two meetings every year and a good organized communitiy behind SwiNOG. Agree, here in .nl we have (how surpising) NLNOG. This is a semi-open forum (read access for everyone, posting for a limited group). From time to time we even have social meetings. No formal meetings (yet). Works like a charme! -- Sabri Berisha, SAB666-RIPE - I route, therefore you are http://www.cluecentral.net - http://www.virt-ix.net
Re: European Nanog?
On 13.09.2004 11:37 Neil J. McRae wrote: 2. EOF is not a RIPE NCC activity. Who runs/funds/maintains it then? EOF is run my itself and has a status as a RIPE WG, hence imbedded in RIPE. Arnold
Re: 30 Gmail Invites
And here I thought I was the only one to seriously consider blocking gmail (to and from) because of the security implications. I find it interesting how many people are concerned with sending email to gmail users yet are quite willing to send email to public mailing lists that are archived and indexed by Google. Does anyone really believe that people will use gmail as their one and only email account? Perhaps they are really using it for trading DIVX encoded movies. After all, the cost of sending a DIVX encoded movie from one gmail.com mailbox to another gmail.com mailbox is relatively low. What happens to your network when this happens and instead of receiving a stream of HTML search pages from Google, you now start receiving huge DIVX film downloads, all from a single site! Assuming that they aren't Akamized... --Michael Dillon
RE: European Nanog?
So the RIPE NCC - thanks. EOF is run my itself and has a status as a RIPE WG, hence imbedded in RIPE.
Re: European Nanog?
On 13.09.2004 12:20 Neil J. McRae wrote: So the RIPE NCC - thanks. EOF is run my itself and has a status as a RIPE WG, hence imbedded in RIPE. As already noted here a couple of times: RIPE != RIPE NCC Although MERIT is organizing NANOG meetings, no one would say: MERIT == NANOG. Right? Arnold
RE: European Nanog?
As already noted here a couple of times: RIPE != RIPE NCC Although MERIT is organizing NANOG meetings, no one would say: MERIT == NANOG. Right? I love the obsession that people have with this! You can state what you like, but the income from the NCC is what mostly funds the other RIPE activities, in which case its all the same to me, does the EOF live on a RIPE.NET server? Yes. Who funds those servers? Regards, Neil.
Re: 30 Gmail Invites
[EMAIL PROTECTED] wrote: Does anyone really believe that people will use gmail as their one and only email account? Perhaps they are really using it for trading DIVX encoded movies. After all, the cost of sending a DIVX encoded movie from one gmail.com mailbox to another gmail.com mailbox is relatively low. What happens to your network when this happens and instead of receiving a stream of HTML search pages from Google, you now start receiving huge DIVX film downloads, all from a single site! I thought there was a message size limit which is far below the mailbox size limit? Haven't tried if they are able to piece up large messages from MIME headers or such. Pete
Re: European Nanog?
On 13.09.2004 12:52 Neil J. McRae wrote: As already noted here a couple of times: RIPE != RIPE NCC Although MERIT is organizing NANOG meetings, no one would say: MERIT == NANOG. Right? I love the obsession that people have with this! You can state what you like, but the income from the NCC is what mostly funds the other RIPE activities, in which case its all the same to me, You are welcome with your sight of the world, but we still believe it's not a disc ;-) does the EOF live on a RIPE.NET server? Yes. Who funds those servers? There ae loads of websites living on someone else server (and even paid for by someone else). But that does not make them necessarily belong to someone else. Arnold
Re: European Nanog?
On Mon, 13 Sep 2004, Arnold Nipper wrote: As already noted here a couple of times: RIPE != RIPE NCC Although MERIT is organizing NANOG meetings, no one would say: MERIT == NANOG. Right? Not quite. As far as I'm concerned, NANOG is part of MERIT activities. And while I'm not certain if NANOG is actually legally organized in any way, if it is, it is probably considered to be subsidiary of MERIT So while NANOG != MERIT, what we have is that NANOG MERIT Similarly while EOF != RIPE NCC, it is part of it, i.e. EOF RIPE I'm not so certain about RIPE NCC to RIPE relationship though, I suspect that RIPE NCC is a subset (RIR services or) larger RIPE organization that is involved in other activities, i.e. RIPE NCC RIPE So in this case both EOF and RIPE NCC being subsets of same larger set, these subsets may intersect (or one subset maybe contained in another or equal to it) but we do not know about it without additional data and can not make logical conclusion that EOF RIPE NCC. All we can can say is both EOF and RIPE NCC represent organized activity of RIPE existing in parallel and possibly sharing in some parts of the activity. But of course, overall funding for RIPE still comes from RIPE NCC, so while other activities of RIPE are not necessarilty parts of RIPE NCC they are still funded by it :) -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: 30 Gmail Invites
Hell, I couldn't even log into it. The system was Temporarily unavailable when I tried. Curtis Petri Helenius wrote: [EMAIL PROTECTED] wrote: Does anyone really believe that people will use gmail as their one and only email account? Perhaps they are really using it for trading DIVX encoded movies. After all, the cost of sending a DIVX encoded movie from one gmail.com mailbox to another gmail.com mailbox is relatively low. What happens to your network when this happens and instead of receiving a stream of HTML search pages from Google, you now start receiving huge DIVX film downloads, all from a single site! I thought there was a message size limit which is far below the mailbox size limit? Haven't tried if they are able to piece up large messages from MIME headers or such. Pete
Re: European Nanog?
On 13.09.2004 13:27 william(at)elan.net wrote: I'm not so certain about RIPE NCC to RIPE relationship though, I suspect that RIPE NCC is a subset (RIR services or) larger RIPE organization that is involved in other activities, i.e. RIPE NCC RIPE No, that's not true. There is no order function for EOF, RIPE and RIPE NCC. While EOF has a RIPE WG status it is not a RIPE WG (this was at least my understanding). And the only relation between RIPE and RIPE NCC is that RIPE NCC is provid(es)ing administrative support for RIPE. But of course, overall funding for RIPE still comes from RIPE NCC, so while other activities of RIPE are not necessarilty parts of RIPE NCC they are still funded by it :) There is no overall funding for RIPE. For what? Meeting costs and the like are paid for by the meeting participants. Arnold
Re: European Nanog?
In article [EMAIL PROTECTED], Ken Gilmour [EMAIL PROTECTED] writes Does anyone know of a list like nanog for Europe? I would be interested in subscribing... If your network is member of LINX or AMS-IX you will find there some private lists which discuss a European flavour of many of the things I see on NANOG. -- Roland Perry
Re: 30 Gmail Invites
On Mon, 13 Sep 2004 11:03:57 +0100 [EMAIL PROTECTED] wrote: I find it interesting how many people are concerned with sending email to gmail users yet are quite willing to send email to public mailing lists that are archived and indexed by Google. There is in most cases a significantly lower expectation of privacy when sending to any public mailing list (regardless of who indexes it) than when sending to a single individual. The difference you cite is, therefore, somewhat understandable. Even more so if people set up forwards from their existing email addresses into GMail accounts, when the senders do not know that the mail they send will be read on Gmail. -- Richard Cox
Re: European Nanog?
On Mon, 13 Sep 2004 06:28:36 +0530, the mental interface of Suresh Ramasubramanian told: Daniel Roesen [12/09/04 20:32 +0200]: But when it comes to mailing list traffic volume, there is no companion that I'm aware of. I rather believe that's a feature, not a bug I'd rather have no mails than tons of gmail invites! -- Microsoft isn't evil, they just make really crappy operating systems. -- Linus Torvalds The best way to prepare [to be a programmer] is to write programs, and to study great programs that other people have written. In my case, I went to the garbage cans at the Computer Science Center and I fished out listings of their operating systems. -- Bill Gates, OS/2 Notebook, Microsoft Press, 1990, p. 614
Sender-ID denied by IETF?
Top story on Slashdot: http://it.slashdot.org/it/04/09/13/1317238.shtml?tid=172tid=95tid=218 Zocalo writes The MARID working group at the IETF responsible for deciding on which extensions to SMTP will be used to try and prevent spoofing of the sender has made their decision. At issue was whether Microsoft's patent encumbered Sender-ID would be eligable for inclusion in an Internet standard. An initial analysis of the text of their decision, available here with a brief analysis, would suggest not. Unless Microsoft is going to make any dramatic concessions out of desperation, that pretty much clears the way for Meng Wong's Classic SPF to become the standard and hopefully make Joe-Jobs at thing of the past. -- Jeff Wheeler Postmaster, Network Admin US Institute of Peace
Re: Sender-ID denied by IETF?
On Mon, Sep 13, 2004 at 10:58:13AM -0400, Jeff Wheeler [EMAIL PROTECTED] wrote a message of 19 lines which said: Top story on Slashdot: http://it.slashdot.org/it/04/09/13/1317238.shtml?tid=172tid=95tid=218 Warning: this is probably non-operational content. I suggest to move the discussion in private or on the MARID Working Group mailing list. Zocalo writes The MARID working group at the IETF responsible for deciding on which extensions to SMTP will be used to try and prevent spoofing of the sender has made their decision. At issue was whether Microsoft's patent encumbered Sender-ID would be eligable for inclusion in an Internet standard. An initial analysis of the text of their decision, available here with a brief analysis, would suggest not. This is heavily simplified (the PRA algorithm was not rejected). Unless Microsoft is going to make any dramatic concessions out of desperation, that pretty much clears the way for Meng Wong's Classic SPF to become the standard and hopefully make Joe-Jobs at thing of the past. This is also either wishful thinking or pure disinformation. For those who want the facts, see: http://www.imc.org/ietf-mxcomp/mail-archive/msg04673.html co-chair judgment of consensus related to last call period of 23-Aug-2004 to 10-Sept-2004
EVENT - Building a network and system management open source tool - talk at BayLISA, Cupertino, California, USA, Thursday 16 Sept. 2004 19:30-21:00
If you are in the San Francisco Bay Area, you can join us for a talk I am giving for the BayLISA (Bay Area Large Installations Systems Administrators User Group). http://ww:w.baylisa.org/ and participate to a talk on the design and building of a new open source system and network management tool. Attendance is free, hosted in the luxurious Apple RD building in Cupertino. Quite often, water and fresh krispy-kremes are served a geek delight! No registration is required, free and open to the public. September 16, 2004 7:30 pm - 9:30 pm Apple Campus, Infinite Loop, Cupertino, CA, USA Town Hall *BLDG 4* Here is the event intro : Forests and Trees://Building an Open Source Discovery Management Tool with XML In a an ideal world everything on the network would have a simple management interface, and every tool could access it. Well, in our real world, large shops typically have at least one version of every major network equipment, hardware, and software produced in the last ten years As sysadmins and network admins, we rely on a mixture of commercial and open source network management tools and a lot of scripting and elbow grease to accomplish our magic. What about an open source system where all management data could be accessed remotely, without an agent to install on your 1000 servers and all protocols could be used with a friendly URL, and return standardized data that could queried and combined together regardless of where they are coming from? The recipe? Put a dose of ssh, sftp, http, nmap, smb, snmp, wbem, wmi, nfs, webdav, dns, dhcp, smtp, wins, ldap, sql, mibs, mofs, ping, arp and a couple other in a large pot. Stir well your alphabet soup, throw in a couple RFCs for spice, then add a pinch of URI, XML, Xpath and Xquery, some scripting, heat up to a gentle boil, and you get something that might taste good, or at least different. In this presentation, we will walk through design issues and trade-offs for such an open source system, and show new ways to extend the web and XML to network management, using existing tools, techniques, and skills. Some live demo will be made of the kind of weird and funny capabilities that are exposed. -- Cheers Philippe philippe ombredanne | nexB - Open IT Asset Management 1 650 799 0949 | pombredanne at nexb.com http://www.nexb.com
Provider/NAP filtering policies
Greetings. I was hoping someone could point me in the direction of provider/NAP prefix filtering policies. Most important to me is UU and Cogent, but a concise listing of notables would be much appreciated. Regards, Jade Jade E. Deane Senior Network Engineer SunGard Futures Systems SunGard Systems International, Inc. [EMAIL PROTECTED] +1 (312) 577-6100 ext. 6961 +1 (866) 741-0076 (Fax)
Re: European Nanog?
On Mon, 13 Sep 2004, Arnold Nipper wrote: On 13.09.2004 11:18 Neil J. McRae wrote: Too many nogs- The RIPE NCC ran a Euro Operators forum that was probably the most useful. 1. EOF is still alive though hardly visible/audible. 2. EOF is not a RIPE NCC activity. I'd agree that RIPE is the forum tho, it *is* the foremost industry forum for policies and is well established. Too many splinter groups already... Steve
Re: Provider/NAP filtering policies
On Mon, 13 Sep 2004 [EMAIL PROTECTED] wrote: I was hoping someone could point me in the direction of provider/NAP prefix filtering policies. Most important to me is UU and Cogent, but a concise listing of notables would be much appreciated. Just to clarify, NAPs or Internet exchanges are typically (like more than 99% of the time) layer-2 services, which don't pay attention to or care about layer-3 things like IP prefixes. A few have policies regarding what participants should filter on their own behalf, but of the four hundered odd exchanges currently operating out there, I don't know of any which filter prefixes themselves. Virtually all _providers_ over a certain size filter heavily, of course, and that's probably the portion of your question you'll get more (and more useful) answers to. -Bill
RE: Provider/NAP filtering policies
My apologies, allow me to make a clarification. When I mentioned NAPs, I was referring more to provider peering policies _AT_ a NAP, rather than a NAP's peering policies which of course as you pointed out would be moot. Being relegated to closed enterprise environments for the past few years, I'm trying to play catch-up and validate my previous assumption that most providers filter at a /19 boundary, etc. Regards, Jade -Original Message- From: Bill Woodcock [mailto:[EMAIL PROTECTED] Sent: Monday, September 13, 2004 12:42 PM To: Deane, Jade Cc: [EMAIL PROTECTED] Subject: Re: Provider/NAP filtering policies On Mon, 13 Sep 2004 [EMAIL PROTECTED] wrote: I was hoping someone could point me in the direction of provider/NAP prefix filtering policies. Most important to me is UU and Cogent, but a concise listing of notables would be much appreciated. Just to clarify, NAPs or Internet exchanges are typically (like more than 99% of the time) layer-2 services, which don't pay attention to or care about layer-3 things like IP prefixes. A few have policies regarding what participants should filter on their own behalf, but of the four hundered odd exchanges currently operating out there, I don't know of any which filter prefixes themselves. Virtually all _providers_ over a certain size filter heavily, of course, and that's probably the portion of your question you'll get more (and more useful) answers to. -Bill
Re: Provider/NAP filtering policies
Greetings. I was hoping someone could point me in the direction of provider/NAP prefix filtering policies. Most important to me is UU and Cogent, but a concise listing of notables would be much appreciated. Jade E. Deane perhaps this would be helpful. http://www.ep.net/policy.html --bill
Re: European Nanog?
2. EOF is not a RIPE NCC activity. actually, it is. but it did not used to be. randy
RE: European Nanog?
You can state what you like, but the income from the NCC is what mostly funds the other RIPE activities, in which case its all the same to me, does the EOF live on a RIPE.NET server? Yes. Who funds those servers? more to the point, who decided meeting content? essentially daniel karrenberg does. randy
Any Kine NOGs? Re: European Nanog?
: The NOG philosophy don't work in Europe. : simply not true. Check out SwiNOG http://www.swinog.ch/ : : And there's NordNOG. Anyone got a list of all english language NOG mailing lists? So far I have AFNOG, SwiNOG (apparently some in english) and SANOG. Thanks, scott
Re: Any Kine NOGs? Re: European Nanog?
: The NOG philosophy don't work in Europe. : simply not true. Check out SwiNOG http://www.swinog.ch/ : And there's NordNOG. Anyone got a list of all english language NOG mailing lists? So far I have AFNOG, SwiNOG (apparently some in english) and SANOG. NZNOG (New Zealand) -Bill
Upcoming NANOG ARIN Meetings
Hi, I've been to previous NANOG meetings and have found them to be very useful. Can someone shed some light for me on the ARIN meetings? I guess I want to know if it worth attending? ARIN folks - please be kind... :) PLEASE REPLY OFF-LIST. Thanks, Charlie
Re: Any Kine NOGs? Re: European Nanog?
At 10:36 13/09/2004 -1000, Scott Weeks wrote: Anyone got a list of all english language NOG mailing lists? So far I have AFNOG, SwiNOG (apparently some in english) and SANOG. My little list includes: NANOG, AfNOG, SANOG, JANOG, EOF, APOPS, SGNOG, NZNOG, NordNOG, SwiNOG, PACNOG So, North America, Africa, South Asia, Japan, Europe, Asia Pacific, Singapore, New Zealand, Nordic Countries, Switzerland, Pacific. There are bound to be others lurking out there... philip --
Ivan damage...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yo Nanogers! Not been able to reach my machines in Jamaica. The Kingston Daily Gleaner is back up with text only pages. They report BOTH the primary and secondary submarine cables to Jamaica are severed: http://www.jamaica-gleaner.com/gleaner/20040913/lead/lead7.html RGDS GARY - --- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFBRiJV8KZibdeR3qURArgoAJ91UqYc96wXd/4wKyDt2Q5o1LGkKACg2yIx MqVarfvBbZpPyMNae5WsNVc= =BCDE -END PGP SIGNATURE-
Re: Upcoming NANOG ARIN Meetings
On Mon, Sep 13, 2004 at 03:26:09PM -0700, Charlie Khanna - NextWeb wrote: Hi, I've been to previous NANOG meetings and have found them to be very useful. Can someone shed some light for me on the ARIN meetings? I guess I want to know if it worth attending? ARIN folks - please be kind... :) well - have you reviewed the ARIN web site? --bill
Re: Upcoming NANOG ARIN Meetings
Can someone shed some light for me on the ARIN meetings? I guess I want to know if it worth attending? wanna watch sausage being made? but the arin sausage factory has become far less scary than apnic's or ripe's, by a long shot. randy
Re: Gb ethernet interface keeping dropping packet in ingress
If you're sniffing one gigabit port from a switch with much higher bandwidth, you're going to lose something. Our primary sensor sits on an aggregation switch just prior to hitting the net, and we have a 2Gb fast etherchannel span port defined and lose relatively little in terms of packet loss. If course, the more aggregate traffic you have, the higher the probability you will max out the span port and it's buffers. Unless you're just drilling the heck out of the server farm(s) on that switch, you won't lose all that much with an etherchannel of 2 Gig ports. We have 2Gb etherchannel uplinks back to the core, and the most the switch could throw at us would be 2Gb etherchannel traffic. So we are spanning the uplinks there. Just as your switches/routers can be over subscribed the the 4506 backplane is only 6Gb/slot, and we don't lose that much, and some of that loss is due to buffer constraints on the switch. Not perfect, but it works. In less critical ennvironments, we can sniff with a 100Mb interface and still do well. The only caution here is that you can seldom catch local traffic. If there's a local scanner (like Blaster started out to be) it doesn't show up except for excessive arps. We have some cron'ed scripts that periodically (1) look at connection counts in the PIX, if they're out of range), we quarantine them to the Perfigo dungeon. Similarly there is a script that counts ARP requests (just the dorms specifically right now) and for every 1000 it forks itself to start anew, and analyzes the numer of ARPS per station. Local scanners get eaten up here really quickly and they are also quarantined. Not how sure this fits into NANOG, this is more of a local ISP/Universiity setting. I don't know that an ISP can do that much, they're too busy keeping the packets flowing and being only minimally intrusive on your traffic without special arrangements, at least as a usual case. Special cases like Slammer, Blaster, and the initial Bagel/MyDoom mix some may have initiated ingress/egress filters for those, temporarily. You should be able to handle an OC-12 with a gig interface or two on the sensor. I wouldn't make any claims for an OC-48 or above. These things don't scale well into the certral peering points (MAE, Abilene, etc);. Jeff
RE: Gb ethernet interface keeping dropping packet in ingress
Now, we do try to monitor some things like that. We have several crons running checking the number of entries in the arp tables of our CPE devices at customer locations, as well as several crons dedicated to specific tell-tale signs of various worms and virii. One that helped out a lot recently was Nachi/Welchia search. Caught 40% of our subscribers that were infected, and helped stop all but 3 specific broadcast storms on our network. All the cron did was look for the specific ICMP packet that the virus put out, and flagged the connection in a list that is emailed to the NOC staff. Joe Johnson -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Kell Sent: Monday, September 13, 2004 10:46 PM To: Joe Shen; [EMAIL PROTECTED] Subject: Re: Gb ethernet interface keeping dropping packet in ingress If you're sniffing one gigabit port from a switch with much higher bandwidth, you're going to lose something. Our primary sensor sits on an aggregation switch just prior to hitting the net, and we have a 2Gb fast etherchannel span port defined and lose relatively little in terms of packet loss. If course, the more aggregate traffic you have, the higher the probability you will max out the span port and it's buffers. Unless you're just drilling the heck out of the server farm(s) on that switch, you won't lose all that much with an etherchannel of 2 Gig ports. We have 2Gb etherchannel uplinks back to the core, and the most the switch could throw at us would be 2Gb etherchannel traffic. So we are spanning the uplinks there. Just as your switches/routers can be over subscribed the the 4506 backplane is only 6Gb/slot, and we don't lose that much, and some of that loss is due to buffer constraints on the switch. Not perfect, but it works. In less critical ennvironments, we can sniff with a 100Mb interface and still do well. The only caution here is that you can seldom catch local traffic. If there's a local scanner (like Blaster started out to be) it doesn't show up except for excessive arps. We have some cron'ed scripts that periodically (1) look at connection counts in the PIX, if they're out of range), we quarantine them to the Perfigo dungeon. Similarly there is a script that counts ARP requests (just the dorms specifically right now) and for every 1000 it forks itself to start anew, and analyzes the numer of ARPS per station. Local scanners get eaten up here really quickly and they are also quarantined. Not how sure this fits into NANOG, this is more of a local ISP/Universiity setting. I don't know that an ISP can do that much, they're too busy keeping the packets flowing and being only minimally intrusive on your traffic without special arrangements, at least as a usual case. Special cases like Slammer, Blaster, and the initial Bagel/MyDoom mix some may have initiated ingress/egress filters for those, temporarily. You should be able to handle an OC-12 with a gig interface or two on the sensor. I wouldn't make any claims for an OC-48 or above. These things don't scale well into the certral peering points (MAE, Abilene, etc);. Jeff
Re: Gb ethernet interface keeping dropping packet in ingress
Joe Johnson wrote: Now, we do try to monitor some things like that. We have several crons running checking the number of entries in the arp tables of our CPE devices at customer locations, as well as several crons dedicated to specific tell-tale signs of various worms and virii. Our list of crons is growing too... One that helped out a lot recently was Nachi/Welchia search. Caught 40% of our subscribers that were infected, and helped stop all but 3 specific broadcast storms on our network. All the cron did was look for the specific ICMP packet that the virus put out, and flagged the connection in a list that is emailed to the NOC s We do the Nachi/Blaster 445 and ICMP pings with a route policy map on our core so as not to disturb the PIX with senseless traffic. We do at least catch the random Nachi probles (which are local), didn't work so sell with machines destined off the local subnet. We do extensive ingress/egress filtering at the border that catches most junk from getting in our out. We're in the process of intergrating this into our Perfigo system, but we've only had the Perfigo solution in place for a few months. It has helped by logically micro-managing each station on their own logical /30 subnet that makes them up, but virii/worms that don't care about gateways and so forth aren't really stopped if they catch a 0-day, very few viruses make meaningful IP address guessing (they'll nail thhe local ranges first, but some go off-campus). This is hopefully caught by a script under developent that uses ipaudit (sourceforge.net) and keeps the top 10 traffic sources inbound/outbound, and cumulative counts each 30 minutes for how many local/hosts appear to be scanning, and likewise for the reverse. We used to shut these ports down, but now we're having Perfigo lock them into a quarantine LAN where their situation is explained, and has hooks to our SUS and antivirus tools (AdAware, Spybot) with contact numbers for the helpdesk if they need assistannce. So far, so good, but could be better. Jeff
Sheesh, regulators
http://www.thehindubusinessline.com/2004/09/11/stories/2004091102660400.htm ISPs may be stopped from offering private leased line services Thomas K. Thomas New Delhi , Sept. 10 INTERNET Service Providers (ISPs) are in for a major setback with the Telecom Regulatory Authority of India (TRAI) proposing to restrict them from offering private leased line services. While the telecom regulator is considering to ask the state-owned Bharat Sanchar Nigam Ltd (BSNL) to resume provision of leased line resources to ISPs, the latter may be allowed to use it only for providing Internet-based services. This will come as a big blow to Internet operators who get a significant part of their revenue from corporate leased line services like virtual private network (VPN). The fight between BSNL and ISPs over the issue has been hanging fire for the last few months. The high point came when BSNL stopped offering leased line services to ISPs on grounds that they were misusing the infrastructure to offer services that were beyond the scope of their licence. BSNL had argued that ISPs, who do not pay any entry fee or licence fee, should not be allowed to offer corporate leased line service as it was infringing on the turf of long distance operators. Companies such as Sify, HCL Infinet and Tata Internet had made representation to the regulator against the stance taken by BSNL. The telecom regulator has taken a position favouring BSNL by saying that the public sector company was justified in its demand, as ISPs were not eligible to provide services such as VPN. This service is used by large corporates to network all their branch offices spread across the country. However, a TRAI report on the issue said that BSNL was fair in demanding that ISPs can use the leased lines only for Internet purpose and not resell it, because they were not entitled to do the business of reselling bandwidth leased from other telecom service providers. The telecom regulator has also sought the views of the Department of Telecom (DoT) on the issue and would give its final directive in the next few weeks. DoT officials said that the department was looking at allowing ISPs to offer VPN services but only after paying an entry fee to level the playing field with long distance players.
