- Test - lists.nanog.org

Who owns (or is allocated) 208.64.200.0/22?
by mikea 08 Mar '11

08 Mar '11

I rise to expose my ignorance. 208.0.0.0/8 is an ARIN block, and ARIN has allocation data for the blocks immediately adjoining 208.64.200.0/22, but no allocation data for 208.64.200.0/22 itself, either in WHOIS or in the website. Nor does 208.64.200.0/22 appear to be "special" in any way. Is this an oversight? How do I get it corrected, if it is? -- Mike Andrews, W5EGO mikea(a)mikea.ath.cx Tired old sysadmin

4 4

Re: [afnog] Suspicious request for IP address space
by Phil Regnauld 08 Mar '11

08 Mar '11

(Cross posting to nanog, apologies if this is considered not appropriate). Shepherd Magumo (shepherd) writes: > Good day, > > I work for an ISP with own small AfriNIC IP block and ASN number and > recently received a second suspicious request for a huge IP address space > with server hosting solution and we are about to turn it down. > > Below is the exact request and I am sure there is something dodge about this > request. Anybody else in ISP receive this? > > We are looking for an IP address space of /17 and we would like to lease it > > for one complete year. Please quote us the price and if its something in > > our > > range, We will go ahead and purchase, Along with it do you provide > > dedicated > > servers and hosting services. Get back to me soon along with the requested > > details. Hi Shepherd, Without disclosing the sender of this mail, do you know where it's originating from, region wise ? The size looks a bit large to be a legitimate request. They might be probing the market to find a LIR willing to go along with a scam. As I see it, if you consider the ratio of available IPv4 space left in the AfriNIC pool vs. the population in Africa, there is a temptation for IPv4 hungry orgs. to acquire v4 space via front companies in Africa, and announce it elsewhere - where the validation process for the appropriate RIR would be more stringent. Cheers, Phil

6 7

Ethernet circuit testing
by Dustin Swinford 08 Mar '11

08 Mar '11

More often on Ethernet services, we experience a customer wanting to see more than an Ookla based server test from our network. Our hands in the field are limited in the number of Ethernet smart loopback devices that they own. If we do have a tester on site, we can generate traffic from an Exfo purpose built appliance toward the loop and determine results. Too often, we have found things such as ftp downloads to be unreliable based on use of server, windows PC doing the download, etc. What other methods are you guys using for testing these services?

6 5

A BGP issue?
by Greg Ihnen 08 Mar '11

08 Mar '11

