- NANOG - lists.nanog.org

Weekly Routing Table Report
by Routing Analysis Role Account 19 Jul '13

19 Jul '13

This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats(a)lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith <pfsinoz(a)gmail.com>. Routing Table Report 04:00 +10GMT Sat 20 Jul, 2013 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 459588 Prefixes after maximum aggregation: 186889 Deaggregation factor: 2.46 Unique aggregates announced to Internet: 228557 Total ASes present in the Internet Routing Table: 44556 Prefixes per ASN: 10.31 Origin-only ASes present in the Internet Routing Table: 34873 Origin ASes announcing only one prefix: 16201 Transit ASes present in the Internet Routing Table: 5897 Transit-only ASes present in the Internet Routing Table: 150 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 29 Max AS path prepend of ASN ( 36992) 22 Prefixes from unregistered ASNs in the Routing Table: 3294 Unregistered ASNs in the Routing Table: 1332 Number of 32-bit ASNs allocated by the RIRs: 4887 Number of 32-bit ASNs visible in the Routing Table: 3786 Prefixes from 32-bit ASNs in the Routing Table: 11394 Special use prefixes present in the Routing Table: 27 Prefixes being announced from unallocated address space: 264 Number of addresses announced to Internet: 2630581868 Equivalent to 156 /8s, 203 /16s and 126 /24s Percentage of available address space announced: 71.1 Percentage of allocated address space announced: 71.1 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 94.7 Total number of prefixes smaller than registry allocations: 160716 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 110373 Total APNIC prefixes after maximum aggregation: 33801 APNIC Deaggregation factor: 3.27 Prefixes being announced from the APNIC address blocks: 112375 Unique aggregates announced from the APNIC address blocks: 46225 APNIC Region origin ASes present in the Internet Routing Table: 4855 APNIC Prefixes per ASN: 23.15 APNIC Region origin ASes announcing only one prefix: 1220 APNIC Region transit ASes present in the Internet Routing Table: 826 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 23 Number of APNIC region 32-bit ASNs visible in the Routing Table: 605 Number of APNIC addresses announced to Internet: 726149792 Equivalent to 43 /8s, 72 /16s and 42 /24s Percentage of available APNIC address space announced: 84.9 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-133119 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/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, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 159451 Total ARIN prefixes after maximum aggregation: 80739 ARIN Deaggregation factor: 1.97 Prefixes being announced from the ARIN address blocks: 160053 Unique aggregates announced from the ARIN address blocks: 74115 ARIN Region origin ASes present in the Internet Routing Table: 15795 ARIN Prefixes per ASN: 10.13 ARIN Region origin ASes announcing only one prefix: 6003 ARIN Region transit ASes present in the Internet Routing Table: 1653 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 27 Number of ARIN region 32-bit ASNs visible in the Routing Table: 19 Number of ARIN addresses announced to Internet: 1067944512 Equivalent to 63 /8s, 167 /16s and 138 /24s Percentage of available ARIN address space announced: 56.5 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, 62464-63487, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/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, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 118451 Total RIPE prefixes after maximum aggregation: 60254 RIPE Deaggregation factor: 1.97 Prefixes being announced from the RIPE address blocks: 121926 Unique aggregates announced from the RIPE address blocks: 78676 RIPE Region origin ASes present in the Internet Routing Table: 17315 RIPE Prefixes per ASN: 7.04 RIPE Region origin ASes announcing only one prefix: 8212 RIPE Region transit ASes present in the Internet Routing Table: 2835 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 29 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2376 Number of RIPE addresses announced to Internet: 656323556 Equivalent to 39 /8s, 30 /16s and 179 /24s Percentage of available RIPE address space announced: 95.4 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, 56320-58367 59392-61439, 196608-199679 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/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, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 48852 Total LACNIC prefixes after maximum aggregation: 9509 LACNIC Deaggregation factor: 5.14 Prefixes being announced from the LACNIC address blocks: 53365 Unique aggregates announced from the LACNIC address blocks: 25309 LACNIC Region origin ASes present in the Internet Routing Table: 1985 LACNIC Prefixes per ASN: 26.88 LACNIC Region origin ASes announcing only one prefix: 580 LACNIC Region transit ASes present in the Internet Routing Table: 363 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 29 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 780 Number of LACNIC addresses announced to Internet: 133371048 Equivalent to 7 /8s, 243 /16s and 20 /24s Percentage of available LACNIC address space announced: 79.5 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 262144-263679 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 10977 Total AfriNIC prefixes after maximum aggregation: 2546 AfriNIC Deaggregation factor: 4.31 Prefixes being announced from the AfriNIC address blocks: 11605 Unique aggregates announced from the AfriNIC address blocks: 3986 AfriNIC Region origin ASes present in the Internet Routing Table: 643 AfriNIC Prefixes per ASN: 18.05 AfriNIC Region origin ASes announcing only one prefix: 186 AfriNIC Region transit ASes present in the Internet Routing Table: 134 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 6 Number of AfriNIC addresses announced to Internet: 46422784 Equivalent to 2 /8s, 196 /16s and 91 /24s Percentage of available AfriNIC address space announced: 46.1 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2922 11560 918 Korea Telecom (KIX) 17974 2589 871 92 PT TELEKOMUNIKASI INDONESIA 7545 2030 320 108 TPG Internet Pty Ltd 4755 1757 391 192 TATA Communications formerly 9829 1536 1220 44 BSNL National Internet Backbo 9583 1221 92 505 Sify Limited 4808 1171 2152 336 CNCGROUP IP network: China169 9498 1161 309 71 BHARTI Airtel Ltd. 7552 1159 1080 13 Vietel Corporation 24560 1085 394 164 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 2986 3690 68 bellsouth.net, inc. 18566 2067 382 184 Covad Communications 1785 2001 678 126 PaeTec Communications, Inc. 22773 1996 2927 124 Cox Communications, Inc. 20115 1668 1622 620 Charter Communications 4323 1615 1118 404 Time Warner Telecom 701 1531 11127 797 UUNET Technologies, Inc. 30036 1345 304 660 Mediacom Communications Corp 7018 1299 11035 822 AT&T WorldNet Services 11492 1224 218 360 Cable One Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1579 544 16 Corbina telecom 2118 1385 97 13 EUnet/RELCOM Autonomous Syste 34984 1296 244 222 BILISIM TELEKOM 31148 973 43 21 FreeNet ISP 20940 927 319 728 Akamai Technologies European 13188 837 98 81 Educational Network 6830 807 2376 442 UPC Distribution Services 8551 780 370 45 Bezeq International 12479 675 789 57 Uni2 Autonomous System 34744 637 170 73 SC GVM SISTEM 2003 SRL Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 28573 2933 1589 109 NET Servicos de Comunicao S.A 10620 2653 419 229 TVCABLE BOGOTA 7303 1733 1155 222 Telecom Argentina Stet-France 8151 1269 2751 385 UniNet S.A. de C.V. 18881 1165 844 20 Global Village Telecom 27947 829 94 91 Telconet S.A 6503 819 434 63 AVANTEL, S.A. 3816 717 306 85 Empresa Nacional de Telecomun 7738 698 1370 35 Telecomunicacoes da Bahia S.A 11172 618 88 65 Servicios Alestra S.A de C.V Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 36998 1253 80 4 MOBITEL 24863 883 274 30 LINKdotNET AS number 6713 542 617 25 Itissalat Al-MAGHRIB 8452 438 956 9 TEDATA 24835 332 80 8 RAYA Telecom - Egypt 3741 259 922 218 The Internet Solution 29571 220 17 12 Ci Telecom Autonomous system 15706 219 32 6 Sudatel Internet Exchange Aut 36992 206 527 23 Etisalat MISR 12258 193 28 71 Vodacom Internet Company Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 2986 3690 68 bellsouth.net, inc. 28573 2933 1589 109 NET Servicos de Comunicao S.A 4766 2922 11560 918 Korea Telecom (KIX) 10620 2653 419 229 TVCABLE BOGOTA 17974 2589 871 92 PT TELEKOMUNIKASI INDONESIA 18566 2067 382 184 Covad Communications 7545 2030 320 108 TPG Internet Pty Ltd 1785 2001 678 126 PaeTec Communications, Inc. 22773 1996 2927 124 Cox Communications, Inc. 4755 1757 391 192 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 28573 2933 2824 NET Servicos de Comunicao S.A 17974 2589 2497 PT TELEKOMUNIKASI INDONESIA 10620 2653 2424 TVCABLE BOGOTA 4766 2922 2004 Korea Telecom (KIX) 7545 2030 1922 TPG Internet Pty Ltd 18566 2067 1883 Covad Communications 1785 2001 1875 PaeTec Communications, Inc. 22773 1996 1872 Cox Communications, Inc. 4755 1757 1565 TATA Communications formerly 8402 1579 1563 Corbina telecom Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 30031 UNALLOCATED 12.27.122.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 209 Qwest 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 14764 UNALLOCATED 12.108.237.0/24 7018 AT&T WorldNet Servic 33649 UNALLOCATED 12.111.112.0/24 19029 New Edge Networks 30621 UNALLOCATED 12.151.74.0/23 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.0.0/24 2541 >>UNKNOWN<< 128.0.16.0/21 43568 RIPE Network Coordination Cen 128.0.24.0/21 41794 Altline LLC 128.0.42.0/24 60619 >>UNKNOWN<< 128.0.43.0/24 60619 >>UNKNOWN<< 128.0.46.0/23 39743 Mobimax Telecom SRL 128.0.53.0/24 60993 Totalsoft SA 128.0.54.0/24 60972 Carpatair SA 128.0.55.0/24 48571 SC efectRO SRL 128.0.56.0/24 60996 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.200.128.0/17 59628 Telecommunications Company of 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 64.185.224.0/24 27431 JTL Networks Inc. 64.185.225.0/24 27431 JTL Networks Inc. 64.185.226.0/24 27431 JTL Networks Inc. 64.185.227.0/24 27431 JTL Networks Inc. 64.185.228.0/24 27431 JTL Networks Inc. 64.185.229.0/24 27431 JTL Networks Inc. 64.185.230.0/24 27431 JTL Networks Inc. Complete listing at http://thyme.rand.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:16 /9:11 /10:30 /11:92 /12:251 /13:479 /14:905 /15:1604 /16:12704 /17:6645 /18:11085 /19:22460 /20:32118 /21:34588 /22:48452 /23:42430 /24:241814 /25:1289 /26:1629 /27:837 /28:43 /29:69 /30:19 /31:0 /32:18 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2018 2067 Covad Communications 6389 1715 2986 bellsouth.net, inc. 22773 1298 1996 Cox Communications, Inc. 8402 1274 1579 Corbina telecom 36998 1221 1253 MOBITEL 30036 1212 1345 Mediacom Communications Corp 11492 1185 1224 Cable One 1785 1070 2001 PaeTec Communications, Inc. 6983 1021 1148 ITC^Deltacom 10620 980 2653 TVCABLE BOGOTA Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:819 2:727 3:3 4:19 5:832 6:16 8:572 12:1920 13:2 14:864 15:11 16:3 17:10 20:17 23:296 24:1770 27:1499 31:1314 32:45 33:2 34:5 36:59 37:1886 38:884 39:2 40:175 41:2776 42:235 44:8 46:1954 47:2 49:671 50:775 52:12 54:34 55:8 57:26 58:1162 59:582 60:328 61:1420 62:1155 63:2015 64:4348 65:2148 66:4180 67:2014 68:1088 69:3278 70:796 71:489 72:1914 74:2481 75:324 76:307 77:1140 78:957 79:609 80:1290 81:1007 82:635 83:579 84:581 85:1206 86:465 87:1020 88:546 89:1812 90:150 91:5538 92:620 93:1770 94:1939 95:1688 96:520 97:343 98:1027 99:43 100:30 101:585 103:2963 105:519 106:139 107:208 108:516 109:1865 110:927 111:1069 112:550 113:819 114:698 115:1000 116:962 117:834 118:1131 119:1307 120:390 121:737 122:1808 123:1236 124:1376 125:1387 128:636 129:224 130:309 131:671 132:360 133:155 134:268 135:68 136:257 137:242 138:340 139:193 140:202 141:328 142:548 143:380 144:513 145:98 146:529 147:403 148:665 149:352 150:148 151:551 152:414 153:189 154:28 155:405 156:266 157:388 158:278 159:742 160:346 161:449 162:478 163:226 164:581 165:504 166:253 167:599 168:1030 169:128 170:1065 171:182 172:23 173:1595 174:544 175:494 176:1119 177:2122 178:1873 179:65 180:1473 181:549 182:1263 183:425 184:673 185:656 186:2327 187:1318 188:1909 189:1316 190:6745 192:6857 193:5859 194:4696 195:3544 196:1346 197:890 198:4541 199:5363 200:6007 201:2213 202:8840 203:8891 204:4504 205:2595 206:2866 207:2853 208:4013 209:3581 210:2913 211:1519 212:2200 213:2008 214:922 215:99 216:5255 217:1615 218:616 219:312 220:1276 221:556 222:321 223:440 End of report

