September 1997 - Test - lists.nanog.org

Packets from net 10 (no, not the lyrics)
by Dennis Simpson 23 Sep '97

23 Sep '97

> Date: Tue, 23 Sep 1997 20:46:15 +0900 > To: Cary Howell <chowell(a)comstar.net> > From: Martyn Williams <martyn(a)twics.com> > Subject: Re: Spammer at new home. > Cc: nanog(a)merit.edu > > Isn't spammer Quantum at quantcom.com ? Actually, quantumcomm.com is a more interesting traceroute. Especially hops 11 and 12, clearly being passed by Sprintlink. Does anyone besides me see it as an issue that Sprintlink would pass those packets? No, the network 10 isn't in my routing tables. Should I be filtering all reserved space at my border, or would it be reasonable for me to expect the big guys not to take packets with clearly inappropriate source addresses? Or is my view on the situation incomplete? traceroute www.quantumcomm.com traceroute to www.quantumcomm.com (206.191.222.77), 30 hops max, 40 byte packets 1 www-186 (205.210.186.2) 2 ms * 1 ms 2 bcicor1-100bt-e1.barrie.connex.net (205.189.200.35) 1 ms 1 ms 1 ms 3 207.107.244.217 (207.107.244.217) 6 ms 207.107.244.213 (207.107.244.213) 6 ms spc-tor-7-Serial11-0-0-28.Sprint-Canada.Net (207.107.244.209) 6 ms 4 204.50.251.33 (204.50.251.33) 112 ms 11 ms 220 ms 5 144.228.165.25 (144.228.165.25) 20 ms 22 ms 19 ms 6 144.228.60.21 (144.228.60.21) 20 ms 21 ms 20 ms 7 144.232.0.78 (144.232.0.78) 21 ms 48 ms 20 ms 8 144.232.8.86 (144.232.8.86) 71 ms 77 ms 31 ms 9 144.228.50.18 (144.228.50.18) 43 ms 40 ms 37 ms 10 sl-sspace-1-S0-T1.sprintlink.net (144.228.18.78) 41 ms 39 ms 43 ms 11 10.1.0.5 (10.1.0.5) 41 ms 44 ms 41 ms 12 10.0.0.138 (10.0.0.138) 110 ms 71 ms 50 ms 13 206.191.222.77 (206.191.222.77) 76 ms 53 ms 51 ms bcicor1.barrie>sh ip rout 10.0.0.0 % Network not in table bcicor1.barrie>sh ip bgp sum BGP table version is 3941193, main routing table version 3941193 48010 network entries (187332/187900 paths) using 11208976 bytes of memory 19645 BGP path attribute entries using 2615348 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory Dampening enabled. 243 history paths, 78 dampened paths 93539 received paths for inbound soft reconfiguration Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State 206.186.255.219 4 3602 1397791 460484 3941185 0 0 1w1d 206.221.252.1 4 6327 1107934 701905 3941185 0 0 1d07h

6 15

Agenda update
by Susan R. Harris 23 Sep '97

23 Sep '97

Greetings - There's now a list of NANOG presentations we've scheduled so far: http://www.nanog.org/mtg-9710/topics.html We'll be adding new talks regularly; stay tuned. -------------------------------------------------------------------------- Susan R. Harris, Ph.D. Merit Network, Inc. Phone: 313.936.2100 srh(a)merit.edu Senior Science Writer Fax: 313.647.3185

1 0

Re: Packets from net 10 (no, not the lyrics)
by Kenneth E. Gray 23 Sep '97

23 Sep '97

And that would be process switching to Null0, I believe. At 08:22 AM 9/23/97 -0700, Kevin Oberman wrote: >> Date: Tue, 23 Sep 1997 10:45:19 -0400 >> From: "Randall S. Benn" <rbenn(a)clark.net> > >> 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. > >I don't think so. The static routes will require processing every >packet destined for the 10.0.0.0/8 and 127.0.0.0/8 nets, but you will >still have the bad route. The CPU will have to deal with any traffic >for 10.0.0.0/8 and any interior routers will forward packets since you >have a route. > >On the other hand, a filter on the BGP session will block the route >from being accepted and only require CPU action once...when it is >announced. You have no route to these nets and can't propagate the >routes since you don't have them. > >Andrew clearly has the correct approach. >-- >R. Kevin Oberman, Network Engineer >Energy Sciences Network (ESnet) >Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) >E-mail: oberman(a)es.net Phone: +1 510 486-8634 > > Ken Gray || || ISP Systems Engineer || || Reston, Virginia USA |||| |||| tel: +1.703.397.5942 ..:||||||:..:||||||:.. e-mail: kegray(a)cisco.com c i s c o S y s t e m s fax: +1.703.397.5999

1 0

[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