Re: a fun hijack: 1/8, 2/8, 3/8, 4/8, 5/8, 7/8, 8/8, 12/8 briefly announced by AS 23520 (today)
On Wed, 2006-06-07 at 11:01 -0700, Josh Karlin wrote: Check out the IAR for Potential Prefix Hijacks and if you're coming to this more than 24 hours after the post, do a search on AS 23520 as the hijacking AS. I don't know how long the routes were announced, but they seem to be gone now. Or maybe the IAR is horribly broken, in which case I will be lynched :) You are the broken part, due to the mere simple fact that you accept those routes. That your uplinks are accepting them also means that you are not paying them enough so that they don't accept them either. But in ARIN land you have an excuse, more or less, as there is not a real 'good' routing database. In RIPE land we at least have route+route6 objects in the RIPE database where one can filter on, but that is only for RIPE. A sane and complete routing information database would already considerably help here. RADB is nice but does not help much to make the info complete. Also anybody can then still announce the prefix with the correct source ASN and other nasty tricks. In the end, the complete solution to most of these issues will be in the form of S-BGP (http://www.ir.bbn.com/sbgp/) and similar solutions. And the IETF is fortunately working on this: http://www.ietf.org/html.charters/sidr-charter.html It might take some time still, but it will come one day and then these issues are gone. At the moment you'll just have to trust your peers and try to get them to implement a sane policy on what kind of announcements they accept or not. Greets, Jeroen signature.asc Description: This is a digitally signed message part
2006.06.06 NANOG-NOTES CC1 ENUM LLC update
(sorry these are coming out delayed, I had to deal with an internal routing challenge for much of yesterday afternoon. --Matt) 2006.06.06 CC1 ENUM LLC IPv6 DAY http://www.ipv6day.org/ 6bone is being shut down today, on the grounds that IPv6 is live and commercial, based on Jeordi's findings. Quotes slide, link to page you can register your apps on... Moderator for second session, Vish from Netflix, member of program committee. couple of topics to talk about; will start off with Karen Mulberry from Neustar talking about the US ENUM trial This is her first NANOG, very informative, interesting, entertaining. CC1 ENUM LLC --what is it? some background: north american numbering plan, 19 countries. formed sept 2004 by industry CC1 shared by 19 countries? US and canada and others. LLC obtained the CC1 ENUM trial delegation in Feb 2006 1 exists at RIPE, points to a server in Canada, waiting for the rest to happen. USG guiding principle and canadian government and carribean--interoperate, protect privacy, foster innovation, promote competition. US Trial is for End User ENUM ONLY applied to FCC for numbering for trial, waiver hasn't been given yet; only regional numbers, no 800, toll free, or other non-geo numbers used during trial No testing in enum.arpa? of carrier enum. CC1 ENUM trial test service as interface within CC1, specifically in US CIRA will host the temporary Tier 1 registry Each CC1 country must opt into ENUM trial, gets their own Tier 1 registry CIRA just handles 800 area codes for CC1 for US Canada itself has a trial committee, they are preparing their own corp. to handle Canada. And Jamaica is going to do their own. US Trial, TPAC is committee of trial participants, will produce trial results. Each country will do their own Tier 1B registry Trial roles--a number identified; Tier1B is a subset of a Tier1 registry Tier2 provider. Local exchange provider has to provide... [wow, slide went fast] Trial in 3 phases. registry infrastructure registry/registrar interface application testing phase 2 is under development; phase 3 has some proposals. Phase 1 is underway. TPAC (trial committee) -- 11 members signed MOU developed documents thus far TPAC US trial estimated timeline phase 1: registry infrastructure late june/july, lasts 2 months, starts after FCC grants waiver phase 2: registry/registrar interface expected to start aug, lasts 2 months depends on when phase 1 ends, depends on FCC waiver phase 3 applications later this fall CC1 timeline as of march 2006 [eyechart slide, good luck reading it.] By Q4 2006, an RFP will be issued for commercial tier1 and tier1B registries for CC1, goal to go live mid 2007. commercial operations 2 RFPs tier 1A (for all CC1) tier 1B for US expect to see the RFPs Q3/Q4 2006, beta late next year. Challenges facing enum defining the global standard for Carrier/Infrastructure /Operator/Provider ENUM Protecting end user security and privacy managing opt in requirements ensuring verification and authentication integrating domestic/global policy mandates. how do we integrate what happens in the US with the rest of the world. CC1 ENUM info resources CC1 ENUM LLC http://www.enumllc.com/ US ENUM Forum http://www.enum-forum.org/ Canadian ENUM Working Group http://www.enumorg.ca/ Q: What about bringing carrier/operator enum to IETF forum? A: working on it -- there was an announcement yesterday in regards to that. Moving on to next speaker now.
2006.06.06 NANOG-NOTES IDC power and cooling panel
(ok, one more set of notes and then off to sit in traffic for an hour on the way to work... --Matt) 2006.06.06 Power and Cooling panel Dan Golding, Tier1 research, moderator Hot Time in the Big IDC Cooling, Power, and the Data Center 3 IDC vendors, 4 hardware vendors Michael Laudon, force10 Jay Park, equinix Rob Snevely, Sun Josh Snowhorn, terremark David Tsiang, cisco Brad Turner, juniper Brian Young, SD The power and cooling crisis internet datacenters are getting full most of the slack capacity has been used up devices are using more and more power low power density - routers, full sized servers medium power density - 1u servers, switches high power density - blade servers Many data centers are full at 70-80% floor space utilized North America IDC occupancy is around 50% most sought-after space is around 70% full when power and cooling capacity is used up, floor space is vacant but can't be used. There is a relationship between power and cooling devices are not 100% efficient I^2R losses means that power becomes heat (conservation of energy) heat must be dissipated The ability to dissipate heat with normal cooling technologies is hitting the wall need new techniques Some quick rules of thumb a rack or cabinet is a standard unit of space from 30-40sqft per rack power is measured in watts many facilities do around 80-100w/sqft; at 30sqft per rack, that's about 3kw/rack high how did we get here? what is current situation where are we going? [dang, he's flying through his slides!!] Hardware engineers T-series hardware engineer for Juniper CRS-1 hardware E-series datacenter design issues for Sun, there were other hardware vendors who were not interested in showing up, these people were brave for coming up here! Josh snowhorn, IDC planner Jay Park, electrial engineer for equinix Brian Young, SD cage design specialist What do the IDC vendors feel the current situation is in terms of power/cooling, how did we get here? Josh--designed datacenters at 100w/sq/ft, more than enough for the carriers; the server guys hit 100w/sqft in a quarter rack. you could cannabalize some power and cooling, but still ran out of cooling. Now spend hundreds of millions to make 200wsqft datacenters, or higher. Now, to hardware vendors--why are their boxes using up so much electricity, putting out so much heat? What are economics behind increasing density and heat load? From high-end router space--it's been simple, the bandwidth demand has grown faster than the power efficiency can keep up with. In the past, had the ability to improve keep up, do power spins about every 2 years, half power; but now bandwidth is doubling every year, but takes two years to drop power in half. We've been loosing at this game for a while, and running out of room on the voltage scale; 90nm is down at 1v, can't go much lower, since diode drop is at 0.7v; at 65nm, it's still at 1v, there's no big hammer anymore for power efficiency. Need to pull some tricks out, but may need to do clock gating, may get some 20-30% efficiency gains, but not much more that can be pulled out of the bag now. Newton was right; you can do some tricks, but no magic. Chip multithreading is one area they're trying to squeeze more performance out of; don't replicate ancillary ASICs for each core. Also can more easily share memory, and nobody has a 100% efficient power supply, so you lose some power there too. More and more getting squeezed in each rack. Also a drive on cost; amortizing costs over space and capability. reducing costs per port is a big driver. And customers are pushing for more and more density, since the cost of real-estate is getting so high, since each square foot costs so high. In Ginza, $120/sq ft for space. If you go to places where realestate is cheap, easier/cheaper to just build really big rooms, and let power dissipate more naturally. IDC people agree, some cities are just crazy in real-estate costs. But for those in suburban areas, cost of real-estate isn't so expensive. 3kw per blade server, put a few in a rack, you hit nearly 10kw in a rack. Soon, will need direct chilled water in the rack to cool them. But chilled water mixed with other colocation and lower density cabinets is very challenging to build. But need to have enclosed space to handle local chilled water coolers in localized racks. 20 years ago at IBM, nobody wanted chilled water in their hardware. Now, we're running out of options. Disagree--other ways of handling the challenge; how thermally efficient are the rooms in the first place, and are there other ways of handling heat issues? Cables with a cutout in tiles allows air to escape in areas that don't provide cooling. Josh notes the diversity between carriers at 40w/sq/ft vs hosting providers at 400w/sq/ft is making engineering decisions challenging. It's not about power really anymore, we can get power, it's about cooling now. Dealing with space in wrong terms--watts/sq ft, vs requirements of each
Re: 2006.06.06 NANOG-NOTES CC1 ENUM LLC update
On Jun 8, 2006, at 10:04 AM, Matthew Petach wrote: (sorry these are coming out delayed, I had to deal with an internal routing challenge for much of yesterday afternoon. --Matt) I think I speak for the whole list when we say you have absolutely NO reason to apologize, Matt. In fact, I think we'll nominate you for Most Useful Meeting Attendee. :) -- TTFN, patrick
Re: 2006.06.06 NANOG-NOTES CC1 ENUM LLC update
Tell you what -- I'd love to see this for every meeting, in some sore of official capacity. Reminds be of Stan's notes from the regional techs meetings.. On Thu, 8 Jun 2006, Patrick W. Gilmore wrote: On Jun 8, 2006, at 10:04 AM, Matthew Petach wrote: (sorry these are coming out delayed, I had to deal with an internal routing challenge for much of yesterday afternoon. --Matt) I think I speak for the whole list when we say you have absolutely NO reason to apologize, Matt. In fact, I think we'll nominate you for Most Useful Meeting Attendee. :) -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben Net Access Corporation, 800-NET-ME-36, http://www.nac.net
Re: 2006.06.06 NANOG-NOTES CC1 ENUM LLC update
On Thu, Jun 08, 2006 at 01:39:41PM -0400, Alex Rubenstein wrote: Tell you what -- I'd love to see this for every meeting, in some sore of official capacity. Seconded. I found the this especially useful as I was unable to attend this time. --dmm pgps1jvoVrTvd.pgp Description: PGP signature
Re: 2006.06.06 NANOG-NOTES CC1 ENUM LLC update
On Thu, 8 Jun 2006, David Meyer wrote: On Thu, Jun 08, 2006 at 01:39:41PM -0400, Alex Rubenstein wrote: Tell you what -- I'd love to see this for every meeting, in some sore of official capacity. Seconded. I found the this especially useful as I was unable to attend this time. This will be heresy, but... Perhaps there should be a home for this on the nanaog.org web farm? or is capturing this in the email archive 'ok' ?
Re: 2006.06.06 NANOG-NOTES CC1 ENUM LLC update
On Thu, Jun 08, 2006 at 01:12:25PM -0400, Patrick W. Gilmore wrote: On Jun 8, 2006, at 10:04 AM, Matthew Petach wrote: (sorry these are coming out delayed, I had to deal with an internal routing challenge for much of yesterday afternoon. --Matt) I think I speak for the whole list when we say you have absolutely NO reason to apologize, Matt. In fact, I think we'll nominate you for Most Useful Meeting Attendee. :) I'll third, or fourth, or whatever number is current. Just because you aren't meeting your own expectations doesn't mean that you're not exceeding everyone else's. ;-) Even God rested on the seventh day after pulling six all-nighters. [OK, for the picky among you, He could only pull five, since He didn't invent Night until the second day ...] -- Joe Yao --- This message is not an official statement of OSIS Center policies.
Re: 2006.06.06 NANOG-NOTES IDC power and cooling panel
Dan Golding, 30 seconds, what would each person like to see the folks on other side do to help. Did anybody mention cogeneration? At least some of that waste heat is turned into electricity which reduces the total consumption off the grid. http://www.polarpowerinc.com/products/generators/cogenset.htm And what about risks? As you increase the active cooling of your IDC, you reduce the ability to survive power outages. This is another reason to separate hot customers from cool. In the event of a power outage, your cool customers who have better heat engineering do not have to share fate with the lazy hot customers. Here I am referring to server customers who do have choices to use more efficient hardware, improve the power efficiency of their software, and do things like server virtualisation to reduce the CPU count in your IDC. The embedded systems industry has plenty of experience in reducing power consumption through both hardware and software improvements. --Michael Dillon
Notes from meeting [was: 2006.06.06 NANOG-NOTES CC1 ENUM LLC update]
On Jun 8, 2006, at 2:02 PM, Christopher L. Morrow wrote: On Thu, 8 Jun 2006, David Meyer wrote: On Thu, Jun 08, 2006 at 01:39:41PM -0400, Alex Rubenstein wrote: Tell you what -- I'd love to see this for every meeting, in some sore of official capacity. Seconded. I found the this especially useful as I was unable to attend this time. This will be heresy, but... Perhaps there should be a home for this on the nanaog.org web farm? or is capturing this in the email archive 'ok' ? Excellent idea, Chris. Should we push this to NANOG-futures, or is it OK to discuss here? -- TTFN, patrick
Re: Notes from meeting [was: 2006.06.06 NANOG-NOTES CC1 ENUM LLC update]
On Thu, 8 Jun 2006, Patrick W. Gilmore wrote: On Jun 8, 2006, at 2:02 PM, Christopher L. Morrow wrote: On Thu, 8 Jun 2006, David Meyer wrote: On Thu, Jun 08, 2006 at 01:39:41PM -0400, Alex Rubenstein wrote: Tell you what -- I'd love to see this for every meeting, in some sore of official capacity. Seconded. I found the this especially useful as I was unable to attend this time. This will be heresy, but... Perhaps there should be a home for this on the nanaog.org web farm? or is capturing this in the email archive 'ok' ? Excellent idea, Chris. Should we push this to NANOG-futures, or is it OK to discuss here? punt to futures (which has a much smaller membership atleast) and probably Randy should put this on the Sterring Committee agenda for next week.
Re: Notes from meeting [was: 2006.06.06 NANOG-NOTES CC1 ENUM LLC update]
Moving thread to [EMAIL PROTECTED] NANOG@ BCC'ed. -- TTFN, patrick On Jun 8, 2006, at 2:55 PM, Christopher L. Morrow wrote: On Thu, 8 Jun 2006, Patrick W. Gilmore wrote: On Jun 8, 2006, at 2:02 PM, Christopher L. Morrow wrote: On Thu, 8 Jun 2006, David Meyer wrote: On Thu, Jun 08, 2006 at 01:39:41PM -0400, Alex Rubenstein wrote: Tell you what -- I'd love to see this for every meeting, in some sore of official capacity. Seconded. I found the this especially useful as I was unable to attend this time. This will be heresy, but... Perhaps there should be a home for this on the nanaog.org web farm? or is capturing this in the email archive 'ok' ? Excellent idea, Chris. Should we push this to NANOG-futures, or is it OK to discuss here? punt to futures (which has a much smaller membership atleast) and probably Randy should put this on the Sterring Committee agenda for next week.
Re: 2006.06.06 NANOG-NOTES CC1 ENUM LLC update
On Jun 8, 2006, at 10:12 AM, Patrick W. Gilmore wrote: On Jun 8, 2006, at 10:04 AM, Matthew Petach wrote: (sorry these are coming out delayed, I had to deal with an internal routing challenge for much of yesterday afternoon. --Matt) I think I speak for the whole list when we say you have absolutely NO reason to apologize, Matt. In fact, I think we'll nominate you for Most Useful Meeting Attendee. :) Seconded. (Although I would love to know how Matt manages to do this...) -- TTFN, patrick -- Do not meddle in the affairs of wizards, for they are subtle and quick to anger. -- J.R.R. Tolkien
Re: 2006.06.06 NANOG-NOTES CC1 ENUM LLC update
(sorry these are coming out delayed, I had to deal with an internal routing challenge for much of yesterday afternoon. --Matt) i demand a full refund! :-)
Re: a fun hijack: 1/8, 2/8, 3/8, 4/8, 5/8, 7/8, 8/8, 12/8 briefly announced by AS 23520 (today)
josh, all, these are always fun. these events continue to be a problem for all of us. Check out the IAR for Potential Prefix Hijacks and if you're coming to this more than 24 hours after the post, do a search on AS 23520 as the hijacking AS. here are some other details that we saw about this event. - as of two days ago 23520 only originated 26 prefixes - yesterday they originated 2821 prefixes. this event was about a lot more than a few /8s. - we still see them originating 140 prefixes, as of this afternoon (EDT). here's a list of the prefixes that we saw them originate yesterday that were not originated two days ago. the average amount of time a peer of renesys's saw those prefixes routed was about 80 seconds. 1.0.0.0/8 2.0.0.0/8 3.0.0.0/8 4.0.0.0/8 4.0.0.0/9 4.17.250.0/24 4.23.84.0/22 4.23.112.0/24 4.23.113.0/24 4.23.114.0/24 4.36.116.0/23 4.36.116.0/24 4.36.117.0/24 4.36.118.0/24 4.36.200.0/21 4.67.64.0/22 4.79.181.0/24 4.128.0.0/9 5.0.0.0/8 6.1.0.0/16 6.2.0.0/22 6.3.0.0/18 6.4.0.0/16 6.5.0.0/19 6.8.0.0/20 6.9.0.0/20 6.10.0.0/15 6.14.0.0/15 7.0.0.0/8 8.0.0.0/8 8.0.0.0/9 8.2.64.0/23 8.2.144.0/22 8.3.0.0/23 8.3.12.0/24 8.3.13.0/24 8.3.15.0/24 8.3.33.0/24 8.3.37.0/24 8.3.46.0/24 8.3.208.0/24 8.4.86.0/24 8.4.96.0/20 8.4.113.0/24 8.4.224.0/24 8.5.192.0/22 8.6.89.0/24 8.6.220.0/22 8.6.240.0/24 8.6.241.0/24 8.6.244.0/23 8.7.49.0/24 8.7.81.0/24 8.7.83.0/24 8.7.86.0/23 8.7.96.0/21 8.7.176.0/23 8.7.216.0/24 8.8.9.0/24 8.8.176.0/24 8.8.178.0/24 8.8.192.0/23 8.8.196.0/22 8.8.200.0/23 8.8.202.0/23 8.9.3.0/24 8.9.4.0/24 8.9.5.0/24 8.9.6.0/24 8.9.10.0/24 8.9.36.0/24 8.9.37.0/24 8.9.192.0/24 8.9.193.0/24 8.10.2.0/24 8.10.50.0/24 8.10.114.0/24 8.10.115.0/24 8.10.116.0/23 8.10.119.0/24 8.10.128.0/24 8.10.208.0/24 8.10.241.0/24 8.11.192.0/24 8.11.252.0/24 8.11.253.0/24 8.11.254.0/23 8.14.128.0/23 8.14.176.0/23 8.15.3.0/24 8.128.0.0/9 9.4.0.0/16 11.11.11.0/24 12.0.0.0/8 12.0.0.0/9 12.0.18.0/24 12.0.19.0/24 12.0.20.0/23 12.0.22.0/24 12.0.28.0/24 12.0.29.0/24 12.0.43.0/24 12.0.48.0/20 12.0.102.0/24 12.0.153.0/24 12.0.170.0/24 12.0.176.0/24 12.0.232.0/24 12.0.239.0/24 12.0.252.0/23 12.1.54.0/24 12.1.56.0/24 12.1.57.0/24 12.1.58.0/24 12.1.59.0/24 12.1.96.0/24 12.1.211.0/24 12.1.216.0/24 12.1.225.0/24 12.1.230.0/24 12.1.235.0/24 12.2.6.0/23 12.2.22.0/24 12.2.35.0/24 12.2.46.0/24 12.2.49.0/24 12.2.59.0/24 12.2.60.0/22 12.2.88.0/22 12.2.115.0/24 12.2.120.0/24 12.2.124.0/24 12.2.126.0/24 12.2.127.0/24 12.2.142.0/24 12.2.169.0/24 12.2.210.0/24 12.3.4.0/23 12.3.7.0/24 12.3.19.0/24 12.3.33.0/24 12.3.54.0/24 12.3.57.0/24 12.3.59.0/24 12.3.70.0/24 12.3.80.0/22 12.3.91.0/24 12.3.119.0/24 12.3.147.0/24 12.3.164.0/24 12.3.165.0/24 12.3.167.0/24 12.3.170.0/24 12.3.212.0/24 12.4.26.0/24 12.4.27.0/24 12.4.50.0/23 12.4.50.0/24 12.4.51.0/24 12.4.52.0/23 12.4.52.0/24 12.4.53.0/24 12.4.96.0/23 12.4.96.0/24 12.4.97.0/24 12.4.100.0/24 12.4.121.0/24 12.4.124.0/24 12.4.193.0/24 12.4.194.0/24 12.4.196.0/22 12.4.199.0/24 12.4.211.0/24 12.4.225.0/24 12.5.1.0/24 12.5.48.0/21 12.5.48.0/24 12.5.49.0/24 12.5.50.0/23 12.5.52.0/24 12.5.53.0/24 12.5.54.0/23 12.5.56.0/22 12.5.56.0/23 12.5.58.0/24 12.5.59.0/24 12.5.60.0/22 12.5.67.0/24 12.5.96.0/24 12.5.103.0/24 12.5.122.0/23 12.5.127.0/24 12.5.128.0/24 12.5.129.0/24 12.5.130.0/24 12.5.131.0/24 12.5.134.0/24 12.5.136.0/24 12.5.144.0/24 12.5.162.0/24 12.5.173.0/24 12.5.186.0/23 12.5.207.0/24 12.5.226.0/24 12.5.238.0/24 12.5.245.0/24 12.6.4.0/24 12.6.5.0/24 12.6.9.0/24 12.6.21.0/24 12.6.42.0/23 12.6.89.0/24 12.6.94.0/24 12.6.95.0/24 12.6.129.0/24 12.6.136.0/24 12.6.152.0/23 12.6.193.0/24 12.6.195.0/24 12.6.200.0/24 12.6.201.0/24 12.6.206.0/24 12.6.208.0/20 12.6.245.0/24 12.6.247.0/24 12.7.5.0/24 12.7.7.0/24 12.7.51.0/24 12.7.134.0/24 12.7.135.0/24 12.7.172.0/24 12.8.2.0/23 12.8.7.0/24 12.8.56.0/24 12.8.97.0/24 12.8.129.0/24 12.8.167.0/24 12.8.177.0/24 12.8.184.0/24 12.8.188.0/24 12.8.197.0/24 12.8.198.0/24 12.8.199.0/24 12.9.10.0/24 12.9.29.0/24 12.9.124.0/24 12.9.136.0/24 12.9.138.0/24 12.9.139.0/24 12.9.144.0/24 12.9.194.0/23 12.9.196.0/22 12.9.206.0/24 12.9.238.0/24 12.9.239.0/24 12.9.241.0/24 12.9.245.0/24 12.9.249.0/24 12.10.20.0/23 12.10.44.0/23 12.10.90.0/24 12.10.91.0/24 12.10.115.0/24 12.10.132.0/24 12.10.133.0/24 12.10.150.0/24 12.10.189.0/24 12.10.217.0/24 12.10.219.0/24 12.10.230.0/23 12.10.253.0/24 12.11.0.0/18 12.11.88.0/23 12.11.130.0/24 12.11.131.0/24 12.11.148.0/24 12.11.149.0/24 12.11.150.0/24 12.11.151.0/24 12.11.152.0/24 12.11.171.0/24 12.11.183.0/24 12.12.0.0/20 12.12.16.0/20 12.12.32.0/20 12.12.48.0/20 12.12.64.0/20 12.12.80.0/20 12.12.96.0/20 12.12.112.0/20 12.12.192.0/18 12.12.208.0/22 12.12.232.0/21 12.13.62.0/24 12.13.74.0/24 12.13.112.0/24 12.13.116.0/22 12.13.141.0/24 12.13.164.0/23 12.13.211.0/24 12.14.2.0/24 12.14.36.0/24 12.14.38.0/24 12.14.41.0/24 12.14.80.0/23 12.14.170.0/24 12.14.172.0/23 12.14.232.0/23 12.14.237.0/24 12.14.238.0/23 12.15.7.0/24 12.15.28.0/24 12.15.40.0/24 12.15.41.0/24 12.15.42.0/24 12.15.43.0/24 12.15.46.0/24 12.15.47.0/24 12.15.58.0/24
Re: a fun hijack: 1/8, 2/8, 3/8, 4/8, 5/8, 7/8, 8/8, 12/8 briefly announced by AS 23520 (today)
here's a list of the prefixes that we saw them originate yesterday that were not originated two days ago. the average amount of time a peer of renesys's saw those prefixes routed was about 80 seconds. 1.0.0.0/8 the picture from route-views looks more like http://rip.psg.com/~randy/1.0.0.0.jpg randy
sorbs.net contact?
I see from the archive that there is someone on this list who is a contact for sorbs.net. Please contact me offline as soon as possible. No, forty eight hours isn't going to cut it. Thanks :-) -- mailto:[EMAIL PROTECTED] // IM:layer3arts voice: 402 408 5951 cell : 402 301 9555 fax : 402 408 6902
Re: a fun hijack: 1/8, 2/8, 3/8, 4/8, 5/8, 7/8, 8/8, 12/8 briefly announced by AS 23520 (today)
It may not matter a lot, but a number of those prefixes are marked Reserved to IANA. Nobody should be advertising them. Which is worse - the ones nobody should be advertising or the ones somebody else should be advertising? That depends partly on the why. -- Joe Yao --- This message is not an official statement of OSIS Center policies.
Re: a fun hijack: 1/8, 2/8, 3/8, 4/8, 5/8, 7/8, 8/8, 12/8 briefly announced by AS 23520 (today)
Todd Underwood wrote: josh, all, these are always fun. these events continue to be a problem for all of us. Check out the IAR for Potential Prefix Hijacks and if you're coming to this more than 24 hours after the post, do a search on AS 23520 as the hijacking AS. here are some other details that we saw about this event. - as of two days ago 23520 only originated 26 prefixes - yesterday they originated 2821 prefixes. this event was about a lot more than a few /8s. - we still see them originating 140 prefixes, as of this afternoon (EDT). here's a list of the prefixes that we saw them originate yesterday that were not originated two days ago. the average amount of time a peer of renesys's saw those prefixes routed was about 80 seconds. This is what/when we saw, the middle column is how long we observed the route (HH:MM:SS) before it was withdrawn. if anyone wants a csv dump of the raw data drop me a note off-list. -rick +--+---+-+ | prefix | elapsed | announced | +--+---+-+ | 63.245.0.0/17| 34:06:08 | 2005-08-17 10:41:18 | | 63.245.0.0/17| 69:49:31 | 2005-08-23 23:01:32 | | 63.245.0.0/17| 03:41:18 | 2005-08-26 20:52:52 | | 63.245.1.0/24| 34:06:10 | 2005-08-17 10:41:16 | | 63.245.1.0/24| 69:49:25 | 2005-08-23 23:01:38 | | 63.245.1.0/24| 03:41:17 | 2005-08-26 20:52:53 | | 63.245.2.0/24| 34:06:10 | 2005-08-17 10:41:16 | | 63.245.2.0/24| 69:49:25 | 2005-08-23 23:01:38 | | 63.245.2.0/24| 03:41:17 | 2005-08-26 20:52:53 | | 63.245.7.0/24| 34:06:10 | 2005-08-17 10:41:16 | | 63.245.7.0/24| 69:49:25 | 2005-08-23 23:01:38 | | 63.245.7.0/24| 03:41:17 | 2005-08-26 20:52:53 | | 63.245.30.0/23 | 33:59:39 | 2005-07-07 14:47:34 | | 63.245.30.0/23 | 00:52:30 | 2005-07-09 01:22:23 | | 63.245.30.0/23 | 00:52:49 | 2005-07-09 02:45:11 | | 63.245.30.0/23 | 00:00:29 | 2005-07-09 04:53:35 | | 63.245.30.0/23 | 17:31:39 | 2005-07-09 05:45:11 | | 63.245.30.0/23 | 02:52:10 | 2005-07-10 00:16:46 | | 63.245.30.0/23 | 24:11:12 | 2005-07-10 04:33:23 | | 63.245.30.0/23 | 42:52:31 | 2005-07-25 16:13:55 | | 63.245.30.0/23 | 159:21:36 | 2005-07-28 00:35:48 | | 63.245.30.0/23 | 03:20:50 | 2005-08-04 18:00:08 | | 63.245.30.0/23 | 34:06:10 | 2005-08-17 10:41:16 | | 63.245.30.0/23 | 48:55:07 | 2005-08-18 20:48:22 | | 63.245.30.0/23 | 34:19:50 | 2005-08-23 23:01:38 | | 63.245.30.0/23 | 56:19:24 | 2005-08-25 10:21:32 | | 63.245.30.0/23 | 85:35:18 | 2005-08-27 19:57:29 | | 63.245.30.0/23 | 00:07:38 | 2005-10-18 23:26:11 | | 63.245.32.0/21 | 13:20:11 | 2005-07-25 16:13:50 | | 63.245.46.0/23 | 33:59:41 | 2005-07-07 14:47:32 | | 63.245.46.0/23 | 02:11:56 | 2005-07-09 01:47:45 | | 63.245.46.0/23 | 00:15:43 | 2005-07-09 04:38:48 | | 63.245.46.0/23 | 21:29:00 | 2005-07-09 05:39:56 | | 63.245.46.0/23 | 23:12:13 | 2005-07-10 04:44:19 | | 63.245.46.0/23 | 00:00:30 | 2005-07-11 05:46:09 | | 63.245.46.0/23 | 39:24:30 | 2005-07-25 16:13:54 | | 63.245.46.0/23 | 02:58:40 | 2005-07-27 08:08:41 | | 63.245.46.0/23 | 76:59:42 | 2005-07-28 00:35:47 | | 63.245.46.0/23 | 61:11:01 | 2005-07-31 06:35:37 | | 63.245.46.0/23 | 04:42:10 | 2005-08-04 18:00:08 | | 63.245.46.0/23 | 07:12:53 | 2005-08-04 23:08:36 | | 63.245.46.0/23 | 34:06:12 | 2005-08-17 10:41:14 | | 63.245.46.0/23 | 48:47:07 | 2005-08-18 20:48:22 | | 63.245.46.0/23 | 08:56:24 | 2005-08-20 22:40:29 | | 63.245.46.0/23 | 69:49:26 | 2005-08-23 23:01:37 | | 63.245.46.0/23 | 03:41:18 | 2005-08-26 20:52:52 | | 63.245.46.0/23 | 18:06:19 | 2005-08-27 00:34:37 | | 63.245.46.0/23 | 85:51:37 | 2005-08-27 19:41:10 | | 63.245.104.0/21 | 13:20:11 | 2005-07-25 16:13:50 | | 64.86.178.0/23 | 05:04:05 | 2005-06-30 11:04:59 | | 64.86.178.0/23 | 16:56:40 | 2005-07-04 15:39:30 | | 64.86.178.0/23 | 02:26:38 | 2005-07-05 09:33:20 | | 64.86.178.0/23 | 03:05:53 | 2005-07-05 12:41:03 | | 64.86.178.0/23 | 00:56:06 | 2005-07-05 16:47:32 | | 64.86.178.0/23 | 00:57:06 | 2005-07-05 18:17:36 | | 64.86.178.0/23 | 02:47:55 | 2005-07-05 21:38:13 | | 64.86.178.0/23 | 02:07:35 | 2005-07-20 12:27:48 | | 64.86.178.0/23 | 19:29:23 | 2005-07-28 00:35:47 | | 64.86.178.0/23 | 15:49:49 | 2005-08-04 18:00:08 | | 64.86.178.0/23 | 34:06:12 | 2005-08-17 10:41:14 | | 64.86.178.0/23 | 69:49:26 | 2005-08-23 23:01:37 | | 64.86.178.0/23 | 03:41:18 | 2005-08-26 20:52:52 | | 65.217.50.0/24 | 05:04:05 | 2005-06-30 11:04:59 | | 65.217.50.0/24 | 16:56:40 | 2005-07-04 15:39:30 | | 65.217.50.0/24 | 02:26:38 | 2005-07-05 09:33:20 | | 65.217.50.0/24 | 03:05:53 | 2005-07-05 12:41:03 | | 65.217.50.0/24 | 00:56:06 | 2005-07-05 16:47:32 | | 65.217.50.0/24 | 00:57:06 | 2005-07-05 18:17:36 | | 65.217.50.0/24 | 02:47:55 | 2005-07-05 21:38:13 | | 65.217.50.0/24 | 02:07:35 | 2005-07-20 12:27:48 | | 65.217.50.0/24 |
Screwed Again: House Rejects Net Neutrality
Sorry to interrupt the ever-so-interesting discussions on the list, but this is actually important. Sorry for the editorial comment -- now for the facts. Declan McCullagh, via C|Net News: [snip] The U.S. House of Representatives definitively rejected the concept of Net neutrality on Thursday, dealing a bitter blow to Internet companies like Amazon.com, eBay and Google that had engaged in a last-minute lobbying campaign to support it. By a 152-269 vote that fell largely along party lines, the House Republican leadership mustered enough votes to reject a Democrat-backed amendment that would have enshrined stiff Net neutrality regulations into federal law and prevented broadband providers from treating some Internet sites differently from others. Of the 421 House members who participated in the vote that took place around 6:30 p.m. PT, the vast majority of Net neutrality supporters were Democrats. Republicans represented most of the opposition. The vote on the amendment came after nearly a full day of debate on the topic, which prominent Democrats predicted would come to represent a turning point in the history of the Internet. [snip] More here: http://news.com.com/2100-1028_3-6081882.html - ferg -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://fergdawg.blogspot.com/
2006.06.06 NANOG-NOTES MPLS TE tutorial
(still here, just been really busy at work today; will try to finish sending the notes out tonight. --Matt) 2006.06.06 MPLS TE tutorial Pete Templin, Nextlink [slides are at: http://www.nanog.org/mtg-0606/pdf/pete-templin.pdf http://www.nanog.org/mtg-0606/pdf/pete-templin-exercise.pdf He works in a Cisco shop, no JunOs experience Operator perspective, no logos Traffic engineering before MPLS --the fish problem. two parallel paths, one entry router, one exit router, you end up with all traffic taking one path, not using the other path. IGP metric adjustments can lead to routing loops hard to split traffic No redundancy left over if both paths filled, but can be good for using 2 out of 3 paths. MPLS TE fundamentals Packets are forwarded based on FIB or LFIB FIB/LFIBS built based on RIB TE tunnels; TE tunnel interface is a unidirectional logical link from one router to another. Once the tunnel is configured, a label is assigned for the tunnel that corresponds to the path through the MPLS network (LSP) TE tunnel basics Once traffic is routed onto the tunnel, the traffic flows through the tunnel based on the path. Return traffic could be placed onto a tunnel going the opposite direction, or simply routed by IGP Key terms for TE Headend router on which the tunnel is configured Tail destination address of tunnel Midpoint router(s) along the path along the tunnel LSP Basic TE config Global: mpls traffic-eng tunnels IGP: must be OSPF or IS-IS mpls traffic-eng rouer-id Loopback0 mpls traffic-eng area X | level2 physical interfaces mpls ip mpls traffic-eng tunnels tells IGP to share TE info with other TE nodes interface TunnelX ip unnumbered loopback0 borrow the loopbak's address so we can forward traffic down the tunnel tunnel mode mpls traffic-eng tunnel destination a.b.c.d tunnel tail tunnel mpls traffic-eng path-option 10 dynamic find a dynamic path through network best path with sufficient bandwidth will discuss path selection in a bit Where are we at? Tunnels go from headend to tail end through midpoint routers over a deterministic path we know what commands go on a router for the global physical interface tunnel interface commands TE and bandwidth Physical interfaces can be told how much bandwidth can be reserved (used) ip rsvp bandwidth X X TE tunenls can be configured with how much bandwidth they need: tun mpls traff bandw Y Tunnels will reserve Y bw on outbound interfaces, and find a path across the network wth X(unused)Y BW. This prevents oversubscription, or at least helps control it. You can allow for burst room, but for now we'll stick with static, non-oversubscribed links. TE BW operators can adjust the tunnel bandwidth values over time to match changes in traffic. If tunnels are dynamically placed, the tunnels will dynamically find a path through the network with sufficient bandwidth, or will go down. TE auto-bandwidth magic Tunnels can be configured to watch their actual traffic as in shw int blah| inc rate every five minutes, and update their reservation to match, at periodic intervals. Dynamic reservations to match the live network Bandwidth is 'reserved' using RSVP but not saved for TE Often buys enough time to identify the surge, see where the traffic is coming/going. The number is only a number in control plane; no actual impact on data plane, no shaping, no control on real data flows. tunnel mpls traffic-eng auto-bw frequency Y each auto-bw tunnel does sh int to capture its rate every 300* seconds each auto-bw tunnel updates tunn mpls traff bandwidth X every Y seconds The config actually changes; this will impact your RANCID tracking. It uses highest measured rate during the interval Y May want to tweak your load-interval, since it's a decaying function over time; 5 minute is a fairly smooth value. May need to tweak config check-in system to avoid getting flooded with bandwidth adjustments. Covered: TE tunnel basics router config basics general concepts about TE and bandwidth In this case, the shortest path that has X BW available for reservation actually, bw X at or below priority Y, but that's later. SPF calculations step 0: create a PATH list and a TENT list step 1: put self on PATH list. step 2: step 3: put PATH nodes' neighbors on TENT list step 4: if TENT list is empty, stop. step 5: jump back to step 2: Example exercise -- calculate router A's best path to router D using the handout. CSPF notes No load sharing is performed within a tunnel; as soon as a path is found, it wins CSPF tiebreakers: lowest IGP cost largest minimum available bandwidth lowest hop count top node on the PATH list Creating paths -- can be created dynamically, or statically via static paths. Dynamic: tunnel mpls traff path-option X dynamic Explicit paths paths can be crated manually by explicitly creating a path ip explicit-path name name? next-address X next-address Y tunnel mpls traff path-option X explicit name blah Paths can be created manually by
2006.06.06 Net Optics Learning Center Presents Passive Monitoring Access
(apologies, this really was just a marketing presentation in very, very thin disguise. I really want that hour of my life back. :( --Matt ) 2006.06.06 Net Optics Learning Center Presents The fundamentals of Passive Monitoring Access [slides are at: http://www.nanog.org/mtg-0606/pdf/joy-weber.pdf TAP technology--tools change, but some things stay somewhat constant--need a way to collect information. Port contention for monitoring--how many people are running into these issues? How many people use SPAN ports to get access to information? Agenda: Present an overview of Tap technology and how it makes network monitoring and security devices more effective and efficient. tap technology overview taps, port aggregators, and regen taps active response, bypass switches link aggregators and matrix switches taps with intelligence Add more intelligence, SNMP capability into remote tap systems. passive monitoring access--you should have full access to 100% of the packet data; even errors, etc. at layer 1 and layer 2. passive means without affecting traffic no latency no IP addresses no packets added, dropped, or manipulated No link failure traffic can be collected via: hubs optical taps What is zero delay? eliminates delays caused by the 10msec delay found in most taps when the tap loses power. Zero Delay means if the tap loses power no packets dropped/resent no latency introduced power loss to tap undetectable in the network Hubs are cheap and easy, get most of the info you need. The more utilization, the higher the collision rate means you're not getting all the data you need. Placing devices in-line; you get full visibility, but requires impact when you need to move monitoring tool from one place to another, or work on the tool. advantage: see all traffic including layer 1 and 2 errs preserve full duplex links SPAN ports--gain access to data, internal to a switch; good for data internal to switch fabric. But you lose layer1 and layer2 errs; not so bad for security tools, but for network debugging, horrible. Only supports seeing data flowing through a single switch. fights over who gets access to the port for tools. Test Access Ports (TAP) designed to duplicate traffic for monitoring devices. You put it inline once, it's inline, passive. preserves full duplex links, device neutral, can be installed between any 2 devices. remains passive no failure point introduced fiber taps don't even require power. always need to fail through, no interruption. creates a permanent access port to the data stream. copper and fiber handled differently; copper has a retransmit system to replicate the information; fiber, just splits photon streams. Two output ports, only transmitting data; no way to send data back through. No way to introduce errors. Different types: single tap: duplicates link traffic for a monitoring device regeneration tap: duplicates link traffic for multiple monitoring devices link aggregator tap: combines traffic from multiple links matrix switches: offer software-control access to multiple links other tap options: built-in media conversion--use mismatched interfaces without separate media converter active response--inject responses back into the link. converter taps serve two purposes--connect dissimilar interfaces without media converter. but usually don't fail through cleanly. Active response is generally in the security arena. sends back to both sides. Copper tap devices 10/100baseT 10/100/1000baseT triple speed 1000baseT normal gig tap Need TWO monitoring NICs to see full duplex data, since you get TWO TX links coming at you. Try to get triple speed TAP with dip switch speed/flow setting, rather than trying to autosense. Fiber taps gigabit SX/LX/SZ, 10gig SR/LR/ER (multimode and single mode) still has 2 TX outputs. topology, and split ratio split ratio is amount of light going to each port. split ratio--amount of light you're willing to tolerate giving up on the network port. Basically, work up a Loss Power budget for the link, figure out how much you can afford to lose before you lose link. Need to make sure that there will be no impact for either end! Do you take distance between the monitoring device and the tap output device? Yes, try to keep within the reduced power budget available off the monitor port, usually about 10 meters should be fine. Can you re-use optical taps for OC12 ATM as well as gigE or 10gigE? will be specific for multimode vs single mode, if you stay at 50/50, generally not a problem. Converter taps are generally powered. the primary path is passive, but the monitoring port has to be active to support the media conversion. Port aggregator taps full duplex link being tapped, aggregating out a single link so you don't need 2 NICs to capture the TX data. can also make a port a full duplex, 2 way active/passive port in newer models. what about multiple output ports? allow passive access for multiple monitoring devices to a single