I run a small network on a mission base in the Amazon jungle which is fed by a satellite internet connection. We had an outage from Feb 25th to the 28th where we had no connectivity with email, http/s, ftp, Skype would indicate it's connected but even chatting failed, basically everything stopped working except for ICMP. I could ping everywhere just fine. I started doing traceroutes and they all were very odd, all not reaching their destination and some hopping all over creation before dying. But if I did traceroute with ICMP it worked fine. Does this indicate our upstream (Bantel.net) had a BGP issue? Bantel blamed Hughesnet which is the service they resell. I'm wondering what kind of problem would let ping work fine but not any of the other protocols. It also seems odd that I could traceroute via UDP part way to a destination but then it would fail if the problem was my own provider. Thanks. If this is the wrong forum for this post I'm sorry and please just hit delete. If this is the wrong forum but you'd be kind enough to share your expertise please reply off-list. Thanks! Here's some examples of the traceroutes I saved during the outage. Using UDP: Gregs-MacBook-Pro:~ GregIhnen$ traceroute metaconi.com traceroute to metaconi.com (70.32.39.205), 64 hops max, 52 byte packets 1 192.168.7.1 (192.168.7.1) 1541.165 ms 25.665 ms 39.211 ms 2 * * * 3 192.168.14.254 (192.168.14.254) 625.710 ms 860.264 ms 694.238 ms 4 192.168.180.5 (192.168.180.5) 645.666 ms 757.161 ms 664.785 ms 5 10.254.253.158 (10.254.253.158) 738.661 ms 801.487 ms 728.139 ms 6 fe11-0-5.miami1.mia.seabone.net (195.22.199.77) 726.884 ms 733.989 ms 647.736 ms 7 te3-4.miami7.mia.seabone.net (195.22.199.97) 740.233 ms 694.619 ms 685.464 ms 8 206.111.1.161.ptr.us.xo.net (206.111.1.161) 639.077 ms 741.495 ms 679.880 ms 9 te-4-1-0.rar3.miami-fl.us.xo.net (207.88.12.161) 650.312 ms 612.386 ms 660.452 ms 10 te-3-2-0.rar3.atlanta-ga.us.xo.net (207.88.12.5) 787.079 ms 725.495 ms 685.068 ms 11 te-11-0-0.rar3.washington-dc.us.xo.net (207.88.12.10) 760.002 ms 828.076 ms 702.041 ms 12 ae0d0.mcr2.chicago-il.us.xo.net (216.156.0.166) 719.324 ms 641.274 ms 689.997 ms 13 ae1d0.mcr1.chicago-il.us.xo.net (216.156.1.81) 669.613 ms 813.794 ms 737.211 ms 14 edge1.chi1.ubiquityservers.com (216.55.8.30) 729.875 ms 751.481 ms 730.088 ms 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * Now here it is again doing traceroute via ICMP: Gregs-MacBook-Pro:~ GregIhnen$ traceroute -I metaconi.com traceroute to metaconi.com (70.32.39.205), 64 hops max, 72 byte packets 1 192.168.7.1 (192.168.7.1) 5.254 ms 3.059 ms 2.578 ms 2 * * * 3 192.168.14.254 (192.168.14.254) 1511.146 ms 711.304 ms 822.967 ms 4 192.168.180.5 (192.168.180.5) 712.672 ms 821.990 ms 713.009 ms 5 10.254.253.158 (10.254.253.158) 823.244 ms 711.764 ms 823.219 ms 6 fe11-0-5.miami1.mia.seabone.net (195.22.199.77) 712.640 ms 613.306 ms 614.429 ms 7 te3-4.miami7.mia.seabone.net (195.22.199.97) 823.232 ms 711.881 ms 823.166 ms 8 206.111.1.161.ptr.us.xo.net (206.111.1.161) 712.765 ms 822.398 ms 712.531 ms 9 te-4-1-0.rar3.miami-fl.us.xo.net (207.88.12.161) 822.809 ms 920.831 ms 712.399 ms 10 te-3-2-0.rar3.atlanta-ga.us.xo.net (207.88.12.5) 823.288 ms 711.478 ms 822.887 ms 11 te-11-0-0.rar3.washington-dc.us.xo.net (207.88.12.10) 712.705 ms 822.287 ms 712.713 ms 12 * ae0d0.mcr2.chicago-il.us.xo.net (216.156.0.166) 738.656 ms 919.752 ms 13 ae1d0.mcr1.chicago-il.us.xo.net (216.156.1.81) 921.381 ms 920.884 ms 1228.683 ms 14 edge1.chi1.ubiquityservers.com (216.55.8.30) 921.560 ms 920.482 ms 921.634 ms 15 relativity.mrk.com (70.32.39.205) 880.318 ms 753.150 ms 823.285 ms Gregs-MacBook-Pro:~ GregIhnen$ Here's an example of a UDP traceroute going all over creation: Gregs-MacBook-Pro:~ GregIhnen$ traceroute skype.com traceroute to skype.com (78.141.177.7), 64 hops max, 52 byte packets 1 192.168.7.1 (192.168.7.1) 18.939 ms 4.596 ms 27.124 ms 2 * * * 3 192.168.14.254 (192.168.14.254) 724.034 ms 704.520 ms 823.886 ms 4 192.168.180.5 (192.168.180.5) 711.962 ms 704.606 ms 823.208 ms 5 10.254.253.158 (10.254.253.158) 712.622 ms 912.870 ms 921.471 ms 6 fe11-0-5.miami1.mia.seabone.net (195.22.199.77) 712.642 ms 822.307 ms 712.720 ms 7 * te9-1.ccr01.mia03.atlas.cogentco.com (154.54.11.37) 3692.277 ms 702.345 ms 8 te9-1.ccr01.mia03.atlas.cogentco.com (154.54.11.37) 823.172 ms 920.050 ms 921.612 ms 9 te8-2.ccr01.mia01.atlas.cogentco.com (154.54.28.245) 921.681 ms te8-7.ccr02.mia01.atlas.cogentco.com (154.54.1.185) 703.270 ms te8-2.ccr02.mia01.atlas.cogentco.com (154.54.2.153) 730.152 ms 10 te0-0-0-5.ccr21.atl01.atlas.cogentco.com (154.54.30.33) 797.769 ms te2-1.ccr02.atl01.atlas.cogentco.com (154.54.3.25) 913.513 ms te0-1-0-4.ccr21.atl01.atlas.cogentco.com (154.54.24.161) 782.095 ms 11 te0-4-0-7.ccr21.dca01.atlas.cogentco.com (154.54.42.189) 814.870 ms te0-5-0-7.ccr22.dca01.atlas.cogentco.com (154.54.42.201) 815.878 ms te0-2-0-3.ccr21.dca01.atlas.cogentco.com (154.54.24.9) 912.453 ms 12 te0-5-0-6.ccr22.jfk02.atlas.cogentco.com (154.54.42.30) 913.183 ms te0-2-0-2.ccr21.jfk02.atlas.cogentco.com (154.54.26.186) 913.078 ms te0-4-0-7.ccr22.jfk02.atlas.cogentco.com (154.54.41.14) 913.268 ms 13 te2-8.ccr02.lon02.atlas.cogentco.com (154.54.30.22) 833.515 ms te0-4-0-7.mpd22.jfk02.atlas.cogentco.com (154.54.41.30) 702.568 ms te0-4-0-7.ccr22.bos01.atlas.cogentco.com (154.54.44.50) 815.549 ms 14 te0-3-0-2.ccr21.bos01.atlas.cogentco.com (154.54.44.14) 1010.769 ms te0-1-0-5.ccr21.bos01.atlas.cogentco.com (154.54.44.30) 913.070 ms te4-8.ccr01.lon01.atlas.cogentco.com (130.117.0.186) 913.076 ms 15 te7-3.mpd02.lon01.atlas.cogentco.com (154.54.30.130) 913.495 ms te4-4.mpd02.lon01.atlas.cogentco.com (130.117.1.134) 831.442 ms te1-1.mpd02.lon01.atlas.cogentco.com (154.54.5.162) 811.198 ms 16 te0-0-0-0.mpd21.par01.atlas.cogentco.com (130.117.2.5) 913.200 ms 912.636 ms te1-4.ccr01.bru01.atlas.cogentco.com (130.117.51.106) 921.496 ms 17 te0-0-0-0.mpd21.par01.atlas.cogentco.com (130.117.2.5) 913.344 ms 920.902 ms te1-4.ccr01.bru01.atlas.cogentco.com (130.117.51.106) 921.368 ms 18 149.6.134.86 (149.6.134.86) 920.406 ms 1014.226 ms * 19 213.166.61.194 (213.166.61.194) 959.442 ms 828.583 ms 920.909 ms 20 213.135.247.42 (213.135.247.42) 1019.971 ms 78.141.177.7 (78.141.177.7) 988.848 ms 213.135.247.42 (213.135.247.42) 1011.307 ms Gregs-MacBook-Pro:~ GregIhnen$ UDP traceroute worked to Google though I still couldn't load their pages Gregs-MacBook-Pro:~ GregIhnen$ traceroute google.com traceroute to google.com (74.125.229.114), 64 hops max, 52 byte packets 1 192.168.7.1 (192.168.7.1) 5.023 ms 3.971 ms 6.712 ms 2 * * * 3 192.168.14.254 (192.168.14.254) 1471.985 ms 643.770 ms 785.534 ms 4 192.168.180.5 (192.168.180.5) 712.715 ms 704.409 ms 626.374 ms 5 10.254.253.158 (10.254.253.158) 808.083 ms 647.244 ms 619.878 ms 6 fe11-0-5.miami1.mia.seabone.net (195.22.199.77) 776.534 ms 711.870 ms 640.372 ms 7 * te7-1.miami7.mia.seabone.net (195.22.199.109) 810.819 ms 731.713 ms 8 google.miami7.mia.seabone.net (89.221.41.18) 712.471 ms google.miami7.mia.seabone.net (89.221.41.74) 703.638 ms google.miami7.mia.seabone.net (89.221.41.18) 704.814 ms 9 209.85.253.116 (209.85.253.116) 822.336 ms 761.621 ms 209.85.253.74 (209.85.253.74) 709.705 ms 10 209.85.254.180 (209.85.254.180) 705.062 ms 702.723 ms 824.497 ms 11 74.125.229.114 (74.125.229.114) 712.196 ms 704.509 ms 596.077 ms Gregs-MacBook-Pro:~ GregIhnen$

