- Test - lists.nanog.org

[administrivia] Incorrect URL link for NANOG archives
by Paul Ferguson 23 Sep '97

23 Sep '97

The link for 'NANOG Mailing List Archives from Merit' points to: http://www.merit.edu/mail.archives/html/nanog/ Shouldn't it actually point to: http://www.merit.edu/mail.archives/html/nanog/maillist.html Thanks, - paul

1 0

Re: Packets from net 10 (no, not the lyrics)
by Randall S. Benn 23 Sep '97

23 Sep '97

At 06:16 AM 9/23/97 -0700, you wrote: > >! Loopback >access-list 100 deny ip 127.0.0.0 0.255.255.255 255.0.0.0 0.255.255.255 >! RFC 1918 private blocks >access-list 100 deny ip 10.0.0.0 0.255.255.255 255.0.0.0 0.255.255.255 >access-list 100 deny ip 172.16.0.0 0.15.255.255 255.240.0.0 0.15.255.255 >access-list 100 deny ip 192.168.0.0 0.0.255.255 255.255.0.0 0.0.255.255 >! Test Network >access-list 100 deny ip 192.0.2.0 0.0.0.255 255.255.255.0 0.0.0.255 >! Tiny networks. >access-list 100 deny ip any 255.255.255.128 0.0.0.127 >access-list 100 permit ip any any > I think you'll find that your router's CPU will be happier if you just dump the 1918 networks to the bit bucket on your border routers with a static route via interface Null0: ip route 10.0.0.0 255.0.0.0 null0 ip route 127.0.0.0 255.0.0.0 null0 etc. Considering resource utilization on the router, it is cheaper to do a routing table look-up than it is to do ACLs. Also, when you're doing outbound filtering on the router, you have to do a routing table lookup first before you can do outbound filtering. Save a step and just do the routing table lookup. Randy

3 2

Traffic locality and other questions
by Sean Donelan 23 Sep '97

23 Sep '97

Traffic locality has long been a concern of mine, since one would expect local public library traffic to be dominated by local users. What's interesting is over the last five years the network topology has become less local. Once upon a time, almost every site within a geographic region 'bought' service from a single mid-level provider. MIDNET served the midwest, MERIT served Michigan, SURANET served the southeast, BARRNET served the San Francisco bay area, and so on. The concept of the regional provider dropped out of favor as MCI, Sprint and UUNET entered the marketplace with significantly lower charges than the regional providers. Now network topology, like the airline industry, favors tail circuits feeding into large hubs. With facilities based providers its not uncommon to see a >1,000 mile back-haul for the local loop. Even if both end-users bought service from the same provider, they may end up with service from hubs thousands of miles away from each other. For example, its not uncommon for St. Louis customers to be served from Chicago, Kansas City, or Fort Worth. This is most pronounced in the individual user marketplace. Even if the individual user dials a local phone number, often their connection is hauled to someplace like Northern Virginia (AOL) before heading out on the Internet. So the best performance may come from a provider with connections closer to Northern Virginia than to some place near the user's dialup. What's also interesting is the asymmetry between traffic generators and traffic consumers. Although overall DRA has a even mix of inbound and outbound traffic. I see tremendous inbalances with individual providers. But it is very difficult to tell who is getting a 'free-ride' from whom. Other than SYN-flood attacks, and the dreaded default route, traffic only flows if there is some kind of customer demand on both sides. I have some questions whether it is better to aggregate traffic into a single huge flow, or if it is better to have lots of smaller paths. Would I be better buying a single cross-country OC3 with one provider, or trying to do a deal for several T1's with Turner, Gannett, or other places public libraries are interested in using? Over the last five years, I've found building small bypasses work better. But maybe things have changed and I can meet end-to-end performance requirements by other means. I also have a question about how consolidated the traffic really is. If I only bought circuits from the top three providers, how much of our traffic would that really cover. What if I bought circuits from the top 10 providers. Perhaps the public library market is an aberration, but I see much less traffic aggregation than others report. I use both 'managed' and 'un-managed' connections in both 'transit' and 'peer' provider relationships. My business relationship with the next-hop provider seems to have very little correlation with the traffic flows. DRA's top 20 traffic generators/sinks by end AS, alphabetical order AOL, BBN, CONCERT, DIGEX, DISI, EDS, GANNETT, IACNET, ISI, JVNC, MCI, MERIT, NETCOM, OARNET, PSI, SPRINT, SUPERNET, TURNER, UNISYS, UUNET The top 20 end ASs are extremely volatile. NASA Science Internet can leap to the top for a week, e.g. Pathfinder; or IBM jumps during the Olympics, or UK providers the week following Princess Diana's death. Since most of the long-term large traffic generators are multi-homed among several providers, a very small network topology change can dramatically shift traffic between network backbone providers. Percentage of traffic destined for the top 10 next-hop ASs, includes transit ASs so some next-hop traffic may be inflated by traffic destined to another provider via the transit provider. Since most peering agreements prohibit the release of identifiable information, I'm not identifying which provider goes with what percentage. 14.4% 13.4% 12.0% 7.9% 3.2% 1.9% 1.8% 1.2% 1.1% 1.1% BGP isn't very good at showing 'other' transit paths to networks. Its like adding another lane to a road, traffic that didn't exist before appears. The next-hop rankings are less volatile, but over time they do show significant trends. In the last year, the traffic among next-hops has become flatter at the top, and the tail has become longer. The opposite of what I would expect in a market experiencing consolidation. What I find interesting is the rankings of traffic flows I see don't match with what the pundits rank as the largest network providers. I don't know what that means though. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

