July 2009 - Test - lists.nanog.org

Weekly Routing Table Report
by Routing Analysis Role Account 24 Jul '09

24 Jul '09

This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats(a)lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith <pfs(a)cisco.com>. Routing Table Report 04:00 +10GMT Sat 25 Jul, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 292250 Prefixes after maximum aggregation: 138369 Deaggregation factor: 2.11 Unique aggregates announced to Internet: 145253 Total ASes present in the Internet Routing Table: 31825 Prefixes per ASN: 9.18 Origin-only ASes present in the Internet Routing Table: 27671 Origin ASes announcing only one prefix: 13487 Transit ASes present in the Internet Routing Table: 4154 Transit-only ASes present in the Internet Routing Table: 101 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 39 Max AS path prepend of ASN (22394) 36 Prefixes from unregistered ASNs in the Routing Table: 434 Unregistered ASNs in the Routing Table: 127 Number of 32-bit ASNs allocated by the RIRs: 213 Prefixes from 32-bit ASNs in the Routing Table: 76 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 342 Number of addresses announced to Internet: 2061480576 Equivalent to 122 /8s, 223 /16s and 178 /24s Percentage of available address space announced: 55.6 Percentage of allocated address space announced: 64.4 Percentage of available address space allocated: 86.4 Percentage of address space in use by end-sites: 78.4 Total number of prefixes smaller than registry allocations: 144712 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 69858 Total APNIC prefixes after maximum aggregation: 24855 APNIC Deaggregation factor: 2.81 Prefixes being announced from the APNIC address blocks: 69293 Unique aggregates announced from the APNIC address blocks: 31631 APNIC Region origin ASes present in the Internet Routing Table: 3715 APNIC Prefixes per ASN: 18.65 APNIC Region origin ASes announcing only one prefix: 1012 APNIC Region transit ASes present in the Internet Routing Table: 576 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 16 Number of APNIC addresses announced to Internet: 473972672 Equivalent to 28 /8s, 64 /16s and 63 /24s Percentage of available APNIC address space announced: 88.3 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 180/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 124246 Total ARIN prefixes after maximum aggregation: 66104 ARIN Deaggregation factor: 1.88 Prefixes being announced from the ARIN address blocks: 124900 Unique aggregates announced from the ARIN address blocks: 52323 ARIN Region origin ASes present in the Internet Routing Table: 13128 ARIN Prefixes per ASN: 9.51 ARIN Region origin ASes announcing only one prefix: 5058 ARIN Region transit ASes present in the Internet Routing Table: 1289 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 39 Number of ARIN addresses announced to Internet: 995143360 Equivalent to 59 /8s, 80 /16s and 174 /24s Percentage of available ARIN address space announced: 191.3 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 66929 Total RIPE prefixes after maximum aggregation: 39578 RIPE Deaggregation factor: 1.69 Prefixes being announced from the RIPE address blocks: 66512 Unique aggregates announced from the RIPE address blocks: 44870 RIPE Region origin ASes present in the Internet Routing Table: 13327 RIPE Prefixes per ASN: 4.99 RIPE Region origin ASes announcing only one prefix: 6965 RIPE Region transit ASes present in the Internet Routing Table: 1987 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 21 Number of RIPE addresses announced to Internet: 497559744 Equivalent to 29 /8s, 168 /16s and 40 /24s Percentage of available RIPE address space announced: 98.9 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223 RIPE Address Blocks 25/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 24706 Total LACNIC prefixes after maximum aggregation: 6074 LACNIC Deaggregation factor: 4.07 Prefixes being announced from the LACNIC address blocks: 24652 Unique aggregates announced from the LACNIC address blocks: 13642 LACNIC Region origin ASes present in the Internet Routing Table: 1146 LACNIC Prefixes per ASN: 21.51 LACNIC Region origin ASes announcing only one prefix: 365 LACNIC Region transit ASes present in the Internet Routing Table: 192 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 19 Number of LACNIC addresses announced to Internet: 72665344 Equivalent to 4 /8s, 84 /16s and 201 /24s Percentage of available LACNIC address space announced: 72.2 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247 plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 6131 Total AfriNIC prefixes after maximum aggregation: 1475 AfriNIC Deaggregation factor: 4.16 Prefixes being announced from the AfriNIC address blocks: 6538 Unique aggregates announced from the AfriNIC address blocks: 2506 AfriNIC Region origin ASes present in the Internet Routing Table: 302 AfriNIC Prefixes per ASN: 21.65 AfriNIC Region origin ASes announcing only one prefix: 87 AfriNIC Region transit ASes present in the Internet Routing Table: 64 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 20171264 Equivalent to 1 /8s, 51 /16s and 202 /24s Percentage of available AfriNIC address space announced: 60.1 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1704 6934 409 Korea Telecom (KIX) 17488 1543 137 103 Hathway IP Over Cable Interne 4755 1221 292 145 TATA Communications formerly 9583 1111 86 548 Sify Limited 4134 972 17321 375 CHINANET-BACKBONE 7545 812 198 101 TPG Internet Pty Ltd 23577 786 34 667 Korea Telecom (ATM-MPLS) 9829 782 611 14 BSNL National Internet Backbo 18101 750 201 32 Reliance Infocom Ltd Internet 24560 731 247 170 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4241 3643 324 bellsouth.net, inc. 4323 1899 1050 386 Time Warner Telecom 1785 1713 714 139 PaeTec Communications, Inc. 7018 1511 5907 1047 AT&T WorldNet Services 20115 1423 1461 678 Charter Communications 2386 1272 670 924 AT&T Data Communications Serv 6478 1242 275 315 AT&T Worldnet Services 3356 1190 10960 441 Level 3 Communications, LLC 11492 1128 208 12 Cable One 22773 1077 2604 66 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 30890 481 91 195 Evolva Telecom 12479 475 578 6 Uni2 Autonomous System 3292 459 1903 394 TDC Tele Danmark 702 430 1861 346 UUNET - Commercial IP service 9198 360 138 12 Kazakhtelecom Data Network Ad 3320 352 7082 305 Deutsche Telekom AG 3301 349 1684 311 TeliaNet Sweden 3215 343 3065 108 France Telecom Transpac 8866 333 109 20 Bulgarian Telecommunication C 8551 306 290 38 Bezeq International Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1489 2888 241 UniNet S.A. de C.V. 10620 938 218 114 TVCABLE BOGOTA 28573 651 581 36 NET Servicos de Comunicao S.A 7303 596 316 92 Telecom Argentina Stet-France 22047 543 302 14 VTR PUNTO NET S.A. 11830 488 309 56 Instituto Costarricense de El 11172 443 99 69 Servicios Alestra S.A de C.V 6471 434 96 31 ENTEL CHILE S.A. 7738 410 858 29 Telecomunicacoes da Bahia S.A 3816 382 188 78 Empresa Nacional de Telecomun Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1026 188 7 TEDATA 24863 903 90 48 LINKdotNET AS number 20858 323 34 5 EgyNet 3741 277 856 237 The Internet Solution 2018 244 215 143 Tertiary Education Network 6713 175 166 16 Itissalat Al-MAGHRIB 33783 152 10 8 EEPAD TISP TELECOM & INTERNET 29571 139 15 8 Ci Telecom Autonomous system 24835 129 46 9 RAYA Telecom - Egypt 5536 123 8 9 Internet Egypt Network Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4241 3643 324 bellsouth.net, inc. 4323 1899 1050 386 Time Warner Telecom 1785 1713 714 139 PaeTec Communications, Inc. 4766 1704 6934 409 Korea Telecom (KIX) 17488 1543 137 103 Hathway IP Over Cable Interne 7018 1511 5907 1047 AT&T WorldNet Services 8151 1489 2888 241 UniNet S.A. de C.V. 20115 1423 1461 678 Charter Communications 2386 1272 670 924 AT&T Data Communications Serv 6478 1242 275 315 AT&T Worldnet Services Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 1785 1713 1574 PaeTec Communications, Inc. 4323 1899 1513 Time Warner Telecom 17488 1543 1440 Hathway IP Over Cable Interne 4766 1704 1295 Korea Telecom (KIX) 8151 1489 1248 UniNet S.A. de C.V. 11492 1128 1116 Cable One 4755 1221 1076 TATA Communications formerly 18566 1062 1052 Covad Communications 8452 1026 1019 TEDATA 22773 1077 1011 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.112.0/22 5713 Telkom SA Ltd 41.223.176.0/22 36981 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 26452 Local Communications Networks 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio 63.143.251.0/24 22555 Universal Talkware Corporatio 64.31.32.0/19 11955 ServiceCo LLC - Road Runner Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:18 /9:10 /10:24 /11:58 /12:169 /13:350 /14:613 /15:1170 /16:10543 /17:4767 /18:8242 /19:17172 /20:20526 /21:20395 /22:26268 /23:26180 /24:153024 /25:933 /26:1035 /27:570 /28:159 /29:8 /30:7 /31:1 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2752 4241 bellsouth.net, inc. 4766 1402 1704 Korea Telecom (KIX) 17488 1290 1543 Hathway IP Over Cable Interne 1785 1183 1713 PaeTec Communications, Inc. 11492 1054 1128 Cable One 18566 1043 1062 Covad Communications 2386 989 1272 AT&T Data Communications Serv 9583 964 1111 Sify Limited 4323 963 1899 Time Warner Telecom 8452 948 1026 TEDATA Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:14 8:209 12:2145 13:7 15:19 16:3 17:5 20:36 24:1100 32:52 34:2 38:577 40:98 41:1749 43:1 44:2 47:22 52:6 55:2 56:2 57:24 58:596 59:649 60:461 61:1078 62:1106 63:2037 64:3711 65:2401 66:3582 67:1663 68:861 69:2640 70:552 71:154 72:1651 73:2 74:1636 75:175 76:348 77:849 78:580 79:359 80:974 81:840 82:585 83:451 84:624 85:1060 86:369 87:678 88:363 89:1468 90:50 91:2415 92:377 93:1069 94:1068 95:1122 96:155 97:225 98:250 99:27 110:176 111:348 112:113 113:144 114:254 115:330 116:1123 117:534 118:355 119:734 120:147 121:783 122:1059 123:704 124:974 125:1374 128:225 129:232 130:128 131:414 132:74 133:9 134:186 135:40 136:225 137:165 138:167 139:81 140:449 141:121 142:383 143:354 144:359 145:48 146:387 147:155 148:517 149:223 150:175 151:193 152:145 153:147 154:2 155:275 156:167 157:301 158:118 159:342 160:289 161:156 162:274 163:164 164:475 165:520 166:467 167:361 168:708 169:171 170:479 171:41 172:10 173:315 174:258 178:1 186:107 187:146 188:354 189:537 190:2914 192:5783 193:4270 194:3313 195:2692 196:1123 198:3647 199:3369 200:5140 201:1282 202:7716 203:8324 204:3903 205:2159 206:2447 207:2746 208:3895 209:3436 210:2539 211:1123 212:1666 213:1631 214:82 215:29 216:4540 217:1365 218:402 219:451 220:1107 221:475 222:327 End of report

