September 2004 - Test - lists.nanog.org

Re: *blocking access to rebel web sites
by J. Oquendo 15 Sep '04

15 Sep '04

>> Russian Internet providers block access to Chechen rebel web site Please excuse my off-topic response. Earlier this year I was researching terror related websites and snagged the top 25 (according to Alexa, and articles mentioning these sites) "Jihad(iot)" related "terror" sites and found that of the 25 sites, 22 were running in my own backyard, America. Rather than make this already off topic post longer here is the link to the article for anyone who would like to read it. Basically, whois, nslookup information for the top sites. I didn't bother posting the other 3 since they had little relevance to someone else's "War on Terror" http://www.politrix.org/modules.php?name=News&file=article&sid=1141 As for Kavkaz... Same *foo* different day. ISP's can block all they'd like to, but it does little since my government tells me the terrorists now use crypto, proxies, and weapons of mass destruction. So most of these cmopilliterates are now hijacking mars rovers to read my GMail and plot, just what I needed. whois kavkaz.org Domain Name: KAVKAZ.ORG Registrar: NETWORK SOLUTIONS, INC. Whois Server: whois.networksolutions.com Referral URL: Name Server: ATRIVO.BASSINTER.COM Name Server: ATRIVO2.BASSINTER.COM Updated Date: 23-feb-2002 Registrant: Udug, Movladi (KAVKAZ14-DOM) 10 Bird Lane Orlando, FL 32860 US Domain Name: KAVKAZ.ORG Administrative Contact, Technical Contact: Udug, Movladi (ZWWPQJQEGI) salatag(a)hotmail.com Udug,Movladi 10 Bird Lane Orlando, FL 32860 US +1-9745572730 123 123 1234 # whois -a 66.28.38.232 OrgName: Cogent Communications OrgID: COGC NetRange: 66.28.0.0 - 66.28.255.255 CIDR: 66.28.0.0/16 NetName: COGENT-NB-0000 TechHandle: ZC108-ARIN TechName: Cogent Communications TechPhone: +1-877-875-4311 TechEmail: noc(a)cogentco.com =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo GPG Key ID 0x51F9D78D Fingerprint 2A48 BA18 1851 4C99 CA22 0619 DB63 F2F7 51F9 D78D http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x51F9D78D sil @ politrix . org http://www.politrix.org sil @ infiltrated . net http://www.infiltrated.net "How can we account for our present situation unless we believe that men high in this government are concerting to deliver us to disaster?" Joseph McCarthy "America's Retreat from Victory"

1 0

Russian ISPs block access to Chechen rebel web site
by Sean Donelan 15 Sep '04

15 Sep '04

BBC Mon FS1 FsuPol kt/mjm/skh Source: Ekho Moskvy radio, Moscow, in Russian 0800 gmt 14 Sep 04 Russian Internet providers block access to Chechen rebel web site It seems that Moscow has managed to close down a Chechen separatist web site. Since this morning access to the Kavkaz-Tsentr web site and the Chechenpress page has been blocked. Yesterday the Russian Foreign Ministry demanded that Lithuania stop Kavkaz-Tsentr operating. The fact is that the separatists' server is located in the private flat of a Lithuanian MP. The Lithuanian ambassador to Russia was summoned to the Foreign Ministry yesterday. Meanwhile, Lithuanian official structures have not yet asked the service provider for Kavkaz-Tsentr to shut down the site. Ekho Moskvy was informed of this by the head of the Elneta company [Internet service provider], Rimantas Pasys. Pasys noted that at present the Kavkaz-Tsentr web site is working. It seems that access to the site is being prevented by service providers based in Russia.

1 0

RE: Email Complexes
by Hosman, Ross 15 Sep '04

15 Sep '04

I've gotten a few emails asking why we are doing this. We are doing this in order to provider better service to our Customers. Charter need's pop3 access at the following companies so that we can monitor track and monitor SMTP performance between our network and yours. AOL Yahoo Gmail MSN/Hotmail Cox Comcast Adelphia Earthlink Verizon -----Original Message----- From: owner-nanog(a)merit.edu Sent: Tuesday, September 14, 2004 9:24 AM To: 'bmanning(a)vacation.karoshi.com' Cc: 'nanog(a)merit.edu' Subject: RE: Email Complexes Let me calrify, I work as a HSD Administrator for Charter Communications in their mail, news, web group. We want these accounts so that we can ensure email is going to the other complexes without a hitch. We would also monitor how long it would take email to go from our complex to the respective company's complex. -----Original Message----- From: bmanning(a)vacation.karoshi.com [mailto:bmanning@vacation.karoshi.com] Sent: Tuesday, September 14, 2004 9:18 AM To: Hosman, Ross Cc: 'nanog(a)merit.edu' Subject: Re: Email Complexes On Tue, Sep 14, 2004 at 09:08:21AM -0500, Hosman, Ross wrote: > > I was wondering if anyone knew people at the following companies: > > AOL > Yahoo > Gmail > MSN/Hotmail > Cox > Comcast > Adelphia > Earthlink > Verizon i think most everyone knows someone at one or more of these companies. > > We would like accounts setup at these companies to monitor outgoing email to > these complexes. If you know/are someone at one of these companies could you > please contact me off list. accounts from each of these companies is easy to get. one does not need special privledges here, just the money to pay for the regular account fees. > > Ross Hosman > HSD Administrator > ross.hosman(a)chartercom.com > 314-543-5823

