RE: IPv4 address shortage? Really?

[Nathan Eisenberg]

> And I fully expect that to be done at some point or another.  Country
> takes the entire 32bit address space for itself.  You want to serve
> that
> country?  Fine, apply for an allocation out of their /0 and route to it
> over v6.

What happens when countries are formed from secession?  Does one half have to 
renumber?  ;)

Re: A BGP issue?

[Hank Nussbacher]

At 21:49 07/03/2011 -0500, Patrick W. Gilmore wrote:

On Mar 7, 2011, at 14:27, Greg Ihnen  wrote:

> 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!


Honestly, I would rate this as one of the most on-topic posts in a while.


+1.
When you have http working I suggest running:
http://netalyzr.icsi.berkeley.edu/index.html
to give you a benchmark of what your connection can do in the way of protocols.

Regards,
Hank

Re: About the different causes of multiple origin ASN(MOAS) problem

[Gaurab Raj Upadhaya]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 3/7/11 5:32 PM, Yaoqing(Joey) Liu wrote:

> 4. Multi-homing using static route (customer doesn't have AS number)

4a: Upstream forces static routes, because they can't support 4 byte ASN
(or don't want to).

- -gaurab


> 5. Misconfiguration
> 6. Hijacking
> 7. What else?



- -- 

http://www.gaurab.org.np/


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk112mYACgkQSo7fU26F3X2m7QCgiE5VDvKanS6EhhPy9N7sv6CK
nhEAn0Smmxjoi2K9Tn/1lo74/iYzTEHQ
=h7tS
-END PGP SIGNATURE-

RE: IPv4 address shortage? Really?

[George Bonser]

>   well... not that it gained any traction atall, but given
>   the actual size/complexity of the global interconnect mesh,
>   we -could- ease the transition timing by many years with the
>   following administrative change.  No tricks, no OS hacks,
>   no changes to software anywhere..  just a bit of renumbering...
> 
>   recipie:
> 
>   the usable IPv4 ranges
>   RFC 1918
> 
>   Step one:   Invert RFC 1918 to define the global Internets
> interconnection
>   mesh.
>   Step two:   make all other usable IPv4 space "private".
> 
>   Serves 2,000,000 million clients w/o changing to a new protocol
> family.
> 
> 
> Enjoy!
> 
> --bill

And I fully expect that to be done at some point or another.  Country
takes the entire 32bit address space for itself.  You want to serve that
country?  Fine, apply for an allocation out of their /0 and route to it
over v6.

Re: why hp bladeserver chassis have a sudden interest in thailand.

[Randy Bush]

> http://forums11.itrc.hp.com/service/forums/questionanswer.do?admit=109447626+1299558177753+28353475&threadId=1471451

rofl.  the goddesses are indeed just.

randy

RE: Ethernet circuit testing

[Frank Bulk]

I've heard good things from a neighbor service provider that uses EXFO's
EtherSAM.

Frank

-Original Message-
From: Dustin Swinford [mailto:dustinna...@gmail.com] 
Sent: Monday, March 07, 2011 2:07 PM
To: nanog@nanog.org
Subject: Ethernet circuit testing

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?  

 

 

 

Re: why hp bladeserver chassis have a sudden interest in thailand.

[Kevin Day]

On Mar 7, 2011, at 10:47 PM, Jay Ashworth wrote:

> - Original Message -
>> From: "Joel Jaeggli" 
> 
>> http://forums11.itrc.hp.com/service/forums/questionanswer.do?admit=109447626+1299558177753+28353475&threadId=1471451
>> 
>> 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)
> 
> (HP Blades apparently depended on rDNS for 49.48/16 failing hard, which 
> stopped happening when the block was allocated)

For those at home scratching their heads, I ran into this before too when 
trying to figure out why they were making in-addr.arpa requests over and over 
again...

49 decimal in ASCII = "1"
48 decimal in ASCII = "0"
46 decimal in ASCII = "."
49 decimal in ASCII = "1"
or "10.1"

If you had a hard-coded IP address instead of a hostname for its management 
host, the logic to resolve the hostname would get confused and attempt to do a 
reverse-dns lookup of the first 4 characters of the ASCII representation of the 
hostname, and connect to that instead. So, if your management host was 
"10.1.1.1" the first 4 characters were "10.1" which is 49.48.46.49 if you smash 
the values of each character into a v4 address and try to grab a PTR record for 
it. If that lookup failed, it'd fall back to connecting to the IP correctly. 
Only after 49.48/16 was assigned and started giving out PTR records did this 
bug actually do anything.

It is attempting to SSH to the host at 49.48.46.49 though, which is probably 
bad.


(the above is my own attempt at figuring out what was happening, but might not 
be 100% accurate)

Re: why hp bladeserver chassis have a sudden interest in thailand.

[Jay Ashworth]

- Original Message -
> From: "Joel Jaeggli" 

> http://forums11.itrc.hp.com/service/forums/questionanswer.do?admit=109447626+1299558177753+28353475&threadId=1471451
> 
> 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)