5 6

RE: [arin-ppml] why hp bladeserver chassis have a sudden interest in thailand.
by Henault, Ken 08 Mar '11

08 Mar '11

HP has identified a DNS related issue with HP Virtual Connect that does not impact data traffic but does impair the manageability of Virtual Connect devices. HP is acting promptly to help customers remove this issue in the short term with an interim resolution. A permanent firmware fix will be available in the next three weeks. Customer Advisory Document ID: c02720395, March 7, 2011 is available now at the url below to resolve this issue. If you have questions or need assistance, contact HP Support in your home country. HP is committed to minimizing any impact on customer environments and to resolving the issue as quickly as possible. Download Customer Advisory Document ID: c02720395, March 7, 2011: http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=c027… Visit the HP Support worldwide contact list: http://welcome.hp.com/country/us/en/wwcontact_us.html

1 0

why hp bladeserver chassis have a sudden interest in thailand.
by Joel Jaeggli 08 Mar '11

08 Mar '11

http://forums11.itrc.hp.com/service/forums/questionanswer.do?admit=10944762… As a potentially cautionary tale for the squatting on unused pieces of address space either in your network or applications. drive slow (and filter 22 outgoing to 49.48.46.49 until you get new firmware) joel

5 4

the largest deployment of v6 in japan
by Randy Bush 08 Mar '11

