- NANOG - lists.nanog.org

165.138.0.0
by Shawn David Solomon 28 May '98

28 May '98

---------- Forwarded message ---------- Date: Thu, 28 May 1998 10:46:54 -0500 (EST) From: Aaron Branham <abranham(a)ind.net> To: Sean Donelan <SEAN(a)SDG.DRA.COM> Cc: nanog(a)merit.edu Subject: 165.138.0.0 Sean, when I look at a full BGP table from MCI/Sprint/UUnet/and ANS I see a lot of /16 - /24's on the 12.0.0.0 (which also has a /8), 24.0.0.0 (which has no /8), 53.0.0.0, 62.0.0.0, etc.....Some of these have the classic /8 covering them and some don't. It's the same story for several /16's (class b networks) I see 132.155.204.0/23 (without a /16 anywhere), 134.128.52.0/24 (without a /16). Do you have problems getting to all of these? >From a router that has a customer connection to ANS, MCI, UUnet, and Sprint I see all of our routes even though we only have uplinks to MCI and Sprint. This router has direct connects with MCI and UUnet and iBGP peers with a router that has the connections to Sprint and ANS. Core#sh ip b reg _1767_ ...cut.... * i165.138.96.0/20 208.160.14.1 0 0 1239 1239 1767 i * i 208.160.14.1 0 0 1239 1239 1767 i *> 166.48.222.45 0 0 3561 3561 1767 i * 157.130.97.209 0 0 701 701 1239 1767 i ...cut.... This is the other router..... ...cut.... * i165.138.96.0/20 208.160.10.1 0 0 3561 3561 1767 i * i 208.160.10.1 0 0 3561 3561 1767 i * 192.103.62.121 0 0 1323 1673 3561 1767 i *> 144.228.13.229 0 0 1239 1239 1767 i ...cut.... The purpose of the /20's and /19's on our 165.138.0.0, 165.139.0.0 and 157.91.0.0 networks was to provide better service to our customers and to try and save IP address space for others. Like some of the class A's above we treated these as CIDR blocks instead of going to our upstream providers or the ARIN to get more addresses. Because our network has a dozen pops thoughout the state and each has at least one upstream connection to Sprint and MCI we advertise them as the /19's and /20's. This provides the greates redundancy for our customers. Sprint's policy does not apply to customer routes so they do not filter at the /16 level for classic B addresses. (They do for everybody else though....) Neither does MCI and it appears that ANS and UUnet do not filter with their connections to MCI and Sprint. We have run this way for several weeks now and this is the first call on the problem that we have gotten. But since the idea here is connectivity we'll re-announce the /16 from at least one of the POPs. But in order to make sure the /16 is always routable we'll have to advertise it from every POP that has a /20 or /19 sub address. Otherwise if the one POP advertising the /16 goes down our customers on the noted networks will loose connectivity to your network. (We'll also have to put in a /16 static route to overide the null0 that BGP will inject into our routing tables.) It was much cleaner to just advertise the /19's and /20's without the /16 but we can (and I guess will have to unless you change your filters) do it the other way. - - Aaron Branham [AKB8] (a(a)ind.net) <Phone# 317.263.8976>

1 0

PC Bozo's World bites again (CNN, too)
by Vadim Antonov 28 May '98

28 May '98

Check http://cnn.com/TECH/computing/9805/26/net.access.idg/index.html Those bozos are suggesting to reduce MTU from 1500 to 576 to "improve performance", so packets "won't fragment in backbones"! The bright idea to fix CTS/RTS setting didn't come along in their brilliant minds. Here goes the average packet size. Down the drain... Now what do we do to control the damage? I also think it's a good time to measure the gullibilty of the general public by measuring packet size distribution :) --vadim

6 6

165.138.0.0
by Aaron Branham 28 May '98

28 May '98