1 0

Re: 5 forwarded messages... (fwd)
by Lucy Lynch 24 Jul '09

24 Jul '09

All - Forwarded with permission. I think that Jonathan was actually commenting on two aspects that make the Internet model unique, one of which is the innovative nature of peering relationships and the second is the sense of a shared interest in the health and safety of global routing which is reflected in responses to network issues. NANOG is a part of both these forms of "goodness". - Lucy ---------- Forwarded message ---------- Date: Fri, 24 Jul 2009 09:54:39 -0400 From: Jonathan Zittrain <zittrain(a)law.harvard.edu> To: lynch(a)isoc.org Subject: Re: 5 forwarded messages... Lucy, Thanks for forwarding. It's not easy to compress the details of Internet routing (including BGP) into a short talk for laypeople, and going from that to a news article is even more lossy. Here's the context in which I brought it up: the Internet is not the only way to build a global data network, and its differences from other models, literal and metaphorical, are notable. The protocols themselves were in large part developed without the standard attempts to profit from them -- a case of the "patent that never was," as some have also called the Web. The daisy chains (daisy webs?) of routing are not, to me, functionally equivalent to the transitivity of contracts that make the international postal system flow, because of the ways in which new ISPs and ASNs can come and go, and overlap one another. There is a generativity to the network that has allowed for the kinds of innovation that simply haven't happened in more closed (and, some would say, rational) means of networking. I'm sure my view here is colored by my longtime experience with CompuServe, and the near-universal view I perceived among its engineers and sysops in the mid-80's that tomorrow's global network would be the winner of the grudge match among them, the Source, Prodigy, AOL, etc., not the backwater Internet. On the "volunteer" label -- I did not mean that members of NANOG (or the broader network community) are unemployed, or even employed only in unrelated fields. Instead, I wanted to say that when an incident like the YouTube/Pakistan situation comes up, there are people working together to solve it who don't owe YouTube a thing, and that aside from (re-)advertising its own equally or more specific route to itself, YouTube was not particularly privileged to fix the blackholing. It required people to help each other sort out the competing claims, and then favor YouTube's claim over that of AS17557. So, as I understand it, current routing implementations entail certain systemic vulnerabilities for which the YouTube incident is a good example, and when risks materialize they're dealt with in a kind of ad hoc fashion that relies on a lot of cooperation, and not necessarily among contracting parties. I see similarities to the ways Wikipedia governance works, but that's probably flamebait for another time. Anyway, as the clueless country lawyer, I'm anxious to know what I'm missing or getting wrong or imprecise. Best, JZ At GMT-4 09:06 AM 7/24/2009, you wrote: > Jonathan - > > As I mentioned earlier, it looks like the BBC managed to > mangle your point about transit relationships fairly > thoroughly. I think Patrick caught your quote, but the > gist of your point has been lost. > > > Lucy Lynch > Director, Trust and Identity Initiatives > Internet Society (ISOC ) > > ---------- Forwarded message ---------- > Date: Wed, 22 Jul 2009 20:44:21 -0400 > From: Patrick W. Gilmore <patrick(a)ianai.net> > To: NANOG list <nanog(a)nanog.org> > Subject: Re: Nanog mentioned on BBC news website > > On Jul 22, 2009, at 7:41 PM, Kevin Oberman wrote: > >>> Date: Wed, 22 Jul 2009 21:27:39 +0100 >>> From: "andrew.wallace" <andrew.wallace(a)rocketmail.com> >>> Big up the Nanog community, you do the net proud... >>> http://news.bbc.co.uk/1/hi/technology/8163190.stm >> First showed up on NANOG 7 hours ago, but it was a fun read. >> Clearly the article has little connection with reality. I am not an >> unpaid volunteer and neither were most or all of those involved. The >> idea that just because the traffic does not originate or terminate on my >> net means that working on solving a problem is altruism is pretty silly. > > My fav part: > > <quote> > "That's precisely how packets move around the internet, sometimes in a many > as 25 or 30 hops with the intervening entities passing the data around having > no contractual or legal obligation to the original sender or to the > receiver." > </quote> > > How many of you pass packets without getting paid? > > Kinda makes you wonder about all those other TED talks, huh? > > >> And NANOG was not really involved though several of those that were are >> active in NANOG. > > Well, one could argue that NANOG _is_ its members. > > Yeah, a stretch, but I'm trying. :-) > > -- > TTFN, > patrick > > > > > ---------- Forwarded message ---------- > Date: Thu, 23 Jul 2009 14:56:36 -0400 > From: Deepak Jain <deepak(a)ai.net> > To: Jim Mercer <jim(a)reptiles.org>, Patrick W. Gilmore <patrick(a)ianai.net> > Cc: NANOG list <nanog(a)nanog.org> > Subject: RE: Nanog mentioned on BBC news website > >> in the case of intervening entities, it is true that they have no link >> to >> the sender or receiver. my packets from office to home can traverse at >> 3 >> or more networks that are not paid by me, or my company. >> >> they likely have contracts or obligations with their immediate >> neighbours, >> which is basically why the system continues to work. > > I'm not sure if this is the benefit for the lurkers or the old guys, or will > eventually get recycled in the press and give me a headache, but here goes. > > I think what people seem to keep skipping over is the concept that packets > generated from "A" go to ISP "B" who has relationship with C... to pass > packets to "Z". From the point of view of "C" all packets from "B" (including > "A") are just "B"'s traffic. It's not as simple as I have an agreement with > my neighbor and we pass slop around. > > If I am "C", whatever my neighbor is moving is essentially of equal value in > my agreement with my neighbor (until one of us chooses to renegotiate it: > i.e. peering dispute, whatever). No matter which "A" is sending it to "B". I > don't *really* get the option to pick and choose on a per packet basis. > > In the case of three intervening networks, each is aggregating their > customers' traffic and passing the relevant portions to the neighboring > network (presumably for *their* aggregated customers' traffic). > > This is, in some ways, fundamentally different than the US highway system, > where if I'm driving a truck between one state and another, the next state > (even though they have interconnection agreements) can set different rules on > me than the state I just left. I know this happens with (for example) > Michigan and its neighbors. > > In the Internet context, my neighbor is responsible to abide by our agreement > and prevent the traffic coming over to me from violating that agreement and I > am allowed to police and enforce that border any way I want. > > What this means is that if "A" is affected by something, from my perspective > as "C", "B" is absolutely authoritative for the discussion about "A"'s > traffic and what to do with it. (No matter how many "B"'s A has contracted > with, B and C do not have to ask A for permission for ways/means/methods to > move packets). We can agree to drop it on the floor, give it priority or > special treatment or generally just ignore it and let the packets pass the > way they will. > > This how the so-called community "volunteers" have so much ability to affect > and improve the system. Everyone operates in their own fiefdom owing little > allegiance (other than those of commerce and equity) to its neighbors. I may > charge a tariff to enter my fiefdom, but once packets enter my fiefdom, they > are my packets. I protect them, and try to speed them on their way without > impediment and I negotiate with others on their behalf to improve their > happiness. > > And continuing the micro-economics analogy... this is why periodic wars break > out between larger fiefdoms and there is little way to influence them to play > for the "good" of the system. The only way to influence them is for their own > good. > > DJ > > P.S. I've been scratching my head and wondering what this TED thing is all > about, it seems like a big cheerleading thing.. > > > > > > ---------- Forwarded message ---------- > Date: Thu, 23 Jul 2009 16:38:24 -0400 > From: William Herrin <herrin-nanog(a)dirtside.com> > To: Jim Mercer <jim(a)reptiles.org> > Cc: NANOG list <nanog(a)nanog.org> > Subject: Re: Nanog mentioned on BBC news website > > On Thu, Jul 23, 2009 at 7:27 AM, Jim Mercer<jim(a)reptiles.org> wrote: >> On Wed, Jul 22, 2009 at 08:44:21PM -0400, Patrick W. Gilmore wrote: >>> My fav part: >>> <quote> >>> "That's precisely how packets move around the internet, sometimes in a >>> many as 25 or 30 hops with the intervening entities passing the data >>> around having no contractual or legal obligation to the original >>> sender or to the receiver." >>> </quote> >>> >>> How many of you pass packets without getting paid? >> >> in the case of intervening entities, it is true that they have no link to >> the sender or receiver. Â my packets from office to home can traverse at 3 >> or more networks that are not paid by me, or my company. > > If I pay you to send my packets and you pay bob to send my packets > then I have paid bob to send my packets. Transitive property of > payment. ;-) > > 'Couse bob doesn't pay claire anything but denise pays claire to > receive packets for denise, my packets are intended for denise and bob > and claire have a peering agreement in which they agree to swap > already-paid traffic directly rather than both paying ed to do it for > them. > > So it ain't free and at each step there is a contractual obligation to > at least one of the sender or receiver. > > Regards, > Bill > > -- > William D. Herrin ................ herrin(a)dirtside.com bill(a)herrin.us > 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> > Falls Church, VA 22042-3004 > > > > ---------- Forwarded message ---------- > Date: Thu, 23 Jul 2009 13:50:44 -0700 > From: Patrick W. Gilmore <patrick(a)ianai.net> > To: North American Operators' Group <nanog(a)nanog.org> > Subject: Re: Nanog mentioned on BBC news website > > > > Sent from my iPhone, please excuse any errors. > > > On Jul 23, 2009, at 4:27, Jim Mercer <jim(a)reptiles.org> wrote: > >> On Wed, Jul 22, 2009 at 08:44:21PM -0400, Patrick W. Gilmore wrote: >>> My fav part: >>> <quote> >>> "That's precisely how packets move around the internet, sometimes in a >>> many as 25 or 30 hops with the intervening entities passing the data >>> around having no contractual or legal obligation to the original >>> sender or to the receiver." >>> </quote> >>> How many of you pass packets without getting paid? >> in the case of intervening entities, it is true that they have no link to >> the sender or receiver. my packets from office to home can traverse at 3 >> or more networks that are not paid by me, or my company. >> they likely have contracts or obligations with their immediate neighbours, >> which is basically why the system continues to work. > > I honestly expected someone to mention this when I wrote the original post, > but I had hopes no one would. :-) > > It is clear the intent of the TED speaker was the intermediaries were > transiting packets out of the good of their hearts. > > Allow me to illustrate: > > The postal system is amazing! You can mail a letter from the US to England > and the "intermediate" carrier will deliver the mail even though they have NO > contract with you or the recipient! How awesome is that? > > This is not fantasy. You give it to the USPS, who will hand it to DHL, who > will hand it to Royal Mail, who will hand it to the recipient. Does _anyone_ > comment on the lack of your contract with DHL? Is anyone surprised it still > works? Is it worthy of a TED talk? > > -- > TTFN, > patrick > > > > ---------- Forwarded message ---------- > Date: Fri, 24 Jul 2009 07:27:30 +0300 > From: Raymond Macharia <rmacharia(a)gmail.com> > To: nanog(a)nanog.org > Subject: Re: Nanog mentioned on BBC news website > > Hi > To summarize the article "Nanogers you do a great job" > On the rest we can safely say we are probably more clueful as to what > goes on and we can try as much to correct but I doubt anyone will want > to put all the gory details in any form of press > > Raymond > > On 7/22/09, andrew.wallace <andrew.wallace(a)rocketmail.com> wrote: >> Big up the Nanog community, you do the net proud... >> >> http://news.bbc.co.uk/1/hi/technology/8163190.stm > > -- > Sent from my mobile device > > Raymond Macharia

