June 2010 - Test - lists.nanog.org

Experience with the Dell PowerConnect 8024F - compare to the Cisco Nexus 5010
by Steven Fischer 18 Jun '10

18 Jun '10

Does anyone have any experience with the Dell PowerConnect 8024F 10-gig switch that they'd be willing to share? How does it perform? How reliable is it? My experiences with the Dell switches have been less than favorable to this point, but I am willing to concede that some of that may be colored by my Cisco bias. Would you trust this Dell switch in a high-performance computing environment, where the ability to move data for sustained durations at rates close to line speed is paramount, along with high-reliability/high-availability? Any feedback is welcomed. -- To him who is able to keep you from falling and to present you before his glorious presence without fault and with great joy

4 4

DC rectifier
by Ric Moseley 18 Jun '10

18 Jun '10

Anyone have any recommendations on a DC rectifier shelf? Been looking at Valere but the lead time is 4-6 weeks (which is too long). Thanks. Ric.

1 0

Root Zone DNSSEC Deployment Technical Status Update
by Joe Abley 18 Jun '10

18 Jun '10

Root Zone DNSSEC Deployment Technical Status Update 2010-06-18 This is the ninth of a series of technical status updates intended to inform a technical audience on progress in signing the root zone of the DNS. RESOURCES Details of the project, including documentation published to date, can be found at <http://www.root-dnssec.org/>. We'd like to hear from you. If you have feedback for us, please send it to rootsign(a)icann.org. KSK CEREMONY 1 COMPLETE The first KSK ceremony for the root zone was completed this week in Culpeper, VA, USA. The Ceremony Administrator was Mehmet Akcin. The first production KSK has now been generated. This is the key that is scheduled to be put into service on 2010-07-15. The first production Key Signing Request (KSR) generated by VeriSign has now been processed by ICANN using the root zone KSK, and the resulting Signed Key Response (KSR) has been accepted by VeriSign. This SKR contains signatures for Q3 2010, for use between 2010-07-01 and 2010-09-30. Audit materials relating to the first ceremony will be published as soon as is practical, and in particular before 2010-07-15. The KSK and SKR generated during this ceremony will not be approved for production until the KSK key pair has been successfully transported to ICANN's west-coast ceremony facility in El Segundo, CA, USA, and placed in secure storage. KSK CEREMONY 2 SCHEDULED The second KSK ceremony for the root zone is scheduled to take place in El Segundo, CA, USA on 2010-07-12. Replication of key materials onto west-coast HSMs, enrolment of west-coast crypto officers and processing of the Q4 2010 KSR (for production use between 2010-10-01 and 2010-12-31) will take place during this ceremony. PLANNED DEPLOYMENT SCHEDULE Already completed: 2010-01-27: L starts to serve DURZ 2010-02-10: A starts to serve DURZ 2010-03-03: M, I start to serve DURZ 2010-03-24: D, K, E start to serve DURZ 2010-04-14: B, H, C, G, F start to serve DURZ 2010-05-05: J starts to serve DURZ 2010-06-16: First Key Signing Key (KSK) Ceremony To come: 2010-07-12: Second Key Signing Key (KSK) Ceremony 2010-07-15: Distribution of validatable, production, signed root zone; publication of root zone trust anchor (Please note that this schedule is tentative and subject to change based on testing results or other unforeseen factors.)

1 0

Weekly Routing Table Report
by Routing Analysis Role Account 18 Jun '10

