- NANOG - lists.nanog.org

Weekly Routing Table Report
by Routing Analysis Role Account 01 Jul '11

01 Jul '11

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, 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 02 Jul, 2011 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 362404 Prefixes after maximum aggregation: 164721 Deaggregation factor: 2.20 Unique aggregates announced to Internet: 179786 Total ASes present in the Internet Routing Table: 38071 Prefixes per ASN: 9.52 Origin-only ASes present in the Internet Routing Table: 31670 Origin ASes announcing only one prefix: 15223 Transit ASes present in the Internet Routing Table: 5179 Transit-only ASes present in the Internet Routing Table: 136 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 33 Max AS path prepend of ASN (22394) 27 Prefixes from unregistered ASNs in the Routing Table: 877 Unregistered ASNs in the Routing Table: 484 Number of 32-bit ASNs allocated by the RIRs: 1514 Number of 32-bit ASNs visible in the Routing Table: 1222 Prefixes from 32-bit ASNs in the Routing Table: 2774 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 134 Number of addresses announced to Internet: 2492654912 Equivalent to 148 /8s, 146 /16s and 229 /24s Percentage of available address space announced: 67.3 Percentage of allocated address space announced: 67.3 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 91.0 Total number of prefixes smaller than registry allocations: 151058 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 90072 Total APNIC prefixes after maximum aggregation: 30234 APNIC Deaggregation factor: 2.98 Prefixes being announced from the APNIC address blocks: 86827 Unique aggregates announced from the APNIC address blocks: 37040 APNIC Region origin ASes present in the Internet Routing Table: 4494 APNIC Prefixes per ASN: 19.32 APNIC Region origin ASes announcing only one prefix: 1243 APNIC Region transit ASes present in the Internet Routing Table: 708 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 18 Number of APNIC region 32-bit ASNs visible in the Routing Table: 53 Number of APNIC addresses announced to Internet: 621139616 Equivalent to 37 /8s, 5 /16s and 214 /24s Percentage of available APNIC address space announced: 78.8 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 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, 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: 141388 Total ARIN prefixes after maximum aggregation: 72780 ARIN Deaggregation factor: 1.94 Prefixes being announced from the ARIN address blocks: 113365 Unique aggregates announced from the ARIN address blocks: 46607 ARIN Region origin ASes present in the Internet Routing Table: 14460 ARIN Prefixes per ASN: 7.84 ARIN Region origin ASes announcing only one prefix: 5524 ARIN Region transit ASes present in the Internet Routing Table: 1519 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 30 Number of ARIN region 32-bit ASNs visible in the Routing Table: 13 Number of ARIN addresses announced to Internet: 819612288 Equivalent to 48 /8s, 218 /16s and 74 /24s Percentage of available ARIN address space announced: 65.1 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, 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, 173/8, 174/8, 184/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: 86326 Total RIPE prefixes after maximum aggregation: 49069 RIPE Deaggregation factor: 1.76 Prefixes being announced from the RIPE address blocks: 79752 Unique aggregates announced from the RIPE address blocks: 52675 RIPE Region origin ASes present in the Internet Routing Table: 15768 RIPE Prefixes per ASN: 5.06 RIPE Region origin ASes announcing only one prefix: 7871 RIPE Region transit ASes present in the Internet Routing Table: 2503 Average RIPE Region AS path length visible: 4.6 Max RIPE Region AS path length visible: 33 Number of RIPE region 32-bit ASNs visible in the Routing Table: 899 Number of RIPE addresses announced to Internet: 478628096 Equivalent to 28 /8s, 135 /16s and 73 /24s Percentage of available RIPE address space announced: 77.1 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 196608-198655 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, 176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 33414 Total LACNIC prefixes after maximum aggregation: 7555 LACNIC Deaggregation factor: 4.42 Prefixes being announced from the LACNIC address blocks: 32490 Unique aggregates announced from the LACNIC address blocks: 16972 LACNIC Region origin ASes present in the Internet Routing Table: 1473 LACNIC Prefixes per ASN: 22.06 LACNIC Region origin ASes announcing only one prefix: 440 LACNIC Region transit ASes present in the Internet Routing Table: 272 Average LACNIC Region AS path length visible: 4.4 Max LACNIC Region AS path length visible: 19 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 253 Number of LACNIC addresses announced to Internet: 85702656 Equivalent to 5 /8s, 27 /16s and 184 /24s Percentage of available LACNIC address space announced: 56.8 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 8217 Total AfriNIC prefixes after maximum aggregation: 1963 AfriNIC Deaggregation factor: 4.19 Prefixes being announced from the AfriNIC address blocks: 6492 Unique aggregates announced from the AfriNIC address blocks: 1972 AfriNIC Region origin ASes present in the Internet Routing Table: 466 AfriNIC Prefixes per ASN: 13.93 AfriNIC Region origin ASes announcing only one prefix: 145 AfriNIC Region transit ASes present in the Internet Routing Table: 103 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 4 Number of AfriNIC addresses announced to Internet: 24304128 Equivalent to 1 /8s, 114 /16s and 218 /24s Percentage of available AfriNIC address space announced: 36.2 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2460 9500 928 Korea Telecom (KIX) 17974 1835 461 42 PT TELEKOMUNIKASI INDONESIA 7545 1543 301 85 TPG Internet Pty Ltd 4755 1476 627 162 TATA Communications formerly 24560 1153 336 187 Bharti Airtel Ltd., Telemedia 9829 1098 914 45 BSNL National Internet Backbo 9583 1056 78 506 Sify Limited 4808 1050 2091 298 CNCGROUP IP network: China169 17488 960 186 103 Hathway IP Over Cable Interne 18101 932 116 139 Reliance Infocom Ltd Internet 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 3619 3819 245 bellsouth.net, inc. 18566 1913 365 241 Covad Communications 1785 1802 681 122 PaeTec Communications, Inc. 4323 1660 1082 399 Time Warner Telecom 20115 1589 1532 635 Charter Communications 19262 1450 4806 370 Verizon Global Networks 7018 1361 7053 887 AT&T WorldNet Services 22773 1347 2897 87 Cox Communications, Inc. 6478 1338 248 613 AT&T Worldnet Services 7029 1285 790 298 Windstream Communications Inc 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 34984 535 106 185 BILISIM TELEKOM 6830 513 1780 318 UPC Distribution Services 3292 469 2080 404 TDC Tele Danmark 20940 467 137 360 Akamai Technologies European 8866 451 134 26 Bulgarian Telecommunication C 29049 440 33 45 AzerSat LLC. 12479 438 593 7 Uni2 Autonomous System 3320 420 8151 367 Deutsche Telekom AG 8551 404 354 44 Bezeq International 702 396 1803 310 UUNET - Commercial IP service 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 10620 1541 282 157 TVCABLE BOGOTA 8151 1424 2742 356 UniNet S.A. de C.V. 28573 1271 996 80 NET Servicos de Comunicao S.A 7303 1000 507 175 Telecom Argentina Stet-France 6503 747 354 74 AVANTEL, S.A. 14420 685 55 81 CORPORACION NACIONAL DE TELEC 22047 576 322 17 VTR PUNTO NET S.A. 3816 535 232 92 Empresa Nacional de Telecomun 7738 516 986 31 Telecomunicacoes da Bahia S.A 27947 505 53 53 Telconet S.A 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 8452 792 445 11 TEDATA 24863 789 147 37 LINKdotNET AS number 15475 524 74 8 Nile Online 36992 315 415 14 Etisalat MISR 3741 261 937 223 The Internet Solution 6713 241 215 13 Itissalat Al-MAGHRIB 24835 211 78 10 RAYA Telecom - Egypt 33776 210 12 8 Starcomms Nigeria Limited 29571 192 17 11 Ci Telecom Autonomous system 16637 149 441 86 MTN Network Solutions 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 3619 3819 245 bellsouth.net, inc. 23456 2774 692 1512 32-bit ASN transition 4766 2460 9500 928 Korea Telecom (KIX) 18566 1913 365 241 Covad Communications 17974 1835 461 42 PT TELEKOMUNIKASI INDONESIA 1785 1802 681 122 PaeTec Communications, Inc. 4323 1660 1082 399 Time Warner Telecom 20115 1589 1532 635 Charter Communications 7545 1543 301 85 TPG Internet Pty Ltd 10620 1541 282 157 TVCABLE BOGOTA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 17974 1835 1793 PT TELEKOMUNIKASI INDONESIA 1785 1802 1680 PaeTec Communications, Inc. 18566 1913 1672 Covad Communications 4766 2460 1532 Korea Telecom (KIX) 7545 1543 1458 TPG Internet Pty Ltd 10620 1541 1384 TVCABLE BOGOTA 4755 1476 1314 TATA Communications formerly 23456 2774 1262 32-bit ASN transition 4323 1660 1261 Time Warner Telecom 22773 1347 1260 Cox Communications, Inc. 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 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 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.155.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.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 Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.225.128.0/18 36377 Comcast Telecommunications, I 24.225.192.0/23 36377 Comcast Telecommunications, I 24.225.192.0/18 36377 Comcast Telecommunications, I 24.225.224.0/21 36377 Comcast Telecommunications, I 24.225.237.0/24 36377 Comcast Telecommunications, I 24.225.248.0/21 36377 Comcast Telecommunications, I 27.0.128.0/17 7514 Media Exchange, Inc. 31.135.216.0/21 51388 UAB Marsatas 41.190.32.0/23 31856 CABSAS 41.190.34.0/23 31856 CABSAS 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:22 /9:12 /10:28 /11:81 /12:231 /13:461 /14:801 /15:1396 /16:11983 /17:5875 /18:9808 /19:19455 /20:25864 /21:26151 /22:34633 /23:33577 /24:188712 /25:1089 /26:1268 /27:740 /28:200 /29:9 /30:2 /31:0 /32:6 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2227 3619 bellsouth.net, inc. 18566 1869 1913 Covad Communications 10620 1436 1541 TVCABLE BOGOTA 23456 1369 2774 32-bit ASN transition 6478 1309 1338 AT&T Worldnet Services 11492 1090 1136 Cable One 7011 1055 1156 Citizens Utilities 1785 1052 1802 PaeTec Communications, Inc. 7029 1032 1285 Windstream Communications Inc 22773 862 1347 Cox Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:319 2:47 4:16 5:1 6:3 8:337 12:1976 13:1 14:472 15:15 16:3 17:8 20:10 23:13 24:1657 27:788 31:488 32:64 33:4 34:2 36:4 37:1 38:741 39:3 40:103 41:2550 42:23 44:3 46:992 47:3 49:196 50:431 52:13 54:2 55:4 56:2 57:33 58:859 59:476 60:386 61:1173 62:1048 63:1936 64:3947 65:2293 66:3875 67:1900 68:1095 69:3026 70:758 71:389 72:1890 74:2380 75:313 76:341 77:885 78:712 79:461 80:1118 81:844 82:501 83:457 84:686 85:1080 86:552 87:759 88:334 89:1532 90:211 91:3917 92:537 93:1053 94:1319 95:853 96:446 97:254 98:890 99:36 101:77 103:100 106:10 107:19 108:71 109:1019 110:608 111:712 112:304 113:407 114:544 115:669 116:969 117:668 118:854 119:1155 120:308 121:669 122:1612 123:969 124:1298 125:1236 128:246 129:173 130:168 131:564 132:112 133:21 134:213 135:48 136:215 137:136 138:298 139:115 140:474 141:241 142:403 143:416 144:481 145:54 146:448 147:213 148:659 149:247 150:163 151:190 152:330 153:180 154:4 155:399 156:199 157:351 158:138 159:452 160:314 161:211 162:309 163:164 164:510 165:354 166:529 167:432 168:737 169:158 170:847 171:78 172:1 173:1635 174:615 175:377 176:141 177:134 178:990 180:878 181:21 182:485 183:219 184:313 185:1 186:1253 187:733 188:872 189:944 190:4928 192:5894 193:4972 194:3495 195:3027 196:1224 197:41 198:3564 199:3959 200:5519 201:1513 202:8394 203:8418 204:4222 205:2347 206:2678 207:2812 208:3962 209:3460 210:2693 211:1455 212:2103 213:1743 214:770 215:70 216:4929 217:1644 218:544 219:361 220:1204 221:492 222:361 223:180 End of report