1 0

AOL Postmaster
by John Zettlemoyer 19 Jul '13

19 Jul '13

Could someone from the AOL mail group (AOL Postmaster) please contact me off list. Thank you. John Zettlemoyer Sr. Director of I.T. Infrastructure WCiT - West-Canaan LLC john(a)wcit.net

1 0

Re: Friday Hosing
by Bryan Fields 18 Jul '13

18 Jul '13

On 7/12/13 1:39 PM, Patrick W. Gilmore wrote: > Put another way, whether it was stupid or evil, the results are the same. Turning off a customer in good standing is actionable in court, and should be avoided by legitimate businesses at nearly all costs. You can void a contract at any time so long as you're willing to accept the result. I've seen people have their service cut off and a carrier keep their equipment. Sure they will get it back, but is it worth spending 100k fighting them in court for three years? -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

15 18

fbi.gov hostmaster contact?
by Ray Van Dolson 17 Jul '13

17 Jul '13

Looking for a DNS/hostmaster contact for fbi.gov for troubleshooting a DNSSEC issue[1]. Have tried the usual hostmaster alias with no luck. Thanks, Ray [1] https://lists.isc.org/pipermail/bind-users/2013-July/091142.html

1 0

tools and techniques to pinpoint and respond to loss on a path
by Andy Litzinger 17 Jul '13

