November 2002 - Test - lists.nanog.org

IP backbone numbering/naming
by Steve Rude 16 Nov '02

16 Nov '02

Hi All, I am trying to collect information about using RFC 1918 space on an ISP backbone. I have read the RFC several times, and I don't see where it says that you cannot use 10/8 space to number your backbone links (/30s). I know this is an old thread that has been rehashed several times, but can anyone please send me links or information that I can use to convince my boss that we should use our arin alloc'd space on our backbone instead of using private space. Also if anyone has opinions on naming conventions for backbone such as why to or why not to even have dns resolution for your backbone and some conventions please let me know. TIA! -- Steve Rude steve(a)rudedogg.com

7 6

Re: PM3's crashing
by mikenoc＠mindspring.com 16 Nov '02

16 Nov '02

We have hundreds of PM3's across the country and we havent seen any problems. Mike F. Earthlink NOC On Sat, 16 Nov 2002 01:43:26 -0500 (EST) Brian Wallingford <brian(a)meganet.net> wrote: > > :> > :> Do you have SNMP enabled? We have a couple > of TNTs stop talking to the > :> ethernet periodically, apparently due to the > SNMP bugs (and someone > :> probing). Software upgrades are now > scheduled (of course, not an option > : > :Strange, as I recall the testing we did at the > last snmp 'event' showed > :the TNT's to actually be one of the best off > snmp-bug-wise, with no > :service impacting snmp bugs. > > Same here. > > Not that snmp bugs should matter - why should > such traffic be allowed > inbound? > >

1 0

BGP Dampening
by Mark V. A. Bown 15 Nov '02

15 Nov '02

Greetings, I pose this question do its puzzling major. Two nights ago at approximately 10:20 PM PST I started receiving enough invalid routes that it caused my processor on router B to reach 100 percent utilization for 30 second interval every 3 min. While doing a debug on updates I discovered that router A was injecting routes from two of my transit connections into my tables and then removing them. When I checked router A there was a dampening list being created, but still Router A passed these routes on to Router B, but stranger still not on to Router C. When I check router B there were no dampened paths in the tables. My question is why didn't Router B dampen the invalid routes, and two why did Router A pass them along to Router B, and not Router C? Background Router C: 7513, dual processor, full memory IOS; Version 12.1(5c)E12, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1) Router B: 7507, dual processor, full memory IOS; Version 12.1(2)E, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1) Router A: 12012, dual processor, full memory IOS; GS Software (GSR-P-M), Version 12.0(21)ST2, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1) Route Sources: there are 4 full tables coming into Router A, 3 of equal preference and one of lesser preference. Yet the router still chose the flapping route???? If this is not worthy of the groups time could someone please contact me off list Mark V. A. Bown mark.bown(a)optigate.net Optigate Networks Inc. www.optigate.net

1 0

Traceroute from A to B
by Minseok Kwon 15 Nov '02

15 Nov '02

Is there a way or tool to find the route between two arbitrary hosts from one of my local machines? In other words, given two host IP addresses A and B, I would like to find the route between A and B. I can use a source route, 'traceroute -g', to approximate the route. I have tried this option. Lots of routers, however, do not accept source routes. Any help will be appreciated. Thanks.

3 2

Re: DirecPC Protocols
by Crist J. Clark 15 Nov '02

15 Nov '02

On Fri, Nov 15, 2002 at 04:41:10PM +0100, Jurian van der Knaap wrote: > You might get some info out of the Linux DirecPC driver, or maybe the > developers of the driver can help. > > Find it at http://sourceforge.net/projects/direcpc > > Hope this is of any help, Yeah, this helped. It showed me that their protocol is totally broken. They do an GRE- or IPIP-like encapsulation, but then set the protocol field to that of the encapsulated packet. Or if the encapsulated packet is not TCP, UDP, or ICMP, they set the outer protocol to TCP. This will totally break behind NAT when the NATing device changes the source IP address and then "fixes" the TCP or UDP checksum due to the pseudo-header change. Either the NATing device drops the packet when the intial checksum is wrong or it mangles the payload, which isn't really TCP. Who designs these things? And what were they smoking when they did? -- Crist J. Clark | cjclark(a)alum.mit.edu | cjclark(a)jhu.edu http://people.freebsd.org/~cjc/ | cjc(a)freebsd.org

2 1

Next NANOG meeting/stats
by Susan Harris 15 Nov '02

15 Nov '02

