November 2011 - Test - lists.nanog.org

Cell-based OOB management devices
by David Hubbard 15 Nov '11

15 Nov '11

Hi all, I am looking at cellular-based devices as a higher speed alternative to dial-up backup access methods for out of band management during emergencies. I was wondering if anyone had experiences with such devices they could share? Devices I've found include Sierra Wireless AirLink Raven X, Digi's ConnectWAN 3G or 4G and Opengear's ACM5004-G. I have no experience with any but they all appear to support the Sprint network which I assume would be ideal due to not having usage caps on data (currently). The Opengear device runs linux and has four serial ports, a usb port for additional storage and ethernet, so it seems to have some small advantages over the others since it could double as an emergency self-contained management station you can SSH into and run diagnostics from. All appear to have VPN/gateway support. What none of them are clear on is how you would connect to it over cellular since I assume you're just paying for a typical data plan and it will randomly obtain IP addresses. Maybe some type of dynamic dns service so you can easily figure out your device's current IP? How stable is the access to the device? Any idea if any of them can do ipv6? Thanks! David

7 6

Re: airgap / negligent homicide charge
by Mickey Fox 14 Nov '11

14 Nov '11

The determination of whether a failure rises to the level of negligent homicide will require a review of industry standards, company standards and sometimes straight common-sence. If the industry standard is airgap re security you are probably okay so long as you review and address the very concerns and questions you are raising in a responsible fashion that does not rely solely on expediency, cost, etc., but looks to real-world scenarios and emergency / backup procedures, equipment, testing and training. Mickey Fox CMK Consulting Services On Nov 14, 2011 9: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: Arguing against using public IP space > (Valdis.Kletnieks(a)vt.edu) > 2. Re: Arguing against using public IP space (Joel jaeggli) > 3. Re: Arguing against using public IP space (Jimmy Hess) > 4. Re: Arguing against using public IP space (Owen DeLong) > 5. Re: Arguing against using public IP space (Dobbins, Roland) > 6. Cable standards question (Sam (Walter) Gailey) > 7. Re: Cable standards question (Daniel Seagraves) > 8. Re: Arguing against using public IP space (Joe Greco) > 9. Re: Arguing against using public IP space (Ray Soucy) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 13 Nov 2011 21:43:32 -0500 > From: Valdis.Kletnieks(a)vt.edu > To: Brett Frankenberger <rbf+nanog(a)panix.com> > Cc: NANOG <nanog(a)nanog.org> > Subject: Re: Arguing against using public IP space > Message-ID: <81357.1321238612(a)turing-police.cc.vt.edu> > Content-Type: text/plain; charset="us-ascii" > > On Sun, 13 Nov 2011 19:14:59 CST, Brett Frankenberger said: > > > What if you air-gap the SCADA network of which you are in > > administrative control, and then there's a failure on it, and the people > > responsible for troubleshooting it can't do it remotely (because of the > > air gap), so the trouble continues for an extra hour while they drive > > to the office, and that extra hour of failure causes someone to die. > > Should that result in a homicide charge? > > If you designed a life-critical airgapped network that didn't have a > trained > warm body at the NOC 24/7 with an airgapped management console, and hot > (or at > least warm) spares for both console and console monkey, yes, you *do* > deserve > that negligent homicide charge. > > >

3 2

equinix sv3 provider recommendations
by Jon Heise 14 Nov '11

14 Nov '11

I'm setting up internet connectivity in the equinix SV3 datacenter, we are already a level3 customer what other providers have been reliable from sv3.

1 0

Re: packet loss out of Texas on Cogent and GlobalCrossing
by Charles Gagnon 14 Nov '11

14 Nov '11

