- NANOG - lists.nanog.org

Re: 4 Byte AS tested
by Randy Bush 11 Jan '07

11 Jan '07

Anderson, Matthew R [NTK] wrote: > One test case I would like to see is alternating 2- and 4-byte ASNs in the path. This may be harder. E.g., AS_PATH = 1239 23456 1221 23456 23456 23456. Or how about an AS_PATH including the 4-byte ASN placeholder (23456) whose origin is a 2-byte OLD speaker? E.g., AS_PATH = 1239 23456 1221 23456 23456 23456 12234. line wrap! good idea. and you could do that in your lab using the openbgp and quagga kits posted to the net today! please tell us how it goes. randy

1 0

Anything going on in Atlanta, GA?
by Dean, Matt 11 Jan '07

11 Jan '07

Good evening, I'm currently seeing a routing loop in Atlanta, GA. I've contacted the ISP with no response yet. Just curious if anyone knows if there's something major going on there. My traceroute is below. Tracing route to shs01.mdeinc.ca [207.210.113.61] over a maximum of 30 hops: 1 1 ms 2 ms 2 ms corpnet-rtr01.ba01.mdeinc.ca [10.143.5.1] 2 5 ms 5 ms 5 ms mdei-rci-border-rtr01.ba01.mdeinc.ca [10.99.99.5] 3 17 ms 13 ms 15 ms 10.231.36.1 4 16 ms 13 ms 13 ms gw01.bawk.phub.net.cable.rogers.com [66.185.90.193] 5 13 ms 13 ms 16 ms gw01.bawk.phub.net.cable.rogers.com [66.185.83.253] 6 14 ms 13 ms 13 ms gw01.basp.phub.net.cable.rogers.com [66.185.82.6] 7 15 ms 15 ms 18 ms gw02.mtnk.phub.net.cable.rogers.com [66.185.81.209] 8 15 ms 15 ms 15 ms 66.185.80.41 9 32 ms 31 ms 32 ms igw01.vaash.phub.net.cable.rogers.com [66.185.80.190] 10 36 ms 37 ms 37 ms POS2-1.ar2.DCA3.gblx.net [208.51.239.201] 11 51 ms 54 ms 51 ms NLAYER-COMMUNICATIONS-INC.ge-4-1-0.410.ar4.ATL1.gblx.net [206.41.25.230] 12 267 ms 76 ms 122 ms atl-core-a-tgi2-1.gnax.net [209.51.149.105] 13 * * * Request timed out. 14 54 ms 50 ms 56 ms atl-core-a-tgi2-1.gnax.net [209.51.149.105] 15 * * * Request timed out. 16 52 ms 53 ms 53 ms atl-core-a-tgi2-1.gnax.net [209.51.149.105] 17 * * * Request timed out. 18 54 ms 64 ms 51 ms atl-core-a-tgi2-1.gnax.net [209.51.149.105] 19 * * * Request timed out. 20 52 ms 53 ms 52 ms atl-core-a-tgi2-1.gnax.net [209.51.149.105] 21 * * * Request timed out. 22 53 ms 53 ms 54 ms atl-core-a-tgi2-1.gnax.net [209.51.149.105] 23 * * * Request timed out. 24 53 ms 51 ms 54 ms atl-core-a-tgi2-1.gnax.net [209.51.149.105] 25 * * * Request timed out. 26 54 ms 51 ms 56 ms atl-core-a-tgi2-1.gnax.net [209.51.149.105] 27 * * * Request timed out. 28 53 ms 66 ms 56 ms atl-core-a-tgi2-1.gnax.net [209.51.149.105] 29 * * * Request timed out. 30 52 ms 52 ms 56 ms atl-core-a-tgi2-1.gnax.net [209.51.149.105] Trace complete. Thanks in advance. Matt Dean, MCP, MCDST, MCPS, MCNPS Cremto Inc. Integrated Technology Consulting 530 Adelaide St. West, Unit 6133 Toronto, Ontario M5V 2K7 Canada (416) 619-0472 mdean(a)cremto.com

4 4

4 Byte AS tested
by Geoff Huston 11 Jan '07

11 Jan '07