18 Jun '10

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 19 Jun, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 322870 Prefixes after maximum aggregation: 148946 Deaggregation factor: 2.17 Unique aggregates announced to Internet: 158175 Total ASes present in the Internet Routing Table: 34178 Prefixes per ASN: 9.45 Origin-only ASes present in the Internet Routing Table: 29680 Origin ASes announcing only one prefix: 14399 Transit ASes present in the Internet Routing Table: 4498 Transit-only ASes present in the Internet Routing Table: 104 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 25 Max AS path prepend of ASN (41664) 21 Prefixes from unregistered ASNs in the Routing Table: 266 Unregistered ASNs in the Routing Table: 114 Number of 32-bit ASNs allocated by the RIRs: 631 Prefixes from 32-bit ASNs in the Routing Table: 722 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 156 Number of addresses announced to Internet: 2247247968 Equivalent to 133 /8s, 242 /16s and 72 /24s Percentage of available address space announced: 60.6 Percentage of allocated address space announced: 65.4 Percentage of available address space allocated: 92.8 Percentage of address space in use by end-sites: 83.3 Total number of prefixes smaller than registry allocations: 154420 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 77483 Total APNIC prefixes after maximum aggregation: 26911 APNIC Deaggregation factor: 2.88 Prefixes being announced from the APNIC address blocks: 74300 Unique aggregates announced from the APNIC address blocks: 33095 APNIC Region origin ASes present in the Internet Routing Table: 4075 APNIC Prefixes per ASN: 18.23 APNIC Region origin ASes announcing only one prefix: 1119 APNIC Region transit ASes present in the Internet Routing Table: 639 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 523634976 Equivalent to 31 /8s, 54 /16s and 9 /24s Percentage of available APNIC address space announced: 78.0 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, 43/8, 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, 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: 134278 Total ARIN prefixes after maximum aggregation: 69110 ARIN Deaggregation factor: 1.94 Prefixes being announced from the ARIN address blocks: 107051 Unique aggregates announced from the ARIN address blocks: 41720 ARIN Region origin ASes present in the Internet Routing Table: 13734 ARIN Prefixes per ASN: 7.79 ARIN Region origin ASes announcing only one prefix: 5267 ARIN Region transit ASes present in the Internet Routing Table: 1340 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 22 Number of ARIN addresses announced to Internet: 728209056 Equivalent to 43 /8s, 103 /16s and 150 /24s Percentage of available ARIN address space announced: 62.0 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, 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, 54/8, 55/8, 56/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, 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: 74245 Total RIPE prefixes after maximum aggregation: 43253 RIPE Deaggregation factor: 1.72 Prefixes being announced from the RIPE address blocks: 67494 Unique aggregates announced from the RIPE address blocks: 44391 RIPE Region origin ASes present in the Internet Routing Table: 14528 RIPE Prefixes per ASN: 4.65 RIPE Region origin ASes announcing only one prefix: 7502 RIPE Region transit ASes present in the Internet Routing Table: 2164 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 25 Number of RIPE addresses announced to Internet: 432216992 Equivalent to 25 /8s, 195 /16s and 27 /24s Percentage of available RIPE address space announced: 75.8 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, 196608-197631 RIPE Address Blocks 2/8, 25/8, 31/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, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 28758 Total LACNIC prefixes after maximum aggregation: 6858 LACNIC Deaggregation factor: 4.19 Prefixes being announced from the LACNIC address blocks: 27214 Unique aggregates announced from the LACNIC address blocks: 14180 LACNIC Region origin ASes present in the Internet Routing Table: 1296 LACNIC Prefixes per ASN: 21.00 LACNIC Region origin ASes announcing only one prefix: 402 LACNIC Region transit ASes present in the Internet Routing Table: 227 Average LACNIC Region AS path length visible: 3.9 Max LACNIC Region AS path length visible: 24 Number of LACNIC addresses announced to Internet: 74639360 Equivalent to 4 /8s, 114 /16s and 232 /24s Percentage of available LACNIC address space announced: 55.6 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/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: 7166 Total AfriNIC prefixes after maximum aggregation: 1816 AfriNIC Deaggregation factor: 3.95 Prefixes being announced from the AfriNIC address blocks: 5505 Unique aggregates announced from the AfriNIC address blocks: 1731 AfriNIC Region origin ASes present in the Internet Routing Table: 370 AfriNIC Prefixes per ASN: 14.88 AfriNIC Region origin ASes announcing only one prefix: 109 AfriNIC Region transit ASes present in the Internet Routing Table: 82 Average AfriNIC Region AS path length visible: 3.7 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 18911488 Equivalent to 1 /8s, 32 /16s and 145 /24s Percentage of available AfriNIC address space announced: 56.4 AfriNIC AS Blocks 36864-37887, 327680-328703 & 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 1847 8407 482 Korea Telecom (KIX) 7545 1330 232 107 TPG Internet Pty Ltd 17488 1319 140 127 Hathway IP Over Cable Interne 4755 1310 294 154 TATA Communications formerly 17974 1011 270 50 PT TELEKOMUNIKASI INDONESIA 9583 995 73 490 Sify Limited 4134 983 21291 407 CHINANET-BACKBONE 24560 919 306 169 Bharti Airtel Ltd., Telemedia 4808 837 1572 215 CNCGROUP IP network: China169 9829 793 680 39 BSNL National Internet Backbo 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 3911 3733 287 bellsouth.net, inc. 4323 3368 1114 395 Time Warner Telecom 1785 1793 698 129 PaeTec Communications, Inc. 20115 1553 1514 658 Charter Communications 7018 1513 5737 961 AT&T WorldNet Services 2386 1286 569 910 AT&T Data Communications Serv 6478 1284 260 84 AT&T Worldnet Services 3356 1181 10894 407 Level 3 Communications, LLC 22773 1166 2605 65 Cox Communications, Inc. 11492 1159 208 65 Cable One 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 35805 641 56 6 United Telecom of Georgia 3292 453 2026 393 TDC Tele Danmark 30890 444 111 206 Evolva Telecom 702 411 1869 327 UUNET - Commercial IP service 8551 400 353 46 Bezeq International 8866 400 117 18 Bulgarian Telecommunication C 3301 372 1422 327 TeliaNet Sweden 3320 370 7313 321 Deutsche Telekom AG 34984 360 89 185 BILISIM TELEKOM 9198 352 202 13 Kazakhtelecom Data Network Ad 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 1520 2965 244 UniNet S.A. de C.V. 10620 1059 237 152 TVCABLE BOGOTA 28573 945 767 92 NET Servicos de Comunicao S.A 7303 720 383 102 Telecom Argentina Stet-France 6503 666 174 210 AVANTEL, S.A. 22047 546 310 15 VTR PUNTO NET S.A. 3816 482 212 77 Empresa Nacional de Telecomun 7738 477 922 30 Telecomunicacoes da Bahia S.A 14420 464 32 68 ANDINATEL S.A. 14117 450 31 14 Telefonica del Sur S.A. 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 1163 445 10 TEDATA 24863 720 147 39 LINKdotNET AS number 36992 640 278 186 Etisalat MISR 3741 269 852 230 The Internet Solution 33776 219 12 11 Starcomms Nigeria Limited 2018 211 244 61 Tertiary Education Network 6713 195 186 16 Itissalat Al-MAGHRIB 24835 188 78 10 RAYA Telecom - Egypt 29571 176 19 10 Ci Telecom Autonomous system 29975 133 506 14 Vodacom 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 3911 3733 287 bellsouth.net, inc. 4323 3368 1114 395 Time Warner Telecom 4766 1847 8407 482 Korea Telecom (KIX) 1785 1793 698 129 PaeTec Communications, Inc. 20115 1553 1514 658 Charter Communications 8151 1520 2965 244 UniNet S.A. de C.V. 7018 1513 5737 961 AT&T WorldNet Services 7545 1330 232 107 TPG Internet Pty Ltd 17488 1319 140 127 Hathway IP Over Cable Interne 4755 1310 294 154 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 3368 2973 Time Warner Telecom 1785 1793 1664 PaeTec Communications, Inc. 4766 1847 1365 Korea Telecom (KIX) 8151 1520 1276 UniNet S.A. de C.V. 7545 1330 1223 TPG Internet Pty Ltd 6478 1284 1200 AT&T Worldnet Services 17488 1319 1192 Hathway IP Over Cable Interne 4755 1310 1156 TATA Communications formerly 8452 1163 1153 TEDATA 22773 1166 1101 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.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 Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 31.0.0.0/16 12654 RIPE NCC RIS Project 31.1.0.0/21 12654 RIPE NCC RIS Project 31.1.24.0/24 12654 RIPE NCC RIS Project 41.222.79.0/24 36938 >>UNKNOWN<< 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 6453 Teleglobe Inc. 41.223.196.0/24 36990 Alkan Telecom Ltd 41.223.197.0/24 36990 Alkan Telecom Ltd 41.223.198.0/24 36990 Alkan Telecom Ltd 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:20 /9:10 /10:25 /11:68 /12:194 /13:403 /14:703 /15:1283 /16:11117 /17:5327 /18:9044 /19:18356 /20:22585 /21:22805 /22:29734 /23:29309 /24:168896 /25:950 /26:1238 /27:617 /28:118 /29:47 /30:13 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2506 3911 bellsouth.net, inc. 4323 1852 3368 Time Warner Telecom 4766 1482 1847 Korea Telecom (KIX) 1785 1256 1793 PaeTec Communications, Inc. 11492 1071 1159 Cable One 17488 1066 1319 Hathway IP Over Cable Interne 8452 1051 1163 TEDATA 18566 1040 1059 Covad Communications 10620 975 1059 TVCABLE BOGOTA 7018 914 1513 AT&T WorldNet Services Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:2 4:13 8:285 12:2003 13:7 14:1 15:23 16:3 17:8 20:21 24:1429 27:114 31:1 32:49 33:12 38:681 40:98 41:2437 44:3 47:18 52:9 55:9 56:2 57:25 58:747 59:502 60:458 61:1072 62:1070 63:1971 64:3651 65:2356 66:4259 67:1824 68:1114 69:2883 70:704 71:237 72:1836 73:2 74:2102 75:250 76:308 77:928 78:631 79:417 80:995 81:795 82:487 83:431 84:698 85:1047 86:461 87:692 88:341 89:1578 90:93 91:2818 92:472 93:1064 94:1414 95:612 96:284 97:323 98:580 99:28 108:32 109:528 110:345 111:518 112:265 113:302 114:421 115:548 116:1053 117:639 118:477 119:935 120:147 121:738 122:1449 123:927 124:1114 125:1308 128:226 129:214 130:195 131:553 132:244 133:17 134:196 135:45 136:235 137:162 138:264 139:104 140:510 141:137 142:348 143:392 144:476 145:50 146:442 147:168 148:662 149:300 150:152 151:166 152:295 153:168 154:2 155:328 156:156 157:325 158:107 159:375 160:316 161:181 162:255 163:171 164:408 165:342 166:465 167:404 168:786 169:164 170:703 171:57 172:2 173:840 174:613 175:93 176:1 178:187 180:487 182:119 183:225 184:62 186:469 187:356 188:1081 189:780 190:3777 192:5749 193:4700 194:3357 195:2774 196:1167 198:3586 199:3456 200:5356 201:1546 202:7976 203:8287 204:4076 205:2328 206:2520 207:3070 208:3873 209:3422 210:2505 211:1262 212:1748 213:1682 214:661 215:69 216:4667 217:1432 218:494 219:378 220:1138 221:413 222:311 223:1 End of report