1 0

Blocking IPv6 broadcast
by Sharef Mustafa 23 Jul '09

23 Jul '09

Hi, I have a customer connected to my Cisco 3560 switch via Gigabit Ethernet, recently I noticed that he is broadcasting IPv6 packets such as LLMNR, DHCPv6 and ICMPv6 it seems that the customer is connecting a Vista machine that has some IPv6 services enabled (some IPv6 services are enabled by default on Vista) How can I block such broadcast from entering my network? By the way there is no firewall in this setup, just a switch to switch. BR Sharef

2 1

RE: What else shall we test?
by Adrian Minta 23 Jul '09

23 Jul '09

I will sugest to test the throughput when a BGP peer is flapping. -----Original Message----- From: Michael J McCafferty <mike(a)m5computersecurity.com> Sent: 23 iulie 2009 03:05 To: nanog <nanog(a)nanog.org> Subject: What else shall we test? All, We are putting together a test plan to test a pair of Cisco 7206 VXR's, each with with NPE-G2. The purpose of the test is just to make sure we know where their realistic limits are with a real configuration, full route tables from two providers, etc. We have one JDSU T-Berd 8000 test system with interfaces and software to test a single stream through multi-mode fiber interfaces. We plan to test through the interfaces on the NPE and through PA-GE cards with a variety of packet sizes (especially 64 Byte). I'd be interested in any thoughts on additional testing or testing methodologies we might want to do, to help us set our expectations for this setup and to plan when we need to go bigger as we grow traffic, hosts, etc. We plan to get 1 to 3 additional full tables and peer with Any2 Easy on this network within the next year. We want to determine how this platform will behave under moderate DoS attacks, BGP updates, etc. Is there anything else we need to be mindful of? Can we get a realistic test of the routers with the T-Berd? What else should we test while we have the maintenance window and the test system on hand? Your thoughts and experience are appreciated! Thanks ! Mike -- ************************************************************ Michael J. McCafferty Principal, Security Engineer M5 Hosting http://www.m5hosting.com You can have your own custom Dedicated Server up and running today ! RedHat Enterprise, CentOS, Ubuntu, Debian, OpenBSD, FreeBSD, and more ************************************************************

