- NANOG - lists.nanog.org

Re: A useful oversimplification for network surveillance?
by Fergie (Paul Ferguson) 25 Aug '05

25 Aug '05

Also, this seems like a good time to mention a couple of additionl resources on trending specific TCP and UDP port probes (if you haven't already seen them): http://www.dshield.org/ http://www.mynetwatchman.com/ - ferg -- sjk <sjk(a)cupacoffee.net> wrote: We are an ISP - we look for specific trending data to help pinpoint new potential virus and malware which can adversley effect transit links or equiptment. -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0

Re: A useful oversimplification for network surveillance?
by Florian Weimer 25 Aug '05

25 Aug '05

> We are an ISP - we look for specific trending data to help pinpoint new > potential virus and malware which can adversley effect transit links or > equiptment. Plain IDS data, or netflow data? (I don't doubt the usefulness of flow data.)

1 0

Re: A useful oversimplification for network surveillance?
by Fergie (Paul Ferguson) 25 Aug '05

25 Aug '05

Actually, re-reading your original message, netflow would certainly be helpful in analysis, trending, etc. (along with something along the lines of MRTG) -- and IDS is only helpful after the fact, per se. - ferg -- "Howard C. Berkowitz" <hcb(a)gettcomm.com> wrote: At 3:30 PM +0000 8/25/05, Fergie (Paul Ferguson) wrote: >Howard, > >I'd most certainly use an IDS (i.e. SNORT) for this instead of >netflow.... My concern is scalability, remembering I'm talking about the surveillance level. My preliminary sense is that SNORT is great in a sinkhole, but isn't as scalable as a reasonable NetFlow export. > >-- "Howard C. Berkowitz" <hcb(a)gettcomm.com> wrote: > > NetFlow is the key to analyzing traffic patterns outside the router, > looking for DDoS signatures when known, and for traffic anomalies that > may become DDoS.

2 1

Re: A useful oversimplification for network surveillance?
by Fergie (Paul Ferguson) 25 Aug '05

25 Aug '05

Howard, I'd most certainly use an IDS (i.e. SNORT) for this instead of netfow.... - ferg -- "Howard C. Berkowitz" <hcb(a)gettcomm.com> wrote: NetFlow is the key to analyzing traffic patterns outside the router, looking for DDoS signatures when known, and for traffic anomalies that may become DDoS. -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/

4 5

RE: 4-Byte AS Number soon to come?
by Susan Hares 25 Aug '05

25 Aug '05

Dan: (chair-hat-off) I believe we need to move quickly. 3 years for a major new feature to be fully deployed is tight. But I don't want to deploy something that causes operators problems. If we change, we need to get the changed defined and initial implementation out quickly. (chair-hat-back-on) I believe the WG can move quickly. Sue -----Original Message----- From: Daniel Golding [mailto:dgolding@burtongroup.com] Sent: Wednesday, August 24, 2005 9:16 AM To: Iljitsch van Beijnum; Susan Hares Cc: Yakov Rekhter; NANOG list Subject: Re: 4-Byte AS Number soon to come? Susan, In light of Geoff Huston's recent article which urged alacrity in finalizing a standard and implementing the eventual solution, where are we in this process? Geoff's article suggest that we have about three years until Internet transit AS's should begin transitioning. Given the QA cycle at both router vendors and major carriers, this means that the timeframe is quite condensed, at least by IETF standards. My question, in short, is, will we make it? (the corollary is, does the IETF/IDR have a sense of urgency as they move this process along?) Thanks, Dan On 8/24/05 2:57 AM, "Iljitsch van Beijnum" <iljitsch(a)muada.com> wrote: > > On 24-aug-2005, at 5:50, Susan Hares wrote: > >> This is the first of many steps. And to be fair to the authors, the >> process got held up due to the base draft being re-written. > >> So, the key discussion points are (as Yakov has indicated as well): >> a) Are there any technical problems with the specification >> b) Does the specification cause operational problems? >> c) General concerns about the design of the additions to BGP >> (scaling, etc). > > I find the design less robust than it could be. > > What it does is define that toward a neighbor that also supports wide > AS numbers it will send the AS path with 32-bit AS numbers, and > toward a neighbor that doesn't support wide AS numbers it sends the > AS path with 16-bit AS numbers and a "new AS path" with 32-bit AS > numbers. > > I think it makes more sense to ALWAYS send the old 16-bit AS path and > the new 32-bit AS path attribute. This makes the code path identical > for the two types of peers, which is less likely to lead to new bugs > and makes for easier (operational) debugging. > >> Implementation reports give us the opinion of those who have already >> implemented the protocol. That's usually worth hearing about. > > As an operator, I'm sorry to say I don't always have the highest > possible opinion of the people implementing the protocols. (I always > say: never ask the people who built the thing what it can do.) > Obviously implementing a specification is a crucial step, and an > illuminating one because it brings out bugs and hidden assumptions in > the specification. It can also uncover a broken design, but I hope > and believe this is relatively rare. (And it's not like a broken > design is automatically unimplementable, so implementation is > certainly not guaranteed to bring out design problems.) So yes, it's > worth hearing about, but not worth delaying publication for. And > since the IETF only has one way to publish documents for periods > extending six months... -- Daniel Golding Network and Telecommunications Strategies Burton Group

1 0

Iperf or Iperf like test points?
by Walter C. Ames 25 Aug '05

25 Aug '05

Initial caveat: If this is off topic please just let me know now and please suggest a good forum for this type of question/discussion. The main premise of the question/discussion is the ability to establish/utilize random (or not so) test points (like looking glasses) scattered across the planet to gauge real time bandwidth performance on larger broadband connections. Second caveat: I have done a bit a research trying to figure this out before posting and have had no luck to this point. If this topic has already been covered in depth or otherwise please advise. With that said, the problem that I am facing is that there are no consistently reliable tools that NetOps (or end users for that matter) can use to truly evaluate bandwidth performance on large pipes. Ex: All of the test sites that I have tried from a 100M/FD attached Linux box, riding a GigE backbone to multiple GigE transit lines typically yields BW test results in the 3-7Mbps range. Yet when I Iperf across the backbone I get more reasonable results of between 80-90Mbps TCP. The extent of the problem is that I hand off 10M - GigE connections to my end users and they want a way to test it that is 'Off-Net'. My on-net test platforms give them great results, however since they are on-net the end users dismiss the results (thinking they are fixed I guess). To date I have not found a reasonable method of accomplishing this. Now with the understanding that bandwidth testing at these rates (or any rate for that matter) can prove to be a complete waste of bandwidth simply to give someone a warm and fuzzy, I am willing to let that one go on a case by case basis to simply make the end user happy. That being said, is anyone on this list aware of such a formation of Iperf nodes across the net connected at GigE or better to accomplish this goal? If not I would be willing to start one and give up a server or two and some of my bandwidth to help others out who are probably experiencing (or have experienced) this type of problem in the past. This issue is just burning up a lot of my tech supports time trying to educate the end users. I just feel that a cooperative effort that yields more accurate and consistent results may be a better way to approach this. Thank you in advance. ____ o Walter C. Ames o MDConnect Internet Services o (410)290-8088 (phone) MD o (410)290-8180 (fax)

4 3

Re: ISP's In Uproar Over Verizon-MCI Merger
by Robert Bonomi 25 Aug '05

25 Aug '05

> From owner-nanog(a)merit.edu Wed Aug 24 23:28:58 2005 > Date: Wed, 24 Aug 2005 21:27:15 -0700 (PDT) > From: Joel Jaeggli <joelja(a)darkwing.uoregon.edu> > To: Daniel Golding <dgolding(a)burtongroup.com> > Cc: Joe Abley <jabley(a)isc.org>, Lewis Butler <lbutler(a)covisp.net>, > NANOG list <nanog(a)merit.edu> > Subject: Re: ISP's In Uproar Over Verizon-MCI Merger > > > On Wed, 24 Aug 2005, Daniel Golding wrote: > > > > > I suggest you take another look at these numbers. Those countries with > > overall population densities lower than the US's all have something in > > common - they are really cold. Iceland, Canada, Finland, Norway, Sweden. > > Folks in those countries are densely packed into relatively small regions of > > their overall land area (near oceans or in cities). Sure, some folks live > > out in Nunavut, but a relatively small number. Contrast that with the US > > where the population is far more spread out. > > > > This is an issue of both distribution and density, not just density. > > > So you're saying the US is screwed because of unique geography? Or is that > something poltical will can overcome? political will cannot overcome the situation where it is further from the _property-line_ to the house than the reach of DSL or cable -- never mind the distance from the telco C.O., or the cable head-end. Delivering service in low-population density areas is _expensive_, no matter how you do it, when measured on a 'per user' basis. 'Wireless' is the most efficient way to serve low-density areas, but the cost-per-user is still orders of magnitude higher than wired service in a high-population-density locale. If you want to do 'meaningful' geographic comparasions, one needs to break down each geopolitical entity into sub-areas, by population density. and look at relative coverage within the areas of 'comparable' population density.

1 0

Re: 4-Byte AS Number soon to come?
by Brandon Butterworth 25 Aug '05

25 Aug '05

> The time it would take it to be deployed depends (among other > factors) on whether the IDR WG would reach a (rough) consensus on > moving forward with the existing spec, even if one may argue that > there could be a better alternative to the existing spec. I don't think we're that short of time that any problems with the spec should be put aside, we'll have to work with the results for some time. brandon

2 1

Re: Announcement Propagation Delay in BGP
by Scott Weeks 25 Aug '05

25 Aug '05

----- Original Message Follows ----- From: "Scott Weeks" <surfer(a)mauigateway.com> To: nanog(a)merit.edu Subject: Announcement Propagation Delay in BGP Date: Fri, 19 Aug 2005 10:22:15 -1000 > I am going to be announcing two new prefixs into BGP soon > and the netgeek in me is very curious as to the length of > time it takes to show up in other parts of the world > that're logically far from Hawaii. Instead of going to > www.traceroute.org and refreshing repeatedly, I thought > folks here might've created a tool to do just that. Or, > perhaps, someone else has stats on a test they ran in the > past. > > Anyone got any tools or suggestions on how to measure this > just for fun and not as a scientific study? I plan to > read the beacon paper Took about 100 seconds. Not a scientific measurement. scott

1 0

Cingular Wireless contact?
by Steve Gibbard 24 Aug '05

24 Aug '05

This is a mailing list for the wrong sort of network for this question, but... If anybody knows who to talk to at the former ATT Wireless part of Cingular about a cell site that's been rejecting calls for the last six weeks, can you please contact me off list? Cingular's "Technical Assistance" says they have no idea who to talk to about network problems. Thanks, Steve

4 3