1 0

RIP RM
by Jay Ashworth 30 Jun '11

30 Jun '11

Robert Morris, NSA crypto maven and Unix co-developer, has died at 78 of 'complications of dementia'. Unix haters will probably say 'atojiso'; Barrett Hansen will probably be chagrined. http://j.mp/iZYd0I Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274

1 0

Invitation to connect on LinkedIn
by Yaoqing Liu via LinkedIn 30 Jun '11

30 Jun '11

LinkedIn ------------ Yaoqing Liu requested to add you as a connection on LinkedIn: ------------------------------------------ Ted, I'd like to add you to my professional network on LinkedIn. - Yaoqing Accept invitation from Yaoqing Liu http://www.linkedin.com/e/-voa23o-gpjv55fb-66/q0XU4EiXDUS2IbxL1NdPb3ZaZI/bl… View invitation from Yaoqing Liu http://www.linkedin.com/e/-voa23o-gpjv55fb-66/q0XU4EiXDUS2IbxL1NdPb3ZaZI/bl… ------------------------------------------ DID YOU KNOW you can showcase your professional knowledge on LinkedIn to receive job/consulting offers and enhance your professional reputation? Posting replies to questions on LinkedIn Answers puts you in front of the world's professional community. http://www.linkedin.com/e/-voa23o-gpjv55fb-66/abq/inv-24/ -- (c) 2011, LinkedIn Corporation