17 Jul '13

Hi, Does anyone have any recommendations on how to pinpoint and react to packet loss across the internet? preferably in an automated fashion. For detection I'm currently looking at trying smoketrace to run from inside my network, but I'd love to be able to run traceroutes from my edge routers triggered during periods of loss. I have Juniper MX80s on one end- which I'm hopeful I'll be able to cobble together some combo of RPM and event scripting to kick off a traceroute. We have Cisco4900Ms on the other end and maybe the same thing is possible but I'm not so sure. I'd love to hear other suggestions and experience for detection and also for options on what I might be able to do when loss is detected on a path. In my specific situation I control equipment on both ends of the path that I care about with details below. we are a hosted service company and we currently have two data centers, DC A and DC B. DC A uses juniper MX routers, advertises our own IP space and takes full BGP feeds from two providers, ISPs A1 and A2. At DC B we have a smaller installation and instead take redundant drops (and IP space) from a single provider, ISP B1, who then peers upstream with two providers, B2 and B3 We have a fairly consistent bi-directional stream of traffic between DC A and DC B. Both of ISP A1 and A2 have good peering with ISP B2 so under normal network conditions traffic flows across ISP B1 to B2 and then to either ISP A1 or A2 oversimplified ascii pic showing only the normal best paths: -- ISP A1----------------------ISP B2-- DC A--| |--- ISP B1 ----- DC B -- ISP A2----------------------ISP B2-- with increasing frequency we've been experiencing packet loss along the path from DC A to DC B. Usually the periods of loss are brief, 30 seconds to a minute, but they are total blackouts. I'd like to be able to collect enough relevant data to pinpoint the trouble spot as much as possible so I can take it to the ISPs and request a solution. The blackouts are so quick that it's impossible to log in and get a trace- hence the desire to automate it. I can provide more details off list if helpful- I'm trying not to vilify anyone- especially without copious amounts of data points. As a side question, what should my expectation be regarding packet loss when sending packets from point A to point B across multiple providers across the internet? Is 30 seconds to a minute of blackout between two destinations every couple of weeks par for the course? My directly connected ISPs offer me an SLA, but what should I reasonably expect from them when one of their upstream peers (or a peer of their peers) has issues? If this turns out to be BGP reconvergence or similar do I have any options? many thanks, -andy