(HP Blades apparently depended on rDNS for 49.48/16 failing hard, which 
stopped happening when the block was allocated)

Hey, isn't this what I was talking about a week or two ago: applications
depending on DNS not lying to them about whether things actually exist or
not?  (Ok, it's a *bit* sideways, but not much...)

Cheers,
-- jra

why hp bladeserver chassis have a sudden interest in thailand.

[Joel Jaeggli]

http://forums11.itrc.hp.com/service/forums/questionanswer.do?admit=109447626+1299558177753+28353475&threadId=1471451

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

Re: NANOG Digest, Vol 38, Issue 26

[Yaoqing(Joey) Liu]

On Mon, Mar 7, 2011 at 9:17 PM, Randy Bush  wrote:

> > 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.
>
> there is no complete cause list
>

I admit it's basically impossible to get a complete list, but at least, I
want to have a try to make it as complete as possible in order to
understand the issue. I think industry people should have more experience to
give me the answer, since all the data come from the real practice. For
example, how popular private AS number used for multi-homing, and how
popular one organization has no AS number using static routing.

Yaoqing

>
> you can not know evil from good because you have no way of knowing
> intent
>



>
> haven't you ucla people figured this out yet?
>
> randy
>

Re: IPv4 address shortage? Really?

[bmanning]

On Mon, Mar 07, 2011 at 08:15:20PM -0600, Jima wrote:
> On 3/7/2011 5:43 AM, Vadim Antonov wrote:
> >I'm wondering (and that shows that I have nothing better to do at 3:30am
> >on Monday...) how many people around here realize that the plain old
> >IPv4 - as widely implemented and specified in standard RFCs can be
> >easily used to connect pretty much arbitrary number (arbitrary means
> >>2^256) of computers WITHOUT NETWORK ADDRESS TRANSLATION.  Yes, you hear
> >me right.
> 
>  This seems like either truly bizarre trolling, or the misguided idea 
> of someone who's way too invested in IPv4 and hasn't made any necessary 
> plans or steps to implement IPv6.  To implement this -- which, to begin 
> with, seems like a bad idea to me (and judging by Mr. Andrews' response, 
> others) -- you'd have to overhaul software on many, many computers, 
> routers, and other devices.  (Wait, why does this sound familiar?)  Of 
> course, the groundwork would need to be laid out and discussed, which 
> will probably cost us a few years...too bad we don't have a plan that 
> could be put into action sooner, or maybe even was already deployed.
> 
>  Anyway, the needless ROT13 text fairly well convinced me that our 
> messages may be traveling over an ethernet bridge.
> 
>  Jima


well... not that it gained any traction atall, but given
the actual size/complexity of the global interconnect mesh,
we -could- ease the transition timing by many years with the
following administrative change.  No tricks, no OS hacks,
no changes to software anywhere..  just a bit of renumbering...

recipie:

the usable IPv4 ranges
RFC 1918

Step one:   Invert RFC 1918 to define the global Internets 
interconnection
mesh.
Step two:   make all other usable IPv4 space "private".

Serves 2,000,000 million clients w/o changing to a new protocol family.


Enjoy!

--bill

Re: NANOG Digest, Vol 38, Issue 26

[Randy Bush]

> 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.

there is no complete cause list

you can not know evil from good because you have no way of knowing
intent

haven't you ucla people figured this out yet?

randy

Re: NANOG Digest, Vol 38, Issue 26

[Yaoqing(Joey) Liu]

>
> Message: 9
> Date: Mon, 7 Mar 2011 11:32:39 -0600
> From: "Yaoqing(Joey) Liu" 
> Subject: About the different causes of multiple origin ASN(MOAS)
>problem
> To: nanog@nanog.org
> Message-ID:
>
> 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 +
> From: "Dobbins, Roland" 
> Subject: Re: About the different causes of multiple origin ASN(MOAS)
>problem
> To: nanog group 
> Message-ID: <6a23d7cb-9da4-48df-b655-b1397c573...@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  // 
>
>The basis of optimism is sheer terror.
>
>  -- Oscar Wilde
>
>
>
>
> --
>
> ___
> NANOG mailing list
> NANOG@nanog.org
> https://mailman.nanog.org/mailman/listinfo/nanog
>
> End of NANOG Digest, Vol 38, Issue 26
> *
>