1 0

Invitation to connect on LinkedIn
by Yaoqing Liu via LinkedIn 30 Jun '11

30 Jun '11

LinkedIn ------------ Yaoqing Liu requested to add you as a connection on LinkedIn: ------------------------------------------ Ted, I'd like to add you to my professional network on LinkedIn. - Yaoqing Accept invitation from Yaoqing Liu http://www.linkedin.com/e/-voa23o-gpjunqoh-4g/q0XU4EiXDUS2IbxL1NdPb3ZaZI/bl… View invitation from Yaoqing Liu http://www.linkedin.com/e/-voa23o-gpjunqoh-4g/q0XU4EiXDUS2IbxL1NdPb3ZaZI/bl… ------------------------------------------ DID YOU KNOW you can showcase your professional knowledge on LinkedIn to receive job/consulting offers and enhance your professional reputation? Posting replies to questions on LinkedIn Answers puts you in front of the world's professional community. http://www.linkedin.com/e/-voa23o-gpjunqoh-4g/abq/inv-24/ -- (c) 2011, LinkedIn Corporation

1 0

[pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3)
by Eugen Leitl 29 Jun '11

29 Jun '11

----- Forwarded message from William Salt <williamejsalt(a)googlemail.com> ----- From: William Salt <williamejsalt(a)googlemail.com> Date: Tue, 28 Jun 2011 08:03:25 +0100 To: support(a)pfsense.com Subject: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) Reply-To: support(a)pfsense.com Hi All, For the last couple of months i have been pulling my hair out trying to solve this problem. We have a 1Gbps transatlantic link from the UK to the US, which has successfully passed the RFC2544 test. At either end, we have a media converter, and a supermicro server with an intel quad port NIC running pfsense 2 (RC2 at one end RC3 at the other) and the IGB driver on the quad port. We can pass 1gbps either way with UDP. However we are experiencing very strange issues with tcp connections. With window scaling enabled, and a max socket buffer set to 16MB, we see no difference. Even disabling window scaling and setting the window to 16MB makes no difference. Each TCP connection starts very slowly, and will max out at around 190mbps, taking nearly 2 minutes to climb to this speed before *plateauing*. We have to initiate many (5+) connections to saturate the link with tcp connections with iperf. Real world tests transferring files, max out at 100mbps, using multiple connections. I have followed guides like this: http://www.psc.edu/networking/projects/tcptune/#FreeBSD With no luck, and have tweaked, disabled, and enabled nearly every relevant sysctl parameter with no luck. Can anyone shed some light on this? I am now doubting the IGB driver, and am looking to swap out the cards as a last ditch effort. However, we have tried different hardware (L3 switches, media convertes + laptops etc), and the symptoms still persist... The only constant is freebsd 8.1 - pfsense (or 8.2 for our production systems). I have tried the freebsd net mailinglist, but im hoping you lot can help me! Cheers in advance Will ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

15 25

Wacky Weekend: NERC to relax power grid frequency strictures
by Jay Ashworth 29 Jun '11

29 Jun '11

The North American Electric Reliability Council is planning to relax the standards for how closely power utilities must hold to 60.00Hz. Here's my absolute favorite quote of all time: Tweaking the power grid's frequency is expensive and takes a lot of effort, said Joe McClelland, head of electric reliability for the Federal Energy Regulatory Commission. "Is anyone using the grid to keep track of time?" McClelland said. "Let's see if anyone complains if we eliminate it." http://hosted.ap.org/dynamic/stories/U/US_SCI_POWER_CLOCKS?SITE=AP&SECTION=… I believe the answer to that question is contained here: http://yarchive.net/car/rv/generator_synchronization.html [1] This is gonna be fun, no? Cheers, -- jra [1]Please, let's not start in on the source.[2] [2]No, really: *please*. :-) -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274

