August 2002 - Test - lists.nanog.org

RE: AT&T NYC
by Daniel Golding 29 Aug '02

29 Aug '02

I wish this was a joke, but I know it's not. Ralph, they are talking about running BGP as an IGP, not if they are going to run BGP at all. Most large carriers run BGP everywhere. They also run an IGP for next-hop reachability within their networks (loopbacks, interface /30s, etc). The issue was whether you can get away with not running the IGP, and just running BGP. The problem is, of course, BGP handles many routes well, and converges relatively slowly. IGPs converge quickly, but only handle a relatively small number of routes. If you are offering transit to folks, you need to run BGP pretty much everywhere. If you are peering, or have multiple transits in multiple locations, with a network between them, BGP makes a lot of sense. If not, just run BGP on your edge routers. As far as an IGP - you need one. You don't need route reflectors for 5 routers. You probably do need something at double that number. Use two route reflectors, so if one goes down, you're ok. Redundancy is wonderful. Or use confederation BGP, which doesn't usually have single points of failure, but many be a bit too complex for some networks. Finally, if cutting and pasting a configuration is making you a "sad clown", learn Expect or Perl, and write a script. That way, more routers can be broken in a shorter period of time, leading to greater efficiency. We now return to our regularly scheduled, low level of signal to noise. - Daniel Golding > Ralph Doncaster Said.... > > On Thu, 29 Aug 2002, Peter van Dijk wrote: > > > On Thu, Aug 29, 2002 at 01:09:54PM -0400, alex(a)yuriev.com wrote: > > > > Has anybody mentioned the benefits of ISIS as an IGP to them. > > > Link-state protocols are evil, and when they break, they > *really* break. > > > I still do not see a compeling argument for not using BGP as your IGP. > > > > Slow convergence. > > As well there is the issues of running a full iBGP mesh. I've actually > been doing it, and now that I'm about to add my 5th router, OSPF is > looking a lot better than configuring 4 more BGP sessions. I've heard > some people recommend a route-reflector, but that would mean if the > route-reflector goes down you're screwed. > > -Ralph > >

1 0

RE: Broadening the IPv6 discussion
by Dave Israel 29 Aug '02

29 Aug '02

Mmmm... me too post. I have to agree with Dan on this. The only people who ask me about IPv6 are people who have heard something about it from some tech magazine and want the Newest Thing. Much of its useful functionality (except the widened address space) is available in v4, and v4 is deployed. There is no commercial demand for a v6 backbone. That's the big roadblock right now. -Dave On 8/29/2002 at 11:05:49 -0400, Daniel Golding said: > Hmm. I'm afraid that I have to disagree with just about everything you've > said :) . I haven't seen any enterprise folks demanding v6 - If VOIP and > PDA's (?) use up their IP addresses, they can easily ask for more. The more > you use, the more you get. There is no shortage of v4 space. > > China and Japan are not mandating anything, AFAIK. I believe that v6 > deployment is being encouraged by some countries, and the spread of 3G is > helping things along, but we have yet to see really widespread v6 > deployments anywhere. > > Basically, major backbone networks will deploy v6 when it makes economic > sense for them to do so. Right now, there is no demand and no revenue > upside. I don't expect this to change in the near future. > > v6 is, currently, a solution in search of a problem. v4 space is being > consumed slowly, but we are quite some time from a crisis. Of course, even > when we "consume" all such ipv4 space, there are still expedients that can > be used, including making v4 assets tradable and fungible. > > - Dan > > Irwin Lazar Said... > > > > > > > > Since we're on the topic of IPv6, I wanted to gauge the current > > attitude of > > the ops. community toward its deployment. We're seeing a lot > > more interest > > from our enterprise clients in using v6, especially as things > > like VoIP and > > PDAs consume their address pools, and NAT gets in the way of collaborative > > apps such as netmeeting and business-to-business connectivity. > > However, the > > road-block seems to be the lack of ISPs that offer IPv6 services. > > > > Given that places like China & Japan are now mandating IPv6 for > > their ISPs, > > does anyone see anything resembling a growing momentum toward > > IPv6 adoption, > > or is it still a moot issue for you guys? > > > > Irwin > > >