Good point, I can't seem to reproduce with the looking glass interfaces out there. They either don't use enough packets in sequence or don't through the problem hops. On this path: Send ICMP echos to 24.227.216.194, timeout is 2 seconds, maximum hops are 32,1 0ms 1ms 0ms 74.201.153.2212 143ms 10ms 0ms 216.52.95.893 1ms 1ms 1ms 77.67.70.974 1ms 1ms 1ms 213.200.66.2105 3ms 1ms 2ms 66.198.111.976 19ms 7ms 7ms 216.6.87.97 7ms 7ms 7ms 216.6.87.28 6ms 7ms 7ms 66.198.154.149 6ms 7ms 6ms 107.14.19.13210 107ms 108ms 113ms 66.109.10.1111 118ms 144ms 120ms 107.14.17.13912 119ms 120ms 120ms 72.179.205.5913 115ms 115ms 114ms 24.73.240.19514 115ms 115ms 115ms 24.73.240.252 I re-tested and using 100 msg counts, I get 3-6% packet loss on anything after 10. On hops 1-10, I'm all clean. That 66.109.10.11 address is inside TimeWarner/RR so I'll keep trying to contact them. On Mon, Nov 14, 2011 at 2:23 PM, Eric Tykwinski <eric-list(a)truenet.com> wrote: > Have you check the relevant looking glass sites? > > http://www.cogentco.com/en/network/looking-glass > http://www.globalcrossing.com/network/network_looking_glass.aspx > > We are connected to both providers, so everything is looking clean for us. > > Sincerely, > > Eric Tykwinski > TrueNet, Inc. > P: 610-429-8300 > F: 610-429-3222 > > -----Original Message----- > From: Charles Gagnon [mailto:charlesg@unixrealm.com] > Sent: Monday, November 14, 2011 2:11 PM > To: nanog(a)nanog.org > Subject: packet loss out of Texas on Cogent and GlobalCrossing > > I need the Nanog intellect, > > We are seeing packet loss in certain scenarios only on traffic to and from > Austin, TX. The local provider is Time Warner and they are not having > (obvious) problems. We ran tests from NY and NJ over Internap and AboveNet > connections.We only see problems when the traffic goes over gblx or cogent. > Has anyone heard of problem with these carriers out of Texas? > -- > Charles Gagnon > charlesg at unixrealm.com > > > -- Charles Gagnon charlesg at unixrealm.com

2 1

Cable standards question
by Sam (Walter) Gailey 14 Nov '11

14 Nov '11

Hello, newbie question of the morning time, but hopefully not too off-topic... I run a small town network. A new building is being built that the town wants fiber access to. I have to specify for vendors what it is that the town expects in the cabling. I am (obviously) not a fiber expert, and I'm having trouble phrasing the language of the RFP so that we are assured a quality installation. My question is this; Is there an appropriate standard to specify for fiber-optic cabling that if it is followed the fiber will be installed correctly? Would specifying TIA/EIA 568-C.3, for example, be correct? I'm envisioning something like; "The vendor will provide fiber connectivity between (building A) and (building B). Vendor will be responsible for all building penetrations and terminations. When installing the fiber-optic cable the vendor will follow the appropriate TIA/EIA 568 standards for fiber-optic cabling." Any suggestions or examples of language would be very appreciated. Offlist contact is probably best. Many thanks, ---Sam

9 10

packet loss out of Texas on Cogent and GlobalCrossing
by Charles Gagnon 14 Nov '11

14 Nov '11

I need the Nanog intellect, We are seeing packet loss in certain scenarios only on traffic to and from Austin, TX. The local provider is Time Warner and they are not having (obvious) problems. We ran tests from NY and NJ over Internap and AboveNet connections.We only see problems when the traffic goes over gblx or cogent. Has anyone heard of problem with these carriers out of Texas? -- Charles Gagnon charlesg at unixrealm.com

1 0

Copper not dead for super-fast broadband, says BT | Networking | ZDNet UK
by Network IP Dog 14 Nov '11

14 Nov '11

http://www.zdnet.co.uk/news/networking/2011/11/11/copper-not-dead-for-super- fast-broadband-says-bt-40094401/?ps=twitter

1 0

Re: Arguing against using public IP space
by Jay Hennigan 13 Nov '11

13 Nov '11