5 4

Whoa.
by Alex Rubenstein 23 Sep '97

23 Sep '97

whi4#sho ip bgp 10.0.0.0 BGP routing table entry for 10.0.0.0/8, version 1537750 Paths: (1 available, best #1, advertised over IBGP) 3561 3561 577 204.70.65.53 from 204.70.65.53 (204.70.65.1) Origin incomplete, valid, external, best Now, that is cool. University of Toronto (ASN-CA-NET-AS) Toronto, Ontario M5S 1A1 CANADA Autonomous System Name: CA-NET-AS Autonomous System Number: 577 Hello?!

4 3

Re: Spammer at new home.
by Martyn Williams 23 Sep '97

23 Sep '97

Isn't spammer Quantum at quantcom.com ? At 06:09 97/09/23 -0400, you wrote: > >It seems that Quantum Communications has found a new home. > >/usr/sbin/traceroute www.quantumcomm.com > 1 rtr-jch-1 (207.15.210.249) 1.137 ms 1.045 ms 1.027 ms > 2 pm-atl-3 (207.15.208.19) 26.572 ms 24.226 ms 24.242 ms > 3 rtr-atl-4-E0 (207.15.208.1) 26.287 ms 25.119 ms 26.318 ms > 4 rtr-atl-5 (207.15.208.21) 26.639 ms 26.562 ms 28.243 ms > 5 Fddi1-0.SR1.ATL1.ALTER.NET (137.39.62.1) 30.856 ms 32.738 ms 30.577 >ms > 6 341.ATM6-0.CR2.ATL1.Alter.Net (137.39.21.78) 34.976 ms 32.185 ms >30.897 ms > 7 109.Hssi6-0.CR2.CHI1.Alter.Net (137.39.59.158) 50.41 ms 47.755 ms >48.352 ms > 8 412.atm11-0.gw3.chi1.alter.net (137.39.13.97) 47.937 ms 46.099 ms >48.422 ms > 9 ntr-gw.customer.ALTER.NET (157.130.96.62) 55.593 ms 55.797 ms >54.547 ms >10 ntr-gw.customer.ALTER.NET (157.130.96.62) 55.855 ms 55.414 ms >50.782 ms >11 venice2.ntr.net (206.112.1.253) 61.046 ms 53.04 ms 52.198 ms >12 vmarket-gw.ntr.net (206.112.5.26) 57.262 ms 56.56 ms 56.216 ms >13 206.115.74.175 (206.115.74.175) 59.219 ms 57.707 ms 58.119 ms

2 1

RE: Physical transport media
by Per Engstrom 23 Sep '97

23 Sep '97

> At 5:04 PM -0400 9/16/97, Tim Gibson wrote: > >If I may be so bold here Michael, the TTL of steel is significantly > less > >than so many other datagrams, many due to R.educed U.seable S.urface > >T.ransparancy. > > We think that we have the R.U.S.T problem licked by using stainless > steel > BBs and by using a petroleum based liquid transport medium. We need > the > mass of steel in the datagrams to protect against backhoe fade. After > a few > backhoe operators get torn to shreds by a stream of IP packets from > cut > transport pipes, those big yellow machines will show a little more > respect > and watch where they stick their big yellow buckets. > I can see it now... " We have a BS-3 down due to oil change maintenance." ---------------------------------------- Per Engstrom IXC Communications Broadband Services Network Operations (512)427-3836 pengstrom(a)ixc-comm.net

2 1

NANOG Meeting 10/27 & 28
by Pam Ciesla 22 Sep '97

22 Sep '97