Re: A BGP issue?

[Patrick W. Gilmore]

On Mar 7, 2011, at 14:27, Greg Ihnen  wrote:

> 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!

Honestly, I would rate this as one of the most on-topic posts in a while.

BGP only handles reachability, not higher level protocols.  (Of course, you can 
h4x0r anything to do jus about anything, but we are talking the general case 
here.)

If you can ping, BGP is working.  If you can ping and cannot use TCP, then 
something other than BGP is at fault. 

I've seen strange things like someone enabling TCP compression (common on very 
small or very expensive links) one side but not the other, which then allowed 
ICMP and UDP but not TCP.  It is a great way to annoy someone.  "See, I can 
ping, it must be your side!"

Have you tried TCP traceroute?  Or telnetting to port 80?

-- 
TTFN,
patrick

> 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 

Re: IPv4 address shortage? Really?

[Warren Kumari]

On Mar 7, 2011, at 8:48 PM, Mark Andrews wrote:

> 
> This has been thought of before, discussed and rejected.

But has this: 
http://tools.ietf.org/id/draft-terrell-math-quant-ternary-logic-of-binary-sys-12.txt
 ?

Please read and explain *exactly* why it doesn't work...

W



> 
> In message <1299498200.29652.40.ca...@kotti.kotovnik.com>, Vadim Antonov 
> writes
> :
>> I'm wondering (and that shows that I have nothing better to do at 3:30am
>> on Monday...) how many people around here realize that the plain old
>> IPv4 - as widely implemented and specified in standard RFCs can be
>> easily used to connect pretty much arbitrary number (arbitrary means
>>> 2^256) of computers WITHOUT NETWORK ADDRESS TRANSLATION.  Yes, you hear
>> me right.
>> 
>> And, no, it does not require any changes any in the global routing
>> infrastructure - as implemented now, and most OS kernels (those which
>> aren't broken-as-designed, grin) would do the trick just fine.  None of
>> that dual-stack stupidity, and, of course, no chicken-and-egg problem if
>> the servers and gateways can be made to respect really old and
>> well-established standards.
>> 
>> DNS and most applications would need some (fairly trivial) updating,
>> though, to work properly with the extended addressing; and sysadmins
>> would need to do tweaks in their configs since some mythology-driven
>> "security" can get in the way.  But they don't have to do that en mass
>> and all at once.
>> 
>> The most obvious solution to the non-problem of address space shortage
>> is the hardest to notice, ain't it?
>> 
>> --vadim
>> 
>> P.S. Hfr YFEE gb ebhgr orgjrra cevingr nqqerff fcnprf bire choyvpnyyl
>> ebhgrq fcnpr, Yhxr. Guvax bs cevingr nqqerff ovgf nf n evtug-fvqr
>> rkgrafvba gb gur sbhe-bpgrg choyvp nqqerff.
>> 
>> P.P.S. Gb rkgraq shegure, nygreangr gjb qvfgvapg cevingr nqqerff fcnprf,
>> nf znal gvzrf nf lbh pna svg vagb gur urnqre.
>> 
>> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org


W

PS: :-)   

Re: IPv4 address shortage? Really?

[Scott W Brim]

There are a number of reasons why you want IP addresses to be globally
unique, even if they are not globally routed.

Re: IPv4 address shortage? Really?

[Jima]

On 3/7/2011 5:43 AM, Vadim Antonov wrote:

I'm wondering (and that shows that I have nothing better to do at 3:30am
on Monday...) how many people around here realize that the plain old
IPv4 - as widely implemented and specified in standard RFCs can be
easily used to connect pretty much arbitrary number (arbitrary means

2^256) of computers WITHOUT NETWORK ADDRESS TRANSLATION.  Yes, you hear

me right.


 This seems like either truly bizarre trolling, or the misguided idea 
of someone who's way too invested in IPv4 and hasn't made any necessary 
plans or steps to implement IPv6.  To implement this -- which, to begin 
with, seems like a bad idea to me (and judging by Mr. Andrews' response, 
others) -- you'd have to overhaul software on many, many computers, 
routers, and other devices.  (Wait, why does this sound familiar?)  Of 
course, the groundwork would need to be laid out and discussed, which 
will probably cost us a few years...too bad we don't have a plan that 
could be put into action sooner, or maybe even was already deployed.


 Anyway, the needless ROT13 text fairly well convinced me that our 
messages may be traveling over an ethernet bridge.


 Jima

Re: Switch with 10 Gig and GRE support in hardware.

[Nitzan Tzelniker]