18 38

Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3)
by Eugen Leitl 29 Jun '11

29 Jun '11

----- Forwarded message from William Salt <williamejsalt(a)googlemail.com> ----- From: William Salt <williamejsalt(a)googlemail.com> Date: Wed, 29 Jun 2011 13:16:32 +0100 To: support(a)pfsense.com Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) Reply-To: support(a)pfsense.com Hi all, thanks for the input. We have now swapped the cards to em card at both ends, instead of igb at one end, and em at the other. We are now seeing near gig speeds in both directions. Before, we saw very different speeds in each direction. We have now managed to reach around 860-900mbps each way with the following values in our sysctl.conf: kern.ipc.maxsockbuf=20971520 net.inet.tcp.recvbuf_max=20971520 net.inet.tcp.sendbuf_max=20971520 net.inet.tcp.recvbuf_inc=524288 net.inet.tcp.sendbuf_inc=524288 However, even though we can reach around the upper threshold of the connection, we are seeing the boxes crash, or tcp performance hit the miximum 860-900mbps then drop, and stick at around 8mbps, until a reboot. I might add that we are running 32bit (i386) RC3 at both ends, with 6gb of ram.(probably alot less in the OS, need to upgrade to x64) When i replicated these settings on two fresh boxes beyong the routers at either end, i saw no performance increase... Regards Will On Tue, Jun 28, 2011 at 3:34 PM, Eugen Leitl <eugen(a)leitl.org> wrote: > > ----- Forwarded message from Rhys Rhaven <rhys(a)rhavenindustrys.com> ----- > > From: Rhys Rhaven <rhys(a)rhavenindustrys.com> > Date: Tue, 28 Jun 2011 09:30:06 -0500 > To: nanog(a)nanog.org > Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) > Organization: Rhaven Industrys > User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; > rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10 > > Obviously not helping if you are trying to tune standard TCP, but I > lament that protocols like Tsunami are not in wider use. > http://tsunami-udp.sourceforge.net/ Short of it, a TCP control channel > takes care of error checking and resends while the data channel is a UDP > stream, specifically built to max out LFNs. > > On 06/28/2011 03:52 AM, Eugen Leitl wrote: > > ----- Forwarded message from William Salt <williamejsalt(a)googlemail.com> ----- > > > > From: William Salt <williamejsalt(a)googlemail.com> > > Date: Tue, 28 Jun 2011 08:03:25 +0100 > > To: support(a)pfsense.com > > Subject: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) > > Reply-To: support(a)pfsense.com > > > > Hi All, > > For the last couple of months i have been pulling my hair out > > trying to solve this problem. > > We have a 1Gbps transatlantic link from the UK to the US, which has > > successfully passed the RFC2544 test. > > > > At either end, we have a media converter, and a supermicro server with an > > intel quad port NIC running pfsense 2 (RC2 at one end RC3 at the other) and > > the IGB driver on the quad port. > > > > We can pass 1gbps either way with UDP. However we are experiencing very > > strange issues with tcp connections. > > > > With window scaling enabled, and a max socket buffer set to 16MB, we see no > > difference. > > Even disabling window scaling and setting the window to 16MB makes no > > difference. > > > > Each TCP connection starts very slowly, and will max out at around 190mbps, > > taking nearly 2 minutes to climb to this speed before *plateauing*. > > > > We have to initiate many (5+) connections to saturate the link with tcp > > connections with iperf. > > > > Real world tests transferring files, max out at 100mbps, using multiple > > connections. > > > > I have followed guides like this: > > http://www.psc.edu/networking/projects/tcptune/#FreeBSD > > > > With no luck, and have tweaked, disabled, and enabled nearly every relevant > > sysctl parameter with no luck. > > > > Can anyone shed some light on this? > > > > I am now doubting the IGB driver, and am looking to swap out the cards as a > > last ditch effort. > > However, we have tried different hardware (L3 switches, media convertes + > > laptops etc), and the symptoms still persist... > > The only constant is freebsd 8.1 - pfsense (or 8.2 for our production > > systems). > > I have tried the freebsd net mailinglist, but im hoping you lot can help me! > > > > Cheers in advance > > Will > > > > ----- End forwarded message ----- > > > ----- End forwarded message ----- > -- > Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org > ______________________________________________________________ > ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org > 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE > > --------------------------------------------------------------------- > To unsubscribe, e-mail: support-unsubscribe(a)pfsense.com > For additional commands, e-mail: support-help(a)pfsense.com > > Commercial support available - https://portal.pfsense.org > ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: NANOG Digest, Vol 41, Issue 165
by Savyasachi Choudhary 29 Jun '11

29 Jun '11