08 Mar '11

http://avexnet.or.jp/v6/ http://en.wikipedia.org/wiki/V6_%28band%29

2 1

About the different causes of multiple origin ASN(MOAS) problem
by Yaoqing(Joey) Liu 08 Mar '11

08 Mar '11

Hi, I'm trying to find all causes of multiple origin AS problem(MOAS) as follows, but not sure if it's complete. Also please let me know how popular each item is, especially item 3 and 4 that I'm very curious about. 1. Internet Exchange Points, we have observed a list of this prefixes, although they generally are not announced to the DFZ. 2. Anycast, rare, but occurs sometimes, for example, 192.88.99.0/24, 2002::/16, and 2001::/32 3. Multi-homing with Private AS number 4. Multi-homing using static route (customer doesn't have AS number) 5. Misconfiguration 6. Hijacking 7. What else? Thanks, Yaoqing

3 2

Re: NANOG Digest, Vol 38, Issue 26
by Yaoqing(Joey) Liu 08 Mar '11

08 Mar '11

> > Message: 9 > Date: Mon, 7 Mar 2011 11:32:39 -0600 > From: "Yaoqing(Joey) Liu" <joey.liuyq(a)gmail.com> > Subject: About the different causes of multiple origin ASN(MOAS) > problem > To: nanog(a)nanog.org > Message-ID: > <AANLkTi=RpzYDhcroH2043uiA7XDa0Apo2cHhu6y6XC6V(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi, > > I'm trying to find all causes of multiple origin AS problem(MOAS) as > follows, but not sure if it's complete. Also please let me know how popular > each item is, especially item 3 and 4 that I'm very curious about. > > 1. Internet Exchange Points, we have observed a list of this prefixes, > although they generally are not announced to the DFZ. > 2. Anycast, rare, but occurs sometimes, for example, 192.88.99.0/24, > 2002::/16, and 2001::/32 > 3. Multi-homing with Private AS number > 4. Multi-homing using static route (customer doesn't have AS number) > 5. Misconfiguration > 6. Hijacking > 7. What else? > > Thanks, > Yaoqing > > > ------------------------------ > > Message: 10 > Date: Tue, 8 Mar 2011 01:02:19 +0000 > From: "Dobbins, Roland" <rdobbins(a)arbor.net> > Subject: Re: About the different causes of multiple origin ASN(MOAS) > problem > To: nanog group <nanog(a)nanog.org> > Message-ID: <6A23D7CB-9DA4-48DF-B655-B1397C573BF6(a)arbor.net> > Content-Type: text/plain; charset="us-ascii" > > > On Mar 8, 2011, at 1:32 AM, Yaoqing(Joey) Liu wrote: > > > I'm trying to find all causes of multiple origin AS problem(MOAS) as > > follows, but not sure if it's complete. > > 1. MOAS isn't necessarily a 'problem'; it's fairly common, these days, > and has been for quite some time. The actual problem is the inability to > determine when it's intentional and not evil, vs. unintentional or > intentional and evil. > Good point. That's why I need to have a complete cause list first, then I can try to tell the evil from the good. > > 2. There's already a fair body of work on this topic, as a Web search > for "multiple origin as" reveals. Check the NANOG archives for Lixia's > preso, among others. > I know a lot of previous work about MOAS, but they were not comprehensive enough to drill down to the prefix level and also the results have been outdated. We need to know what things were going on recently. Yaoqing > > ----------------------------------------------------------------------- > Roland Dobbins <rdobbins(a)arbor.net> // <http://www.arbornetworks.com> > > The basis of optimism is sheer terror. > > -- Oscar Wilde > > > > > ------------------------------ > > _______________________________________________ > NANOG mailing list > NANOG(a)nanog.org > https://mailman.nanog.org/mailman/listinfo/nanog > > End of NANOG Digest, Vol 38, Issue 26 > ************************************* >

2 2

NANOG List Outages
by Michael K. Smith - Adhost 08 Mar '11

08 Mar '11

Hello: We had a system issue over the weekend that interrupted delivery of all of the NANOG mailing lists. We are working presently to clear the queues of the various applications that service the lists. I anticipate we will have "complete" delivery within a few hours. If you find that messages you sent to the lists have not been processed and you feel they need to be part of the lists, please send your message(s) again. We apologize for any inconvenience this may have caused. If you have further issues please send emal to admins(a)nanog.org and we will do our best to assist you. Regards, Mike On behalf of the NANOG Communications Committee -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksmith(a)adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)

1 0