6 5

RE: Office 365..? how Microsoft handed the NSA access to encrypted messages
by Scott Weeks 16 Jul '13

16 Jul '13

--- rwebb(a)ropeguru.com wrote: From: Robert Webb <rwebb(a)ropeguru.com> At least there are some that try and take a stand for their customer and not just hand over the keys to the palace when the good ole boys ask. ----------------------- Like web search engine startpage.com scott

3 2

The 4th Global IPv6 Deployment Monitoring Survey is underway!
by John Curran 16 Jul '13

16 Jul '13

NANOGers - If you have a moment, it would be helpful if you could complete the 4th annual Global IPv6 Deployment Monitoring Survey. Completion only takes a few minutes, and the data from the survey is useful in tracking progress and hurdles in IPv6 deployment. Thanks! /John John Curran President and CEO ARIN Begin forwarded message: From: ARIN <info(a)arin.net<mailto:info@arin.net>> Subject: [arin-announce] The 4th Global IPv6 Deployment Monitoring Survey is Open Now Date: July 1, 2013 8:00:32 AM EDT To: <arin-announce(a)arin.net<mailto:arin-announce@arin.net>> Dear Community, As in previous years, the Number Resource Organization (NRO) invites you to participate in the 4th consecutive Global IPv6 Deployment Monitoring Survey on the current and future use of IPv6. The IPv6 Deployment Monitoring Survey is now online, and we encourage all members of our community to participate: https://www.surveymonkey.com/s/GlobalIPv6survey2013 The purpose of the survey is to better understand where the Internet community is going, and what can be done to ensure it is ready for the widespread adoption of IPv6. We hope this survey will establish a comprehensive view of current IPv6 penetration and future deployment plans for IPv6. This year's survey is similar to those conducted in previous years (2010, 2011 and 2012), and will enable a comparison of progress. What is clear is that community participation does contribute to a better understanding of how IPv6 is being used. In 2012, 91% of the over 1,500 respondents indicated that they were interested in participating again in the 2013 survey. This survey has a maximum of 30 questions and will take about 20 minutes to complete. For those without IPv6 allocations or assignments, or have not yet deployed IPv6, the questions will be fewer in number. The survey will be open for a month and will close on 31 July 2013. Results of the IPv6 Deployment Monitoring Survey will be presented and discussed widely, with the support of your Regional Internet Registry (RIR). We appreciate your time and interest in completing this survey. If you have any questions concerning the survey, please send an email to info(a)gnksconsult.com. Regards, Susan Hamlin Director, Communications and Member Services American Registry for Internet Numbers (ARIN) _______________________________________________ ARIN-Announce You are receiving this message because you are subscribed to the ARIN Announce Mailing List (ARIN-announce(a)arin.net) Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-announce Please contact info(a)arin.net if you experience any issues.