HP A5820 (3com/H3C in the past )  is doing 24*10GE + GRE (we test it )
btw in the latest release it is also doing mpls (not test it yet )

Nitzan

On Tue, Mar 1, 2011 at 17:28, Leigh Porter wrote:

> OK. Please show me a “switch” that will terminate Layer 3 GRE tunnels..
>
>
>
> If it does GRE then it is making Layer 3 forwarding decisions which is a
> router function. It may be built into a switch as well, but it is still a
> router.
>
>
>
> --
>
> Leigh Porter
>
>
>
>
>
> From: tsi...@gmail.com [mailto:tsi...@gmail.com]
> Sent: 01 March 2011 15:10
> To: sth...@nethelp.no; Leigh Porter
> Cc: nanog@nanog.org
> Subject: Re: Switch with 10 Gig and GRE support in hardware.
>
>
>
> is the requirment still 1-2 U switch?
>
> - Reply message -
> From: sth...@nethelp.no
> Date: Tue, Mar 1, 2011 4:44 am
> Subject: Switch with 10 Gig and GRE support in hardware.
> To: 
> Cc: 
>
>
> > Juniper MX80 does all this.
>
> 1. It's not a switch (so don't expect "switch pricing").
> 2. It doesn't offer 12 x 10GE ports.
>
> And I believe this has been mentioned earlier in the same thread...
>
> Steinar Haug, Nethelp consulting, sth...@nethelp.no
>
>
>
>
>

Re: IPv4 address shortage? Really?

[Mark Andrews]

This has been thought of before, discussed and rejected.

In message <1299498200.29652.40.ca...@kotti.kotovnik.com>, Vadim Antonov writes
:
> I'm wondering (and that shows that I have nothing better to do at 3:30am
> on Monday...) how many people around here realize that the plain old
> IPv4 - as widely implemented and specified in standard RFCs can be
> easily used to connect pretty much arbitrary number (arbitrary means
> >2^256) of computers WITHOUT NETWORK ADDRESS TRANSLATION.  Yes, you hear
> me right.
> 
> And, no, it does not require any changes any in the global routing
> infrastructure - as implemented now, and most OS kernels (those which
> aren't broken-as-designed, grin) would do the trick just fine.  None of
> that dual-stack stupidity, and, of course, no chicken-and-egg problem if
> the servers and gateways can be made to respect really old and
> well-established standards.
> 
> DNS and most applications would need some (fairly trivial) updating,
> though, to work properly with the extended addressing; and sysadmins
> would need to do tweaks in their configs since some mythology-driven
> "security" can get in the way.  But they don't have to do that en mass
> and all at once.
> 
> The most obvious solution to the non-problem of address space shortage
> is the hardest to notice, ain't it?
> 
> --vadim
> 
> P.S. Hfr YFEE gb ebhgr orgjrra cevingr nqqerff fcnprf bire choyvpnyyl
> ebhgrq fcnpr, Yhxr. Guvax bs cevingr nqqerff ovgf nf n evtug-fvqr
> rkgrafvba gb gur sbhe-bpgrg choyvp nqqerff.
> 
> P.P.S. Gb rkgraq shegure, nygreangr gjb qvfgvapg cevingr nqqerff fcnprf,
> nf znal gvzrf nf lbh pna svg vagb gur urnqre.
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: IPv4 address shortage? Really?

[Christopher Morrow]

On Mon, Mar 7, 2011 at 6:43 AM, Vadim Antonov  wrote:
>
> --vadim
>
> P.S. Hfr YFEE gb ebhgr orgjrra cevingr nqqerff fcnprf bire choyvpnyyl
> ebhgrq fcnpr, Yhxr. Guvax bs cevingr nqqerff ovgf nf n evtug-fvqr
> rkgrafvba gb gur sbhe-bpgrg choyvp nqqerff.
>
> P.P.S. Gb rkgraq shegure, nygreangr gjb qvfgvapg cevingr nqqerff fcnprf,
> nf znal gvzrf nf lbh pna svg vagb gur urnqre.

Gbqq Haqrejbbq jbhyq ybir lbhe fbyhgvba! Cebcf!

Re: Ethernet circuit testing

[Sherwin Ang]

RFC2544 testers.

On Tue, Mar 8, 2011 at 4:06 AM, Dustin Swinford  wrote:
> 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?
>
>
>
>
>
>
>
>

NANOG List Outages

[Michael K. Smith - Adhost]

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 adm...@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 mksm...@adhost.com
w: +1 (206) 404-9500 f: +1 (206) 404-9050
PGP: B49A DDF5 8611 27F3  08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)

