- Test - lists.nanog.org

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

30 Gmail Invites
by Todd Mitchell - lists 13 Sep '04

13 Sep '04

16 16

RE: European Nanog?
by Michel Renfer 13 Sep '04

13 Sep '04

Hi Nicolas > 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. http://www.swinog.ch cheers, michel

2 1

Problem
by Abhishek Verma 13 Sep '04

13 Sep '04

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

1 0

Re: 30 Gmail Invites
by Robert Bonomi 12 Sep '04

12 Sep '04

> From owner-nanog(a)merit.edu Sat Sep 11 21:58:47 2004 > From: "Steven M. Bellovin" <smb(a)research.att.com> > To: Paul Vixie <vixie(a)vix.com> > Cc: nanog(a)merit.edu > Subject: Re: 30 Gmail Invites > Date: Sat, 11 Sep 2004 22:54:16 -0400 > > > In message <g38ybgi5nd.fsf(a)sa.vix.com>, Paul Vixie writes: > > > >i still can't understand why anyone would want a gmail account, free or not. > > > >not just "anyone on nanog". anyone, anywhere, ever. the reasons "why not" > >are compelling enough. but there are no counterbalancing reasons "why to", > >either compelling or otherwise. > > I agree. The privacy implications are *really* scary. (And they're > sufficiently worse for non-subscribers that I've contemplated blocking > gmail-bound messages from my (personal) systems.) > > --Steve Bellovin, http://www.research.att.com/~smb > > > From owner-nanog(a)merit.edu Sat Sep 11 21:58:47 2004 > From: "Steven M. Bellovin" <smb(a)research.att.com> > To: Paul Vixie <vixie(a)vix.com> > Cc: nanog(a)merit.edu > Subject: Re: 30 Gmail Invites > Date: Sat, 11 Sep 2004 22:54:16 -0400 > > > In message <g38ybgi5nd.fsf(a)sa.vix.com>, Paul Vixie writes: > > > >i still can't understand why anyone would want a gmail account, free or not. > > > >not just "anyone on nanog". anyone, anywhere, ever. the reasons "why not" > >are compelling enough. but there are no counterbalancing reasons "why to", > >either compelling or otherwise. > > I agree. The privacy implications are *really* scary. (And they're > sufficiently worse for non-subscribers that I've contemplated blocking > gmail-bound messages from my (personal) systems.) While we're on _that_ subject, what about Postini, or Brightmail, or -any- other big provider (e.g. SBC/Yahoo) that handles mail for multiple 'client' domains? Every one of those folks also reads and analyzes everybody's incoming mail, including correlating it with mail sent to other destination on their systems. AND correlating source (IP address and/or email address) with content.

4 3