- NANOG - lists.nanog.org

RE: Email Complexes
by JDeane＠sungardfutures.com 14 Sep '04

14 Sep '04

With all due respect, call these organizations as a customer and request an account. With that being said, might I suggest a far better method: http://www.ietf.org/html.charters/msgtrk-charter.html Regards, Jade -----Original Message----- From: Hosman, Ross [mailto:Ross.Hosman@chartercom.com] Sent: Tuesday, September 14, 2004 9:51 AM To: Hosman, Ross; 'bmanning(a)vacation.karoshi.com' Cc: 'nanog(a)merit.edu' Subject: RE: Email Complexes 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

Upcoming NANOG & ARIN Meetings
by Charlie Khanna - NextWeb 14 Sep '04

14 Sep '04

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

6 6

Email Complexes
by Hosman, Ross 14 Sep '04

14 Sep '04

I was wondering if anyone knew people at the following companies: AOL Yahoo Gmail MSN/Hotmail Cox Comcast Adelphia Earthlink Verizon 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. Ross Hosman HSD Administrator ross.hosman(a)chartercom.com 314-543-5823

3 2

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

14 Sep '04

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

1 0

EVENT - Building a network and system management open source tool - talk at BayLISA, Cupertino, California, USA, Thursday 16 Sept. 2004 19:30-21:00
by Philippe Ombredanne 14 Sep '04

14 Sep '04

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 R&D 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

2 1

Gb ethernet interface keeping dropping packet in ingress
by Joe Shen 14 Sep '04

14 Sep '04

Hi, I'm using Harbour 10G lay3 switch which interconnects a Catalyst6509 and a Foundry switch. the interconnecting lines are all 1Gbps ethernet (1000Gb LX). Catalyst6509----Harbour 10G switch----Foundry Switch---Firewall the firewall and harbour interconnect at layer 3. We noticed there is something abnormal on link between 10G switch and Foundry switch: 1. The load on that 1Gbps link may decrease sharply from 110Mbps to 20Mbps and come back, the frequency and occuring time is random. 2. we monitoring connection to Firewall interface by 'ping' with twenty 50byte packets every 20 seconds, and there is packet loss and end-to-end latency increase around the time when link load decreases sharply. 3. on Harbour switch, the interface counter always shows there is "Dropped Packets on Ingress" on interface connecting foundry and cisco, and the number increase continuously. I've disable auto-negotiation and flow-control on between 10G switch and Foundry switch, firewall interface. What's maybe the possible reason for problem above? thanks in advance. Joe __________________________________________________ Do You Yahoo!? Download the latest ringtones, games, and more! http://sg.mobile.yahoo.com

2 2

RE: Gb ethernet interface keeping dropping packet in ingress
by Joe Johnson 14 Sep '04

14 Sep '04

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: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of > Jeff Kell > Sent: Monday, September 13, 2004 10:46 PM > To: Joe Shen; nanog(a)merit.edu > 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

2 1

Provider/NAP filtering policies
by JDeane＠sungardfutures.com 13 Sep '04

13 Sep '04

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. jdeane(a)sungardfutures.com +1 (312) 577-6100 ext. 6961 +1 (866) 741-0076 (Fax)

3 2

RE: Provider/NAP filtering policies
by JDeane＠sungardfutures.com 13 Sep '04

13 Sep '04

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:woody@pch.net] Sent: Monday, September 13, 2004 12:42 PM To: Deane, Jade Cc: nanog(a)merit.edu Subject: Re: Provider/NAP filtering policies On Mon, 13 Sep 2004 JDeane(a)sungardfutures.com 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

1 0

Sender-ID denied by IETF?
by Jeff Wheeler 13 Sep '04

13 Sep '04

Top story on Slashdot: http://it.slashdot.org/it/04/09/13/1317238.shtml?tid=172&tid=95&tid=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

2 1