1 0

Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at
by Paul Vixie 29 Aug '02

29 Aug '02

> > If this function of your ISP costs less than 1 FTE per 10,000 > > dialups or 1,000 T1's or 100 T3's, then your ISP is a slacker and > > probably a magnet for professional spammers as well. > ... you're offering very definitive figures/labeling, and I'm curious > as to what you are basing your calculations/labels on, and what the > linearity of the scaling is in your opinion. > > Your own experience at MAPS? At MFN? Wishful thinking? those numbers are very round. i've seen folks do 1 FTE per 50,000 dialup users and get away with it, but that person was VERY busy. that ratio only works if the rest of the system is designed to repel the professional spammers, i.e., full ANI with filtering, full verification of credit cards (charge and refund before opening the account), nonrefundable deposit if terminated for spamming, and instant termination even at 4AM on sunday morning, ~30 hours or more before the account manager or any other manager could give approval. > Personally, I'd much rather try to justify a FTE for 1000 T-1s than I > would for 10,000 dialup users. like i said, the numbers were very round. as long as you understand that there IS a ratio and that the cost of dealing with outbound traffic does not end at the demarc point where it's handed to a peer or transit, then what the actual nonzero "abuse desk" costs actually are is a detail. this seems like something isp/c or cix should do a survey on.

4 3

Re: IPv6 Interview Questions and critic
by Kurtis Lindqvist 29 Aug '02

29 Aug '02

> However IPv6 has many privacy issues. IPv6 address space uses an ID > (indentifier) derived from your hardware or phone. "That allows your > packets to be traced back to your PC or cell-phone" said <censored>. > <censored> fears abuse as a hardware ID wired into the ipv6 protocol can > be used to determine the manufacturer, make and model number, and value > of the hardware equipment being used by the end user. ...uhm, and? What is the real difference with a IPv4 address and privacy? You can tell as much (more or less) with a port scan to a IPv4 address...and someone will always track the "ID" (I guess that is what I call IP address). If we are talking about the EUI64, that will disclose the vendor but hardly the make and model number.... - kurtis -

5 8

irtf-chair@ietf.org: Internet Measurement Research Group
by Mark Allman 29 Aug '02

29 Aug '02

Folks- A new group within the IRTF has been formed that will focus on measuring networks. It seems obvious that operators will have some valuable input into these issues and I would encourage folks to participate if they can. The announcement (& group charter) are attached. allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ ------- Forwarded Message From: irtf-chair(a)ietf.org To: IETF-Announce:;;@loki.ietf.org Subject: Internet Measurement Research Group Date: Thu, 29 Aug 2002 07:24:02 -0400 A new IRTF research group, IMRG (Internet Measurement Research Group), has begun, with the appended charter. Use imrg-request(a)ietf.org to subscribe to the mailing list. See http://imrg.grc.nasa.gov/imrg/ for further information. - - Vern Paxson (IRTF chair) - -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ There is considerable network measurement work being conducted within the Internet community -- both in standards bodies (e.g., IETF IPPM WG) and in various research labs. The goal of the Internet Measurement Research Group (IMRG) is to provide a venue to: (1) provide a forum for discussion of Internet measurement research issues, (2) aid in the coordination of various research projects, (3) assess new measurement techniques, and (4) increase interactions between operators, developers of measurement tools and techniques, and researchers who analyze and model Internet dynamics. The scope includes all kinds of network measurement (active techniques, passive monitoring, end-point probing, in-network methods, network layer, transport layer, application layer, etc.). The RG will both attempt to design new measurement techniques and analyze measurements of the network taken. The following represent examples of the types of projects that the RG might undertake: Tackle outstanding issues dealing with measurement infrastructures (e.g., Surveyor, NIMI), such as: scalability of meshes, security of measurement tools in the mesh, access control, resource control, scheduling issues. Tackle the often thorny issue of sharing measurement data within the community. The RG could define a systematic way for storing measurements and any needed meta-data that should be kept with the measurements. In addition, the RG could foster research into systems for remote requests for measurement, analysis, and anonymization, facilitating a formed of reduced access to data that cannot be directly released. Provide a venue for assessing new measurement techniques, and a forum for sharing preliminary findings in rough form, to encourage further work and collaboration. Provide a venue for developing models based on network measurements, helping to better understand network dynamics and aiding researchers attempting to conduct useful simulations of the network. Foster communication between the research and operations communities. For example, operators could provide feedback to researchers as to what sorts of network properties/characteristics they would like to see measured, and how well current techniques work. Catalog core problems that need to be addressed. Even if the RG is not actively working on these problems, having a "wish list" of outstanding problems may foster work in these areas. Coordination - the RG will provide: A venue for exploring measurement techniques before they are ready to be standardized by the IETF (in IPPM, for instance). A venue for discussing real world experience with IETF defined metrics and measurement techniques. A "measurement arm" to various IETF working groups to gain a better understanding of how protocols work in the wild (e.g., which HTTP capabilities are being implemented or the performance of the global DNS system). ------- End of Forwarded Message