On 11/13/11 3:58 PM, Jason Lewis wrote: > People keep pointing to this as unlikely. I argue that spammers are > currently doing this all over the world, maybe not as widespread wiith > 1918 space. If I can announce 1918 space to an ISP where my target > is...it doesn't matter if everyone else ignores or drops it. The ISP > allowed it, so all their customers will route the traffic. I still > think it's a valid attack vector, discounting it because people would > laugh at me, seems like a poor security posture. It would be your target announcing the RFC1918 space, so the security risk would be if his ISP, your ISP and all of the intermediate peering/transit links were to honor those announcements and route the traffic to the target. Possible, and it has probably happened at some point, but not likely. The closer your logically to your target the more likely such an attack would succeed. I certainly don't recommend announcing RFC1918 space to the public Internet. Doing so is a bad thing. If you do so there is indeed a non-zero chance that someone close enough to you could connect to your network and do damage. Announcing RFC1918 space is less likely to route very far than announcing public space that isn't allocated to you, however. That's what the spammers all over the world are doing. In terms of security, most every SCADA system, as others have pointed out, should not be connected to the public Internet AT ALL. In this case it really doesn't matter what addressing scheme is used. Use Novell IPX or Appletalk if you want. Or MODBUS. If, however, it is using IPv4, RFC1918 space in a different subnet than anything used internally within the organization is a better choice than any public space or subnets of RFC1918 space in use within the organization. This offers a degree of protection against mis-cabling and other accidental or malicious vectors that could allow other networks to communicate with the SCADA network. It would probably be best if the SCADA hardware vendors were to ship their gear with no IP addresses pre-programmed at all, as well as preventing them from being configured until any default passwords are changed. Similarly, they should educate their installation contractors about such things. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay(a)impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV

1 0

Edgecast network issues seen in combination with lowered MTU
by Owen Roth 11 Nov '11

11 Nov '11

Hello, I had an issue with lowered MTU through a portion of my network, and besides the expected impact, some clients were unable to access resources either directly hosted or indirectly served content by EdgeCast Networks (had to look at traceroutes and view source to determine). I also found nodes that weren't pingable, and didn't appear to have ICMP unreachables available but no directly impacted end-to-end lowered MTU was visible. It seems to be a PathMTU issue or a weird unidirectional MTU issue (?). I have fixed the lowered MTU, and so restored connectivity to affected users -- this is not a current problem but still an incipient one. I consulted with EdgeCast NOC in this matter, but it is hard to demonstrate a <1% problem when it isn't apparent from every other network. Or they may have contracted clue-immunity, it's hard to tell. I've used MTUroute/TCProute and "ping a.b.c.d df-bit size 1500". That did NOT show an issue, 1500 bytes were pingable from the customer end and edge router. Given that I know it was an MTU issue, as that's how I patched and then fixed it, is there another tool that would detect whatever this is? Has anyone else seen this compound problem with EdgeCast Networks? Is "ICMP unreachables" ON to NOT break PMTUD per RFC, still best practice or has that drifted? Regards, Owen

1 0

BGP Update Report
by cidr-report＠potaroo.net 11 Nov '11

11 Nov '11