The next NANOG meeting will be held February 9-11, 2003, in Phoenix, Arizona, where it will be warm and sunny. Registration opens January 2. Our hosts for this meeting are Rodney Joffe and UltraDNS. Rodney, this is the third time you've hosted NANOG, and we are very grateful for your long-term support! Below are some stats from our last meeting and an update on the list. ====================================================================== NANOG 26 Eugene, Oregon, Oct. 27-29 Hosted by Sprint and the University of Oregon (thank you!) Total attendees: 505 Speakers: 35 (3 panels) Total attending both NANOG & ARIN 93 NAPs represented: 8 Univ/college/schools 16 Asia/Pacific/Africa 36 Europe 17 Attendees representing vendors 104 Attendees representing ISPs 213 R&E 63 Other (gov't., software vendor, content, consultant) 125 Wireless card loans: 49 Largest simultaneous # of wireless users: 400 Concurrent RealMedia viewers: up to 101 Concurrent multicast viewers: ~20 to 30 Unique multicast viewers: ~50 to 100 Meeting coordination: Merit Squid cache: Measurement Factory Sponsors: Foundry, Adlex, Arbor Cisco, Force10, Juniper Packet Design, Seranoa, Redback NANOG Email List Stats ---------------------- Direct NANOG subscribers 5927 nanog-post 4635 nanog-announce 533 nanog-digest 809

1 0

DirecPC Protocols
by Crist J. Clark 15 Nov '02

15 Nov '02

I've been looking for some technical descriptions on how DirecPC works from a TCP/IP point of view. Does anyone out there have some references? I have not been able to find anything too detailed, and from what I have been told, they are not too forthcoming when contacted directly. I know the rough outline. The customer sends out traffic over a normal PPP link (since the customer has no uplink to the DirecPC satellite) to a separate ISP. The traffic has a spoofed source address set to some DirecPC server at their ground site(s). Thus, the third-party target's response goes to DirecPC who send it over their satellite link back to the customer using the wide satellite pipe instead of the narrow PPP pipe. But I'm curious about the details. First things first, anyone know how the DirecPC link is established? That is, how the customer tells DirecPC what his IP address is? I assume this must all happen over the PPP-link, or at least the two-way PPP-link is used for bootstrapping. Now once things are going, what kind of predictive ACKing games does DirecPC play? The reason I am curious is that I'm trying to figure out what kinds of things ISPs, or any Internet access provider (say the user is dialing into a corporate RAS), can do to break or accomodate DirecPC. The obvious things that come to mind are egress filtering and NAT. In addition to any technical information that can help me figure this out for myself, experience others have had with these same problems would also be helpful. Thanks a lot for any help. -- Crist J. Clark | cjclark(a)alum.mit.edu | cjclark(a)jhu.edu http://people.freebsd.org/~cjc/ | cjc(a)freebsd.org

5 6

Re: PAIX
by Paul Vixie 15 Nov '02

15 Nov '02

> > I'm putting the number closer to 40 (the "NFL cities") right now, and > > 150 by the end of the decade, and ultimately any "metro" with population > > greater than 50K in a 100 sq Km area will need a neutral exchange point > > (even if it's 1500 sqft in the bottom of a bank building.) > > What application will require this dense peering? today, we need this dense peering to keep local traffic local just with apps that folks already run. kazaa and gaming are examples where isochrony or high volume bidirectional peer-to-peer traffic are already present, but the fact is that "hub & spoke" is a better topology for a metro than for a region, even where http/smtp/ftp are still the primary applications. going forward, movies on demand and other things that we currently use satellites or cable TV systems for. voip. internet-delivered radio, using things like 802.11 and bluetooth as the "last mile." i want a Dick Tracy wristwatch and i know that thousands of other people will want it too and i can do the arithmetic to see that there will be more than one (probably more than several) providers per metro, even in small metros, and that if their closest exchange point is in some other metro, it can't take off. someone mentioned SIX. but a peering switch does not an exchange point make. without a PNI upgrade path, which means a certain amount of hard colo, the ceiling is too low. (that's one reason why ATM-based metro exchanges are not growing very fast, and why nobody is building new ones any more.)

3 2

The Cidr Report
by cidr-report＠potaroo.net 15 Nov '02

15 Nov '02