3 2

Methodology for BGP policy development
by Pete Kruckenberg 15 Sep '04

15 Sep '04

I'm looking for some good material on the methodology (best practices) of moderately-complex BGP policy development. I've found no shortage of the tools (prefix lists, community list filters, route maps, etc) for *implementation* of BGP policy. Including plenty of router configuration examples. I'm looking for help with the steps before the router configuration. What is a good methodology to go from a set of (~30-50) narrative descriptions ("Propagate prefixes received from Customer Type X only to Peers Type Y") into a optimal, comprehensive set of community definitions, prefix/community/ASpath filters, route maps, peer templates, policy statements, etc? What methodology works for you? Are there presentations/papers/books/discussion threads that cover this aspect of routing policy development that you would recommend? Thanks for your help. Pete.

1 0

RE: Email Complexes
by Hosman, Ross 15 Sep '04

15 Sep '04

Let me see if I can explain your entire email. Ensuring that email flows freely between our mail complex and other top mail provider complexes is a support issue correct. Actually setting up the system to monitor and to ensure the support people get the data they need is operations/engineering. We like automating a lot of our procedures as our mail complex isn't staffed 24/7. Right now we have a script that monitors incoming mail sent from probes across the us. It monitors how long it takes the email to first hit the IronPort's, then how long it takes to hit the Brightmail, then how long it takes to hit the MTA's. Our script uses pop3 to grab the email and parse the headers we send from the probes (or in this case from the complex to the pop accounts). Yes I do realize some are webmail (AOL, MSN, Gmail), but even a lot of the webmail providers do have pop3 servers. Our intent here is not not only verify that the email got there but that it got there in a reasonable time (lets face it email is becoming a more imporant part of life/business today). As fair as teaching the support guys to go look at the mail queue, would you honestly want them to be doing that? We have over 65 mail machines and should I trust them with checking them every 10 min? Since we are not staffed 24/7 what happeneds if we have all gone home? The way we have it setup if the mail never reaches the complex tier-1 gets a page, 15 minutes later if the problem still isn't solved tier-2 gets a page. I believe automating the system rather then trutsing a staff member to check it and to pray that it dosen't break during the night is a much better way of doing it. -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Mark Foster Sent: Tuesday, September 14, 2004 4:04 PM To: Hannigan, Martin Cc: nanog(a)merit.edu Subject: RE: Email Complexes I find it interesting that you'd like pop3 access to a bunch of listed *webmail* providers. Who provide access via the web - NOT pop3. I also agree with the below statement - your mail queues themselves will provide far more accurate information. The issue of 'successful mail delivery' would be a support issue, not an operations issue, as long as you as an operations staffer can verify that your mailserver is not holding the mail for undue periods. (Mail doesnt have a delivery SLA in general, after all.) And if your support staff need offsite mail accounts to verify delivery delay times, they should be able to purchase them or otherwise obtain them, and keep a database of mail account access details that they can use *on demand*. This would of course entail them becoming customers and footing the regular monthly bill, or whatever. In every ISP i've ever worked for, all we've needed to do is verify that we're delivering the mail to the advertised MX in a timely fashion, and our responsibility ends at that point. Outside of the usual responsibilities of a good ISP - like providing responsive abuse/security staff, like providing a valid abuse@ contact :-) This would be one of the primary reasons your mail doesn't get accepted, and prevention is better than cure... So in all honesty - if your company wants to extend its monitoring-ability outside of its own network to those of other providers, it should do so in the 'usual fashion' - sign up. How is this something that yourself as an operations employee got involved in anyway, as it strikes me as a support issue? - Mark. On Tue, 14 Sep 2004, Hannigan, Martin wrote: > > > > Ross, > > There are a lot of knowledgeable people on this list [tier 3]. > > Why can't you already tell if you aren't getting through to > major providers? Wouldn't your queues backup, or are you being > blocked and the messages are being rejected and you are trying > to track that? > > -M< > > > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > Hosman, Ross > Sent: Tuesday, September 14, 2004 2:41 PM > To: 'paul(a)adelphiacom.net'; Roy > Cc: nanog(a)merit.edu > Subject: RE: Email Complexes > > > > Your right this isn't my department and it's not my place to tell them how > to do their job. If Roy would like to send me a valid abuse complaint I'll > make sure to forward it on or even walk it over to the abuse department > supervisor. > > I would also like to say I'm suprised at how many people have been attacking > me on/off the list for asking a simple question. I'm just trying to ensure > people are able to recieve/send mail from/to charter's mail complex. I > didn't think asking for some help would be a big deal (as I thought there > might be some people on the list from the companies that were knowledgeable > instead of having to deal with typical tier-1 support). > > -----Original Message----- > From: Paul Bradford [mailto:paul@adelphiacom.net] > Sent: Tuesday, September 14, 2004 1:31 PM > To: Roy > Cc: Hosman, Ross; nanog(a)merit.edu > Subject: RE: Email Complexes > > > Come on... what is this.... Ross doesn't have the ability to put more > "clueful" people in abuse, he's prolly an engineer like you and me.... > we just want to fix the network.... why take this e-mail as a chance to > bash Charter? > > Ease up, > Paul > > On Tue, 2004-09-14 at 14:01, Roy wrote: > > I suggest you concentrate some resources in your abuse department. One > > charter IP address hit my firewall 1617 times so far today. Repeated > > complaints to abuse(a)charter.net just get ignored. > > > > According to the local newspaper, my fellow citizens consider Charter the > > worst company in town. > > > > Roy >