Re: About the different causes of multiple origin ASN(MOAS) problem

[Dobbins, Roland]

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.

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.

---
Roland Dobbins  // 

The basis of optimism is sheer terror.

  -- Oscar Wilde

About the different causes of multiple origin ASN(MOAS) problem

[Yaoqing(Joey) Liu]

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

Re: Ethernet circuit testing

[Tim Jackson]

http://documents.exfo.com/specsheets/ETS-1000L-angHR.pdf

We use these for
testing, much cheaper than a full test set...



On Mon, Mar 7, 2011 at 2:06 PM, Dustin Swinford wrote:

> 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?
>
>
>
>
>
>
>
>

RE: Ethernet circuit testing

[Holmes,David A]

EXFO purchased the BRIX active management system a couple of years ago. BRIX 
can be used to determine basic rtt, packet loss, jitter, and also contains a 
suite of application tests such as ftp, various voice codecs, etc.

-Original Message-
From: Dustin Swinford [mailto:dustinna...@gmail.com] 
Sent: Monday, March 07, 2011 12:07 PM
To: nanog@nanog.org
Subject: Ethernet circuit testing

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?  

 

 

 

Ethernet circuit testing

[Dustin Swinford]

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?  

 

 

 

IPv4 address shortage? Really?

[Vadim Antonov]

I'm wondering (and that shows that I have nothing better to do at 3:30am
on Monday...) how many people around here realize that the plain old
IPv4 - as widely implemented and specified in standard RFCs can be
easily used to connect pretty much arbitrary number (arbitrary means
>2^256) of computers WITHOUT NETWORK ADDRESS TRANSLATION.  Yes, you hear
me right.

And, no, it does not require any changes any in the global routing
infrastructure - as implemented now, and most OS kernels (those which
aren't broken-as-designed, grin) would do the trick just fine.  None of
that dual-stack stupidity, and, of course, no chicken-and-egg problem if
the servers and gateways can be made to respect really old and
well-established standards.

DNS and most applications would need some (fairly trivial) updating,
though, to work properly with the extended addressing; and sysadmins
would need to do tweaks in their configs since some mythology-driven
"security" can get in the way.  But they don't have to do that en mass
and all at once.

The most obvious solution to the non-problem of address space shortage
is the hardest to notice, ain't it?

--vadim

P.S. Hfr YFEE gb ebhgr orgjrra cevingr nqqerff fcnprf bire choyvpnyyl
ebhgrq fcnpr, Yhxr. Guvax bs cevingr nqqerff ovgf nf n evtug-fvqr
rkgrafvba gb gur sbhe-bpgrg choyvp nqqerff.

P.P.S. Gb rkgraq shegure, nygreangr gjb qvfgvapg cevingr nqqerff fcnprf,
nf znal gvzrf nf lbh pna svg vagb gur urnqre.

Something is worng with the list I think .

[Mr. James W. Laferriere]

	Hello All ,  Nothing in the archive nor in the mailbox ,  Testing if 
mail server is actually accepting mail .

Sorry ,  JimL
--
+--+
| James   W.   Laferriere | SystemTechniques | Give me VMS |
| Network&System Engineer | 3237 Holden Road |  Give me Linux  |
| bab...@baby-dragons.com | Fairbanks, AK. 99709 |   only  on  AXP |
+--+

Re: Real World NAT64 deployments

[MAWATARI Masataka]

JPIX started XLATE trial service for our IX members in July 2010.
I talked about this service status at APRICOT 2011 last month.
Please see a presentation material below.
http://www.apricot-apan.asia/__data/assets/pdf_file/0018/31365/Masataka_Mawatari_IPv6v4_Exchange_Service_for_sharing_IPv4_address.pdf

If you have any comments, please let me know.


Regards,
Masataka MAWATARI


* On Thu, 3 Mar 2011 13:31:06 -0700
* Elliot Finley  wrote:

> So as not to re-invent the wheel - if you are currently doing NAT64 in
> production and are willing to share:
> 
> What software/hardware are you using?
> 
> Why?
> 
> TIA
> Elliot

Something is worng with the list I think .

[Mr. James W. Laferriere]

	Hello All ,  Nothing in the archive nor in the mailbox ,  Testing if 
mail server is actually accepting mail .

Sorry ,  JimL
ps: with the right domain nake this time .
--
+--+
| James   W.   Laferriere | SystemTechniques | Give me VMS |
| Network&System Engineer | 3237 Holden Road |  Give me Linux  |
| bab...@baby-dragons.com | Fairbanks, AK. 99709 |   only  on  AXP |
+--+

A BGP issue?

[Greg Ihnen]

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.