1 0

RE: tools and techniques to pinpoint and respond to loss on a path
by Andy Litzinger 16 Jul '13

16 Jul '13

> From: Blake Dunlap [mailto:ikiris@gmail.com] > While any provider will attempt to fix peer / upstream issues as they can, any > SLA you would have is between two points on their private network, not > from point A to point Z that they have no control over across multiple peers > and the public internet itself. makes sense- thanks for confirming > The much more common design is using a single > provider for each thread between sites. Then at least you have an end-to- > end SLA in effect, as well as a single entity that is responsible for the entire > link in question. > > This sounds like you're trying to achieve private link IGP / FRR level site to site > failover/convergence across the public internet. Perhaps you should rethink > your goals here or your design? Kind of- I can actually tolerate the blips, but I want to be able to measure and track them in such a way that I know where the loss is occurring. If a particular path is reconverging more often than should be reasonably expected I want to be able to prove it within reason. We also have a customer who happens to host at DC B with the same connectivity. Every time there is one of these blips their alerting fires off a thousand messages and they open a ticket with us. I'd like to be able to show them some good data on the path during the blip so we back a discussion along the lines of "live with it, or pay to privately connect to us". -andy > -Blake > > On Mon, Jul 15, 2013 at 4:18 PM, Andy Litzinger > <Andy.Litzinger(a)theplatform.com> wrote: > Hi, > > Does anyone have any recommendations on how to pinpoint and react to > packet loss across the internet? preferably in an automated fashion. For > detection I'm currently looking at trying smoketrace to run from inside my > network, but I'd love to be able to run traceroutes from my edge routers > triggered during periods of loss. I have Juniper MX80s on one end- which I'm > hopeful I'll be able to cobble together some combo of RPM and event > scripting to kick off a traceroute. We have Cisco4900Ms on the other end and > maybe the same thing is possible but I'm not so sure. > > I'd love to hear other suggestions and experience for detection and also for > options on what I might be able to do when loss is detected on a path. > > In my specific situation I control equipment on both ends of the path that I > care about with details below. > > we are a hosted service company and we currently have two data centers, > DC A and DC B. DC A uses juniper MX routers, advertises our own IP space > and takes full BGP feeds from two providers, ISPs A1 and A2. At DC B we > have a smaller installation and instead take redundant drops (and IP space) > from a single provider, ISP B1, who then peers upstream with two providers, > B2 and B3 > > We have a fairly consistent bi-directional stream of traffic between DC A and > DC B. Both of ISP A1 and A2 have good peering with ISP B2 so under normal > network conditions traffic flows across ISP B1 to B2 and then to either ISP A1 > or A2 > > oversimplified ascii pic showing only the normal best paths: > > -- ISP A1----------------------ISP B2-- DC A-- > | |--- ISP B1 ----- DC B > -- ISP A2----------------------ISP B2-- > > > with increasing frequency we've been experiencing packet loss along the > path from DC A to DC B. Usually the periods of loss are brief, 30 seconds to a > minute, but they are total blackouts. > > I'd like to be able to collect enough relevant data to pinpoint the trouble > spot as much as possible so I can take it to the ISPs and request a > solution. The blackouts are so quick that it's impossible to log in and get a > trace- hence the desire to automate it. > > I can provide more details off list if helpful- I'm trying not to vilify anyone- > especially without copious amounts of data points. > > As a side question, what should my expectation be regarding packet loss > when sending packets from point A to point B across multiple providers > across the internet? Is 30 seconds to a minute of blackout between two > destinations every couple of weeks par for the course? My directly > connected ISPs offer me an SLA, but what should I reasonably expect from > them when one of their upstream peers (or a peer of their peers) has > issues? If this turns out to be BGP reconvergence or similar do I have any > options? > > many thanks, > -andy