1 0

AT&T outage
by Manolo Hernandez 29 Aug '02

29 Aug '02

For everyones knowledge yesterdays AT&T outage was not really an outage but a Route-Reflection FUBAR on their Chicago link. -- Manolo Hernandez - Network Administrator Dialtone Internet - Extremely Fast Linux Web Servers phone://954-581-0097 fax://954-581-7629 mailto:manolo@dialtone.com http://www.dialtone.com "The only source of knowledge is experience." - A. Einstein

1 0

wireless access point accounting
by Hugh Irvine 29 Aug '02

29 Aug '02

Hello Everyone - I have recently been investigating wireless access points for 802.1x. Is anyone out there using radius authentication and accounting with these devices? If so could you please send me copies of the authentication requests and the accounting starts and stops? Any war stories regarding different brands would also be welcome. many thanks Hugh NB: I am travelling this week, so there may be delays in our correspondence. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence.

1 1

Contact for dmisinetworks.com /
by Avleen Vig 29 Aug '02

29 Aug '02

Currently seeking an abuse contact for the above domain, or the party responsible for netblock that 66.21.84.209 is a part of: Netname: BELLSNET-BLK8 Netblock: 66.20.0.0 - 66.21.255.255 Maintainer: BELL Seeing repeated abuse from a single user against multiple hosts, and emails to abuse@bellsouth have gone unanswered. -- Avleen Vig: Work Time: Unix Systems Admin Email: work(a)silverwraith.com Play Time: Network Security Admin Pager: av-pager, at silverwraith.com Smurf Amplifier Finding Executive: http://www.ircnetops.org/smurf

2 1

Icelandic service restored
by Sean Donelan 29 Aug '02

29 Aug '02

The CANTAT-3 trans-atlantic cable between the Iceland and Canada and Europe was cut early this morning. E-mail and telephone service was restored around 3pm local time. Iceland Telecom said phone and Internet traffice was effectively cut off for about 9 hours while it re-routed the affected communications via satellite.

1 0

Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
by Brad Knowles 28 Aug '02

28 Aug '02

At 6:13 PM -0700 2002/08/27, David Schwartz wrote: > I'm afraid the technology to rapidly sift through large volumes of > information to search for specific areas of interest is widely available. Really? Where? I'd like to know what they are and where. > It > is totally reasonable to not want to send mail through your ISP's mail > servers and perhaps directly to a trusted mail distributor over an encrypted > link. Fair enough. > Of course, you can easily use a port other than 25 for this purpose. Indeed. > The problem comes when the recipient tries to validate your origin address > against your secure mail server. Well, if you use TLSSMTP, I would think that would be resolved during the connection, by the authentication of the key. -- Brad Knowles, <brad.knowles(a)skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)

2 1