- NANOG - lists.nanog.org

DENOG1 conference registrations are now open
by Marcus Stoegbauer 03 Sep '09

03 Sep '09

Hi all, the German Network Operators Group (DENOG) is holding its first meeting on the 5th of November 2009 in Frankfurt, Germany. Registrations are now open at http://meeting.denog.de/registration_en.html Please note that you can benefit from our early bird rebate if you register early. A full agenda will be available until the end of September. A quick reminder: We are still accepting applications for presentations or short lightning talks. If you are interested please read our CfP at http://meeting.denog.de/cfp_en.html Hope to see you in November, Marcus

1 0

Re: BGP Hijack by AT&T... was: Need Help Getting IP Unblocked by AT&T
by Brian Raaen 03 Sep '09

03 Sep '09

No is just seems to die in their core network. Dorn Hetzel wrote: > If you traceroute from someplace that sees the announcement from ATT, > does it actually go anywhere beyond the core in ATT (as if they are > sending it to any customer circuit of their) ? > > On Thu, Sep 3, 2009 at 10:23 AM, Brian Raaen <braaen(a)zcorum.com > <mailto:braaen@zcorum.com>> wrote: > > I have not seen any changes yet, although I did get an automated > response from their abuse address that they received my message. > Also, > to answer another question I have not changed backbones in over two > years. I largely suspect that this is an issue of a simple typo > and not > anything malicious. > > -- > ----------------- > Brian Raaen > Network Engineer > email: /braaen(a)zcorum.com/ <http://braaen@zcorum.com/> > <mailto:braaen@zcorum.com <mailto:braaen@zcorum.com>> > > > Gustavo Rodrigues Ramos wrote: > > Hi Brian, has someone from at&t contacted you or have you > noticed any change? > > > > Thanks, > > Gustavo. > > > > > > On Thu, Sep 3, 2009 at 9:43 AM, Brian Raaen<braaen(a)zcorum.com > <mailto:braaen@zcorum.com>> wrote: > > > >> I have sent a complaint to the AT&T abuse contact from my ARIN > contact > >> address asking them to stop announcing the route. > >> > >> -- > >> ----------------- > >> Brian Raaen > >> Network Engineer > >> email: /braaen(a)zcorum.com/ <http://braaen@zcorum.com/> > <mailto:braaen@zcorum.com <mailto:braaen@zcorum.com>> > >> > >> Brian Raaen wrote: > >> > >>> I appreciate the offline replies. After doing some more > research myself > >>> the issue appears to be related to the fact that AT&T is > announcing the > >>> block directly. I did show "ip bgp 72.14.76.0" in a couple > routers and > >>> some showed the route originating in 701 (they were able to > reach it) > >>> and others showed it originating in 7018 (and they could not > reach it). > >>> > >>> Here is my question, since I am an ARIN admin contact for the > IP block > >>> how is the best way to get AT&T to quit announcing the block. > >>> > >>> > >>> > > -- ----------------- Brian Raaen Network Engineer email: /braaen(a)zcorum.com/ <mailto:braaen@zcorum.com> Telephone /678-507-5000x5574/

1 0

Re: BGP Hijack by AT&T... was: Need Help Getting IP Unblocked by AT&T
by Brian Raaen 03 Sep '09

03 Sep '09

I have not seen any changes yet, although I did get an automated response from their abuse address that they received my message. Also, to answer another question I have not changed backbones in over two years. I largely suspect that this is an issue of a simple typo and not anything malicious. -- ----------------- Brian Raaen Network Engineer email: /braaen(a)zcorum.com/ <mailto:braaen@zcorum.com> Gustavo Rodrigues Ramos wrote: > Hi Brian, has someone from at&t contacted you or have you noticed any change? > > Thanks, > Gustavo. > > > On Thu, Sep 3, 2009 at 9:43 AM, Brian Raaen<braaen(a)zcorum.com> wrote: > >> I have sent a complaint to the AT&T abuse contact from my ARIN contact >> address asking them to stop announcing the route. >> >> -- >> ----------------- >> Brian Raaen >> Network Engineer >> email: /braaen(a)zcorum.com/ <mailto:braaen@zcorum.com> >> >> Brian Raaen wrote: >> >>> I appreciate the offline replies. After doing some more research myself >>> the issue appears to be related to the fact that AT&T is announcing the >>> block directly. I did show "ip bgp 72.14.76.0" in a couple routers and >>> some showed the route originating in 701 (they were able to reach it) >>> and others showed it originating in 7018 (and they could not reach it). >>> >>> Here is my question, since I am an ARIN admin contact for the IP block >>> how is the best way to get AT&T to quit announcing the block. >>> >>> >>>

1 0

Telstra issues
by Marcus H. Sachs 03 Sep '09

03 Sep '09

Anybody know what is going on with Telstra? We've got complaints coming in from Down Under that good chunks of the country are belly-up. More here: http://forums.whirlpool.net.au/forum-replies.cfm?t=1274075 Marc -- Marc Sachs <marc(a)sans.org> Director, SANS ISC

4 3

Re: Link capacity upgrade threshold
by Bill Woodcock 03 Sep '09

03 Sep '09