BGP Update Report Interval: 03-Nov-11 -to- 09-Nov-11 (6 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9829 50212 2.8% 50.7 -- BSNL-NIB National Internet Backbone 2 - AS8402 26154 1.5% 22.0 -- CORBINA-AS OJSC "Vimpelcom" 3 - AS6316 25706 1.5% 659.1 -- AS-PAETEC-NET - PaeTec Communications, Inc. 4 - AS32528 24976 1.4% 12488.0 -- ABBOTT Abbot Labs 5 - AS27738 24092 1.4% 70.9 -- Ecuadortelecom S.A. 6 - AS20632 19812 1.1% 1981.2 -- PETERSTAR-AS PeterStar 7 - AS24722 17705 1.0% 260.4 -- BABILON-AS Babilon-T 8 - AS9498 17067 1.0% 28.5 -- BBIL-AP BHARTI Airtel Ltd. 9 - AS7552 16942 1.0% 12.2 -- VIETEL-AS-AP Vietel Corporation 10 - AS4274 15310 0.9% 189.0 -- ERX-AU-NET Assumption University 11 - AS45595 13295 0.8% 49.6 -- PKTELECOM-AS-PK Pakistan Telecom Company Limited 12 - AS16916 12798 0.7% 752.8 -- NETLOGIC-WEST - INFINIPLEX LLC DBA NETLOGIC 13 - AS5800 12743 0.7% 49.0 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 14 - AS8866 10934 0.6% 218.7 -- BTC-AS Bulgarian Telecommunication Company Plc. 15 - AS47331 10442 0.6% 4.6 -- TTNET TTNet A.S. 16 - AS4766 10388 0.6% 4.4 -- KIXS-AS-KR Korea Telecom 17 - AS28573 9590 0.5% 12.8 -- NET Servicos de Comunicao S.A. 18 - AS24560 9494 0.5% 12.7 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 19 - AS7029 8930 0.5% 3.6 -- WINDSTREAM - Windstream Communications Inc 20 - AS9649 8751 0.5% 182.3 -- MOPH-TH-AP Information Technology Office TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS32528 24976 1.4% 12488.0 -- ABBOTT Abbot Labs 2 - AS17408 3281 0.2% 3281.0 -- ABOVE-AS-AP AboveNet Communications Taiwan 3 - AS20632 19812 1.1% 1981.2 -- PETERSTAR-AS PeterStar 4 - AS8499 1192 0.1% 1192.0 -- Space Hellas S.A. 5 - AS9562 8166 0.5% 1166.6 -- MSU-TH-AP Mahasarakham University 6 - AS44075 1046 0.1% 1046.0 -- GCCNGN GCCNGN AS 7 - AS17425 4074 0.2% 1018.5 -- EPA-AS-TH Provincial Electricity Authority of Thailand. 8 - AS16916 12798 0.7% 752.8 -- NETLOGIC-WEST - INFINIPLEX LLC DBA NETLOGIC 9 - AS10099 742 0.0% 742.0 -- HKUNICOM1-AP China Unicom (Hong Kong) Operations Limited 10 - AS6316 25706 1.5% 659.1 -- AS-PAETEC-NET - PaeTec Communications, Inc. 11 - AS47859 635 0.0% 635.0 -- CLEORON Cleoron Alliance LTD. 12 - AS46983 527 0.0% 527.0 -- SAML-ASN - Southpaw Asset Management LP 13 - AS50977 3656 0.2% 522.3 -- ESYCOR-AS ESYCOR S.A. 14 - AS18409 2598 0.1% 519.6 -- BOT-TH-AS Bank of Thailand, Bangkok, Thailand 15 - AS55696 1004 0.1% 502.0 -- SCOM-AS-ID Starcom Solusindo PT. 16 - AS16898 488 0.0% 488.0 -- LOG-NET - Global Technology Services, Ltd. 17 - AS48068 486 0.0% 486.0 -- VISONIC Visonic Ltd 18 - AS10445 1894 0.1% 473.5 -- HTG - Huntleigh Telcom 19 - AS16391 473 0.0% 473.0 -- CELITO-1 - Celito Communications Inc. 20 - AS3738 1379 0.1% 459.7 -- SSB-ASN - State Street Bank and Trust Company TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 84.204.132.0/24 19734 1.1% AS20632 -- PETERSTAR-AS PeterStar 2 - 206.80.93.0/24 12756 0.7% AS16916 -- NETLOGIC-WEST - INFINIPLEX LLC DBA NETLOGIC 3 - 202.92.235.0/24 12739 0.7% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 4 - 130.36.34.0/24 12488 0.7% AS32528 -- ABBOTT Abbot Labs 5 - 130.36.35.0/24 12488 0.7% AS32528 -- ABBOTT Abbot Labs 6 - 213.16.48.0/24 10728 0.6% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 7 - 66.248.104.0/21 8529 0.5% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 8 - 66.248.120.0/21 8523 0.5% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 9 - 66.248.96.0/21 8517 0.5% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 10 - 221.183.16.0/23 4245 0.2% AS65500 -- -Private Use AS- AS9808 -- CMNET-GD Guangdong Mobile Communication Co.Ltd. 11 - 202.153.174.0/24 3281 0.2% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 12 - 217.52.130.0/24 2525 0.1% AS15475 -- NOL AS36992 -- ETISALAT-MISR 13 - 110.164.24.0/24 2040 0.1% AS9562 -- MSU-TH-AP Mahasarakham University 14 - 110.164.25.0/24 2040 0.1% AS9562 -- MSU-TH-AP Mahasarakham University 15 - 110.164.27.0/24 2040 0.1% AS9562 -- MSU-TH-AP Mahasarakham University 16 - 110.164.26.0/24 2040 0.1% AS9562 -- MSU-TH-AP Mahasarakham University 17 - 202.151.6.0/24 2036 0.1% AS17425 -- EPA-AS-TH Provincial Electricity Authority of Thailand. 18 - 202.151.7.0/24 2036 0.1% AS17425 -- EPA-AS-TH Provincial Electricity Authority of Thailand. 19 - 59.99.0.0/20 1780 0.1% AS9829 -- BSNL-NIB National Internet Backbone 20 - 117.228.0.0/20 1779 0.1% AS9829 -- BSNL-NIB National Internet Backbone Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog(a)nanog.org eof-list(a)ripe.net apops(a)apops.net routing-wg(a)ripe.net afnog(a)afnog.org

1 0