REMINDER: The room block on the Radisson Resort ends 9/26. UPDATE: The attendee list on the nanog webpage (http://www.nanog.org) is up to date. If you should be on this list and are not or if there are any changes please let me know. NEW: The Super Shuttle is available from the airport to the Radisson for $12.00 one way. It is located outside baggage claim near the cab & limo pickup area. For the return trip call at least 4 hours ahead #800-258-3826. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Pam Ciesla 313-936-0172 - phone Merit Network, Inc. 313-647-3185 - fax University of Michigan 4251 Plymouth Road Bldg. I, Suite C Ann Arbor, MI 48105-2785 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

1 0

Re: Traffic Engineering [was Chanukah [was Re: Hezbollah]]
by pkavi＠pcmail.casc.com 21 Sep '97

21 Sep '97

Kent, As a former network design guy who's done traffic engineering and design (and redesign) on many networks (Internet and otherwise), I disagree that traffic engineering doesn't work for the Internet. I've seen many people go with the "throw bandwidth at the problem" as a cure all. While it tends to work, it tends to be the most expensive method of solving the problem. Doing traffic engineering right is hard. The telcos have it down pat for their voice networks, and telco-based ISPs often have applied this design expertise to their ISP network. Having a person do traffic engineering can save the ISP big bucks. The traffic engineering techniques I'm talking can't handle wildly dynamic situations. For example, a news event like Princess Di's death greatly increases traffic to/from England which plays temporary havoc with forecasted traffic projections. However, outside of these anomalies, traffic projections work pretty well. I've outlined a basic technique below which works for many types of networks, and has some ISP specific steps. The key to this analysis is that it takes into account the underlying traffic flows and then determines the appropriate physical backbone topology, or the changes to be made to an existing topology. This is directly in contrast to the "throw bandwidth at the problem" case that patches a backbone topology which might be sub-optimal in the first place. Here's the overall outline: 1. Divide your network into a small number of geographic areas (between five and ten). Each geographic area you choose probably has a large city that serves as a major traffic source for that area. These cities are usually the natural cities for backbone connectivity. Create an NxN matrix, where N is the total number of areas in your network. Each cell in the matrix will represent the total traffic demand between each source/destination geographic area. There are several factors which effect this matrix, each of which will be discussed below. 1. The locality of traffic. 2. The typical utilization of customers. 3. The entry/exit points of traffic from your network. 2. Identify which % of traffic, if any, has regional locality. For pure Internet traffic, the probability that the source and destinatino of traffic are within the same metropolitan area tends to be low (10% or lower for metros within the US). However, there are exceptions. Telecommuting applications tend to have very high locality. People close to work dial into work through an ISP, so both the source and destination of traffic tends to stay local (70% or higher). Places like the Bay Area in California also tend to have higher traffic locality. This is because the Bay Area has lots of Internet users (which tend to be traffic sinks), and lots of web sites (which tend to be traffic sources). ISPs outside of the US tend to have a higher percentage of traffic staying within the country, especially non-english speaking countries. 3. Measure/estimate the typical utilization of customers. Utilization needs to be measured/estimated in both send and receive directions. Dial-up users typically receive almost seven times as much as they send. Corporate customers not doing telecommuting applications tend to receive about four times as much as they send (less because corporations have web sites that others access). Web server farms have the opposite characteristics of dial-up users. Percentage utilization tends to increase with bandwidth. In the U.S., a T1 customer connection typically has a peak recieve utilization of 20% or less. However, a DS3 customer can easily have a receive utilization of 50% or more. Simple explanation is that someone paying big bucks for a DS3 wants to make sure it is justified. So, take the total number of users in each area, the connection speeds and customer types, multiply by the appropriate factors, and you get the total demand you are trying to serve out of each area. Take this traffic demand, and multiply it by the non-local traffic. This represents the total traffic that you need to get either in/out of the network, or in/out of this particular part of your network. 4. Determine the entry/exit points for traffic with your network, and its effect upon the traffic matrix. How do you setup your routing policies? Many ISPs use nearest exit. If the nearest exit is in the same geographic area, the traffic sent by your customers does not affect any other part of the overall traffic matrix. If the nearest exit is not within the same geographic area, determine the area where this traffic will be sent. Enter this value in the appropriate source/destination box of the traffic matrix. It gets harder when peering with many other ISPs, some of whom you connect to in the same area, and others in remote areas. In this case, determine which percentage of the traffic goes into each particular region, and The main traffic sources into your network (excluding your customers) are your peering points (both public and private). The amount of traffic from each peering point is measurable. You can generally estimate that this traffic is to be distributed proportional to the overall traffic demand in each geographic area. This is a significant amount of matrix math, but the overall concept is simple. Determine the overall flow between one part of your network to another. 5. With me so far? Good, now it's time to design your backbone to handle your demands. You can use dedicated lines or layer two services such as Frame Relay or ATM. The simplicity of using Frame Relay or ATM is that the circuits you need between each geographic area has been defined by your traffic matrix. This is part of the appeal of using public L2 services for a backbone. Designing your own backbone is a bit harder. The actual topology tends to be straightforward--you need to connect up the major cities in each of the geographic areas. For five areas, a simple ring suffices. For up to 10 areas, this tends to be rings bisected once or twice. The real work in designing your own backbone is in satisfying the traffic demands going across your network. Remember that geographic areas in the center of your network have to carry the traffic demands going across your network. This imposes a heavier burden in the center of the network than the traffic matrix would indicate. You also have to worry about resiliency, having sufficient bandwidth when the backhoes go fiber hunting, etc. 6. Design the network within each geographic areas. The steps for designing the network within each geographic area tend to be similar to that of designing the overall network. Breaking the overall design process into a regional network and backbone network makes the problem more tractable. 7. Measure data from a real network. This is really important. You've made lots of assumptions. Regularly check the overall traffic to see if it matches the assumptions. Refine the traffic matrix to see if it still represents reality. Create trendlines which show the overall traffic changes to/from each area, and project these trendlines into the future. You will tend to have pretty good certainty about 4 months into the future, with the value of the information decaying after that. Use this data to determine where to add additional peering points. Estimate what impact this would have on the traffic matrix. 8. Factor the measured and projected data into the next network backbone design. This next backbone design gives you the optimum backbone given the underlying flows in your network. See what changes you need to make to your backbone to get to this new optimum backbone, and order the circuits. Phew! Like I said earlier, it is hard to do right, and I've left out quite a few details in the above outline. But having been there, done that, (quite a few times) I can say it really works. And it saves ISPs money! Question for NANOG members. How important is traffic engineering given that it is fairly hard to do properly and you folks have enough other things to think about? Prabhu Kavi IP Business Marketing Manager Ascend Communications prabhu.kavi(a)ascend.com ______________________________ Reply Separator _________________________________ Subject: Chanukah [was Re: Hezbollah] Author: "Kent W. England" <kwe(a)geo.net> at smtplink Date: 9/16/97 2:09 PM At 05:03 PM 14-09-97 -0400, Dorian R. Kim wrote: >... One of the >things that needs to be engineered into building and maintaining >national/international backbones is traffic accounting to an arbitrary >granularity that paves the way for better traffic engineering and >bandwidth projections. There are already ample tools to to per-prefix >matrix of traffic right now. Tying this in with good sales projections >will alleviate much of the last minute fire fighting. > >This will most likely never be 100% accurate and precise, but there is >no reason why we can't get a better handle on bandwidth forecasts. (say to >95% percentile) Dorian; I don't want to throw cold water on the value of planning and foresight, but in terms of predicting traffic patterns it has never worked on the Internet. It sounds good and that was the argument that all the mainframe networkers made to us early Internet networkers -- Why can't you tell me upfront what your bandwidth requirements are going to be? Don't you know exactly how many terminals you have and where they are and what application keystrokes are going to be pressed at any given time? How else can you guarantee response time in your network? This Internet stuff is stupid. It'll never work. Somehow with the way that HTTP/HTML caught fire and Internet-CB (aka VocalTec and CUSeeMe) took off, I would be loath to think I could project my backbone needs with any reliability based on *historical* projections. > >Furthermore, with the deployment of WDM and Internet core devices moving >closer to the transmission gear, if you have access to fiber, getting more >bandwidth may become as straightforward as using an additional wavelength >on the ADM that your router's plugged into. > >-dorian > > > This I like a lot better as a design technique. Throwing more bandwidth at the problem almost always works (unless the transport protocol is broken). Like Peter Kline said, Turn up the speed dial upon onset of congestion. Simple. Effective. Then again, creating a data architecture for the web (a problem that has been recognized, but not addressed in the last five years) would eliminate much of the backbone bandwidth demand. What would happen if -- presto -- a data architecture for the web showed up one day? A lot of backbone bandwidth would become surplus and a lot more edge bandwidth would be needed ASAP. What does that do to historical projections? --Kent

19 29

BGP4 on a /20
by Phil Howard 20 Sep '97

20 Sep '97

I'm trying to understand what all the implications of running BGP4 on a network with a prefix longer than 19 bits. Here are some of the points I am thinking about. <flameshields> If I go ahead and announce a /20 via two backbones, one of which is the provider of the address space, then there will be redundant routes for this space as the backbone provider will be announcing the /19 (or shorter) block themselves. If I do this, it adds to the routing table glut, among other things. The advantage gained is questionable. If my link to the provider that the space comes from goes down, they are still announcing and I'll only be able to reach where my path via the alternate provider is shorter than the path to the down provider itself. OTOH If the provider were to be convinced to stop announcing for my /20, then I'm going to get filtered at Sprint and AGIS and whoever else is doing this and there won't be any /19 announcement that I can use a default path on. But the real catch here is that for the provider to stop announcing my /20 they have to split their /19 into two /20's. And if that was really a /18 that means they will be announcing a /19 and a /20 where before only a /18. This gets worse the larger their block was. Even worse than that, by doing this, they now have a /20 (the other half of the /19 my /20 is in) with other customers who will now also be filtered out at Sprint and AGIS and whoever else. While it can be OK to me if I want to give up that reachability, this is also imposing this on the other customer(s) in the other /20. So that provider is not even likely to do that. So, should I add to the glut of routes or should I add to the glut of routes? This needs to be simpler. </flameshields> -- Phil Howard +-------------------------------------------------------------+ KA9WGN | House committee changes freedom bill to privacy invasion !! | phil at | more info: http://www.news.com/News/Item/0,4,14180,00.html | milepost.com +-------------------------------------------------------------+

3 4

Re: BGP4 on a /20
by Security Administrator 20 Sep '97

20 Sep '97

If all the customers on a multi-billion dollar network could not reach my network I would think about paying a different upstream provider to peer with me. I announce a /19 and a /22 to NetRail and UUnet, and they both do an excellent job of getting Sprint's customers routed to my network. Marcus R. Williams, Jr. security(a)tomco.net ISP Programmer / Engineer On Fri, 19 Sep 1997, Brian Horvitz wrote: > Date: Fri, 19 Sep 1997 10:54:05 -0400 > From: Brian Horvitz <horvitz(a)nsa.shore.net> > To: Security Administrator <security(a)tomco.net> > Subject: Re: BGP4 on a /20 > > Because if all the customers on a multi-billion dollar network can't get to > him it's not real good. > > Brian > > At 10:32 AM 9/19/97 -0400, you wrote: > >Why should you concern yourself with the problems of a multi-billion > >dollar company like Sprint? > > > >Marcus R. Williams, Jr. > >security(a)tomco.net > >ISP Programmer / Engineer > > > >On Thu, 18 Sep 1997, Phil Howard wrote: > > > >> Date: Thu, 18 Sep 1997 18:22:19 -0500 > >> From: Phil Howard <phil(a)charon.milepost.com> > >> To: nanog(a)merit.edu > >> Subject: BGP4 on a /20 > >> > >> I'm trying to understand what all the implications of running BGP4 on > >> a network with a prefix longer than 19 bits. Here are some of the points > >> I am thinking about. > >> > >> <flameshields> > >> > >> If I go ahead and announce a /20 via two backbones, one of which is > >> the provider of the address space, then there will be redundant routes > >> for this space as the backbone provider will be announcing the /19 > >> (or shorter) block themselves. > >> > >> If I do this, it adds to the routing table glut, among other things. > >> The advantage gained is questionable. If my link to the provider that > >> the space comes from goes down, they are still announcing and I'll only > >> be able to reach where my path via the alternate provider is shorter > >> than the path to the down provider itself. > >> > >> OTOH > >> > >> If the provider were to be convinced to stop announcing for my /20, > >> then I'm going to get filtered at Sprint and AGIS and whoever else > >> is doing this and there won't be any /19 announcement that I can use > >> a default path on. > >> > >> But the real catch here is that for the provider to stop announcing > >> my /20 they have to split their /19 into two /20's. And if that was > >> really a /18 that means they will be announcing a /19 and a /20 where > >> before only a /18. This gets worse the larger their block was. > >> > >> Even worse than that, by doing this, they now have a /20 (the other > >> half of the /19 my /20 is in) with other customers who will now also > >> be filtered out at Sprint and AGIS and whoever else. While it can be > >> OK to me if I want to give up that reachability, this is also imposing > >> this on the other customer(s) in the other /20. So that provider is > >> not even likely to do that. > >> > >> So, should I add to the glut of routes or should I add to the glut of > >> routes? > >> > >> This needs to be simpler. > >> > >> </flameshields> > >> > >> -- > >> Phil Howard > +-------------------------------------------------------------+ > >> KA9WGN | House committee changes freedom bill to privacy invasion > !! | > >> phil at | more info: > http://www.news.com/News/Item/0,4,14180,00.html | > >> milepost.com > +-------------------------------------------------------------+ > >> > > > > >

2 1