1 0

Secure Tunneling. Only with more Control!!!
by Nick Khamis 16 Jul '13

16 Jul '13

Not having to hijack http://seclists.org/nanog/2013/Jul/251, and without further ado, On 7/12/13, ryangard(a)gmail.com <ryangard(a)gmail.com> wrote: > It wouldn't be. When the endpoint in question is compromised, there isn't > any amount of tunneling or obscurity between point a and point b that will > resolve it. Only thing you can do is change to a solution that you have more > control over. > Sent on the TELUS Mobility network with BlackBerry This just got very interesting. Given that we do not own any Microsoft products here, and still able to function like any other corporation, I am more interested in a "solution that you have more control over" secured connections. We currently are using OpenVPN and PKI, coupled with a company policy of key updates every 3 months this will only get incrementally more complex as the number of clients increase. Not to mention one only needs a 3 minutes.... Question: What other options do we have to maintain a secure connection between client and server that gives us more control over traditional OpenVPN+PKI. It would be nice to be able to deploy private keys automatically to the different clients however, seems like a disaster waiting to happen. I would really appreciate some of your takes on this matter, what types of technology, policies are being employed out there for secure connections. Kind Regards, Nick.

2 1

One of our own in the Guardian.
by Bill Woodcock 15 Jul '13

15 Jul '13

http://www.guardian.co.uk/world/2013/jul/09/xmission-isp-customers-privacy-… -Bill

20 32