>>> If your 95th percentile utilization is at 80% capacity... >> s/80/60/ > s/60/40/ I would suggest that the reason each of you have a different number is because there's a different best number for each case. Looking for any single number to fit all cases, rather than understanding the underlying process, is unlikely to yield good results. First, different people have different requirements. Some people need lowest possible cost, some people need lowest cost per volume of bits delivered, some people need lowest cost per burst capacity, some need low latency, some need low jitter, some want good customer service, some want flexible payment terms, and undoubtedly there are a thousand other possible qualities. Second, this is a binary digital network. It's never 80% full, it's never 60% full, and it's never 40% full. It's always exactly 100% full or exactly 0% full. If SNMP tells you that you've moved 800 megabits in a second on a one-gigabit pipe, then, modulo any bad implementations of SNMP, your pipe was 100% full for eight-tenths of that second. SNMP does not "hide" anything. Applying any percentile function to your data, on the other hand, does hide data. Specifically, it discards all of your data except a single point, irreversibly. So if you want to know anything about your network, you won't be looking at percentiles. Having your circuit be 100% full is a good thing, presuming you're paying for it and the traffic has some value to you. Having it be 100% full as much of the time as possible is a good thing, because that gives you a high ratio of value to cost. Dropping packets, on the other hand, is likely to be a bad thing, both because each packet putatively had value, and because many dropped packets are likely to be resent, and a resent packet is one you've paid for twice, and that's precluded the sending of another new, paid-for packet in that timeframe. The cost of not dropping packets is not having buffers overflow, and the cost of not having buffers overflow is either having deep buffers, which means high latency, or having customers with a predictable flow of traffic. Which brings me to item three. In my experience, the single biggest contributor to buffer overflow is having in-feeding (or downstream customer) circuits which are of burst capacity too close to that of the out-feeding (or upstream transit) circuits. Let's say that your outbound circuit is a gigabit, you have two inbound circuits that are a gigabit and run at 100% utilization 10% of the time each, and you have a megabit of buffer memory allocated to the outbound circuit. 1% of the time, both of the inbound circuits will be at 100% utilization simultaneously. When that's happening, you'll have data flowing in at the rate of two gigabits per second, which will fill the buffer in one twentieth of a second, if it persists. And, just like Rosencrantz and Guildenstern flipping coins, such a run will inevitably persist longer than you'd desire, frequently enough. On the other hand, if you have twenty inbound circuits of 100 megabits each, which are transmitting at 100% of capacity 10% of the time each, you're looking at exactly the same amount of data, however it arrives _much more predictably_, since the 2-gigabit inflow would only occur 0.0000000000000000001% of the time, rather than 1% of the time. And it would also be proportionally unlikely to persist for the longer periods of time necessary to overflow the buffer. Thus Kevin's ESnet customers, who are much more likely to be 10gb or 40gb downstream circuits feeding into his 40gb upstream circuits, are much more likely to overflow buffers, than a consumer Internet provider who's feeding 1mb circuits into a gigabit circuit, even if the aggregation ratio of the latter is hundreds of times higher. So, in summary: Your dropped packet counters are the ones to be looking at as a measure of goodput, more than your utilization counters. And keep the size of your aggregation pipes as much bigger than the size of the pipes you aggregate into them as you can afford to. As always, my apologies to those of you for whom this is unnecessarily remedial, for using NANOG bandwidth and a portion of your Sunday morning. -Bill

6 5

Google DNS admin
by manolo hernandez 02 Sep '09

02 Sep '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Could someone from google that can assist with a dns issue that originates from their servers please contact me offlist? I have tried normal channels listed on their Arin contact list to no avail. Manolo -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.12 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJKnttbAAoJEOcnyWxdB1IrV8MH/3uru0O9tYH4c1jQEZkpbqhP ZoqGMJm7NSSoH8KUKjVN1Vwze1Hp2JbV6sD5LUL7Au9z9+5DZ5VXoXkfIbfxo48f 63iOsRtPLxBim7o7zxAUOeZbI2+RflbwlIGXERrI12oufmTXEKD/9JioiVKLzsV7 +RtvJ0oPjOBXnqR2axs+zsrRygmBZKNDFavwhNsjZ+cXMZrX0XkTEhbWBv7qBdjU +Q7W7MHfURjay7pO0KW8O5kpCUCetS7Gy9Puxy0qEz4oKIbt9zeEneM6vlPs+EII 45+xheAeDzMf3gKixc+YJYyV1JDXgKQdhdLuddUz8mRX7S0JtO4FX7YP7wEPWZw= =pfuQ -----END PGP SIGNATURE-----

2 2

AT&T - realpages.com Admin
by lmarshall＠inetspace.net 02 Sep '09

02 Sep '09

Would an administrator from AT&T (specifically realpages.com) contact me off-list. We have been attempting to resolve a client issue but normal channels have proved fruitless. L Marshall

1 0

draft-iana-ipv4-examples
by Ron Bonica 02 Sep '09

02 Sep '09

Folks, Please take a look at draft-iana-ipv4-examples. This draft discusses the following subnet allocations: - 192.0.2.0/24 (TEST-NET-1) - 198.51.100.0/24 (TEST-NET-2) - 203.0.113.0/24 (TEST-NET-3) RFC 1166 allocates TEST-NET-1 for use in documentation. Because the other two have been used in documentation, the current draft proposes allocating them, too. There has been some discussion of this on the IETF general mailing list. If you care about this issue, please visit the mailing list archive and check out the thread "Re: Last Call: draft-iana-ipv4-examples (IPv4 Address Blocks Reserved for Documentation) to Informational RFC". Ron

2 1

Network load test equipment
by Greg Schwimer 02 Sep '09

02 Sep '09

I'm looking for equipment that can be used to load test network equipment such as switches, routers, firewall, and load balancers with pre-defined traffic patterns at differing rates. Ideally, this is only something I think I'll need 2-3x a year, so purchasing is not necessarily justifiable. I'd prefer to rent. What products have you used? Where did you get them from? I need to be able to run pre-defined traffic patterns at various rates, in excess of 10Gbps in most cases. Thanks! Greg

4 3

Issues with Gmail
by Jim Wininger 02 Sep '09

02 Sep '09

Anyone else seeing issues with gmail? -- Jim Wininger

24 26