3 2

RE: Email Complexes
by Hannigan, Martin 15 Sep '04

15 Sep '04

Ross, There are a lot of knowledgeable people on this list [tier 3]. Why can't you already tell if you aren't getting through to major providers? Wouldn't your queues backup, or are you being blocked and the messages are being rejected and you are trying to track that? -M< -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Hosman, Ross Sent: Tuesday, September 14, 2004 2:41 PM To: 'paul(a)adelphiacom.net'; Roy Cc: nanog(a)merit.edu Subject: RE: Email Complexes Your right this isn't my department and it's not my place to tell them how to do their job. If Roy would like to send me a valid abuse complaint I'll make sure to forward it on or even walk it over to the abuse department supervisor. I would also like to say I'm suprised at how many people have been attacking me on/off the list for asking a simple question. I'm just trying to ensure people are able to recieve/send mail from/to charter's mail complex. I didn't think asking for some help would be a big deal (as I thought there might be some people on the list from the companies that were knowledgeable instead of having to deal with typical tier-1 support). -----Original Message----- From: Paul Bradford [mailto:paul@adelphiacom.net] Sent: Tuesday, September 14, 2004 1:31 PM To: Roy Cc: Hosman, Ross; nanog(a)merit.edu Subject: RE: Email Complexes Come on... what is this.... Ross doesn't have the ability to put more "clueful" people in abuse, he's prolly an engineer like you and me.... we just want to fix the network.... why take this e-mail as a chance to bash Charter? Ease up, Paul On Tue, 2004-09-14 at 14:01, Roy wrote: > I suggest you concentrate some resources in your abuse department. One > charter IP address hit my firewall 1617 times so far today. Repeated > complaints to abuse(a)charter.net just get ignored. > > According to the local newspaper, my fellow citizens consider Charter the > worst company in town. > > Roy

4 3

Anyone use Riverbed Steelhead?
by Kristin Gorman 14 Sep '04

14 Sep '04

Hello, I was wondering if anyone has worked with the Riverbed Steelhead appliance. So far, we have seen amazing results in our lab (~5-10 Mbps throughput over a 768K link), but It would be nice to hear some real world experiences. I'm also wondering if there is flaky behavior once it's deployed. Thanks, Kristin

1 0

Re: Network Configuration Management Practices
by Robert Bonomi 14 Sep '04

14 Sep '04

> Date: Tue, 14 Sep 2004 12:08:34 -1000 (HST) > Cc: nanog(a)merit.edu > Subject: Re: Network Configuration Management Practices > > On Tue, 14 Sep 2004, Carl W.Kalbfleisch wrote: > > : I am doing some independent research on Network Configuration > : Management Practices. I am trying to get information from service > : providers and enterprises on how they handle this function. I have the > : following specific questions: > : > : 1) What configuration issues most affect the performance and > : reliability of your network? > > Fingers... >;-) "Fat" ones, to be more specific. <wry grin>

1 0

RE: Email Complexes
by David A. Ulevitch 14 Sep '04

14 Sep '04