# bgpctl show rib 203.10.62.0/24 flags: * = Valid, > = Selected, I = via IBGP, A = Announced origin: i = IGP, e = EGP, ? = Incomplete flags destination gateway lpref med aspath origin *> 203.10.62.0/24 147.28.0.1 100 0 0.3130 0.1239 0.4637 0.4637 0.4637 0.4637 0.4637 0.4637 0.1221 1.202 i George Michaelson, Randy Bush and myself have successfully tested the implementation of 4Byte AS BGP on a public Internet transit. The above BGP RIB snapshot was taken at a 4Byte BGP speaker in North America, showing a transit path across AS 1221, AS 4637, AS 1239 and AS 3130 , with correct reconstruction of the originating AS at the other (4Byte AS) end. The code base used was OpenBGPD, with 4 byte patches that I've added to the code in the past couple of weeks. (Patched versions of openbgpd to include 4-byte AS support can be found at http://www.potaroo.net/tools/bgpd/) cheers, Geoff

1 0

Fwd: [routing-wg]New Document Available: RIPE-399
by Fergie 11 Jan '07

11 Jan '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I hadn't seen any mention of this on the list today, so I figured I would mention it. I finally got a few free minutes to review this document this evening and I think it is a really good community resource. FYI, - - ferg [forwarded message] To: routing-wg(a)ripe.net From: RIPE NCC Document Announcement Service <webmaster(a)ripe.net> Subject: [routing-wg]New Document Available: RIPE-399 Sender: routing-wg-admin(a)ripe.net Date: Wed, 10 Jan 2007 16:57:36 +0100 New RIPE Document Announcement - -------------------------------------- A new document is available from the RIPE Document store. Ref: ripe-399 Title: RIPE Routing Working Group Recommendations on Route Aggregation Author: Philip Smith, Rob Evans, Mike Hughes Format: PDF= 89, 997 Date: December 2006 Short content description - ------------------------- This document discusses the need for aggregation of prefixes on the Internet today, and recommends good working practices for Internet Service Providers and other Autonomous Networks connected to the Internet. Accessing the RIPE Document Store - --------------------------------- You can access this RIPE document at: http://www.ripe.net/docs/ripe-399.html [snip] -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.2 (Build 4075) wj8DBQFFpbr7q1pz9mNUZTMRAoZ8AJ4gbdH1fo8OD/KaRToztqpcbp+E3QCdEeZn FtwMbt3qzzAs485WlPvJLwk= =jcbf -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0

Standalone DC power recommendations?
by Deepak Jain 11 Jan '07

11 Jan '07

We are going to need to deploy about 800A of -48VDC power equipment in a datacenter that doesn't supply DC power normally. They will give us an three phase AC-power feed that is generator backed. Can anyone point me in the direction of a decent vendor of DC-power plants that are suitable for this size need and/or a ballpark price one would expect to pay for the equipment? Thanks in advance, Deepak

2 1

Re: Network end users to pull down 2 gigabytes a day, continuously?
by Richard Naylor 10 Jan '07

10 Jan '07

At 08:40 p.m. 9/01/2007 -0500, Gian Constantine wrote: >It would not be any easier. The negotiations are very complex. The issue >is not one of infrastructure capex. It is one of jockeying between content >providers (big media conglomerates) and the video service providers (cable >companies). We're seeing a degree of co-operation in this area. Its being driven by the market. - see below. <snip> On Jan 9, 2007, at 7:57 PM, Bora Akyol wrote: An additional point to consider is that it takes a lot of effort and >>$$$$ to get a channel allocated to your content in a cable network. >> >>This is much easier when TV is being distributed over the Internet. The other bigger driver, is that for most broadcasters (both TV and Radio), advertising revenues are flat, *except* in the on-line area. So they are chasing on-line growth like crazy. Typically on-line revenues now make up around 25% of income. So broadcasters are reacting and developing quite large systems for delivering content both new and old. We're seeing these as a mixture of live streams, on-demand streams, on-demand downloads and torrents. Basically, anything that works and is reliable and can be scaled. (we already do geographic distribution and anycast routing). And the broadcasters won't pay flash transit charges. They are doing this stuff from within existing budgets. They will put servers in different countries if it makes financial sense. We have servers in the USA, and their biggest load is non-peering NZ based ISPs. And broadcasters aren't the only source of large content. My estimate is that they are only 25% of the source. Somewhere last year I heard John Chambers say that many corporates are seeing 500% growth in LAN traffic - fueled by video. We do outside webcasting - to give you an idea of traffic, when we get a fiber connex, we allow for 6GBytes per day between an encoder and the server network - per programme. We often produce several different programmes from a site in different languages etc. Each one is 6GB. If we don't have fiber, it scales down to about 2GB per programme. (on fiber we crank out a full 2Mbps Standard Def stream, on satellite we only get 2Mbps per link). I have a chart by my phone that gives the minute/hour/day/month traffic impact of a whole range of streams and refer to it every day. Oh - we can do 1080i on demand and can and do produce content in that format. They're 8Mbps streams. Not many viewers tho :-) We're close to being able to webcast it live. We currently handle 50+ radio stations and 12 TV stations, handling around 1.5 to 2million players a month, in a country with a population of 4million. But then my stats could be lying...... Rich (long time lurker)