Sean, when I look at a full BGP table from MCI/Sprint/UUnet/and ANS I see a lot of /16 - /24's on the 12.0.0.0 (which also has a /8), 24.0.0.0 (which has no /8), 53.0.0.0, 62.0.0.0, etc.....Some of these have the classic /8 covering them and some don't. It's the same story for several /16's (class b networks) I see 132.155.204.0/23 (without a /16 anywhere), 134.128.52.0/24 (without a /16). Do you have problems getting to all of these? >From a router that has a customer connection to ANS, MCI, UUnet, and Sprint I see all of our routes even though we only have uplinks to MCI and Sprint. This router has direct connects with MCI and UUnet and iBGP peers with a router that has the connections to Sprint and ANS. Core#sh ip b reg _1767_ ...cut.... * i165.138.96.0/20 208.160.14.1 0 0 1239 1239 1767 i * i 208.160.14.1 0 0 1239 1239 1767 i *> 166.48.222.45 0 0 3561 3561 1767 i * 157.130.97.209 0 0 701 701 1239 1767 i ...cut.... This is the other router..... ...cut.... * i165.138.96.0/20 208.160.10.1 0 0 3561 3561 1767 i * i 208.160.10.1 0 0 3561 3561 1767 i * 192.103.62.121 0 0 1323 1673 3561 1767 i *> 144.228.13.229 0 0 1239 1239 1767 i ...cut.... The purpose of the /20's and /19's on our 165.138.0.0, 165.139.0.0 and 157.91.0.0 networks was to provide better service to our customers and to try and save IP address space for others. Like some of the class A's above we treated these as CIDR blocks instead of going to our upstream providers or the ARIN to get more addresses. Because our network has a dozen pops thoughout the state and each has at least one upstream connection to Sprint and MCI we advertise them as the /19's and /20's. This provides the greates redundancy for our customers. Sprint's policy does not apply to customer routes so they do not filter at the /16 level for classic B addresses. (They do for everybody else though....) Neither does MCI and it appears that ANS and UUnet do not filter with their connections to MCI and Sprint. We have run this way for several weeks now and this is the first call on the problem that we have gotten. But since the idea here is connectivity we'll re-announce the /16 from at least one of the POPs. But in order to make sure the /16 is always routable we'll have to advertise it from every POP that has a /20 or /19 sub address. Otherwise if the one POP advertising the /16 goes down our customers on the noted networks will loose connectivity to your network. (We'll also have to put in a /16 static route to overide the null0 that BGP will inject into our routing tables.) It was much cleaner to just advertise the /19's and /20's without the /16 but we can (and I guess will have to unless you change your filters) do it the other way. - - Aaron Branham [AKB8] (a(a)ind.net) <Phone# 317.263.8976>

1 0

Re: The Great Exchange
by Scott Huddle 28 May '98

28 May '98

On the international slide, I've seen a slide presentation from Deutche Telecom that said that half of all of its traffic stayed in country, which *I'd* label as "local". This is all WAG, tho. I'll argue that you can never measure this accurately from the network (how much traffic did you *not* count?, how much traffic was delivered on campus? is the site multihomed?), you have to measure it from the edge. To really test this you need sampling from the users, ala the Nielson method and knowledge of geography for IP addresses. Market opportunity anyone? -scott > From owner-nanog(a)merit.edu Wed May 27 16:36 EDT 1998 > Date: Wed, 27 May 1998 16:25:06 -0400 (EDT) > From: Al Reuben <alex(a)nac.net> > To: Tom Perrine <tep(a)SDSC.EDU> > cc: perry(a)piermont.com, dpickett(a)northc.com, nanog(a)merit.edu > Subject: Re: The Great Exchange > MIME-Version: 1.0 > Sender: owner-nanog(a)merit.edu > Content-Type> : > TEXT/PLAIN> ; > charset=US-ASCII> > Content-Length: 854 > > > I'd guestimate that local peering and stuff accounts for as much as 5 to > 15% of our traffic. > > > > Perhaps someone who is actually running a local exchange can report on > > how much traffic they are carrying that is now not being sent to a > > MAE-equivalent? I think that actual experience and hard data will > > surprise us all. > > > > --tep > > > > > > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > Atheism is a non-prophet organization. > I route, therefore I am. > Alex Rubenstein, alex(a)nac.net, KC2BUO, ISP/C Charter Member > Father of the Network and Head Bottle-Washer > Net Access Corporation, 9 Mt. Pleasant Tpk., Denville, NJ 07834 > Don't choose a spineless ISP! We have more backbone! http://www.nac.net > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > > >

3 3

Re: The Great Exchange
by shields＠crosslink.net 28 May '98

28 May '98

In article <199805271744.NAA21312(a)jekyll.piermont.com>, "Perry E. Metzger" <perry(a)piermont.com> wrote: > In the long run, why are we assuming there will be locality of > traffic? > > It is true that the old PSTN has locality of traffic, but it doesn't > have flat rate pricing, or the usage patterns that the Internet has. Why are you assuming that the Internet will continue to have non-distance-sensitive pricing, when it clearly has distance- sensitive costs (ultimately)? -- Shields, CrossLink.

4 5

Re: Core router bakeoff?
by Brian Moore 28 May '98

28 May '98

This is going to sound mean, but it isn't intended to be :) Cisco's documentation on Kerberized telnet is actually pretty darn good. It's a three or four-step process. The docs even include sample KDC configs. Documentation for 11.2 is in the 'Security Configuration Guide' section on 'Configuring Network Access Security,' 'Establishing Kerberos-Authenticated Server-Client System.' Brian At 10:24 PM 5/8/98 -0500, Sam Birch wrote: >Not that I've done it, but you can use Kerberos to remotely manage a Cisco, >giving you an encrypted telnet. In fact, does anyone have any pointers >about how?

10 13

Re: The Great Exchange
by Sean Donelan 28 May '98