1 0

What Platform for a small ISP (was: Cisco 7600 (7609) as a core BGP router)
by R. Benjamin Kessler 22 Jul '09

22 Jul '09

There has been a lot of good feedback regarding the deficiencies of the 7600 platform... So, the new question is: what platforms should a small, start-up ISP consider when looking to provide Ethernet services to their customers? - Scalability - 100M, 1G, 10G access speeds (backplane limitations, number of ports per chassis, etc.) - MPLS Capabilities - QoS Features - Ease of configuration and support, etc. (finding NOC talent, scripting tools, etc.) - Software/Hardware "stability" and "longevity" (we don't want something that is brand-new and therefore "buggy" nor do we want something that is going EOL next year) - Bang for the buck (both acquisition and on-going maintenance and support) I'm sure I'm missing a lot of things...are there any good presentations from previous NANOG meetings that one should review? Thanks in advance, Ben

5 5

What is good in modular routers these days?
by William Pitcock 22 Jul '09

22 Jul '09

Hi, I'm looking for a Cisco 2600-like platform, except with the capability of routing with gigabit and 10gigabit linecards (and not being EOL, of course). Ideally it would be capable of doing full BGP tables in the supervision engine, although that isn't necessarily a show stopper right now. Lack of IPv6 support, however, is. Does anyone even make standalone modular routers anymore? I don't need or want switching capabilities as seen on say a Cisco 6500 series platform, as my network topology would not benefit from that, and the cost overhead would probably not justify having it anyway. Right now we are using software routing appliances for this, but they do not tend to fare well in high packets/second scenarios (e.g. inbound DDoS attacks). William -- William Pitcock SystemInPlace - Simple Hosting Solutions 1-800-688-5018

19 25

Are you an "unpaid volunteer"?
by Graeme Fowler 22 Jul '09

22 Jul '09

http://news.bbc.co.uk/1/hi/business/8163190.stm Some of it is right. Some of it is wrong. All of it makes for interesting reading from the point of view of a layperson. We are all, apparently, unsung heroes... Graeme PS Yes, there's plenty to tear apart in the article. Don't shoot the messenger though!

2 1

Re: Opensource or Low Cost NMS for Server Hardware / ApplicationMonitoring
by Chaim Rieger 22 Jul '09

22 Jul '09

In that case might as well include Carp, vrrp, fping as well ------Original Message------ From: Roland Dobbins To: NANOG list Subject: Re: Opensource or Low Cost NMS for Server Hardware / ApplicationMonitoring Sent: Jul 21, 2009 21:42 On Jul 22, 2009, at 11:34 AM, Stefan wrote: > WebNM + Denika + Logalot - set of > tools<http://www.plixer.com/products/index.php> nfdump/nfsen, Stager, RANCID, RCS, CVS, or Subversion - these should all be included in any list of useful open-source tools for network operators, IMHO. ----------------------------------------------------------------------- Roland Dobbins <rdobbins(a)arbor.net> // <http://www.arbornetworks.com> Unfortunately, inefficiency scales really well. -- Kevin Lawton Sent via BlackBerry from T-Mobile

1 0

Cisco 7600 (7609) as a core BGP router.
by Jim Wininger 21 Jul '09

21 Jul '09

I have an opportuniy to put two 7609s into the core of my network. Currently we have 3 upstream providers, taking full BGP routes. (2 in one router and one in another). We have 17 BGP peers/customers (peering to each router), and adding about one new BGP peer every 2-3 months. It is a modest network by most standards. We are running OSPF and BGP between the existing routers. Not rocket science, nothing special (no MPLS, no VRF etc), very simple network. Does anyone have any recommendations on the 7600's as a core BGP router? Good or bad? Have they been a stable platform in a core/BGP environment? -- Jim Wininger

20 27

Re: Cisco 7600 (7609) as a core BGP router.
by Larry May 21 Jul '09

21 Jul '09

We purchased one 7609 for deployment of transit BGP...it doesn't come close to the performance of a GSR w/PRP2's. Extremely high CPU useage on the 7609 with each BGP session... But on the 6509's...it does fine... Larry May Network Services n|Frame 888-223-8633

1 0