<quote who="Hosman, Ross"> > We like automating a lot of our procedures as our mail complex isn't > staffed > 24/7. That's not surprising. > Right now we have a script that monitors incoming mail sent from > probes across the us. It monitors how long it takes the email to first hit > the IronPort's, then how long it takes to hit the Brightmail, then how > long > it takes to hit the MTA's. Reverse the wires, the rest of the internet would appreciate it. You missed the point of my previous email. Thousands of hours are wasted by engineers dealing with abuse that is not insignificantly caused by Charter. And now "Charter" (not you, but Charter) is asking for some free accounts so they can enhance their "mail complex." You *are* Charter and netops *is* a two-way street, please act accordingly. Don't just say it isn't your department because guess what, it's all of our departments. -david ---------------------------------------------------- David A. Ulevitch - Founder, EveryDNS.Net http://david.ulevitch.com -- http://everydns.net ----------------------------------------------------

1 0

[Fwd: RE: Email Complexes]
by Mark Foster 14 Sep '04

14 Sep '04

[My first response was direct to Ross. This has been paraphrased slightly to make it useful (hopefully) to NANOG...] -------- Original Message -------- Subject: RE: Email Complexes Date: Wed, September 15, 2004 9:53 am Hi Ross :) Please don't get me wrong, I applaud your efforts, because you're right - email is huge, and most customers don't have a reasonable expectation of the service to be expected in terms of mail delivery between providers. ("What do you mean its not there yet! I sent it 10 minutes ago!") My point is that by posting on NANOG saying 'give me an account please' for the purpose of keeping *your* customers happy strikes me as, well, interesting. You have the resources to monitor your own mail systems by watching your outbound mail queue. Every daemon I know of has ways of monitoring the outbound queue, and verifying that you're definately offloading mail to advertised MX's. I noticed an example for Sendmail was quoted on the list a short while ago. This is stuff you can influence - its your systems. Thats where i'd expect you to concentrate your efforts. By extension of this, it's not unreasonable for this information to perhaps be scripted and monitored via a web interface - nagios? - and made available to your upper echilon support staff. Hell at one of the ISPs I worked for - as a Tier 1 and 2 support tech - I had shell access to one of the unix boxes and a commandline script which would tell me how much mail was in the queue. If this remained low, I could verify there wasnt a problem. If it spiked, then I escalated a query to the NOC to find out what the story was. At the ISP I work for currently we dont even have that sort of information. If mail gets delayed we troubleshoot *without* that information. We're an ISP with 500,000 customers and have a team of ~15 technical specialists whos expertise closes on that of a junior NOC engineer. They successfully deal with all manner of technical queries and they can call the NOC directly to find out if theres anything odd going on server-side. They also clearly explain to any Tier 1's (and any customers) they speak to that email is not a guarunteed service, and is delayed from time to time, and theres nothing we can do except make sure that *our systems* are working as well as possible. Who's to say that your monitoring wont be thrown off by problems at $third_party ? Parsing headers is a good way to identify total delivery times, but anything beyond your own MX's is outside of your control anyway, so outside of casual interest I see little value in actually knowing exactly whats broken at AOL and Gmail, etc. (Isnt this AOL and Gmails problem, not yours?) Get queue monitoring. Script it to make the details available via the Web to your senior tech support staff. And remind your support guys that email is not guarunteed, and you'll do your level best to keep things running smoothly, but that once the mail leaves the network its outside of your control. So once you've verified that it has infact left your network, your job is done. Mark. (Disclaimer: Comments are mine and mine alone, and do not represent my employer or any previous employer for that matter.) > Let me see if I can explain your entire email. > > Ensuring that email flows freely between our mail complex and other top > mail provider complexes is a support issue correct. Actually setting up > the system to monitor and to ensure the support people get the data > they need is operations/engineering. > > We like automating a lot of our procedures as our mail complex isn't > staffed 24/7. Right now we have a script that monitors incoming mail > sent from probes across the us. It monitors how long it takes the email > to first hit the IronPort's, then how long it takes to hit the > Brightmail, then how long it takes to hit the MTA's. Our script uses > pop3 to grab the email and parse the headers we send from the probes > (or in this case from the complex to the pop accounts). Yes I do > realize some are webmail (AOL, MSN, Gmail), but even a lot of the > webmail providers do have pop3 servers. > > Our intent here is not not only verify that the email got there but > that it got there in a reasonable time (lets face it email is becoming > a more imporant part of life/business today). > > As fair as teaching the support guys to go look at the mail queue, > would you honestly want them to be doing that? We have over 65 mail > machines and should I trust them with checking them every 10 min? Since > we are not staffed 24/7 what happeneds if we have all gone home? The > way we have it setup if the mail never reaches the complex tier-1 gets > a page, 15 minutes later if the problem still isn't solved tier-2 gets > a page. I believe automating the system rather then trutsing a staff > member to check it and to pray that it dosen't break during the night > is a much better way of doing it. > *snip*

1 0