28 May '98

I feel a major rathole opening up, but when has that stopped me... This seems logical, this seems to make sense. And then we have the hub-and-spoke model brought about by airline deregulation and FEDEX. There you have an entire industries built out of moving people and goods from end points to central sorting facilities and then back out to their destinations. Think of O'Hare as a the MAE-East of the FAA.AIRNET. Yes, I know there are no 'pure' examples. Even FEDEX tries to intercept local packages before they get on the planes, and route them via local trucks. Like most things, there isn't a 'pure' answer. It is efficient to have a few (we can argue over the number, 3 NAPs seems to small for today's Internet) hubs. But it is also efficient to try to intercept local traffic, and handle it locally (local exchange, caching, etc). Of course, living in the St. Louis TWA hub city, you may understand why I don't always think letting a single carrier domainant a hub is a great idea. >In large metro areas, or any place with a large *number* of ISPs, >there will be advantages to local interconnects. Period. Even if >there is distance-insensitive pricing for their connection to a >MAE-thing, I would think that they would rather save that precious >bandwidth for traffic that really needs to go to the MAE-thing. It >could reduce their need to buy a bigger pipe to that major >interconnect, just to carry that local traffic "up-and-back". -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: The Great Exchange
by Anthony Sticha 28 May '98

28 May '98

I wish that such a thing actually existed. Right now most charges are on volume, with only one providor (to my knowledge) bringing a pipe in from the US on a flat rate charge. -----Original Message----- From: Sean Donelan <SEAN(a)SDG.DRA.COM> To: nanog(a)merit.edu <nanog(a)merit.edu> Date: Thursday, 28 May 1998 12:37 Subject: Re: The Great Exchange >>I think it's a North American view of the world, unsurprising on NANOG >>:-) Traffic metering is the dominant charging mechanism for permanent >>connections in Oz and Connect differentiate traffic based on its >>source (domestic/cache/external). > >Hasn't a price war just broken out in Australia, with the dominant >feature being the introduction of flat-rate pricing? > >-- >Sean Donelan, Data Research Associates, Inc, St. Louis, MO > Affiliation given for identification not representation > >

1 0

Re: SMURF amplifier block list
by Sean M. Doran 27 May '98

27 May '98

| Posting it here weekly only provides a mechanism for the littele fsckers | that smurf to gain an up to date list of sites to bounce from. And consequently increases the liklihood that more networks will refuse traffic to or from these networks, which in turn increases the pressure on these sites to wonder what is happening to their connectivity and how to repair it. Which may just solve the problem. This is a monumental admission: I think Karl is doing the right thing. Sean.

43 112

Anyone from UUNET out there??
by Vinny India 27 May '98

27 May '98

Why can't people connected to UUNET in the southeast get to my network. This problem has been going on for quite some time, and I have had no luck with the UUNET NOC. I am in as 3064 multi-hommed with AS1239 and AS4647, here is an example of a traceroute through UUNET in Atlanta. I'm looking for some help from a tech at UUNET on this matter. Thank you, Vinny India WAN Administrator CyberGate NOC 954-429-8080 traceroute to hypertek.net (207.36.74.137), 200 hops max, 40 byte packets 1 router (208.233.58.129) 13.977 ms 3.265 ms 9.639 ms 2 disdn-2-MEM-TO.mem.net (208.233.48.142) 28.099 ms 28.900 ms 28.185 ms 3 border-1-MEM-TO.mem.net (208.233.48.129) 30.999 ms 30.737 ms 33.123 ms 4 Loopback0.GW1.ATL1.Alter.Net (137.39.2.42) 44.481 ms 41.481 ms 40.564 ms 5 103.ATM10-0-0.XR1.ATL1.ALTER.NET (146.188.232.34) 42.013 ms 59.390 ms 42.370 ms 6 195.ATM5-0-0.CR2.ATL1.ALTER.NET (146.188.232.25) 43.246 ms 51.334 ms 41.801 ms 7 102.ATM11-0-0.XR2.ATL1.ALTER.NET (146.188.232.30) 41.970 ms 41.476 ms 49.120 ms 8 194.ATM5-0-0.CR2.ATL1.ALTER.NET (146.188.232.29) 45.594 ms 42.698 ms 41.979 ms 9 102.ATM11-0-0.XR2.ATL1.ALTER.NET (146.188.232.30) 63.663 ms 41.157 ms 41.841 ms 10 194.ATM5-0-0.CR2.ATL1.ALTER.NET (146.188.232.29) 41.789 ms 43.079 ms 42.759 ms 11 102.ATM11-0-0.XR2.ATL1.ALTER.NET (146.188.232.30) 43.895 ms 46.727 ms 43.638 ms 12 194.ATM5-0-0.CR2.ATL1.ALTER.NET (146.188.232.29) 42.019 ms 48.979 ms 46.465 ms

2 1