1 0

DNSsec from domailcontrol.com
by MKS 18 Jun '10

18 Jun '10

Hi We (a small ISP in the middle of nowhere) are having problems resolving DNSsec records from godaddy. This commands works just fine # dig @ns52.domaincontrol.com loomus.com but this doesn't # dig @ns52.domaincontrol.com +dnssec loomus.com We don't receive the reply to the query. and no, this isn't a packet size issue, the reply for the second command is 124bytes, and the host isn't behind a firewall. So the same commands work just fine outside our network, and we are only having problems with nsxx.domailcontrol.com As far as I can see, when enabling +dnssec the EDNS option is activated and this is added in the dns querty "OPT UDPsize=4096 OK" I have also tried # dig @ns52.domaincontrol.com +dnssec +bufsize=512 loomus.com without any success. Does someone have any brilliant suggestions? Please contact me on or off list Regards MKS

2 1

Sending ARP request to unicast MAC instead of broadcast MAC address?
by Chris Woodfield 17 Jun '10

17 Jun '10

OK, this sounds Really Wacky (or, Really Hacky if you're into puns) but there's a reason for it, I swear... Will typical OSS UNIX kernels (Linux, BSD, MacOS X, etc) reply to a crafted ARP request that, instead of having FF:FF:FF:FF:FF:FF as its destination MAC address, is instead sent to the already-known unicast MAC address of the host? Next, what would be your utility of choice for crafting such a packet? Or is this something one would need to code up by hand in a lower-level language? Thanks, -C

5 5

Customer Interface Reporting / Portal
by Serge Vautour 17 Jun '10

17 Jun '10

Hello, What are people using to provide customer interface usage reports to customers? There seems to be lots of RRD based tools that can gather the data and store it for long term viewing. We use ZenOSS for internal purposes for example. How do we go about providing each customer access to their data in a secure way? A portal type access. Is anyone aware of a tool that includes a front end that can partition the data on a per customer basis? Each customer would have their own login ID and only see their data? How do we link the data to that customer? Some customer ID on the interface description? Thanks, Serge

3 2

AT&T's blue network SMS<->SMTP off the air
by John Todd 17 Jun '10

17 Jun '10

To those of you who may rely upon AT&T to deliver your email-to-SMS messages for monitoring: some of you may be currently out of luck. I would just send this to the "outages(a)puck.nether.net" list, but it does seem to be a meta-network failure in that for better or worse many of us use SMS as a method to monitor outages, so this perhaps moves it up a notch in the importance hierarchy enough to warrant a NANOG post. I am experiencing failures on my email transmissions to my older "blue" (aka: Cingular) AT&T devices at the moment, for both incoming and outgoing. Many of you may be using older "blue" cards in your NOC phones, SMS gateway devices, or perhaps even your personal mobile devices for those of you who still live in the dark ages of phones that aren't [2.5,3,4,x]G capable. I am unable to diagnose the problems fully, but at least some (if not all) of the SMS-to-email gateway failures are due to mmode.com's MX hosts (in the "airdata.com" zone) being unreachable due to absence of functioning authoritative resolvers for that zone, and possibly other failures as well. This appears to be causing "550 Access Denied" messages being returned to my mobile devices that are sending to email addresses, and mail spooling on my Internet SMTP hosts that are trying to send to the "NPAxxxyyyy(a)mmode.com" addresses for SMTP-to-SMS relay. There is a rumor that this is NOT related to the deactivation of the "downloads" components of the blue network on the 15th, but I suspect that someone just decided to pull the plug on everything. Reading to the end of the thread below, there is someone who states AT&T claims it will be back online by the evening of the 17th at the surprisingly accurate time of 9:55 PM (timezone unstated.) More speculation: http://forums.wireless.att.com/t5/mMode/URGENT-mmode-down-again-Their-mta01… I don't know if this is causing problems with anyone using TAP interfaces, or with any of AT&T's other SMTP<->SMS gateway services like @txt.att.net. SMS, and mobile devices in general, are a single point of failure for contacting on-call staff for various problems - perhaps it's time to insist that everyone carries two mobile devices, on different frequency and technology platforms, with different carriers, and split messages to both due to the anecdotally increasing failure rates of mobile networks. Conspiracy theories of how collusive unreliability would increase ARPU across the board for all carriers would be interesting to hear... but not in this forum, I suspect. :-) JT

2 1

help
by T Kawasaki 17 Jun '10

17 Jun '10

________________________________ From: "nanog-request(a)nanog.org" <nanog-request(a)nanog.org> To: nanog(a)nanog.org Sent: Thu, June 17, 2010 8:00:02 AM Subject: NANOG Digest, Vol 29, Issue 51 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: Todd Underwood was a little late (Jon Lewis) 2. Re: Todd Underwood was a little late (Mark Andrews) 3. Re: Todd Underwood was a little late (Roy) 4. Re: Todd Underwood was a little late (Garrett Skjelstad) 5. AT&T's blue network SMS<->SMTP off the air (John Todd) 6. AAAA being added for i.root-servers.net (Lindqvist Kurt Erik) ---------------------------------------------------------------------- Message: 1 Date: Wed, 16 Jun 2010 22:43:11 -0400 (EDT) From: Jon Lewis <jlewis(a)lewis.org> Subject: Re: Todd Underwood was a little late To: Mark Andrews <marka(a)isc.org> Cc: nanog(a)nanog.org Message-ID: <Pine.LNX.4.61.1006162237180.5148(a)soloth.lewis.org> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Thu, 17 Jun 2010, Mark Andrews wrote: > Why was this traffic hitting your DNS server in the first place? It should > have been rejected by the ingress filters preventing spoofing of the local > network. When I ran a smaller simpler network, I did have input filters on our transit providers rejecting packets from our IP space. With a larger network, multiple IP blocks, numerous multihomed customers, some of which use IP's we've assigned them, it gets a little more complicated to do. I could reject at our border, packets sourced from our IP ranges with exceptions for any of the IP blocks we've assigned to multihomed customers. The ACLs wouldn't be that long, or that hard to maintain. Is this common practice? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ ------------------------------ Message: 2 Date: Thu, 17 Jun 2010 13:27:09 +1000 From: Mark Andrews <marka(a)isc.org> Subject: Re: Todd Underwood was a little late To: Jon Lewis <jlewis(a)lewis.org> Cc: nanog(a)nanog.org Message-ID: <201006170327.o5H3R9fA072599(a)drugs.dv.isc.org> In message <Pine.LNX.4.61.1006162237180.5148(a)soloth.lewis.org>, Jon Lewis write s: > On Thu, 17 Jun 2010, Mark Andrews wrote: > > > Why was this traffic hitting your DNS server in the first place? It should > > have been rejected by the ingress filters preventing spoofing of the local > > network. > > When I ran a smaller simpler network, I did have input filters on our > transit providers rejecting packets from our IP space. With a larger > network, multiple IP blocks, numerous multihomed customers, some of which > use IP's we've assigned them, it gets a little more complicated to do. One can never do a perfect job but one can stop a large percentage of the crap. You should know the multi-homed customers and their address ranges so they become exceptions. You also run filters on internal routers. There are internal ingress/egress points as well as interconnects. > I could reject at our border, packets sourced from our IP ranges with > exceptions for any of the IP blocks we've assigned to multihomed > customers. The ACLs wouldn't be that long, or that hard to maintain. Is > this common practice? > > ---------------------------------------------------------------------- > Jon Lewis | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka(a)isc.org ------------------------------ Message: 3 Date: Wed, 16 Jun 2010 21:38:42 -0700 From: Roy <r.engehausen(a)gmail.com> Subject: Re: Todd Underwood was a little late Cc: nanog(a)nanog.org Message-ID: <4C19A6D2.6030603(a)gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 6/16/2010 7:43 PM, Jon Lewis wrote: > On Thu, 17 Jun 2010, Mark Andrews wrote: > >> Why was this traffic hitting your DNS server in the first place? It >> should >> have been rejected by the ingress filters preventing spoofing of the >> local >> network. > > When I ran a smaller simpler network, I did have input filters on our > transit providers rejecting packets from our IP space. With a larger > network, multiple IP blocks, numerous multihomed customers, some of > which use IP's we've assigned them, it gets a little more complicated > to do. > > I could reject at our border, packets sourced from our IP ranges with > exceptions for any of the IP blocks we've assigned to multihomed > customers. The ACLs wouldn't be that long, or that hard to maintain. > Is this common practice? > > - Sounds like a good use of URPF. ------------------------------ Message: 4 Date: Wed, 16 Jun 2010 22:07:10 -0700 From: Garrett Skjelstad <garrett(a)skjelstad.org> Subject: Re: Todd Underwood was a little late To: Roy <r.engehausen(a)gmail.com> Cc: nanog(a)nanog.org Message-ID: <AANLkTim-6WCFwrPNyBwXV1P7CwWReCa6DauH-rHvvo_a(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 RFC 2827 anyone? On Wed, Jun 16, 2010 at 9:38 PM, Roy <r.engehausen(a)gmail.com> wrote: > On 6/16/2010 7:43 PM, Jon Lewis wrote: > >> On Thu, 17 Jun 2010, Mark Andrews wrote: >> >> Why was this traffic hitting your DNS server in the first place? It >>> should >>> have been rejected by the ingress filters preventing spoofing of the >>> local >>> network. >>> >> >> When I ran a smaller simpler network, I did have input filters on our >> transit providers rejecting packets from our IP space. With a larger >> network, multiple IP blocks, numerous multihomed customers, some of which >> use IP's we've assigned them, it gets a little more complicated to do. >> >> I could reject at our border, packets sourced from our IP ranges with >> exceptions for any of the IP blocks we've assigned to multihomed customers. >> The ACLs wouldn't be that long, or that hard to maintain. Is this common >> practice? >> >> - >> > > Sounds like a good use of URPF. > > > ------------------------------ Message: 5 Date: Wed, 16 Jun 2010 23:26:30 -0700 From: John Todd <jtodd(a)loligo.com> Subject: AT&T's blue network SMS<->SMTP off the air To: nanog(a)nanog.org Message-ID: <7A699AC1-EF4E-4731-8D81-FAEDC3CE1C01(a)loligo.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes To those of you who may rely upon AT&T to deliver your email-to-SMS messages for monitoring: some of you may be currently out of luck. I would just send this to the "outages(a)puck.nether.net" list, but it does seem to be a meta-network failure in that for better or worse many of us use SMS as a method to monitor outages, so this perhaps moves it up a notch in the importance hierarchy enough to warrant a NANOG post. I am experiencing failures on my email transmissions to my older "blue" (aka: Cingular) AT&T devices at the moment, for both incoming and outgoing. Many of you may be using older "blue" cards in your NOC phones, SMS gateway devices, or perhaps even your personal mobile devices for those of you who still live in the dark ages of phones that aren't [2.5,3,4,x]G capable. I am unable to diagnose the problems fully, but at least some (if not all) of the SMS-to-email gateway failures are due to mmode.com's MX hosts (in the "airdata.com" zone) being unreachable due to absence of functioning authoritative resolvers for that zone, and possibly other failures as well. This appears to be causing "550 Access Denied" messages being returned to my mobile devices that are sending to email addresses, and mail spooling on my Internet SMTP hosts that are trying to send to the "NPAxxxyyyy(a)mmode.com" addresses for SMTP-to-SMS relay. There is a rumor that this is NOT related to the deactivation of the "downloads" components of the blue network on the 15th, but I suspect that someone just decided to pull the plug on everything. Reading to the end of the thread below, there is someone who states AT&T claims it will be back online by the evening of the 17th at the surprisingly accurate time of 9:55 PM (timezone unstated.) More speculation: http://forums.wireless.att.com/t5/mMode/URGENT-mmode-down-again-Their-mta01… I don't know if this is causing problems with anyone using TAP interfaces, or with any of AT&T's other SMTP<->SMS gateway services like @txt.att.net. SMS, and mobile devices in general, are a single point of failure for contacting on-call staff for various problems - perhaps it's time to insist that everyone carries two mobile devices, on different frequency and technology platforms, with different carriers, and split messages to both due to the anecdotally increasing failure rates of mobile networks. Conspiracy theories of how collusive unreliability would increase ARPU across the board for all carriers would be interesting to hear... but not in this forum, I suspect. :-) JT ------------------------------ Message: 6 Date: Thu, 17 Jun 2010 10:31:57 +0200 From: Lindqvist Kurt Erik <kurtis(a)kurtis.pp.se> Subject: AAAA being added for i.root-servers.net To: NANOG list <nanog(a)nanog.org> Message-ID: <E85117CB-7A03-488E-A8DB-A8764A5C3CD1(a)kurtis.pp.se> Content-Type: text/plain; charset="iso-8859-1" All, This is to inform you that, we (Netnod/Autonomica, operators of i.root-servers.net) have been notified by IANA that on our request an AAAA record will be added to the root-zone with serial number 2010061700. Best regards, - kurtis - --- Kurt Erik Lindqvist, CEO kurtis(a)netnod.se, Direct: +46-8-562 860 11, Switch: +46-8-562 860 00 Please note our new address: Franz?ngatan 5 | SE-112 51 Stockholm | Sweden

1 0

pls help about mtu setting
by Deric Kwok 17 Jun '10

17 Jun '10

Hi My DSL company asks me to set the modem 146 2 and my old company used 14 92 What is the different? Why it is not standard 1 500? Thank you

4 3