Hi, There is a command to limit the number of redistributed route. redistribute maximum-prefix Say, if ISIS imports routes, it will redistribute only the number of configured routes in 'redistribute maximum-prefix . My question is: say I make the number as 10. So initially ISIS will redistribute inly 10 routes recvd from say BGP, and drop other packets. But later, if I change the number to 20, how should it work? How will BGP send other routes? ' I think Huawei doed not have this command, but Cisco has Regards, Savyasachi 7676077879 On Wed, Jun 29, 2011 at 3:00 AM, <nanog-request(a)nanog.org> wrote: > Send NANOG mailing list submissions to > nanog(a)nanog.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > nanog-request(a)nanog.org > > You can reach the person managing the list at > nanog-owner(a)nanog.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > > Today's Topics: > > 1. RE: [pfSense Support] Strange TCP connection behavior 2.0 RC2 > (+3) (Leigh Porter) > 2. Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 > (+3) (Cameron Byrne) > 3. Re: Announcing Project BISMark: ISP Performance Measurements > from Home Routers (Daniel Espejel) > 4. Re: website in ipv6 (Kenny Sallee) > 5. Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 > (+3) (PC) > 6. Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 > (+3) (Cameron Byrne) > 7. DENOG 3 - Call for Participation and Papers (Marcus Stoegbauer) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 28 Jun 2011 16:11:23 +0000 > From: Leigh Porter <leigh.porter(a)ukbroadband.com> > Subject: RE: [pfSense Support] Strange TCP connection behavior 2.0 RC2 > (+3) > To: Cameron Byrne <cb.list6(a)gmail.com> > Cc: "williamejsalt(a)googlemail.com" <williamejsalt(a)googlemail.com>, > NANOG list <nanog(a)nanog.org> > Message-ID: > <D181DDABABE57E4DB72FEE0033147864075D66(a)EALPO1.ukbroadband.com> > Content-Type: text/plain; charset="us-ascii" > > > > > -----Original Message----- > > From: Cameron Byrne [mailto:cb.list6@gmail.com] > > Sent: 28 June 2011 16:53 > > To: Leigh Porter > > Cc: Andreas Ott; Eugen Leitl; williamejsalt(a)googlemail.com; NANOG list > > Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 > > (+3) > > In the 3G world, i have had good results overcoming longish RTT by > > using the Hybla TCP algorithm http://hybla.deis.unibo.it/ > > > > I am hoping it gets more default traction, especially in wireless > > where the radio link is a pretty big latency source > > > > Cameron > > How do you implement this for lots of clients and servers that have out of > the box implementations? The FastSoft box is a TCP man-in-the-middle box > that essentially implements the FAST TCP algorithm without either end having > to worry about it. > > I have also used home-fudged TCP proxies with some success. > > Some 3G/wireless/VSAT vendors implement their own TCP modification stacks > but they usually only fiddle with window sizes and such. > > -- > Leigh > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > > > ------------------------------ > > Message: 2 > Date: Tue, 28 Jun 2011 09:16:13 -0700 > From: Cameron Byrne <cb.list6(a)gmail.com> > Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 > (+3) > To: Leigh Porter <leigh.porter(a)ukbroadband.com> > Cc: "williamejsalt(a)googlemail.com" <williamejsalt(a)googlemail.com>, > NANOG list <nanog(a)nanog.org> > Message-ID: > <BANLkTi=nbqdV+=ZUvLaiwy_ZHwS_fk79amzFXxYB-ca_MSt7ZA(a)mail.gmail.com > > > Content-Type: text/plain; charset=ISO-8859-1 > > On Tue, Jun 28, 2011 at 9:11 AM, Leigh Porter > <leigh.porter(a)ukbroadband.com> wrote: > > > > > >> -----Original Message----- > >> From: Cameron Byrne [mailto:cb.list6@gmail.com] > >> Sent: 28 June 2011 16:53 > >> To: Leigh Porter > >> Cc: Andreas Ott; Eugen Leitl; williamejsalt(a)googlemail.com; NANOG list > >> Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 > >> (+3) > >> In the 3G world, i have had good results overcoming longish RTT by > >> using the Hybla TCP algorithm ?http://hybla.deis.unibo.it/ > >> > >> I am hoping it gets more default traction, especially in wireless > >> where the radio link is a pretty big latency source > >> > >> Cameron > > > > How do you implement this for lots of clients and servers that have out > of the box implementations? The FastSoft box is a TCP man-in-the-middle box > that essentially implements the FAST TCP algorithm without either end having > to worry about it. > > > > You don't, the full benefits only come with a Linux kernel patch. The > good news is that it only has to be implemented on the client end. > > > I have also used home-fudged TCP proxies with some success. > > > > Some 3G/wireless/VSAT vendors implement their own TCP modification stacks > but they usually only fiddle with window sizes and such. > > > > That's why i said i hope it catches on as default :) If Android > implemented Hybla, i think it would be a great improvement for user > experience. Nobody likes the middleboxes that proxy TCP.... they cost > money, don't scale well, and are generally fragile. Hybla is not a > solution for the OPs issue, just a solution for high RTT links where > the client can do Hybla. It an evolutionary step that i think would > make a great fit in smartphones like Android. > > Cameron > > -- > > Leigh > > > > > > ______________________________________________________________________ > > This email has been scanned by the MessageLabs Email Security System. > > For more information please visit http://www.messagelabs.com/email > > ______________________________________________________________________ > > > > > > ------------------------------ > > Message: 3 > Date: Tue, 28 Jun 2011 12:50:29 -0500 > From: Daniel Espejel <daniel.unam.ipv6(a)gmail.com> > Subject: Re: Announcing Project BISMark: ISP Performance Measurements > from Home Routers > To: nanog(a)nanog.org > Message-ID: <BANLkTimbkG9CyN2PjiA7AECbok-V5Fenkw(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi. > > I would like to participate in the Bismark project, for now only as a > poller-kind user. > While checking the router n600 specifications datasheet it seems that this > device is IPv6 compliant in some degree (because of the IPv6 Ready Logo > included at the bottom of the sheet). > > I'm really interested in performing some test about that issue; but I'm > also > worried about privacy/confidentiality and navigation speed features. > > It's likely all those whom participate may find related information about > this topics in the project website and related mailing list. > > Well, I'm waiting to get my hands dirty on N600 and this way trying to > solve > some of my doubts (or catch a lot more). > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Tue, 28 Jun 2011 11:30:07 +0100 > > From: Alex Brooks <askoorb+nanog(a)gmail.com> > > Subject: Re: Announcing Project BISMark: ISP Performance Measurements > > from Home Routers > > To: nanog <nanog(a)nanog.org> > > Message-ID: <BANLkTikuyoBbOJotA3qrJQRDWjvd-cWWOA(a)mail.gmail.com> > > Content-Type: text/plain; charset=ISO-8859-1 > > > > Hello, > > > > On Mon, Jun 27, 2011 at 9:48 PM, Nick Feamster <feamster(a)cc.gatech.edu> > > wrote: > > > > > > Hello NANOG, > > > > > > We've launched Project BISMark, a project that performs active > > performance measurements of upload and download throughput, latency, etc. > > from OpenWRT-based routers running inside of homes. ? We have tested our > > OpenWRT image on the NetGear WNDR 3700v2 and are currently shipping out > > NetGear routers with the BISMark firmware to anyone who is interested. > > > > > > > -- > *Daniel Espejel Perez > * > > > ------------------------------ > > Message: 4 > Date: Tue, 28 Jun 2011 11:09:04 -0700 > From: Kenny Sallee <kenny.sallee(a)gmail.com> > Subject: Re: website in ipv6 > To: Mark Andrews <marka(a)isc.org> > Cc: nanog list <nanog(a)nanog.org> > Message-ID: <BANLkTikt-7aRAXBYzUk0ao9V5DBeKz-0eg(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > > > > > > > > > > > I did this by creating a 6to4 tunnel to a relay provided by > > > > 6in4, not 6to4. While HE do operate 6to4 relays, the brokered tunnel > > service is 6in4. > > > > > A very important distinction I didn't have clear in my head. To > regurgitate > some reading I just completed: both methods use v6 in v4 tunneling using ip > proto 41 in the IPv4 protocol field. However, 6to4 derives the IPv4 tunnel > destination of an IPv6 packet based on bits 17-48 of the IPv6 packet - > which > when converted, equals the 32 bit IPv4 destination. While 6in4 is > statically configured IPv4 source and destination IP addresses on the > Tunnel > (gre) interface. In Cisco world the config comes down to 'tunnel mode > ipv6ip' vs 'tunnel mode ipv6ip 6to4' and a few other lines of config. > > Of course there are a lot more details then that searchable via google. > Thanks for pointing out my mistake - it helped me learn some more! Later, > Kenny > > > ------------------------------ > > Message: 5 > Date: Tue, 28 Jun 2011 14:24:59 -0600 > From: PC <paul4004(a)gmail.com> > Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 > (+3) > To: Cameron Byrne <cb.list6(a)gmail.com> > Cc: "williamejsalt(a)googlemail.com" <williamejsalt(a)googlemail.com>, > NANOG list <nanog(a)nanog.org> > Message-ID: <BANLkTi=xzzwc_vj=cA+aZLpZ5=M_tgFaUA(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > I have found most/all modern 3g networks can achieve optimal download speed > within their latency limitations (<200ms domestic end-to-end is normal for > most today) when combined with a modern operating system that does > automatic > TCP receive window adjustments based on per-flow characteristics. I never > had a problem getting ~2 megabit from EVDO-revA, and can get ~20 megabit > without issue from the new Verizon LTE network. (Windows XP is not > modern). > > As for VSAT, most every vsat equipment manufacturer has TCP > acceleration/proxy support built into the satellite modem. They basically > forge acks at the hub site to buffer data from the server, then deliver it > it to the remote end in a continuous flow. Many also have protocol > optimizations for some of the more "chatty" protocols. If you use it, your > 10 megabit should be achievable for typical HTTP/FTP consumer internet > activities, and it's surprisingly fast. I've sustained 6 without issue on > VSAT, only limited by bandwidth available, doing a simple SCP file > transfer. > > Of course, none of this is to the scale of transatlantic gigabit transfers > with a single flow... > > > On Tue, Jun 28, 2011 at 10:16 AM, Cameron Byrne <cb.list6(a)gmail.com> > wrote: > > > On Tue, Jun 28, 2011 at 9:11 AM, Leigh Porter > > <leigh.porter(a)ukbroadband.com> wrote: > > > > > > > > >> -----Original Message----- > > >> From: Cameron Byrne [mailto:cb.list6@gmail.com] > > >> Sent: 28 June 2011 16:53 > > >> To: Leigh Porter > > >> Cc: Andreas Ott; Eugen Leitl; williamejsalt(a)googlemail.com; NANOG > list > > >> Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 > > >> (+3) > > >> In the 3G world, i have had good results overcoming longish RTT by > > >> using the Hybla TCP algorithm http://hybla.deis.unibo.it/ > > >> > > >> I am hoping it gets more default traction, especially in wireless > > >> where the radio link is a pretty big latency source > > >> > > >> Cameron > > > > > > How do you implement this for lots of clients and servers that have out > > of the box implementations? The FastSoft box is a TCP man-in-the-middle > box > > that essentially implements the FAST TCP algorithm without either end > having > > to worry about it. > > > > > > > You don't, the full benefits only come with a Linux kernel patch. The > > good news is that it only has to be implemented on the client end. > > > > > I have also used home-fudged TCP proxies with some success. > > > > > > Some 3G/wireless/VSAT vendors implement their own TCP modification > stacks > > but they usually only fiddle with window sizes and such. > > > > > > > That's why i said i hope it catches on as default :) If Android > > implemented Hybla, i think it would be a great improvement for user > > experience. Nobody likes the middleboxes that proxy TCP.... they cost > > money, don't scale well, and are generally fragile. Hybla is not a > > solution for the OPs issue, just a solution for high RTT links where > > the client can do Hybla. It an evolutionary step that i think would > > make a great fit in smartphones like Android. > > > > Cameron > > > -- > > > Leigh > > > > > > > > > ______________________________________________________________________ > > > This email has been scanned by the MessageLabs Email Security System. > > > For more information please visit http://www.messagelabs.com/email > > > ______________________________________________________________________ > > > > > > > > > > ------------------------------ > > Message: 6 > Date: Tue, 28 Jun 2011 13:35:16 -0700 > From: Cameron Byrne <cb.list6(a)gmail.com> > Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 > (+3) > To: PC <paul4004(a)gmail.com> > Cc: "williamejsalt(a)googlemail.com" <williamejsalt(a)googlemail.com>, > NANOG list <nanog(a)nanog.org> > Message-ID: > <BANLkTin4RBcVAZaz9kwoBouHmT1TBndkbQ_xc9E=OFFx4GEr5w(a)mail.gmail.com > > > Content-Type: text/plain; charset=ISO-8859-1 > > On Tue, Jun 28, 2011 at 1:24 PM, PC <paul4004(a)gmail.com> wrote: > > I have found most/all modern 3g networks can achieve optimal download > speed > > within their latency limitations (<200ms domestic end-to-end is normal > for > > most today) when combined with a modern operating system that does > automatic > > TCP receive window adjustments based on per-flow characteristics.? I > never > > had a problem getting ~2 megabit from EVDO-revA, and can get ~20 megabit > > without issue from the new Verizon LTE network.? (Windows XP is not > modern). > > > > AFAIK, Verizon and all the other 4 largest mobile networks in the USA > have transparent TCP proxies in place. > > My point was that if end-hosts had Hybla or something similar, these > proxies can be removed providing a better end-to-end solution. > > Cameron > > > As for VSAT, most every vsat equipment manufacturer has TCP > > acceleration/proxy support built into the satellite modem.? They > basically > > forge acks at the hub site to buffer data from the server, then deliver > it > > it to the remote end in a continuous flow.? Many also have protocol > > optimizations for some of the more "chatty" protocols.? If you use it, > your > > 10 megabit should be achievable for typical HTTP/FTP consumer internet > > activities, and it's surprisingly fast.? I've sustained 6 without issue > on > > VSAT, only limited by bandwidth available, doing a simple SCP file > transfer. > > > > Of course, none of this is to the scale of transatlantic gigabit > transfers > > with a single flow... > > > > > > On Tue, Jun 28, 2011 at 10:16 AM, Cameron Byrne <cb.list6(a)gmail.com> > wrote: > >> > >> On Tue, Jun 28, 2011 at 9:11 AM, Leigh Porter > >> <leigh.porter(a)ukbroadband.com> wrote: > >> > > >> > > >> >> -----Original Message----- > >> >> From: Cameron Byrne [mailto:cb.list6@gmail.com] > >> >> Sent: 28 June 2011 16:53 > >> >> To: Leigh Porter > >> >> Cc: Andreas Ott; Eugen Leitl; williamejsalt(a)googlemail.com; NANOG > list > >> >> Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 > RC2 > >> >> (+3) > >> >> In the 3G world, i have had good results overcoming longish RTT by > >> >> using the Hybla TCP algorithm ?http://hybla.deis.unibo.it/ > >> >> > >> >> I am hoping it gets more default traction, especially in wireless > >> >> where the radio link is a pretty big latency source > >> >> > >> >> Cameron > >> > > >> > How do you implement this for lots of clients and servers that have > out > >> > of the box implementations? The FastSoft box is a TCP > man-in-the-middle box > >> > that essentially implements the FAST TCP algorithm without either end > having > >> > to worry about it. > >> > > >> > >> You don't, the full benefits only come with a Linux kernel patch. ?The > >> good news is that it only has to be implemented on the client end. > >> > >> > I have also used home-fudged TCP proxies with some success. > >> > > >> > Some 3G/wireless/VSAT vendors implement their own TCP modification > >> > stacks but they usually only fiddle with window sizes and such. > >> > > >> > >> That's why i said i hope it catches on as default :) ?If Android > >> implemented Hybla, i think it would be a great improvement for user > >> experience. ?Nobody likes the middleboxes that proxy TCP.... they cost > >> money, don't scale well, and are generally fragile. ?Hybla is not a > >> solution for the OPs issue, just a solution for high RTT links where > >> the client can do Hybla. ?It an evolutionary step that i think would > >> make a great fit in smartphones like Android. > >> > >> Cameron > >> > -- > >> > Leigh > >> > > >> > > >> > ______________________________________________________________________ > >> > This email has been scanned by the MessageLabs Email Security System. > >> > For more information please visit http://www.messagelabs.com/email > >> > ______________________________________________________________________ > >> > > >> > > > > > > > > ------------------------------ > > Message: 7 > Date: Tue, 28 Jun 2011 23:30:19 +0200 > From: Marcus Stoegbauer <marcus(a)grmpf.org> > Subject: DENOG 3 - Call for Participation and Papers > To: nanog(a)nanog.org > Message-ID: <4E0A47EB.5060808(a)grmpf.org> > Content-Type: text/plain; charset=UTF-8 > > DENOG 3 - Call for Participation and Papers > > The third meeting of the German Network Operators Group (DENOG) will be > held in Frankfurt, Germany on the 20th of October 2011. We are pleased > to hereby invite applications for presentations or lightning talks to be > held at this event. > > General Information > =================== > DENOG is a community for professionals within Germany who are operating, > designing or researching the Internet. It provides a technical forum > where those working on, with and for the Internet can come together to > solve problems with every aspect of their (net)work. > > The meeting is designed to provide an opportunity for the exchange of > information among network operators, engineers, researchers and other > professionals close to the network community. > > More information about DENOG (in German) can be found at > http://www.denog.de/ > Information about the meeting will be published at > http://www.denog.de/meetings/ > > > Meeting Countdown > ================= > What When > ------------------------------------------------------ > Publication of Call for Papers June 28th, 2011 > Deadline for all submissions August 22th, 2011 > Publication of final programme September 3rd, 2011 > Deadline for receipt of final slides October 13th, 2011 > Meeting Day October 20th, 2011 > > Topics for Presentations/Talks > ============================== > The day will be divided into several sessions. The number and length of > presentations per session is not fixed, although due to time constraints > we would prefer the length of the presentations to be between 10 to 30 > minutes. > > However proposals whose subject fall outside of the topics below are > also welcome; please do not hesitate to submit them. > > Lightning Talks > --------------- > In addition to the topics mentioned below we will reserve slots for > lightning talks, which consist of a few slides and will not last longer > than 5 minutes. Lightning talks can be submitted until October 13th, > with the deadline for submission of the corresponding slides being > October 19th. > > Topic #1: Power Efficiency in Networks > --------------------------------------- > For operators of networks and data centres of any size power efficiency > has become more important. Servers and network gear with high power > consumption are expensive because of high operating and cooling power > costs; also in many places supplying more power into the location is no > longer possible. How are you dealing with power problems in your > environment? How do you efficiently cool a rack/a room/a datacenter? Can > a migration to VoIP help you save power? > > Topic #2: Social Networks, Cloud Services and Information Security > ------------------------------------------------------------------ > Social Networks are an essential working tool for networkers and cloud > services are also becoming increasingly popular. The security of your > information and data in these networks is a crucial aspect which we want > to discuss in this session. > > Topic #3: Peering > ------------------ > Everything about your peering experience. Why are you doing it? How are > you doing it? Have you written any useful tools which others might find > interesting? > > Topic #4: ISP BOF > ----------------- > "All things ISP". From Network/SLA Management (for or against it), abuse > handling and log systems to data centre layout and planning (including > power and cooling), everything that is interesting to you as an ISP can > be presented or discussed within this topic. > > Language of Slides and Talks > ============================ > To appeal to an international audience we ask you to produce your slides > in English, but the spoken language of the presentation itself can be > either German or English. > > Submission Guidelines > ===================== > All submissions must have a strong technical bias and must not be solely > promotional for your employer. > > Please remember that your presentations should be suitable for a target > audience of technicians from varied backgrounds, working for companies > whose sizes may vary considerably. > > To submit a proposal for a presentation, we request that you provide the > following information as plain text or PDF format to <denog-pc(a)denog.de>: > > * the name of the presenter (and if applicable your affiliation) > * a working email address > * the name and number of the topic which will contain the presentation > * the title of the presentation > * its expected length (in minutes) > * the preferred spoken language for the presentation > * a short abstract of the presentation (not more than 200 words) > > We also welcome suggestions for specific presentations which you feel > would be valuable to the DENOG community. > > Please be aware that your presentation will be published on the DENOG > website after the event. > > > > ------------------------------ > > _______________________________________________ > NANOG mailing list > NANOG(a)nanog.org > https://mailman.nanog.org/mailman/listinfo/nanog > > End of NANOG Digest, Vol 41, Issue 165 > ************************************** >