This report has been generated at Fri Nov 15 21:51:38 2002 AEST. The report analyses the BGP Routing Table of an AS4637 (Reach) router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/as4637 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 08-11-02 115262 82970 09-11-02 115386 83004 10-11-02 115366 82989 11-11-02 115336 83068 12-11-02 115307 83083 13-11-02 115426 83148 14-11-02 115439 83284 15-11-02 115525 83493 AS Summary 14038 Number of ASes in routing system 5503 Number of ASes announcing only one prefix 1706 Largest number of prefixes announced by an AS AS701 : ALTERNET-AS UUNET Technologies, Inc. 73007104 Largest address span announced by an AS (/32s) AS568 : SUMNET-AS DISO-UNRRA Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 15Nov02 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 115835 83543 32292 27.9% All ASes AS3908 1083 559 524 48.4% SUPERNETASBLK SuperNet, Inc. AS701 1706 1251 455 26.7% ALTERNET-AS UUNET Technologies, Inc. AS7843 744 299 445 59.8% ADELPHIA-AS Adelphia Corp. AS7018 1367 1003 364 26.6% ATT-INTERNET4 AT&T WorldNet Services AS6197 458 108 350 76.4% BATI-ATL BellSouth Network Solutions, Inc AS18566 354 6 348 98.3% COVAD Covad Communications AS4323 523 183 340 65.0% TW-COMM Time Warner Communications, Inc. AS1221 1190 865 325 27.3% ASN-TELSTRA Telstra Pty Ltd AS7046 589 303 286 48.6% UUNET-CUSTOMER UUNET Technologies, Inc. AS6347 358 81 277 77.4% DIAMOND SAVVIS Communications Corporation AS4355 402 135 267 66.4% ERMS-EARTHLNK EARTHLINK, INC AS1239 900 659 241 26.8% SPRINTLINK Sprint AS852 710 469 241 33.9% ASN852 Telus Advanced Communications AS4151 343 106 237 69.1% USDA-1 USDA AS22927 283 48 235 83.0% AR-TEAR2-LACNIC TELEFONICA DE ARGENTINA AS705 437 203 234 53.5% ASN-ALTERNET UUNET Technologies, Inc. AS209 564 331 233 41.3% ASN-QWEST Qwest AS6198 409 179 230 56.2% BATI-MIA BellSouth Network Solutions, Inc AS4814 234 15 219 93.6% CHINANET-BEIJING-AP China Telecom (Group)Beijing Telecom CompanyBeijing China AS1 658 441 217 33.0% GNTY-1 Genuity AS6140 268 67 201 75.0% IMPSAT-USA ImpSat USA, Inc. AS17676 227 30 197 86.8% GIGAINFRA APNIC ASN block AS6595 248 57 191 77.0% DODDSEUR DoD Education Activity Network Assistance Center AS17557 310 122 188 60.6% PKTELECOM-AS-AP APNIC ASN block AS4134 297 114 183 61.6% ERX-CHINALINK Data Communications Bureau AS690 506 327 179 35.4% MERIT-AS-27 Merit Network Inc. AS2048 263 87 176 66.9% LANET-1 State of Louisiana AS7132 232 67 165 71.1% SBIS-AS Southwestern Bell Internet Services AS174 295 136 159 53.9% PSINET PSINet Inc. AS2548 401 243 158 39.4% ICIX-MD-AS Business Internet, Inc. Total 16359 8494 7865 48.1% Top 30 total Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog(a)merit.edu eof-list(a)ripe.net apops(a)lists.apnic.net routing-wg(a)ripe.net afnog(a)afnog.org

1 0

RE: Blocking specific sites within certain countries.
by Simon Waters 14 Nov '02

14 Nov '02

> This all strikes me as incorrect. The function of the domain name system is > primarily to translate an IP number into a domain name, vice versa. If a > user wishes to browse to <http://64.236.16.20> he/she will arrive also at > <www.cnn.com>. Remember some servers won't work with IP address, typically if they host multiple sites on one IP address. A topical example might be; http://www.ehj-navarre.org/ versus http://206.168.174.6/ Where users recursive DNS servers are allocated by the ISP's DHCP service this stops the uninitiated, but is trivial for those who know how to work around it. The technical issues are probably well understood by most of NANOG's readership, the issue is 'is it sufficient to satisfy the courts'. My guess is yes, but it is one for the ISPs legal advisers. In most cases I think ISPs would be well advised to oppose being made into censors of the Internet, as it is a model that doesn't scale well. Aside from moral, political and technical objections, it is bad business being the unpaid guardians of everyone elses morality. The key technical objection is of course it undermines the DNS stability, there is no way apriori to establish if a domain contains DNS servers for other domains. Although where it is just one IP address, you could check for a DNS server at the time of censor, but even that could change. Reminds me of the paper on complexity we had posted a few days back, small changes to the universal DNS view usually have a small impact, but sometimes the impact may be amplified.

1 0