2 2

More topics for NANOG 39 - and a reminder to register!
by Steve Feldman 10 Jan '07

10 Jan '07

We've just added more talks and BOFs for NANOG 39! The current list is at http://www.nanog.org/mtg-0702/topics.html Not listed yet are the popular lightning talks, and a keynote presentation we expect to announce later this week. Although the agenda is nearly full, there is still a little space for unusually good or timely last-minute additions. If you haven't already registered, please go to http://www.nanog.org and do! Next Monday, January 15, is the last day for the discounted rate. Also, don't forget that the hotel group rate expires on January 19. See you in Toronto! Steve Feldman PC Chair

1 0

Re: Internet Video: The Next Wave of Massive Disruption to the US Peering Ecosystem (v1.2)
by Brandon Butterworth 10 Jan '07

10 Jan '07

> Then that wouldn't be enough since the other Tier 1's would need to > upgrade their peering infrastructure to handle the larger peering > links (n*10G), having to argue to their CFO that they need to do it so > that their competitors can support the massive BW customers. Someone will take the business so that traffic is coming regardless, they can either be that peer or be the source with the cash. If they can't do either then they're not in business, I hope they wouldn't ignore it congesting their existing peers (I know...) > Then even if the peers all upgraded the peering gear at the same time, > the backbones would have to be upgraded as well to get that traffic > out of the IXes and out to the eyeball networks. The Internet doesn't scale, turn it off brandon

7 6

Re: Network end users to pull down 2 gigabytes a day, continuously?
by Brandon Butterworth 10 Jan '07

10 Jan '07

> Note that video caching systems like P2P networks can > potentially serve video to extremely large numbers of > users while consuming reasonably low levels of upstream > bandwidth. The total bandwidth used is the same though, no escaping that, someone pays. > Then local users > use local bandwidth to get copies of that broadcast over > the next few days. If it was only redistributed locally. Even in that case it's not helping much as it still consumes the most expensive bandwidth (for UK ADSL). Transit is way cheaper than BT ADSL wholesale, you're saving something that's cheap. > For this to work, you need P2P software whose algorithms > are geared to conserving upstream bandwidth Or the caches that are being sold to fudge the protocols to keep it local but if you're buying them we could have just as easily done http download and let it be cached by existing appliances. brandon

4 3

Re: Network end users to pull down 2 gigabytes a day, continuously?
by Fergie 10 Jan '07

10 Jan '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Gian Constantine <constantinegi(a)corp.earthlink.net> wrote: >Ah-ha. You are mistaken. :-) > >My focus is next-gen broadband and video. The wifi guys have their own >>department. > >Good try, though. :-) > Indeed. Also, the current state of wifi (and indeed, wireless connectivity in general) quality has to improve immensely before I would be too terribly concerned with the onslaught of multimedia traffic -- most people are still frustrated with dropped cellphone calls. :-) - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.2 (Build 4075) wj8DBQFFpQsgq1pz9mNUZTMRAsb9AKDjlvJJi7ywr5Qx3GREQLeBLeHyfQCfd+jM 960CsCul1q3NqQYUtENmyvc= =sTEg -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0