1 0

website in ipv6
by Deric Kwok 29 Jun '11

29 Jun '11

Hi all I am trying to configure website for testing ipv6 Just wander how internet users eg: DSL users can visit this website and any people can access this website over the world Thank you

6 11

DENOG 3 - Call for Participation and Papers
by Marcus Stoegbauer 28 Jun '11

28 Jun '11

DENOG 3 - Call for Participation and Papers The third meeting of the German Network Operators Group (DENOG) will be held in Frankfurt, Germany on the 20th of October 2011. We are pleased to hereby invite applications for presentations or lightning talks to be held at this event. General Information =================== DENOG is a community for professionals within Germany who are operating, designing or researching the Internet. It provides a technical forum where those working on, with and for the Internet can come together to solve problems with every aspect of their (net)work. The meeting is designed to provide an opportunity for the exchange of information among network operators, engineers, researchers and other professionals close to the network community. More information about DENOG (in German) can be found at http://www.denog.de/ Information about the meeting will be published at http://www.denog.de/meetings/ Meeting Countdown ================= What When ------------------------------------------------------ Publication of Call for Papers June 28th, 2011 Deadline for all submissions August 22th, 2011 Publication of final programme September 3rd, 2011 Deadline for receipt of final slides October 13th, 2011 Meeting Day October 20th, 2011 Topics for Presentations/Talks ============================== The day will be divided into several sessions. The number and length of presentations per session is not fixed, although due to time constraints we would prefer the length of the presentations to be between 10 to 30 minutes. However proposals whose subject fall outside of the topics below are also welcome; please do not hesitate to submit them. Lightning Talks --------------- In addition to the topics mentioned below we will reserve slots for lightning talks, which consist of a few slides and will not last longer than 5 minutes. Lightning talks can be submitted until October 13th, with the deadline for submission of the corresponding slides being October 19th. Topic #1: Power Efficiency in Networks --------------------------------------- For operators of networks and data centres of any size power efficiency has become more important. Servers and network gear with high power consumption are expensive because of high operating and cooling power costs; also in many places supplying more power into the location is no longer possible. How are you dealing with power problems in your environment? How do you efficiently cool a rack/a room/a datacenter? Can a migration to VoIP help you save power? Topic #2: Social Networks, Cloud Services and Information Security ------------------------------------------------------------------ Social Networks are an essential working tool for networkers and cloud services are also becoming increasingly popular. The security of your information and data in these networks is a crucial aspect which we want to discuss in this session. Topic #3: Peering ------------------ Everything about your peering experience. Why are you doing it? How are you doing it? Have you written any useful tools which others might find interesting? Topic #4: ISP BOF ----------------- "All things ISP". From Network/SLA Management (for or against it), abuse handling and log systems to data centre layout and planning (including power and cooling), everything that is interesting to you as an ISP can be presented or discussed within this topic. Language of Slides and Talks ============================ To appeal to an international audience we ask you to produce your slides in English, but the spoken language of the presentation itself can be either German or English. Submission Guidelines ===================== All submissions must have a strong technical bias and must not be solely promotional for your employer. Please remember that your presentations should be suitable for a target audience of technicians from varied backgrounds, working for companies whose sizes may vary considerably. To submit a proposal for a presentation, we request that you provide the following information as plain text or PDF format to <denog-pc(a)denog.de>: * the name of the presenter (and if applicable your affiliation) * a working email address * the name and number of the topic which will contain the presentation * the title of the presentation * its expected length (in minutes) * the preferred spoken language for the presentation * a short abstract of the presentation (not more than 200 words) We also welcome suggestions for specific presentations which you feel would be valuable to the DENOG community. Please be aware that your presentation will be published on the DENOG website after the event.

1 0